Arm Begins Adding ARMv8.7-A Support In LLVM Clang 12

[Jumbotron]

The age of ARM will only truly be here when there's a standard 'PC platform' for laptops and desktops on ARM, like how ACPI + UEFI makes up this universal generic platform for x64 hardware. I have no frigging wish to see something like this:

1. Windows 10 / Vendor-cutomized Linux kernel for ARM64 for Qualcomm Snapdragon 6xx SoCs
2. Windows 10 / Vendor-cutomized Linux kernel for ARM64 for Qualcomm Snapdragon 7xx SoCs
3. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Qualcomm Snapdragon 8xx SoCs
4. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Qualcomm Snapdragon 9xx SoCs
5. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Microsoft SQ1 SoCs
6. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Microsoft SQ2 SoCs
7. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Samsung Exynos 75XX SoCs
8. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Samsung Exynos 78XX SoCs
9. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Samsung Exynos 79XX SoCs
10. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Samsung Exynos 96XX SoCs
11. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Samsung Exynos 8XX SoCs
12. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Samsung Exynos 7-series SoCs
13. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Samsung Exynos 88XX SoCs
14. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Samsung Exynos 98XX SoCs
15. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Samsung Exynos 9XX SoCs
16. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Samsung Exynos 10XX SoCs
17. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for NVidia Tegra X1 SoCs
18. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for NVidia Tegra X2 SoCs
19. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for NVidia Tegra Xavier SoCs
20. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for NVidia Tegra Orin SoCsSim
21. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for AllWinner A6X SoCs
22. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for AllWinner A7X SoCs
23. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for AllWinner A8X SoCs
24. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for AllWinner A10X SoCs
25. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for AllWinner A20X SoCs
26. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for AllWinner A30X SoCs
27. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Mediatek MT673X SoCs
28. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Mediatek MT675X SoCs
29. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Mediatek Helio X SoCs
30. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Mediatek Helio A SoCs
31. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Mediatek Helio P SoCs
32. Windows 10/ Vendor-cutomized Linux kernel for ARM64 for Mediatek Helio G SoCs

Because that is what we're bloody seeing on all those specialized ARM boards. Nvidia's customized Ubuntu images for Tegra contain DTBs and patches which allow them to light up their own Jetson boards but will not work on any other ARM hardware. Raspbian only works on Pis and no other ARM hardware boards.

We desperately need some kind of standard platform to allow generic Linux installations across all ARM64 hardware like what we are currently taking for granted with x64. and the fastest way to achieve that is to adapt SBSA for consumer platforms.

Last but not least, we need Microsoft to drop the 'No user control over Secure Boot for ARM64 computers' if we truly want ARM64 desktop Linux to take off. Because right now, Microsoft mandates that all Windows ARM64 deployments must have Secure Boot permanently set to 'On' with no option to disable it or add additional keys / hashes to the SB database.

First of all...the Age of ARM does not and will never depend on Desktop Linux as it is expressed now as a hacked together, fragmented platform (Red Hat or Ubuntu or Suse, RPM or DEB, Snap or Flatpak, GNOME or KDE or XFCE, or Cinnamon or MATE or Budgie or Enlightement or Arcan, etc) that can be put on any dusty piece of shit former Windows computer. Desktop Linux has been trapped for nearly 30 years as a hacked together, cheap version of Unix that can be installed on x86 computers to get around Unix licensing .....and oh yeah...if you're geeky enough you can install it on your unused Windows computer and make a go at it as an "alternative" personal computing experience", with the best part of it being "free". The Age of ARM is happening NOW and will ACCELERATE with just Windows, Mac and ChromeOS with Android and iOS having been the pioneers for the last decade and a half. It won't care about Desktop Linux. Because Desktop Linux has never cared about itself to keep from fragmenting into a thousand geeky ass flowers all of which smells like shit to the average consumer.

But there is a way the Age of ARM to work on Desktop Linux. HP, Dell and Lenovo can take every x86 pre-installed Linux Desktop or Laptop right now and have an identical product with an ARM board in it from either Mediatek or Qualcomm and put Ubuntu on it and call it a day. The change in the Linux Kernel for a Mediatek SoC and a Qualcomm SoC is miniscule.

