1. 20
  1.  

  2. 7

    M1 … seems to be the first case of an ARMv8 SoC that removes the 32-bit execution unit from the CPU.

    thunderxx, qualcomm centriq also dropped 32-bit compatibility.

    1. 3

      Cortex-A65(AE), Cortex-A34 too.

    2. 7

      My personal opinion is that support for ARMv6+VFPv2 should be maintained in distributions like Debian and Fedora.

      My personal opinion is exactly the opposite. Raspberry Pi users are imposing unreasonable burden on ARM distribution maintainers. For better or worse, the entire ecosystem standardized on ARMv7 except Raspberry Pi. The correct answer is to stop buying Raspberry Pi.

      1. 3

        I faced this issue directly, being as I was a distribution developer working on ARM at the time. I feel your pain.

        However, they made the choices they made for cost reasons, and the market has spoken. I can’t argue with that.

        1. 2

          It could be worse. At least the Pi is ARMv7TDMI. Most AArch32 software defaults to Thumb-2 now and the Pi is just new enough to support it. I maintain some Arm assembly code that has two variations, ARMv6T2 and newer, everything else. I can probably throw away the older ones now, they were added because an ultra low-budget handset maker shipped ARMv5 Android devices and got a huge market share in India or China about 10 years ago and a user of my library really, really cared about those users.

          1. 1

            shipped ARMv5 Android devices and got a huge market share in India or China

            Interesting, do you know which phone models? The oldest Android phones I could find are ARMv6.

            1. 1

              No idea, sorry. I never saw them, I just got the bug reports. Apparently they’re all gone (broken / unsupported) now. It was always a configuration that Google said was unsupported, but one handset manufacturer had a custom AOSP port that broke the rules (I think they also had their own app store).

          2. 2

            I also agree wiťh you that the correct answer is to stop buying Raspberry Pi, especially their ARMv6 products. But for most beginners in electronics, it seems like “Raspberry Pi” equals “single board computer”. They aren’t going to stop buying them.

            I don’t love MIPS64 or i686 either, but the reality is that the hardware exists and continues to be used. Maintainers should deal with that, IMHO.

            1. 3

              I am just tired of getting issues like https://github.com/rust-embedded/cross/issues/426. This is just a tiny corner. What a horror this is being replicated 100x for every toolchain out there.

          3. 6

            big endian does not exist for ARMv7

            That’s wrong, it’s switchable at runtime via the SETEND instruction on 32-bit Arm. (including from user-space!)

            The target triplet for 32-bit Arm (big endian) with hardware floating point is armeb-linux-gnueabihf.

            1. 1

              Thanks, I did not know that! Added it to the article, including the things you mentioned in your other comment.

            2. 4

              Regarding other systems, if the ARM arhictecure version is supported by a particular distribution, that doens’t mean the SoC and peripherals are supported. Both need to have support in the mainline kernel, otherwise the only choice is a vendor fork of the kernel.

              The other option is to find patches that forward port support to mainline. I’ve did this a while on my old ARM NAS for a while.

              1. 1

                For sure but that model is hardly sustainable for most users, even highly technical ones.

              2. 2

                Regarding other systems, if the ARM arhictecure version is supported by a particular distribution, that doens’t mean the SoC and peripherals are supported. Both need to have support in the mainline kernel, otherwise the only choice is a vendor fork of the kernel.

                This is quickly changing in the AArch64 world, thanks to the work on things like SystemReady, which is standardizing ARM firmware and makes it possible to boot generic kernels who are not aware of the underlying hardware at build time. The future for ARM seems exciting, but for current hardware the support isn’t great in a lot of cases.

                I hadn’t heard about SystemReady, only ServerReady. This is great news as having this kind of standardized interface is the only way IMO that ARM platforms will ever really prosper in the open source ecosystem.

                I’ve owned a Pinebook Pro now for several months, and I’ve chatted with quite a number of very smart people valiantly fighting to squeeze time out of their lives to do important work like firmware maintenance, driver support etc.

                Simple things like going to sleep when the lid is closed don’t work a lot of the time (even if you weren’t the victim of the bad manufacturing glitch that mis-positioned the lid magnet) and lots of applications that depend on accelerated driver support simply won’t work.

                The Pinebook Pro and its ilk are noble experiments at the crest of the wave for widespread AARCH64 support, and I’m happy to have dipped my toe in, but my time with this machine has convinced me that it’s going to be a losing battle until standardized interfaces make support a whole lot easier.

                1. 2

                  I’d like to buy an M1 Mac for the better battery life and thermals, but I have to run a lot of Linux VMs for my job, so it’s a nonstarter.

                  If VirtualBox or VMWare or whatever adds support for M1 Macs to run ARM VMs and I could run CentOS in a virtual machine with reasonable performance, it would definitely affect my decision.

                  (Note that I’d still have to think about it since the software we ship only ships for x86_64, so it would be…yeah, it would probably still be a nonstarter, sadly.)

                  1. 4

                    Parallels runs well, at least for Windows. I’ve heard the UI for adding Linux VMs is picky, but they’ll work fine too.

                    Much of the work around HVF/Virtualization.framework is to make Linux stuff drop-dead easy.

                    1. 3

                      And Qemu is a good option for those too, with picking the patchset from the mailing list for using HVF.

                      VMWare Fusion support is coming, VirtualBox will not be supported according to Oracle.

                    2. 3

                      I do have Parallels running Debian (10, arm64) on an M1. It was a bit weird getting it setup, but it works pretty well now, and certainly well enough for my needs.

                      1. 2

                        There’s a Parallels preview for M1 that works: https://my.parallels.com/desktop/beta

                        It has VM Tools for ARM64 Windows, but not Linux (yet).

                        In my opinion Linux is a better experience under QEMU w/ the patches for Apple Silicon support (see https://gist.github.com/niw/e4313b9c14e968764a52375da41b4278#file-readme-md). I personally have it set up a bit differently (no video output, just serial) and I use X11 forwarding for graphical stuff. See here: https://twitter.com/larbawb/status/1345600849523957762

                        Apple’s XQuartz.app isn’t a universal binary yet so you’re probably going to want to grab xorg-server from MacPorts if you go the route I did.

                        1. 1

                          Genuine question, why not just have a separate system to run the vm’s? That keeps the battery life nice at the expense of requiring network connectivity but outside of “on an airplane” use cases its not a huge issue i find.

                        2. 0

                          not specifically on topic, but

                          It seems that for developers planning to use Microsoft’s Net 5.0 SDK – Linux ARM will be the only option (till Net 6.0 release) [1] I am sure that will be the case for few other platforms/language runtimes.

                          [1] https://medium.com/swlh/discover-net-5-13718fd7a99c