[PATCH 00/16] bootstd: Improve ChromiumOS support

[Alper Nebi Yasak]

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

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