But if that's even too much for the big boys, then just get the latest ARM N1 or X1 generic ARM SoC with Mali Graphics and call it a day once again. Plop Ubuntu on it and sell it. Differentiate in the number of High Perf cores vs low power cores, the amount of RAM, storage, yada yada.

You're making this harder than it has to be. There is no need for some grand unified board theory. It just requires manufacturers to reasonably limit choice. Apple is a Trillion dollar (literally) because of that. It's actually a Unix way of thinking. Make one thing....and make it well.

The only REAL catch in MY master plan for ARM Desktop Linux is the Linux app makers. Where is the ARM port of LibreOffice? Microsoft already has an ARM based Office for ARM Windows and ARM Mac. Where is the ARM port of GIMP? Adobe already has an ARM port of Photoshop for ARM Windows and ARM Mac.

Without Linux app makers getting off their ass, buying a reference ARM N1 or X1 Neoverse board and making a reference version of those apps I mentioned above and more, there will never be an Age of ARM for Desktop Linux. The world of Desktop Linux will forever more be left to eat the scraps from Microsoft's table of x86 hardware.

Tick Tock Desktop Linux. Microsoft and Apple and Google and ARM are leaving your ass behind. Quickly.

[Sonadow]

First of all...the Age of ARM does not and will never depend on Desktop Linux as it is expressed now as a hacked together, fragmented platform (Red Hat or Ubuntu or Suse, RPM or DEB, Snap or Flatpak, GNOME or KDE or XFCE, or Cinnamon or MATE or Budgie or Enlightement or Arcan, etc) that can be put on any dusty piece of shit former Windows computer. Desktop Linux has been trapped for nearly 30 years as a hacked together, cheap version of Unix that can be installed on x86 computers to get around Unix licensing .....and oh yeah...if you're geeky enough you can install it on your unused Windows computer and make a go at it as an "alternative" personal computing experience", with the best part of it being "free". The Age of ARM is happening NOW and will ACCELERATE with just Windows, Mac and ChromeOS with Android and iOS having been the pioneers for the last decade and a half. It won't care about Desktop Linux. Because Desktop Linux has never cared about itself to keep from fragmenting into a thousand geeky ass flowers all of which smells like shit to the average consumer.

But there is a way the Age of ARM to work on Desktop Linux. HP, Dell and Lenovo can take every x86 pre-installed Linux Desktop or Laptop right now and have an identical product with an ARM board in it from either Mediatek or Qualcomm and put Ubuntu on it and call it a day. The change in the Linux Kernel for a Mediatek SoC and a Qualcomm SoC is miniscule.

But if that's even too much for the big boys, then just get the latest ARM N1 or X1 generic ARM SoC with Mali Graphics and call it a day once again. Plop Ubuntu on it and sell it. Differentiate in the number of High Perf cores vs low power cores, the amount of RAM, storage, yada yada.

You're making this harder than it has to be. There is no need for some grand unified board theory. It just requires manufacturers to reasonably limit choice. Apple is a Trillion dollar (literally) because of that. It's actually a Unix way of thinking. Make one thing....and make it well.

The only REAL catch in MY master plan for ARM Desktop Linux is the Linux app makers. Where is the ARM port of LibreOffice? Microsoft already has an ARM based Office for ARM Windows and ARM Mac. Where is the ARM port of GIMP? Adobe already has an ARM port of Photoshop for ARM Windows and ARM Mac.

Without Linux app makers getting off their ass, buying a reference ARM N1 or X1 Neoverse board and making a reference version of those apps I mentioned above and more, there will never be an Age of ARM for Desktop Linux. The world of Desktop Linux will forever more be left to eat the scraps from Microsoft's table of x86 hardware.

Tick Tock Desktop Linux. Microsoft and Apple and Google and ARM are leaving your ass behind. Quickly.

I think you misunderstand me. The point I am trying to make is that for ARM on desktop and laptop computing to work, we need to have some kind of standard platform like what we had for x64 hardware. It does not have to be Linux-centric.

That list of 32 possible Windows 10 images is hypothetical but can and will very well become reality if there is no such standard platform for ARM. Any ARM vendor will definitely be keen to see their hardware in a future Windows desktop or laptop computer, but you can bet Microsoft has no desire to maintain special kernel images for every single possible ARM SoC. That's why I say desktop and laptop ARM really needs a unified platform like the PC platform for x64 where it does not matter what x64 processor is used because the combination of ACPI + BIOS / UEFI means that a single OS image always works across all processors past, present and future.

