Did you notice that rather than on PC where you download a generic image which you can just live boot from USB, on ARM every distro needs to support every device individually? It's not just lacking mainline Linux support, it's also lacking a generic way to boot these devices like x86 has. can solve this perfectly by implementing UEFI on a dedicated chip but current new @PINE64 devices are lacking this. Let's get loud to make them add this again in new devices!

Flashing so-called "platform firmware" which implements , like u-boot, to this would allow the user to boot generic UEFI images not made specifically for the device in question. Finally you'd be able to properly live-boot a distribution through e.g. sdcards, USB sticks, etc. And you no longer have to wonder if your distro supports your particular device, you just have to download their generic UEFI image!

Modules like are really important to achieve the goal we've set at : device support for 10 years and more. Once a device is fully mainlined and can boot using a generic image we no longer have to put any effort in supporting this particular device. Everything will "just work". Just like no distro put any effort in making it boot with my particular desktop and laptop.

Luckily the awesome samueld from has made a project called -Boot:

It does exactly this: provide "platform firmware" for devices that implements allowing you to boot generic UEFI ARM image. Myself and @martijnbraam are going to make postmarketOS support this kind of booting and I hope we can make this mandatory for every device that uses u-boot to boot. And I need _you_ to tell other distros to support this method of booting as well!

Because be honest, who doesn't want to see GRUB booting on your phone allowing you to choose from a multitude of installed distributions? 😉

As a proof-of-concept, changing 3 lines made our pmOS image "just work" using tow-boot!

We're ready for on the @Pine64, just waiting for you ;)

I read the web page you linked in your first toot. Not being very technical, I'm not sure about the status of the original Pinephone: is it possible to have SPI flash support it, or is it too late?

@normandc It's a piece of hardware. You can't just add it to already shipped devices ;)

@bart thanks.
in my defence, I did say I'm not very technical. ;-)


OMG, I have been *wishing* for the ability to multiboot my phone so desperately! It would be so amazing to have the 3-4 most interesting OS's all installed on my #PinePhonePro, and just boot in and update occasionally without having to reinstall and set up each from scratch every. single. time. there's a new release. It would definitely make me use that distro more.

Hoping @ManjaroARM @ubports @ArchLinux_Community and @sailfishosnews@mastodon.sociall incorporate this like #PostMarketOS ASAP!


@Blort @ManjaroARM @ubports @ArchLinux_Community Thanks for your excitement! 😄 Quick note as it bothers the hell out of me, it's either "postmarketOS" or "pmOS", but not "PostMarketOS" lol.

Note that of course distributions will have to change their install methods, as right now most, including pmOS, just wipe the medium you're installing it on before installation. That shouldn't happen if you want to have 3 distros on your SD 😛

@bart one question: this would work for systemd-boot as well, right?

@bart @martijnbraam sounds amazing!
Is there a reason why you did not ping Mobian and ManjaroARM directly?

@silmathoron @martijnbraam I'm talking with them, just not on Mastodon. Behind the scenes stuff on Matrix 😉

@bart What is the process to get a device running this?

@justinz SPI flash is a hardware component, you can't "install" it through software

@bart Does that mean the end of device tree files? If so, how will peripheral discovery work in the generic images?

Also, what is the recovery mechanism in case of failure? Tossing a broken SD (or eMMC, if in a socket) is cheap and easy. I didn't see any bricked PCs yet, but had already used the DualBIOS feature to recover some machines.

Don't get me wrong, the ubiquity of x86 is made possible in part by abstraction of the early boot process, and this is likely welcome also for Arm. Also, the probability of failure is probably negligible.

But still, as a tinkerer, I love the unbrickability of my #Pinephone :-)

@ledoian The platform firmware tells the kernel what device it is booting, the kernel can then load the correct device tree.

Not sure why the recovery mechanism would be different with dedicated boot storage. You just tell the platform firmware (e.g. u-boot) to boot from a different medium. Or are you talking about flashing the platform firmware itself?

@bart Sorry for the confusion. I meant recovery of the platform firmware (similar to when an x86 BIOS is corrupted). Would there be any other way than flashing the SPI flash externally?

@ledoian That I'm not personally sure of, you'd have to ask someone more knowledgeable than myself

@bart @PINE64 This has nothing to do with SPI flash, but rather with having an area that is bootable and not overwritten during installation.

In the #Librem5, this function could be served by the eMMC storage, which contains extra "boot" partitions that are not normally visible from the OS, but the CPU can boot from them.

Placing u-boot there with some common interface like UEFI was always something I wanted to have.

@dcz @PINE64 You're right about that bootable area. The SPI flash is something that can provide this however, and @PINE64 has had this on devices before and seems like the most logical choice.

I'd love it if the Librem 5 had something comparable, it would be good to discuss this with the Tow-Boot author!

@craftyguy @dcz @bart @PINE64 For the record, there's nothing that inherently prevents u-boot on L5 from accessing the SD card (which is a mass storage device connected over USB) to boot the kernel from it. All it needs is drivers and correct configuration, which simply hasn't been done yet. Angus has mentioned that it should be easier now on mainline u-boot, so there's a chance it may be there soon(ish).

@dcz @bart

Where can I find out more info about these extra "boot" partitions? If they're hidden by the OS (by u-boot?), are they meant to be written to by uuu?

@craftyguy @dcz @bart "Hidden" is a wrong word, they're just separate - available as /dev/mmcblk0boot0 and /dev/mmcblk0boot1, currently empty by default. There's also a Replay Protected Memory Block at /dev/mmcblk0rpmb. Each of them 4MB.

@dos @dcz @bart

Will the SOC automatically try to boot from those first? (or at all?)

@craftyguy @dcz @bart AFAIUI you can set which partition (boot0, boot1 or user) is bootable. Never tried myself though :)

@dos @craftyguy @dcz Yup just found those boot partitions on my L5. @craftyguy tells me the L5 is close to running mainline u-boot so it would be amazing to get that on there. Then we can just boot a normal (U)EFI image on there without having to ship u-boot in the distribution anymore

@bart @PINE64 Hmm it sounds like the more urgent thing needed is a disable-eMMC link for booting so you can force the SD boot.

@bart @PINE64

Did you notice that rather than on PC where you download a generic image which you can just live boot from USB, on ARM every distro needs to support every device individually? It’s not just lacking mainline Linux support, it’s also lacking a generic way to boot these devices like x86 has.

I didn’t understand what was going on when i got my first arm device(s) a while back. Once i found out, i sold them.

@justinz @PINE64 Most phones are Android phones which don't abide to standards at all so no. We can do this properly on these devices though!

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!