It's Becoming Possible To Run Linux Distributions On The HP/ASUS/Lenovo ARM Laptops

[RussianNeuroMancer]

ARM is dead to me and the market as a whole as long as this isn't addressed. No one, not even Windows users, want to deal with device-specific image files.

Some ARM devices support UEFI: https://wiki.debian.org/InstallingDe...96Boards/HiKey

[oiaohm]

Ugh, I'd thought we would get past the point of device specific image files.

Since these laptops support UEFI on ARM, aren't dtb files redundant ?

The answer is no. dtb files contain more information about hardware than UEFI includes ,

https://www.kernel.org/doc/Documentation/efi-stub.txt

Yes EFI on arm in fact to Linux provided dtb or acpi. dtb the device tree can encode information you cannot put in acpi.

Another thing I'm woried about is that the Infrastructure around ARM isn't as flexible as x86. Like, as far as I know I can't just pop a CD into an ARM laptop and boot from it and install the system like that. :'( Maybe that's why ARM hasn't catched on..

To be truthful we have not 100 percent tried. Problem is not that ARM infrastructure isn't as flexible as x86 it the other way over arm infrastructure is too flexible. This relates to the above problem why we have both dtb and acpi on arm.

https://fosdem.org/2019/schedule/event/one_image_to_rule_them_all/

A group is now trying to make single images for arm devices. Turns out some of the differences are helping. What boot sector in fact is loaded is giving you clue to what soc vendor you are dealing with.

The reality here is if we can get one image that will work that one image could fire up to EFI with correct acpi/dtb allowing future booting a lot more simply.

This is the case no one has really tried completely.

Early firmware in amd, intel and via being different x86 vendors is in fact different. With arm devices we are still starting in early firmware of non uniform. The one image to rule them all is how much of early firmware support can be put on one boot up media without having hiss fits. So far it looking more and more like most major vendors of arm soc chip can use a unified early firmware image.

The price of a unified arm media looks at this stage will cost 1 meg area at start of media in boot up stuff I don't think that prices these days is too insane.

[oiaohm]

ARM is dead to me and the market as a whole as long as this isn't addressed. No one, not even Windows users, want to deal with device-specific image files.

https://fosdem.org/2019/schedule/event/one_image_to_rule_them_all/

This problem might be dealt with in the next 12 months if we are lucky. Part of the problem is no one until this group has really tried.

[Sonadow]

https://fosdem.org/2019/schedule/eve...rule_them_all/

This problem might be dealt with in the next 12 months if we are lucky. Part of the problem is no one until this group has really tried.

12 months? Dream on. 12 years more like it.

Even those same ARM laptops mentioned in the git repository have issues (read: not able to) installing a clean Windows ARM iso from USB.

ARM needs to completely rethink their approach to non-embedded computing. Either set up a separate business unit to cater to desktop/laptop and server computing with SBSA, SBBR and UEFI to make a clean break from embedded ARM, or leave the non-embedded space completely.

It's not unheard of for SBSA-compliant ARM servers to not be able to boot and install a generic ARM Linux ISO image.

[chithanh]

The answer is no. dtb files contain more information about hardware than UEFI includes ,

https://www.kernel.org/doc/Documentation/efi-stub.txt

Yes EFI on arm in fact to Linux provided dtb or acpi. dtb the device tree can encode information you cannot put in acpi.

If people would use the actual origin of device trees, namely Open Firmware (IEEE-1275), then those could come naturally and they would avoid the mess that is ACPI.
There is even an example implementation of Open Firmware on ARM (OLPC XO-1.75). But there seems to be no commercial interest in having that.

[oiaohm]

Even those same ARM laptops mentioned in the git repository have issues (read: not able to) installing a clean Windows ARM iso from USB.

That a Windows problem. The report here said images when the reality is the 3 different brands of arm64 are in fact installing from 1 image with 1 grub and 1 Linux kernel.

ARM needs to completely rethink their approach to non-embedded computing. Either set up a separate business unit to cater to desktop/laptop and server computing with SBSA, SBBR and UEFI to make a clean break from embedded ARM, or leave the non-embedded space completely.

Really this does not make very much sense. Be it a dekstop/laptop or embedded arm in a lot cases you are talking about stack of identical drivers.

It's not unheard of for SBSA-compliant ARM servers to not be able to boot and install a generic ARM Linux ISO image.

Where do you get the idea of generic ARM Linux ISO those have not existed to boot with. Yes they have existed to provide applications after you have used a customised boot disc matching the hardware. This is why the following is really big news.

https://fosdem.org/2019/schedule/eve...rule_them_all/
This is the first time a proper generic ARM64 Linux image has attempted to be made. Patches are going up stream into uboot and UEFI standard..

Yes this work means the 3 laptops that have been go booting with a single image uefi could be integrated on a image for booting raspberry pi 3 and related arm64 clones/forks from a single image.

Basically we are about see what a single generic Linux boot image for arm64 can in fact do and what the limitations really are. Yes covering all the boards uboot support as a starting point is insanely impressive.

uboot and uefi covers 90+ percent of everything arm.

[oiaohm]

If people would use the actual origin of device trees, namely Open Firmware (IEEE-1275), then those could come naturally and they would avoid the mess that is ACPI.
There is even an example implementation of Open Firmware on ARM (OLPC XO-1.75). But there seems to be no commercial interest in having that.

The origin of device trees predates Open Firmware (IEEE-1275) its 1991 sun open boot is where device tree starts.

https://elinux.org/images/e/e2/Engaging_Device_Trees_0.pdf

Device Tree Blob (dtb)(Flat Device Tree) form of device tree is a pure Linux kernel development that is also used by uboot.
https://git.kernel.org/pub/scm/utils/dtc/dtc.git this is the compiler you need to make dtb files. Large percentage of the device tree master files are part of the Linux kernel source.

This is way different to the ACPI path where you leave it up to the vendor to put the right stuff in firmware of the device. When the vendor customises their windows install to ignore the screwups they made in firmware of course the so called generic windows installer completely bites the big one.

[Britoid]

The price of a unified arm media looks at this stage will cost 1 meg area at start of media in boot up stuff I don't think that prices these days is too insane.

Hopefully that might trickle down to Android and we get single Android images. There's GSI but it requires vendors to put device configuration files in another partition and it's still device-specific kernels.

But some OEMs would never give up that control. I think it would be pretty amazing one day to be able to boot a phone off a USB stick, install the OS and have everything working.

[oiaohm]

Hopefully that might trickle down to Android and we get single Android images. There's GSI but it requires vendors to put device configuration files in another partition and it's still device-specific kernels.

Its android party why I said 12 months. This is not 100 percent tricking down from Android somethings are trickle up from android.

But some OEMs would never give up that control. I think it would be pretty amazing one day to be able to boot a phone off a USB stick, install the OS and have everything working.

Google trebble work is only the tip.
https://source.android.com/devices/a...odular-kernels "Future Android versions" and "Upstreaming" sections of this make it very clear what google will be pushing for in Android 10.

Basically OEM never giving up that control is not exactly true. Since the upstreaming announcement from google as something that want to see in future we are seeing way more drivers up-streamed by the SoC vendors. This android caused up-streaming is also why the 3 laptops mentioned on this project have working kernels now.

Google has quite extreme whip if you don't meet our quality control we will not certify you to ship with Google play store. Android device without Google play is not that sell-able. OEM and SOC vendor most critical requirement is that product will be bought by customer.

Education users a lot of the PI and PI clone boards so this market is also applying a lot of force for vendors to open up drivers and other parts. With unified boot discs for these devices there will be more pressure .

Other thing to remember SOC vendors don't reinvent every part of the SOC chip every time they make a new version. So SOC vendor releases drivers for all the current versions of their chips they also release a segment of drivers for all their older chips in some cases this is 100 percent of their product lines are in fact the current set of drivers.

This is why Sonadows idea that we need different for arm embedded and arm desktop/arm server. Really we need the 1 unified image that can pressure vendors that if they don't support it they will lose big money currently this where android heading on phones.

https://fosdem.org/2019/schedule/event/one_image_to_rule_them_all/

This one image to rule them all is truly a goal. This one image will apply more pressure on SOC and OEMs not to hold onto the control as tightly. Think about day comes that 1 image to boot most PI clone boards you attempt to sell a PI clone board with some OEM or SOC vendor unique driver and the 1 image no longer works your board will not sell.

Part of the reason why x86 has some form of sanity is that Windows was the 1 image SOC/OEM had to support. Microsoft never really used the whip they had on vendors to create uniform generic driver coverage resulting in different windows machines being a total ass to reinstall when not using vendor install media.

Arm platforms just need the same 1 image/images that SOC/OEM has to support to have sales.

[misGnomer]

Among the recent FOSDEM news was a preview of one ARM SOC vendor's planned big brother to the $99 Pinebook ARM netbook with target being 14' 1080p / 4gb / 64gb plus an NVMe slot.

Although the company was based in China (PRC) with the potential issues involved, they did seem genuinely supportive of open source and if the laptop (using RK3399 IIRC) has practical mainline kernel support it could become relatively popular if they hit the hoped $200 target.

I don't know what distro they might preload or what bootloader/manager it uses, but if it runs Debian then the door is open.