If you want a more practical reason why this is necessary, consider this situation: I buy an ARM64 laptop from XXX Vendor but it's loaded to the brim with bullshit shareware, nagware and trialware that I have no interest in. So what do I do? I download a copy of Windows 10 for ARM64 from Microsoft and replace the bundled OS with a clean upstream image from Microsoft. Except that I can't because the lack of a unified platform means that only the Vendor's version of Windows for ARM will even boot as it has special stuff baked into the image that contain low-level bits critical for initializing and bringing up various low-level interfaces within the ARM SoC, which almost never happens on x64 because of this unified platform built over ACPI and BIOS/UEFI.

The good news is that Microsoft is in the early stages of establishing such a standard platform; to the best of my understanding, ARM devices on Windows 8 and Windows 10 must use UEFI, which is a huge step to a unified 'PC platform' for ARM. Now this is where desktop Linux comes in: by piggybacking on Microsoft's standard PC platform for ARM hardware so that distributions can continue to ship generic kernel and OS images like what they are currently doing with x64, and users like me can easily build the latest upstream kernel from kernel.org to support things like newer graphics cards or WiFi hardware (especially for desktop ARM computers), which is currently impossible on vendor-customized kernels and distributions.

And for desktop Linux to piggy back on Microsoft's standardized platform, we kind of really need Microsoft to drop its 'No user control over Secure Boot' requirement for ARM64 hardware.

[dragon321]

Where is the ARM port of GIMP?

On GIMP site in the download section? "Flatpak build available in: i386, x86-64, ARM and AArch64.". Beside from that why "port" would be needed? GIMP compiles fine for ARM without any need to port anything. Just like most open source applications. Same goes for LibreOffice. It's running on ARM for years.

Most of Linux application worked fine on ARM and other architectures before Apple and Microsoft started thinking about supporting ARM. I could run whole Linux desktop on Raspberry Pi 1 in 2012 with native ARM applications. without need for x86 emulation. Same on other architectures even earlier. We all know how much worth was Windows RT. So tell me again who is leading in ARM race?

[Space Heater]

The only REAL catch in MY master plan for ARM Desktop Linux is the Linux app makers. Where is the ARM port of LibreOffice? Microsoft already has an ARM based Office for ARM Windows and ARM Mac. Where is the ARM port of GIMP? Adobe already has an ARM port of Photoshop for ARM Windows and ARM Mac.

GIMP and Libreoffice (and thousands of other "apps") have worked on Aarch64 for a while now and distributions like Ubuntu, OpenSUSE, and Fedora already package them. Not to mention that arm already has standards to allow booting a single OS image on multiple devices, and that work was pushed in large part due to Red Hat and Microsoft.

You love grandstanding about arm and how Linux is shit, but in reality you don't know the first thing about arm, linux, their respective ecosystems or computer architecture in general. You are a run of the mill charlatan that wants to scream at people.

[Sonadow]

Not to mention that arm already has standards to allow booting a single OS image on multiple devices, and that work was pushed in large part due to Red Hat and Microsoft.

I seriously hope you are not referring to SBSA. That thing may be a standard platform but it is targeted at servers. The SBSA-compliant eMag ARM workstation that Anandtech reviewed was shown to take almost 5 minutes to boot. We need something faster for consumer machines like desktop and laptop computers.

[Space Heater]

I seriously hope you are not referring to SBSA. That thing may be a standard platform but it is targeted at servers. The SBSA-compliant eMag ARM workstation that Anandtech reviewed was shown to take almost 5 minutes to boot. We need something faster for consumer machines like desktop and laptop computers.

I seriously hope you are not referring to a specific implementation of SystemReady (it's not just for servers) as being representative of the standard itself.

Just because an amd64 Dell/HPE/Supermicro server takes a long time to boot (generally due to the firmware performing additional hardware checks) does not at all imply that amd64 consumer machines will take several minutes to boot. The requirements for BBR firmware are intended to be extremely boring and essentially identical to what we see in amd64 machines, UEFI and ACPI.

Please read what arm's SystemReady program entails before jumping to the conclusion that it is only for large systems or that it must be slow.

[phuclv]

AHEM.....let Wikipedia be your guide.

All the newer implementations are from Apple. There are no cores from ARM that support those newer ISAs