Hi Alper, On Fri, 4 Aug 2023 at 03:51, Alper Nebi Yasak <alpernebiya...@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 <alpernebiya...@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
