(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@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#sele...
- 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?