Linux Support Emerging For The Samsung Galaxy Book4 Edge X1 Elite Laptop

[phoronix]

Phoronix: Linux Support Emerging For The Samsung Galaxy Book4 Edge X1 Elite Laptop

Following all of the Snapdragon X1 upstream enablement work over the past number of months by Qualcomm and then DeviceTree additions emerging for enabling the likes of the ASUS Vivobook S 15, Lenovo Yoga Slim 7x, Lenovo ThinkPad T14s Gen 6, and Microsoft Surface 7, the Samsung Galaxy Book4 Edge is the newest Snapdragon X1 Elite laptop seeing Linux DT support...

https://www.phoronix.com/news/Samsung-Galaxy-Book4-Edge-Linux

[jonkoops]

Is there an accurate overview of these Snapdragon devices and their support under Linux? For example, something that resembles the Feature Support page for Asahi Linix. Buying these devices feels kind of like a blind guess.

[duby229]

Is there an accurate overview of these Snapdragon devices and their support under Linux? For example, something that resembles the Feature Support page for Asahi Linix. Buying these devices feels kind of like a blind guess.

Yeah, I think that's right. Because of what Device Trees is every device will individually need specific support in the kernel. I'm sure there will be a list of which devices are supported, but it will probably always feel like a blind guess. I'm really concerned about how operating system installers and LiveUSB operating systems are going to work in the future.

There have been conversations about it here in the past but I'm still unsure.

EDIT: I think every OS installer or LiveUSB will need to release an ISO for every device...

EDIT: Maybe not? Any devices that are supported by the same kernel should be able to boot from it? I'm rething what I wrote, but I'm still unsure.

[sophisticles]

I don't understand the concerns around device trees, if anything they make it easier to support hardware:

https://en.wikipedia.org/wiki/Devicetree

Linux

Given the correct device tree, the same compiled kernel can support different hardware configurations within a wider architecture family. The Linux kernel for the ARC, ARM, C6x, H8/300, MicroBlaze, MIPS, NDS32, Nios II, OpenRISC, PowerPC, RISC-V, SuperH, and Xtensa architectures reads device tree information; on ARM, device trees have been mandatory for all new SoCs since 2012. This can be seen as a remedy to the vast number of forks (of Linux and Das U-Boot) that have historically been created to support (marginally) different ARM boards. The purpose is to move a significant part of the hardware description out of the kernel binary, and into the compiled device tree blob, which is handed to the kernel by the boot loader, replacing a range of board-specific C source files and compile-time options in the kernel.

[jonkoops]

I think every OS installer or LiveUSB will need to release an ISO for every device...

They won't, as long as the installation media uses a Linux kernel version that supports the device it will work.

[duby229]

I don't understand the concerns around device trees, if anything they make it easier to support hardware:

https://en.wikipedia.org/wiki/Devicetree

So, I've read just as much as you have, but I did not come to that conclusion. Who going to supply the dtb file? Device manufactures or Linux enthusiasts? Also who specifies the code and writes the compiler for it?

EDIT: The point I'm making there is that it would need a proprietary boot loader to do it.

EDIT: Some thing would have to load prior to the on disk boot loader and then chainload the operating system. Which takes the choice of what hardware can be booted totally out of the hands of the operating system itself.

EDIT: The device manufactures would have to have each one of their devices individually configured to allow Linux to boot. The alternative is to compile all that information into the kernel the old way and have custom kernels for each device that manufactures haven't configured to allow Linux to boot...

[duby229]

I think it's gonna be a shit show of whether or not devices actually can boot a stock kernel, even if the hardware in that device is all technically supported by that kernel.

[ahrs]

I don't understand the concerns around device trees, if anything they make it easier to support hardware

The purpose is to move a significant part of the hardware description out of the kernel binary, and into the compiled device tree blob, which is handed to the kernel by the boot loader.

That's the concern, every single device needs device tree enablement in order to even be able to boot. This makes sense for embedded devices but not for laptops and desktops. You want your kernel to be able to just boot as an EFI Stub without any of this and go on its way. Sure, hardware has quirks and these quirks need to go into the kernel but you at least get something on the screen with many devices working out of the box (except those that need new drivers or quirk handling).

[Sonadow]

So, I've read just as much as you have, but I did not come to that conclusion. Who going to supply the dtb file? Device manufactures or Linux enthusiasts? Also who specifies the code and writes the compiler for it?

EDIT: The point I'm making there is that it would need a proprietary boot loader to do it.

EDIT: Some thing would have to load prior to the on disk boot loader and then chainload the operating system. Which takes the choice of what hardware can be booted totally out of the hands of the operating system itself.

EDIT: The device manufactures would have to have each one of their devices individually configured to allow Linux to boot. The alternative is to compile all that information into the kernel the old way and have custom kernels for each device that manufactures haven't configured to allow Linux to boot...

On top of that, dtbs are not kernel agnostic. A dtb which works on one kernel version is not going to work on a different version, no matter what people say. The real world outcomes speak for themselves. If it were agnostic, SBCs as they are will not be a complete shitshow locked to only one vendor-provided kernel for their entire 10 years service life

And enough spewing of that tired "it's supposed to work as long as <blah blah>". There are so many damned things in Linux and its distributions that are "supposed to work" but never actually do so in the real world, especially the enterprise and corporate world. but instead of buckling up and doing something about it, all they do is blame everybody else like OEMs, political systems, economic systems except themselves.

Linux is "supposed to be capable of generating a dtb from the ACPI tables". Sure, damn right it does. And it also doesn't boot.

Shared libraries are "supposed to be the way to do things". And what does this give us? A glued mess of shit that cannot even allow for side-by-side installations of various libraries or programs of similar versions.

Software "is supposed to just work on all versions of glibc as long as they rebuild it for older glibc versions, because everybody is supposed to upgrade to a newer release as soon as it is published". And sane developer will just give Linux the finger when they can build once and run their program on both newer and older versions of macOS and Windows.

If you want an OS that will work on all ARM notebooks or PCs when such devices eventually go mainstream, the only available choice for the foreseeable future is still Windows. Or use macOS on Apple Silicon. Because only Microsoft and Apple have the commercial power and the market reach to enforce and standardize a hardware platform to their specifications. That is the reality of the economics of consumer computing and consumer hardware platforms.

And it will stay that way unless Qualcomm reverses course and allows booting over EFI and ACPI on Linux instead of insisting on goddamned device trees.

[mb_q]

And it will stay that way unless Qualcomm reverses course and allows booting over EFI and ACPI on Linux instead of insisting on goddamned device trees.

According to the PostmarketOS wiki, its not that Linux can't use UEFI+ACPI on Qualcomm X, it is just that it is basically a useless shim, and Windows has critical info baked inside as drivers, so not unlike DTDs, even worse. ARM has the "SystemReady" platform that supports both injecting device trees from bootloader, UEFI+ACPI and LinuxBoot (Linux in firmware, so it can just kexec rather without feeding anything), so three generic ways to feed hardware info. It is only up to OEM to support Linux smoothly, and some vendors do that.