<Armbian-Discord> <r​pardini> very interested in this. grub might have been the safe choice back when... but if we can make systemd-boot go on MBR it'd be in
<Armbian-Discord> <M​anoftheSea> I got so far as to generate the offset-GPT for ebin, on which I know GPT UEFI sd-b work together. So I need to boot the image with the serial connected, and see how that goes. If u-boot doesn't work there, it's not gonna work elsewhere.
<Armbian-Discord> <r​pardini> btw I gave up on the 14/15 partitioning scheme as uefi default and will retire it down to some uefi-x86-legacy stuff
<Armbian-Discord> <r​pardini> I dunno ebin at all; on meson64 uboot and GPT will not live together AFAIK
<Armbian-Discord> <r​pardini> I mean on the "same media": both uboot and GPT on SD for example. If uboot is in SPI/MMC etc, no problem
<Armbian-Discord> <M​anoftheSea> do you know why they won't live together?
<Armbian-Discord> <r​pardini> never went into it, writing uboot to the required offset destroys gpt
<Armbian-Discord> <r​pardini> which is not true of rk for example
<Armbian-Discord> <n​armstrong> amlogic loads bootloader from sector 1, and we can't move it
<Armbian-Discord> <n​armstrong> we can make it load from another media or the emmc boot partitions for example to use EFI boot
<Armbian-Discord> <n​armstrong> on lafrite since u-boot is on an SPI we can use EFI boot, same for boards with SPI like the N2, but there's the shitty vendor bootloader on it
<Armbian-Discord> <M​anoftheSea> It's amlogic that loads sector 1? okay.
<Armbian-Discord> <M​anoftheSea> I remembered one of the two did sector 1, and the other did something like sector 32.
<Armbian-Discord> <n​armstrong> nop not on amlogic, only sector 1
<Armbian-Discord> <n​armstrong> remember those are high volume Set Top Box secure SoCs, so they care about boot security from big customers and not about a potential EFI boot on a low volume SBC market
<Armbian-Discord> <n​armstrong> unlike allwinner and rockchip who also targets general purpose platforms
<Armbian-Discord> <M​anoftheSea> Yeah, I've known that one of the vendors had this problem, just not which one.
<Armbian-Discord> <M​anoftheSea> Also, when doing a test, make sure you're using the right test medium. I just booted the known working system rather than the offset-GPT system, and got excited for a second.
<Armbian-Discord> <T​onymac32> I've been victimized by this
<Armbian-Discord> <T​onymac32> 😄
<Armbian-Discord> <n​armstrong> anyway all this is now documented: https://u-boot.readthedocs.io/en/latest/board/amlogic/boot-flow.html
<Armbian-Discord> <r​pardini> Yep, given the non-GPT-ness of Amlogic, my "non-plan" there for EFI is: do nothing. Armbian uboot already supports EFI; Armbian SD media will boot (in non-EFI mode), you can then use nand-sata-install to deploy to eMMC/SPI when board supports it. Then use that to EFI-mode boot whatever you want, even to/from USB or NVMe if supported.
<Armbian-Discord> <r​pardini> Alternative (but why?) is to produce SD image with uboot + MBR, and pass down kernel DTB to grub. A lot of work, just to claim "EFI boot", while still images won't be generic, instead still board specific. So I see no point.
<Armbian-Discord> <n​armstrong> yep no need to bother, but those EFI images would be useful for lafrite for example, and any board with mainlin u-boot in SPI or eMMC boot partition
<Armbian-Discord> <T​onymac32> thankfully a generic aarch64 image should be fine on those
<Armbian-Discord> <r​pardini> indeed. That's work to be done on uefi-arm64 -- it probably is missing config options at least
<Armbian-Discord> <r​pardini> I started it's .config by steal from Ubuntu's generic, but that was years ago.
<Armbian-Discord> <M​anoftheSea> "Main partition table begins at sector 1024 and ends at sector 1055" So, yeah, u-boot and systemd-boot can both use offset GPT
<Armbian-Discord> <r​pardini> yeah but would an offset-gpt uboot also work on non-offset gpt media?
<Armbian-Discord> <M​anoftheSea> I didn't change u-boot
<Armbian-Discord> <r​pardini> interesting. how are you offsetting the gpt?
<Armbian-Discord> <M​anoftheSea> sd-b claims Firmware: "UEFI 2.90 (Das U-Boot 8226.1024)"
<Armbian-Discord> <M​anoftheSea> in gdisk, expert options, GPT offset
<Armbian-Discord> <M​anoftheSea> x, j "move the main partition table"
<Armbian-Discord> <M​anoftheSea> But it doesn't move the header, which is the amlogic conflict
<Armbian-Discord> <r​pardini> yeah so no game there.
<Armbian-Discord> <r​pardini> (sharp turn) volunteers to rebase our meson64 5.19 patches against 6.1-rcX ? It seems 6.1 will be LTS, and we've just removed 5.10 from master, while having no 5.15...
<Armbian-Discord> <T​onymac32> lol
<Armbian-Discord> <n​armstrong> I started trying to make missing primary GPT table non a fatal error on Linux & U-Boot, but never finished it...
<Armbian-Discord> <T​onymac32> I can help with that since I have 2 effected boards in GXL
<Armbian-Discord> <r​pardini> Yep, there's a backup GPT at the end of media right...
<Armbian-Discord> <n​armstrong> yep, we could simply use the backup and never the primary, but any change in the partitionning should use tools that only write the backup
<Armbian-Discord> <r​pardini> true, but I think Armbian writes u-boot "last", thus destroying the GPT, but not the backup. (not sure if true of installer as well as image builder).
<Armbian-Discord> <r​pardini> Right now I think we've the most usecases already handled. We might just add instructions for users. "Use Armbian meson64-board-specific SD to install uboot to SPI/MMC, then generic uefi-arm64 on SD/eMMC/USB/NVMe/SATA"
<Armbian-Discord> <r​pardini> and I'll watch with interest what happens with EFI-through-uboot on the rk side of things 😉
<Armbian-Discord> <T​onymac32> lol I have my pine64pro booting whatever EFI image I throw at it, same for ROC-RK3399-PC
<Armbian-Discord> <T​onymac32> thank you SPI
<Armbian-Discord> <n​armstrong> and thank to those board having a decend u-boot on SPI !
<Armbian-Discord> <r​pardini> and what's in that SPI? vendor? 😛
<Armbian-Discord> <T​onymac32> No, ours 😄
<Armbian-Discord> <T​onymac32> I do have a new vendor one from LC to put on the ROC-PC, but ours worked fine
<Armbian-Discord> <r​pardini> yeah, so same principle applies there too
<Armbian-Discord> <T​onymac32> we could make a "minimal" flavor designed only to update u-boot on the flash
<Armbian-Discord> <T​onymac32> of course in theory you don't even need linux for that, just boot command it
<Armbian-Discord> <r​pardini> yeah I think uboot can read from media and write itself to SPI even....
<Armbian-Discord> <T​onymac32> I used to boot to me assembly language app using u-boot
<Armbian-Discord> <T​onymac32> it can basically do whatever you want
<Armbian-Discord> <T​onymac32> with some dinner and drinks first of course
<Armbian-Discord> <r​pardini> yeah it's easier raising things uboot can't do
<Armbian-Discord> <T​onymac32> you have to romance it or you get nowhere
<Armbian-Discord> <r​pardini> I'll have a go: - uboot can't write to ext4 fs's using checksums 😉
<Armbian-Discord> <r​pardini> but yeah, that's stretching it 😉
<Armbian-Discord> <M​anoftheSea> u-boot on SPI is why ebin is so great for testing. Also, having zero kernel patches.
<Armbian-Discord> <M​anoftheSea> But as for "backup GPT", it's in the wrong place when the image is written to media, right? The image is installed on a virtual 4 GB disk, which might be written to a larger SD card. At which point, the installed system repartitions and extends the root FS, but that doesn't do any good for first boot from backup GPT (let alone not actually having a "repair backup GPT" step)
<Armbian-Discord> <M​anoftheSea> hmm, that's interesting... I wiped the header, and u-boot claims to be using backup GPT. But it errors something like 350 times before then launching boot/bootaa64.efi
<Armbian-Discord> <M​anoftheSea> did it just scan for the gpt entries?
<Armbian-Discord> <M​anoftheSea> hmm, no, it was looking for the "EFI PART" stringas the GUID Partition Table Header
<Armbian-Discord> <M​anoftheSea> still. u-boot appears to be able to use the backup GPT. On the other hand... linux doesn't seem to be able to find the partitions for root device