On 2/25/25 21:49, Stephen Boyd wrote:
Quoting Caleb Connolly (2025-02-24 06:30:43)
you might have some luck booting pmOS, we build depthcharge compatible
images for trogdor
https://images.postmarketos.org/bpo/edge/google-trogdor/
There's also a generic ARM64 EFI image that should work. You may need to
edit the image and remove efi/systemd/drivers/dtbloader.efi from the ESP:
https://images.postmarketos.org/bpo/edge/postmarketos-trailblazer/
Cool thanks for the pointers. I'm loading u-boot as a payload from
depthcharge so that I don't have to remove the write protect on the
flash. It's the altfw boot method.
I tried to boot the Debian ISO from a USB stick but it looks like the
FDT memory node isn't modified when I use u-boot to load the DTB from
the one flashed to the eMMC for the ChromeOS installation. Does the
efi_dt_fixup_protocol run in that case? I've never tried any of this
stuff before so I'm learning while I go.
The /memory node isn't used when booting with EFI, some EFI table is
used instead. I also don't think we use the DT fixup protocol in
mach-snapdragon so that should be a no-op.
Oh right, thanks. It's been almost a decade since I booted anything from
EFI :)
I've been using this sort of flow to read the DTB from the FIT image
that chromeos has:
bootflow scan -l
bootflow select 2 # Select the MMC partition for cros bootmethod
bootflow read
bootflow info
fit=$hex_address_for_FDT_from_info_above
imxtract ${fit} fdt-22 ${fdt_addr_r} # fdt-22 matches my board variant
fdt addr ${fdt_addr_r}
load usb 0:2 ${kernel_add_r} /EFI/BOOT/BOOTAA64.EFI
bootefi ${kernel_addr_r} ${fdt_addr_r}
This seems to work to get me to the installation menu but then when I
run installation the kernel doesn't boot and it looks like memory hasn't
been updated per the earlycon info that I see. I'll continue
That's weird indeed.
I think once the FDT is loaded you can just run "bootefi" with no
arguments and it should pick up the USB drive automatically.
If you have some logs I'd be happy to take a look? You can find me
@calebccff in #u-boot-qcom on libera.chat
I figured it out. There were 2 problems with Debian. First, Debian uses
the coreboot framebuffer driver and it is missing commit ecea08916418
("firmware: coreboot: framebuffer: Avoid invalid zero physical
address"). This causes the system to crash pretty early because it tries
to create a framebuffer when coreboot doesn't provide one. The second
problem is that the kernel is so old on the netinst ISO I was using that
it doesn't enable any drivers for SC7180. I can block the coreboot
framebuffer driver from loading on the kernel commandline but then the
problem is that the mmc can't be mounted and the serial console doesn't
work because things like the clk driver and pinctrl driver never probe.
yeahhh distro support for qcom is still in it's infancy really, at least
on pmOS we can mostly rule out missing modules for this platform since
it's already for sure supported.
I tried flashing Fedora 41 Workstation to a USB stick and it "just
works" after loading the DTB from the FIT image stored on eMMC. How is
Nice! Glad to see Fedora has the right options enabled
this supposed to work in general? Should I be storing the DTB on disk so
The SystemReady approach is that firmware provides the FDT, if you don't
pick a DTB then the one that U-Boot itself was using will be passed
through instead, this ought to work assuming there isn't too much churn
in the DT upstream (and assuming you keep U-Boot up to date, I'd really
like to spend some time on LVFS at some point...)
However, acknowledging the limitations of this approach, there's a few
pieces that move together to try and load the DTB from some well-known
paths on the ESP:
1. efi_load_distro_fdt() - this is called into in the "bootefi bootmgr"
path (which is what you should be using fyi, see also eficonfig) if you
don't provide an FDT explicitly and will search for $fdtfile in /, /dtb,
/dtb/current, and /dtbs. This works on a few distros but not e.g. debian
which puts everything under a versioned path.
2. $fdtfile - the filename of the DTB to load has to come from
somewhere, in mach-snapdragon/board.c we have some basic logic in
configure_env() which tries to piece this together from the root
compatible array.
The $fdtfile logic is not flawless, it only works on boards that follow
a specific pattern in their compatible and filename, it just happens to
work for most of the basic ones. I would be happy to see this logic
expanded though.
that U-Boot can pick it up somehow? I don't really want to write the
kernel's DTB to the flash, but I suppose I could do that if necessary.
Eventually I'll need to parse a FIT image looking for the right DTB that
matches the SKU and board ID that coreboot tells me U-Boot is running
on so that the proper display bridge is used. Right now I'm just
hard-coding this all.
Ahh that's annoying, Coreboot doesn't just give you a framebuffer you
can write to?
Yeah, on ARM64 coreboot leaves that up to the payload. Once the DSI and
DSI-to-eDP bridge code is ported over to U-Boot I should be able to get
a console on the display instead of over serial. I'll work on that next.
--
Caleb (they/them)
