[PATCH 00/12] Support to run U-Boot on sc7180 Trogdor Chromebooks

[Caleb Connolly]

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)