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.
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
this supposed to work in general? Should I be storing the DTB on disk so
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.
