Announcement

Collapse
No announcement yet.

Linux 6.2 Picking Up Mainline Support For Apple M1 Pro/Max/Ultra Hardware

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux 6.2 Picking Up Mainline Support For Apple M1 Pro/Max/Ultra Hardware

    Phoronix: Linux 6.2 Picking Up Mainline Support For Apple M1 Pro/Max/Ultra Hardware

    While Asahi Linux has been running on the higher-end Apple M1 SoC variants and those Macs utilizing them, with the mainline Linux 6.2 kernel will finally be the upstreaming of the Apple M1 Pro/Max/Ultra support with the various device trees set to be added...

    https://www.phoronix.com/news/Linux-...-Pro-Max-Ultra

  • #2
    Um, doesn't Ubuntu run perfectly fine on ARM as well?

    Comment


    • #3
      Originally posted by caligula View Post
      Um, doesn't Ubuntu run perfectly fine on ARM as well?
      The Linux kernel is over 80% hacks for the bits of custom hardware that go into every computer. The architecture​ is a non-issue. Look at the wiki link.

      Comment


      • #4
        Every Arm device is different. Sure, the CPU's instruction set architecture is the same, but there is a lot more than that to a complete computer platform.

        The userspace is compatible. All your debian / arch / whatever packages should run fine on all Arm hardware, incl. the new Macs, but the kernel needs a lot of work to support the hardware properly.

        Apple in particular, likes to ... uhm ... Think Different™. This hardware platform has quite a lot of differences compared to other Arm devices. The CPU's interrupt controller, power management, PCIe subsystem, and many other aspects of the hardware, are non-standard.

        Right now, Asahi Linux has the special Linux kernel and firmware and anything else that needs special support. If you want the best support for Apple hardware and you want to run Ubuntu or whatever, you would have to take Asahi's kernel and stuff, to replace Ubuntu's. However, Asahi are gradually working on upstreaming everything, so that eventually everything will just work out of the box on any distro.

        Comment


        • #5
          Can't wait for object c and appletalk network protocol.

          Comment


          • #6
            elatllat tajjada Those are the very things that really led me to disappointment about ARMv8, since I thought it was supposed to fix those issues. It's one thing to need a custom kernel to get some obscure device or GPU to work but it's been pretty annoying having to still use whole custom disk images, whether for chips commonly found in a variety of SBCs or in platforms that allow you to choose what device to boot from.

            I've pretty much limited my ARM use to servers and robots since usually all I need is USB and networking support, but even then, it's often pretty tedious work compared to being able to just load whatever OS I want.

            Comment


            • #7
              Originally posted by schmidtbag View Post
              elatllat tajjada Those are the very things that really led me to disappointment about ARMv8, since I thought it was supposed to fix those issues. It's one thing to need a custom kernel to get some obscure device or GPU to work but it's been pretty annoying having to still use whole custom disk images, whether for chips commonly found in a variety of SBCs or in platforms that allow you to choose what device to boot from.

              I've pretty much limited my ARM use to servers and robots since usually all I need is USB and networking support, but even then, it's often pretty tedious work compared to being able to just load whatever OS I want.
              I think the problem is you thought an instruction set fixes you can run an OS of your choice on a device. ISA is to run software on the CPU (which works, you run pre-compiled binaries from the Ubuntu repository on Apple M1/M2), not to boot up the device. Also, how is ARMv8 related to a GPU and other non-CPU parts of the device system? E.g. we had ARM GPU in Intel x86 (some Atoms) and we have "x86 GPU" in ARM SoC (AMD RDNA in Exynos and later maybe NVidia in MediaTek). PS: In the server area, ARMs are the same compatible as x86 - a shared EFI BIOS. But obviously nobody cares in the consumer market.
              Last edited by Ladis; 29 October 2022, 11:14 AM.

              Comment


              • #8
                Originally posted by Ladis View Post
                I think the problem is you thought an instruction set fixes you can run an OS of your choice on a device. ISA is to run software on the CPU (which works, you run pre-compiled binaries from the Ubuntu repository on Apple M1/M2), not to boot up the device.
                No actually, I didn't. I'm not really sure why you're explaining all this as if I didn't know any of that, seeing as it should have been made apparent that I have worked with ARM devices, including ARMv8. Before ARMv8 was released, I recall reading about how there was an effort to make systems more compatible with generic images. As far as I understand, the ISA has nothing to do with that. ARM has never had a BIOS, which is one of the fundamental reasons ARM devices have needed custom disk images (more on that later). ARMv8 was not planned to change this, which for the most part still holds true. So, that's why there was discussion of trying to standardize things in a way where you could at the very least boot up a generic kernel and still get a fairly usable system. The problem is trying to get all licensees to agree to comply, which as we see today, did not happen.
                Regardless of everything I said, one way where ARMv8's ISA does actually help with using generic images is the fact it has [more?] virtualization instructions. This makes a big difference.
                Also, how is ARMv8 related to a GPU and other non-CPU parts of the device system? E.g. we had ARM GPU in Intel x86 (some Atoms) and we have "x86 GPU" in ARM SoC (AMD RDNA in Exynos and later maybe NVidia in MediaTek). PS: In the server area, ARMs are the same compatible as x86 - a shared EFI BIOS. But obviously nobody cares in the consumer market.
                If you understood what I was initially talking about, you wouldn't have to ask that question. In short: the OS you run on an ARM system has to be told explicitly the details about what device is connected and how. You can't just simply install GPUs drivers and "poof" they work. Even when you're using SBCs of the exact same chip, you may have devices that don't work using the same disk image because the boards might be set up slightly differently. This is the kind of stuff that really cripples the success of ARM for PC use. This is also why Android uses VMs, because it's much faster and easier to get a barebones OS just set up for hardware functionality that you [arguably] never need to maintain, and then use a generic image for VMs. ARM servers are mostly immune to ARM's shortcomings for a variety of reasons.
                Last edited by schmidtbag; 30 October 2022, 01:56 PM.

                Comment


                • #9
                  Originally posted by schmidtbag View Post
                  ...
                  Eh? You just told the same. Anyway, the success of ARM for PC doesn't depend on a universal booting - majority of devices will be OEM. Like all already existing ARM PCs. And ARM servers are immune, thanks to Microsoft and AMD, who standardized the EFI BIOS and lowlevel details.

                  Comment


                  • #10
                    Originally posted by Ladis View Post
                    Anyway, the success of ARM for PC doesn't depend on a universal booting
                    ARM hasn't penetrated the desktop market for this reason. You can't just install whatever generic OS you want and it'll work perfectly. This is why I can download Debian ARM64 and install it into nearly any x86 PC while I can't just use any Debian based on ARM and install it on Apple M1 and Raspberry Pi.
                    - majority of devices will be OEM. Like all already existing ARM PCs.
                    I just love installing LineageOS onto my Android phone and watching as the bluetooth device will crash the phone when connected to two devices. Every Android device needs its own custom made version of an OS, which is usually done by someone in Russia living in his moms basement. Nothing is truly stable for this reason.
                    And ARM servers are immune, thanks to Microsoft and AMD, who standardized the EFI BIOS and lowlevel details.
                    They're immune because nobody running a ARM server is going to use a generic copy of a Linux OS. It's all custom made.
                    Last edited by Dukenukemx; 30 October 2022, 06:10 PM.

                    Comment

                    Working...
                    X