[PATCH 00/16] bootstd: Improve ChromiumOS support

[Simon Glass]

Hi Alper,

On Fri, 4 Aug 2023 at 03:51, Alper Nebi Yasak <alpernebiyasak at gmail.com> wrote:
>
> (Note that I'm not objecting to merging the patchset as is, just
> detailing future work you/I might want to do for non-CrOS userspace
> support for this bootmeth.)
>
> On 2023-08-04 06:02 +03:00, Simon Glass wrote:
> > On Thu, 3 Aug 2023 at 15:31, Alper Nebi Yasak <alpernebiyasak at gmail.com> wrote:
> >> I guess it boils down to:
> >>
> >> - Enable booting from any chromeos_kernel partition (not just 2 & 4)
> >
> > How do you know which ones hold kernels, and which root disks
> > correspond to each kernel?
>
> You should search all those with FE3A2A5D-4F32-41A7-B725-ACCC3285A309 as
> their GPT partition type GUID. They are ordered wrt/ the type-specific
> Successful, Priority, Tries attribute flags (bits 56, 55-52, 51-48). The
> firmware is also supposed to modify these (decrement Tries on each boot
> attempt, set Priority = 0 if Tries == 0). All these are stock
> depthcharge behaviour, see ChromiumOS docs [5].
>
> The kernels don't necessarily correspond to a specific root, that's a
> per-OS concept. For example on Debian, I have two or three of these
> partitions for the same rootfs used in a cyclic fashion to have
> A/B-style automatic fallback for kernel/initramfs changes. And there may
> not be a rootfs at all, like how Debian Installer runs entirely from its
> initramfs.

OK I see.

>
> [5] ChromiumOS Docs - Disk Format - Selecting the kernel
> https://chromium.googlesource.com/chromiumos/docs/+/HEAD/disk_format.md#selecting-the-kernel
>
> >> - Fixup the ramdisk addr/size in x86 setup info after reading the kernel
> >
> > But ChromeOS doesn't use ramdisk, right?
>
> Not in this way, AFAIK it embeds one into vmlinuz during compile-time? I
> guess the ramdisk addr/size in x86 setup is 0/0 for ChromeOS indicating
> there isn't (an external) one.
>
> But depthcharge is so minimalistic that it loads everything at a fixed
> address and passes x86 setup unchanged as prepared beforehand, so I can
> append a ramdisk to vmlinuz and tell Linux where that will end up in
> memory behind depthcharge's back. (A bit more complicated than that.)
>
> So the thing is, when bootmeth_cros reads the "kernel" data into memory
> somewhere other than 0x100000, the x86 setup from my images will be
> pointing to an unrelated location as the ramdisk, which Linux will fail
> to interpret as a ramdisk and panic.
>
> >> - Prepend cros_secure to kernel cmdline
> >
> > Does it have to be at the start of the cmdline? Also, the cmdline
> > comes from cros at present, so does include that normally.  I think
> > the best way is for you to give it a try and see what is needed.
>
> Doesn't have to be at the start, but Depthcharge unconditionally
> prepends it, I do see multiple "cros_secure"s on ChromeOS /proc/cmdline.
>
> I'd like to have that here too as a way to identify the boot method,
> since non-CrOS userspaces will not have configured cmdline to have that.
> In Debian Installer, I do `grep cros_secure /proc/cmdline` to see if we
> should set up with depthcharge-tools or something else like GRUB.
>
> (Yeah, I should be testing this, but stretched myself too thin.)
>
> >> There's a ready made debian-installer image if you want to test [2]. Has
> >> a partitioning bug defaulting to MBR, but otherwise can install for CrOS
> >> verified boot as well. (It's what took my last year away from U-Boot).
> >>
> >> [1] depthcharge-tools -- Tools to manage the Chrome OS bootloader
> >> https://github.com/alpernebbi/depthcharge-tools
> >>
> >> [2] Debian Installer netboot image for amd64 Chromebooks
> >> https://d-i.debian.org/daily-images/amd64/daily/netboot/depthcharge/
> >
> > I see the installer, but how do I actually run it on bob, say?
>
> I hoped the names were self-evident, but I know I should be writing docs
> on them, just postponing until they are in better shape.
>
> Basically `gzip -d <disk.img.gz | dd of=/dev/sdX` to a USB flash drive
> or microSD card. It's an compressed GPT disk image containing just one
> partition. With stock depthcharge, switch to Developer Mode, insert the
> drive/card and press Ctrl+U on the "OS verification is disabled"
> warning. With U-Boot and bootmeth_cros I think you would at least need
> to patch it for the first partition, and for the ramdisk address.
>
> But the arm64 one won't work on stock depthcharge at all, since pre-2018
> devices like bob have an ugly size limit this doesn't yet fit into, and
> anything else lacks kernel support on the Debian side.
>
> ... So maybe try the amd64 one on brya?

Well I think I will apply this series (with a fix I found) and we can
go from there.

I will look at using the EFI partition type to detect kernels. I will
also see if I can get a test into CI for the ChromiumOS bootmeth,
since it isn't much use without tests.

Then perhaps you might have time to enhance it from there for your use case?

I do imagine one day resurrecting the 2021-era vboot in U-Boot, as a
proper bootmeth, but I am not sure when.

The kernel situation on ARM sounds a little grim. I will check
internally to see if I can figure that out.

Regards,
Simon