[PATCH 0/4] Enable EFI Capsule on Disk on Libre Computer LePotato & LaFrite

[Anand Moon]

Hi Ferass,

Thanks, Sorry for the late reply.

On Fri, 10 Apr 2026 at 17:11, Ferass El Hafidi
<funderscore at postmarketos.org> wrote:
>
> Hi Anand,
>
> On Fri, 10 Apr 2026 10:10, Anand Moon <linux.amoon at gmail.com> wrote:
> >Hi  Ferass,
> >
> >On Thu, 9 Apr 2026 at 02:00, Ferass El Hafidi via groups.io
> ><funderscore=postmarketos.org at groups.io> wrote:
> >>
> >> Mostly everything is already in place to enable EFI capsules and in particular
> >> EFI capsule on disk.
> >>
> >> First, switch all Amlogic boards to use SYSRESET. EFI Capsule on Disk
> >> functionality expects sysreset to be present. As the current reset_cpu()
> >> function in board-common.c is basically only doing PSCI reset on U-Boot
> >> proper, we can replace it with sysreset's PSCI support, which works just
> >> fine for that purpose provided BL31 is running (SPL stays on an
> >> SoC-specific reset_cpu() which does for(;;);, as the overhead for
> >> sysreset is too high and we don't have PSCI yet at that point).
> >>
> >> Then we can enable capsule on disk. LaFrite has Capsule updates enabled
> >> already, so it is simply a matter of enabling CoD. LePotato does not
> >> have Capsule updates enabled by default, however it can be easily enabled
> >> and setup to update u-boot on eMMC/SD.
> >>
> >> With Capsule on Disk setup, it becomes possible to update U-Boot directly
> >> from Linux, without having to worry about manually using `flashprog`
> >> (for SPI flash) or `dd` (for eMMC/SD). Instead, thanks to CoD, updates
> >> can be handled by `fwupd` and applied upon next EFI boot.
> >>
> >> To test:
> >>
> >>  * build U-Boot as usual
> >>
> >>  * in that running U-Boot, run: `efidebug capsule esrt` to get the GUID
> >>    -OR-
> >>    run the following in your tree:
> >>         tools/mkeficapsule guidgen path_to_devicetree_here U_BOOT_MESON_MMC
> >>                                            (or U_BOOT_MESON_SPI on LaFrite)
> >>
> >>  * proceed with the following guide to create a capsule file:
> >>    https://docs.u-boot.org/en/latest/develop/uefi/uefi.html#enabling-uefi-capsule-update-feature
> >>
> >>  * generate a .cab file suitable for fwupd using `mkcab`:
> >>    https://gitlab.postmarketos.org/tauchgang/tauchgang-ci/-/tree/main/mkcab
> >>         mkcab u-boot-libretech-cc.capsule GUID-GOES-HERE libretech-cc "LePotato" 2026.04
> >>    (as of writing, the README.md suggests this is for Qualcomm only. It
> >>     actually does nothing that is Qualcomm-specific, and works on any
> >>     board that supports Capsule on Disk and fwupd)
> >>
> >>  * on the board itself, boot to Linux via EFI, install fwupd, copy the resulting
> >>    .cab file, and run as root:
> >>         fwupdtool --force install u-boot-libretech-cc.cab
> >>
> >>  * reboot, make sure you boot over EFI, else the capsule update will not
> >>    start
> >>
> >> Signed-off-by: Ferass El Hafidi <funderscore at postmarketos.org>
> >Thanks for your work.
> >
> >I haven't tested the EFI portion yet, but I have a few questions regarding
> >the previous commit 17d80a3b326e ("arm: meson: spl: add support for
> >SPL DRAM init").
> >Could you please clarify how you generated the Meson DRAM timing parameters?
> >
Thanks for sharing your progress on this
>
> Reverse-engineering the BL2 blob mainly, though some ancient Amlogic
> U-Boot source drops helped a lot, especially the older ones that had
> some BL2 source code. Amlogic's U-Boot source drops are a huge treasure
> of information when Amlogic's datasheets aren't enough.
>
> I documented some of my work here if you want to know more:
>         https://scm.dersco.re/amlogic/reversing-gxbb-bl2.git/about/
>
> and this is my downstream U-Boot tree I use for experiments. The
> `wip/spl` ones are the relevant branches:
>         https://scm.dersco.re/amlogic/u-boot-kii-pro.git/
>
Thanks, I will check this out.
> Amlogic also defines a few structs in their U-Boot fork, that ends up
> being used by BL2 as acs.bin. These proved valuable for reverse-engineering.
>
> >I’m curious about the boot flow since we can apparently boot U-Boot without
> >the Amlogic-signed BL1 firmware.
> >
>
> BL1 is the bootROM in Amlogic AArch64 BL terminology, so I suppose you
> mean BL2. (I'm not familiar with Meson8b, maybe BL1 means something
> else there)
> In theory BL2, on boards without secureboot fuses blown, is not signed at
> all, you can replace it with anything. For a long time, U-Boot depended
> on Amlogic's BL2 blob along with the SCP firmware blob (BL30) and their
> downstream Trusted Firmware-A blob (BL31). Since then, the TF-A blob got
> reverse-engineered and the work was upstreamed, leaving BL2 and BL30.
>

> My work replaces BL2 with U-Boot SPL to do DRAM init and load BL30, BL31
> and U-Boot proper. However, right now, this is only possible for Meson
> GXBB (S905) and GXL (S905X), though I'd like to make it happen for
> G12A/B and SM1 too. It is also still experimental, so for now to have a
> good experience, the BL2 blob is still recommended, though that will
> hopefully change soon with some polish.
>
You have done good work in reverse engineering.
> >I just wanted to understand how to upstream U-Boot for the Meson8b (Odroid C1+)
> >platform, as it’s currently stuck on a very old version (v2011). It's
> >ARM 32-bit.
> >
>
> As I understand it, Meson8b is a completely different bootflow. I'm not
> very familiar about it but I know the bootflow got redone starting with
> S905 (which also happens to be the first AArch64 SoC produced by
> Amlogic).
>
Correct, only repository I know for mesom8b
But I could not find the configuration file to build this U-Boot.
[1] https://github.com/endlessm/u-boot-meson.git
Let me check on what I can do to gather some more input on this.

> Digging in my IRC logs (#linux-amlogic on libera.chat,
> https://libera.catirclogs.org/linux-amlogic/2023-06-28#34525179),
> apparently these boot to an ARC HS core first, compared to these GXBB
> and newer SoCs. Though I don't know the details.
>
> In any case: Good luck and I hope you succeed at it!
Thanks
>
> If you have any more questions I'm happy to answer them.
>
> Best regards,
> Ferass
Thanks
-Anand