Linux 5.4 Adds Qualcomm Snapdragon 855, Supports Some Newer ARM Laptops

[phoronix]

Phoronix: Linux 5.4 Adds Qualcomm Snapdragon 855, Supports Some Newer ARM Laptops

The ARM SoC platform and driver changes landed on Monday during the first full day of the Linux 5.4 merge window. There is some exciting ARM hardware support improvements for this kernel while doing away with some older platforms...

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

[wizard69]

It would be most interesting to see testing of some of those laptops. The Yoga is particularly interesting.

[jaskij]

Porting between different hardware platforms for supported ARM SoCs is relatively easy as long as you have all the drivers and information. Which is a giant IF for commercial platforms especially since the required information includes electrical schematics.

Usually it jus boils down to making sure the kernel config is ok, writing the device tree and you are good to go. The dtsi for the SoC should be in the kernel sources if it's supported.

The only hard part would be RAM timings.

P.S.
Where do I send bugs in the forum?

[starshipeleven]

Porting between different hardware platforms for supported ARM SoCs is relatively easy as long as you have all the drivers and information. Which is a giant IF for commercial platforms especially since the required information includes electrical schematics.

Usually it jus boils down to making sure the kernel config is ok, writing the device tree and you are good to go. The dtsi for the SoC should be in the kernel sources if it's supported.

This is true, but it's also true that the "ARM laptops" are using UEFI and ACPI, not some random bootloader and device tree. So you shouldn't need schematics, you only need to hope the ACPI tables shipped with the firmware aren't horribly broken.

Where do I send bugs in the forum?

It's vBullettin, so probably somewhere here https://www.vbulletin.com/

[tildearrow]

This is true, but it's also true that the "ARM laptops" are using UEFI and ACPI, not some random bootloader and device tree. So you shouldn't need schematics, you only need to hope the ACPI tables shipped with the firmware aren't horribly broken.

I have a question. Is there any reason why do they break the ACPI tables?
Couldn't they set on a standard chipset for a modern PC, like when they did with the MSX standard?

[starshipeleven]

I have a question. Is there any reason why do they break the ACPI tables?
Couldn't they set on a standard chipset for a modern PC, like when they did with the MSX standard?

Let's start from the beginning. ACPI tables and "broken tables" are a thing for all x86 hardware, not just ARM laptops running Windows.

ACPI tables are a (much older, evolved with time) Intel equivalent to Linux's Device Tree system.
It's a binary (compiled) blob to pass a kernel (windows or Linux or whatever else can read them, it's an open standard) information about the hardware installed in the system, and hardware addresses and stuff. Also standardized function calls for functionality that is done or mediated by the BIOS/UEFI's firmware, like power management, function buttons, screen brightness, fan control on laptops and such (so the manufacturer does not need to opensource that and put their precious IP at risk or something).

Being a compiled blob, you need a compiler to generate it, and the device contains only the blob. No source for it.
Being Microsoft what it is, they provide their own "Windows compliant" compiler for ACPI tables https://docs.microsoft.com/en-us/win...t-asl-compiler
Now I can't claim I'm 100% into what is happening here, but from the bitching I've read when someone is debugging ACPI table issues it seems this compiler is either offering additional stuff that Intel's one does not, or does some special fuckery of its own. End result is that these tables can contain parts that only Windows can read.
This is the "relatively good" situation, where the device at least works with Windows.

Another cause for breakage is human error. Being ACPI an Intel brainchild it's... overcomplicated. This does not help the poor underpaid sods writing the firmware on a hurry for relatively cheap consumer PC hardware.
In this case, the device could have issues even with Windows.

This is one of the reasons the ACPI subsystem in Linux (the module that reads this stuff) is full of workarounds for many different ACPI table bugs and brokenness, to read them anyway, or at least skip the broken part and read the rest.
I strongly suspect Windows also has similar workarounds and stuff in its own ACPI interface.

On a related note, ACPI table issues are one of the main reasons you can't just install MacOS on most consumer hardware and just add drivers.

On many other hardware you need to use bootloaders (like Clover) that override the stock ones with fixed ones made by someone that spent some time debugging the stock ones.
Unsurprisingly, MacOS does NOT tolerate ANY kind of ACPI bug or issue, because Apple controls the full stack and they know they ship only good ACPI tables in their firmware.

[starshipeleven]

ah come on vBullettin. Blocked post for tildearrow above

[tildearrow]

ah come on vBullettin. Blocked post for tildearrow above

Sorry, I was sleeping and couldn't approve it in time.

[jaskij]

Let's start from the beginning. ACPI tables and "broken tables" are a thing for all x86 hardware, not just ARM laptops running Windows.

Being a compiled blob, you need a compiler to generate it, and the device contains only the blob. No source for it.
Being Microsoft what it is, they provide their own "Windows compliant" compiler for ACPI tables https://docs.microsoft.com/en-us/win...t-asl-compiler
Now I can't claim I'm 100% into what is happening here, but from the bitching I've read when someone is debugging ACPI table issues it seems this compiler is either offering additional stuff that Intel's one does not, or does some special fuckery of its own. End result is that these tables can contain parts that only Windows can read.
This is the "relatively good" situation, where the device at least works with Windows.

Another cause for breakage is human error. Being ACPI an Intel brainchild it's... overcomplicated. This does not help the poor underpaid sods writing the firmware on a hurry for relatively cheap consumer PC hardware.
In this case, the device could have issues even with Windows.

So basically the same compatibility issues we had with IE ten or so years back. In kernels of multiple OSes. Yeah. Now, let me quote what Linus Torvalds said in 2003:

Modern PCs are horrible. ACPI is a complete design disaster in every way. But we're kind of stuck with it. If any Intel people are listening to this and you had anything to do with ACPI, shoot yourself now, before you reproduce.

[jaskij]

On a related note, ACPI table issues are one of the main reasons you can't just install MacOS on most consumer hardware and just add drivers.

On many other hardware you need to use bootloaders (like Clover) that override the stock ones with fixed ones made by someone that spent some time debugging the stock ones.
Unsurprisingly, MacOS does NOT tolerate ANY kind of ACPI bug or issue, because Apple controls the full stack and they know they ship only good ACPI tables in their firmware.

Hmm... could this be done by porting those workarounds to the Darwin kernel? Not that it really matters since I believe MacOS cannot be bought separately and it's license is only valid on their hardware.