Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Initial M1 support merged into Linux SoC tree

git.kernel.org

Post reply on HN
Print view View original

311–320 of 337 posts

Re: Initial M1 support merged into Linux SoC tree

#311

Post by jcelerier »

mjg59 wrote: post #297
jcelerier wrote: post #196

Earlier quoted context omitted.

most features of my laptop don't work reliably (MSI GS65) if I don't use the acpi_osi line, why would that be in that case ? I'm on archlinux with pretty much always the latest kernel

What argument are you providing? In some cases if you pretend to be an older version of Windows then things will work better, since it's possible for the kernel to end up pretending to be a new version of Windows without all the relevant semantic changes in the drivers having been made.

No, I have to set it to the latest version (I think? I have acpi_osi="Windows 2019") for things to work correctly

Re: Initial M1 support merged into Linux SoC tree

#312

Post by manmal »

darekkay wrote: post #264
rvz wrote: post #152

Earlier quoted context omitted.

Last time I checked, the Android Emulator running on Apple Silicon still has issues and isn't functionally as good as running it on an Intel Mac. There is no point in getting the M1 Macbook (which is last year's model) since they will either announce a M1X or even a M2 Macbook this year which will most certainly be more performant and optimised than the last generation. One of the several reasons why I stayed away fr…

> There is no point in getting the M1 Macbook since they will either announce a M1X or even a M2 Macbook this year I've been hearing something similar when I got a PS4 in summer 2019. PS5 is still barely available, and I've had almost 2 years of gaming fun. To be fair, the PS4 didn't have as many rough edges back then. But "no point" is a generalization that isn't true for many people.

It’s safe to assume that Apple won’t let the MB Air cannibalize its MB Pro Intel sales for that much longer.

Re: Initial M1 support merged into Linux SoC tree

#314

Post by ndesaulniers »

refulgentis wrote: post #308
shawnz wrote: post #306

Earlier quoted context omitted.

I think the parent poster is saying that LLD needs to take a different approach, not Zig. But it wasn't previously known what approach that would need to be, since M1 does it differently than other ARM CPUs. Therefore there's no expectation that LLD could have gotten it right.

LLVM/Clang were essentially born and stewarded by Apple, it's somewhat odd, to say the least, that they didn't patch LLD on day 1 with the Xcode release that supports M1.

This assumes that LLD has been around much longer than it has.

Apple first sponsored development of LLVM, before clang or LLD existed. Then they sponsored clang development.

LLD came much later. I believe Rui created LLD at Google with an intention of linking Chrome on Windows. That was a very different use case than what Apple had in mind.

Eventually LLD abstracted the target object file, could link ELF executables, and had a good design for furthering support for mach-o. Facebook is developing that in LLD surely to support linking their iOS app much faster. Apple remains disinterested from what I can tell.

Re: Initial M1 support merged into Linux SoC tree

#315

Post by duskwuff »

aulin wrote: post #260
LeonM wrote: post #122

Why does this merge also delete all sorts of (seemingly) unrelated files? Like the 'rocket' and 'Cyclades' drivers in this case.

most probably the m1 stuff introduced some conflict in some dead and unmaintained driver and it was better to ditch them than work on a fix

Actually, it looks as those changes were unrelated! They were merged in from the tty/tty-next tree, which included some changes required to get the M1 UART working.

Here are the original commits:

https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/...

https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/...

Re: Initial M1 support merged into Linux SoC tree

#316

Post by in9 »

ndesaulniers wrote: post #309
marcan_42 wrote: post #117

Hi HN! I wrote an article about this initial support series and what it took to make things work properly on this machine: https://asahilinux.org/2021/03/progress-report-january-febru... It still applies to what got merged; the past month was spent on clean-ups, fixes, and review feedback, but there are no major changes to the approach. This initial merge was quite complex as it has to touch a number of subsystems an…

Thank you so much for the work put in to documentation; written in kernel or blogged, and streamed. I've watched hours of your streams. I've been working on a bootloader and porting Linux to the Nintendo 3DS; I don't really know what I'm doing, but your streams clarified many questions I had about porting Linux to a new device.

This is so awesome dude! Please let us know where we can find more about your project :D

Re: Initial M1 support merged into Linux SoC tree

#317

Post by solarkraft »

chociej wrote: post #289

For the many of you mentioning poor Linux support on the T2 macbooks, check out t2linux.org. They're doing good work but I'm sure could use some help. I too would love an MBP than could run Linux well.

Not to be confused with René Rebe's "T2 Linux" (http://t2sde.org/).

Re: Initial M1 support merged into Linux SoC tree

#318

Post by refulgentis »

ndesaulniers wrote: post #314
refulgentis wrote: post #308

Earlier quoted context omitted.

LLVM/Clang were essentially born and stewarded by Apple, it's somewhat odd, to say the least, that they didn't patch LLD on day 1 with the Xcode release that supports M1.

This assumes that LLD has been around much longer than it has. Apple first sponsored development of LLVM, before clang or LLD existed. Then they sponsored clang development. LLD came much later. I believe Rui created LLD at Google with an intention of linking Chrome on Windows. That was a very different use case than what Apple had in mind. Eventually LLD abstracted the target object file, could link ELF executables,…

thank you, learned a lot :) (I had assumed lld came with the llvm/clang switchover back in...ios 5?)

Re: Initial M1 support merged into Linux SoC tree

#319

Post by comex »

ndesaulniers wrote: post #307
comex wrote: post #303

Earlier quoted context omitted.

Well, in theory , Zig doesn't need to care about the specific approach. In the LLVM IR that Zig produces, thread-local variables are still handled as an abstract "thread_local" flag on global variables. The platform-specific parts are handled by a combination of the IR-to-native-object-file translation done by LLVM, and the linking step. If both of those worked correctly, thread locals would "just work" on M1. The pr…

> LLD is buggy. While certainly not bug free, you may be overstating things. > once Apple whips LLD into shape Pretty sure it's engineers at Facebook contributing mach-o fixes to LLD, not Apple. Apple is happy with their linker ld64.

> Pretty sure it's engineers at Facebook contributing mach-o fixes to LLD, not Apple. Apple is happy with their linker ld64.

Ah, sure enough. My mistake.

Re: Initial M1 support merged into Linux SoC tree

#320

Post by mjg59 »

jcelerier wrote: post #311
mjg59 wrote: post #297

Earlier quoted context omitted.

What argument are you providing? In some cases if you pretend to be an older version of Windows then things will work better, since it's possible for the kernel to end up pretending to be a new version of Windows without all the relevant semantic changes in the drivers having been made.

No, I have to set it to the latest version (I think? I have acpi_osi="Windows 2019") for things to work correctly

Which kernel version are you running? That string was added in 5.4.
Post reply on HN