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

[Caleb Connolly]

On 2/22/25 00:20, Stephen Boyd wrote:
> Quoting Caleb Connolly (2025-02-20 17:00:30)
>> Hi Stephen,
>>
>> On 2/20/25 20:58, Stephen Boyd wrote:
>>> This series supports running U-Boot as a payload on sc7180 Trogdor
>>> Chromebooks like Lazor or Wormdingler. This is a jumble of different
>>> patches to get to the final goal of booting a Linux distro from the eMMC
>>> on Lazor. I've yet to craft a USB stick with a stock distro but I'll
>>> probably do that next week.
>>
>> \o/ wow, this is awesome!
> 
> Thanks!
> 
>>
>> 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.

> 
> 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

> 
>>>
>>> The first few patches add support for the particular SoC sc7180 used on
>>> Trogdor devices. The next set of patches move the coreboot logic out of
>>> x86 into lib to find the coreboot tables on ARM and stash them in global
>>> data. Then I have a handful of patches to let the coreboot commands and
>>> utilities parse and populate various things like pstore and DT with the
>>> proper data from the coreboot tables. Finally, I add the calls to
>>> coreboot dram parsing code in the snapdragon board so that if coreboot
>>> tables exist we get the memory info from coreboot instead of from an
>>> earlier stage DTB.
>>>
>>> I tested the spi driver with the crosec command. The cros bootflow
>>> method almost works, but it seems like chromeos userspace blows up
>>> spectacularly likely because crossystem can't figure out what board it
>>> is running on. I don't really care too much about booting chromeos
>>> userspace here so I'm going to ignore that problem and assume that I can
>>> boot some Linux distro because the eMMC can be read by U-Boot and the
>>> kernel boots.
>>
>> Guess it's time I finally get my hands on one of these devices :D
>>
> 
> I bought a Lazor from eBay for a couple hundred dollars refurbished and
> it is basically brand new because the battery was replaced. I want to
> get the display working, which I think will require me to port the dsi
> and eDP bridge code over even though coreboot would have left everything
> largely configured.

Ahh that's annoying, Coreboot doesn't just give you a framebuffer you 
can write to?

Kind regards,

-- 
Caleb (they/them)