The New ARM Hardware Support That's Now Part Of The Linux 4.21 Kernel

[phuclv]

UEFI is so damn windows inclined they even use PE EXE windows executable format everywhere. A really good way to show UEFI/ACPI vendors only care about Windows

The reason given in "UEFI Specification, version 2.8B" is that

this image type is chosen to enable UEFI images to contain Thumb and Thumb2 instructions while defining the EFI interfaces themselves to be in ARM mode.

[edwaleni]

New platform support for the Rockchip Gru Scarlet, Libretech Amlogic S805-AC, Linksys EA6500 router support, Facebook Backpack-CMM BMC support in the ASpeed code, and other lesser known board additions.

Support in 4.21 is for the Linksys EA6500 V2 using the BCM4708 (BCM4708A0)

The Linksys EA6500 V1 uses a BCM4706 clone and is not the same as the version 2.

[SystemCrasher]

But I guess in the latter you have UEFI and ACPI.

And looking on how this woefull proprietary crap works with Linux, it better to burn in hell, where it belongs. With all tianocore "open" stuff (never, ever seen single HW with OPEN firmware based on it!!!) and Intel and their Management Engines and Boot Guards alltogether. Because it just freakin hard to find computer and especially laptop that would perform adequately using these techs and Linux. Not to mention nobody is going to fix firmware bugs, ever. Especially Linux related ones. To make it more fun, it actually turns computer into remotely controlled backdoored crap, when someone like Intel or BIOS vendor is top power and idiot who bought all that is a mere guest to put it short. Putting that crap into ARMs would make ARMs just as bad as x86 is. What's the point?

UEFI is so damn windows inclined they even use PE EXE windows executable format everywhere. A really good way to show UEFI/ACPI vendors only care about Windows. On funny note, its rather amusing when executable format demands one to put MZ exe with x86 code telling this program can't run in MS-DOS . Twice as laughable on ARMs who stand no chance to execute that code in first place.

[Britoid]

Different types of targets...
ARM *servers* have standards like SBSA precisely to solve this problem. But most of the ARM action (by volume anyway) is in IoT type stuff where the name of the game is to create the absolute most minimal setup possible to minimize price, volume, battery life, ...

My suspicion is that everyone agrees that SOME sort of generic standard (the equivalent of an SBSA-lite) is a great idea that would save everyone time at minor additional cost. But then the moment you actually try to define this, everyone has different claims about what's "essential" to be in the spec vs what's "pointless additional overhead that no-one [ie not me and my company] uses"...

I think the Windows 10 on ARM might rely on that? Given that Microsoft has a generic arm64 ISO (although it only works on Qualcomm atm).

Windows 8/10 Phones shipped with UEFI-on-ARM which meant you could chainload TianoCore etc.

[name99]

As much as it's a good thing that the ARM SoCs support is in the mainline kernel (even if sometimes it's older SoCs), it's still entirely backwards that the kernel needs to be forked for every single ARM SoC, which isn't the case on x86. But I guess in the latter you have UEFI and ACPI.

Different types of targets...
ARM *servers* have standards like SBSA precisely to solve this problem. But most of the ARM action (by volume anyway) is in IoT type stuff where the name of the game is to create the absolute most minimal setup possible to minimize price, volume, battery life, ...

My suspicion is that everyone agrees that SOME sort of generic standard (the equivalent of an SBSA-lite) is a great idea that would save everyone time at minor additional cost. But then the moment you actually try to define this, everyone has different claims about what's "essential" to be in the spec vs what's "pointless additional overhead that no-one [ie not me and my company] uses"...

[Britoid]

As much as it's a good thing that the ARM SoCs support is in the mainline kernel (even if sometimes it's older SoCs), it's still entirely backwards that the kernel needs to be forked for every single ARM SoC, which isn't the case on x86. But I guess in the latter you have UEFI and ACPI.

[phoronix]

Phoronix: The New ARM Hardware Support That's Now Part Of The Linux 4.21 Kernel

The ARM platform and board changes were sent in on New Year's Eve for the Linux 4.21 kernel...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.21-ARM-Changes