Hi Vagrant, On Sun, 06 Jun 2021 14:38:27 -0700 Vagrant Cascadian wrote: > So, I've managed to get a single image that supports booting both the > Pinebook and Pinebook Pro reasonably well! I can pop the microSD card > out of one and put it into the other, and it boots! Awesome! > The only problem with my single image for multiple pinebooks variants is > it requires manually installing u-boot to different offsets for Pinebook > Pro (e.g. idbloader.img at sector 2112 rather than sector 64), >as parts of the Pinebook bootloader are installed at overlapping offsets. Uhhh? Doesn't sound possible to me then to use the same image for both? I'm probably missing something. > But as I understand it, guix only supports a single bootloader entry. That is correct. > To support all of the above, I would need three separate bootloader > instances... one for Pinebook, one for Pinebook Pro, and lastly a > grub-efi bootloader. Stefan wrote a Guix chain bootloader that is in master--but it's meant to be only used for bootloaders where there is a primary "bare-metal-loaded" bootloader and the others are chain-loaded one-after-another from ONE filesystem (for example Raspberry Pi and/or EFI bootloaders). (It's currently used in order to use an EFI bootloader hosted on NFS--which is an awesome way to manage embedded boards) The chain bootloader itself is one Guix bootloader. I advise you to search for mails by Stefan on the guix-devel mailing list--those are very illuminating. > Installing u-boot-pinebook uses: > (define install-allwinner64-u-boot > #~(lambda (bootloader root-index image) > (let ((spl (string-append bootloader "/libexec/u-boot-sunxi-with-spl.bin")) > (u-boot (string-append bootloader "/libexec/u-boot-sunxi-with-spl.fit.itb"))) > (write-file-on-device spl (stat:size (stat spl)) > image (* 8 1024)) > (write-file-on-device u-boot (stat:size (stat u-boot)) > image (* 40 1024))))) > > Installing u-boot-pinebook-pro-rk3399 uses: > > (define install-rockpro64-rk3399-u-boot > #~(lambda (bootloader root-index image) #~(lambda* (bootloader root-index image #:key idb-destination-offset) > (let ((idb (string-append bootloader "/libexec/idbloader.img")) > (u-boot (string-append bootloader "/libexec/u-boot.itb"))) > (write-file-on-device idb (stat:size (stat idb)) > image (* 64 512)) image (or idb-destination-offset (* 64 512))) > (write-file-on-device u-boot (stat:size (stat u-boot)) > image (* 16384 512))))) > > (define install-pinebook-pro-rk3399-u-boot install-rockpro64-rk3399-u-boot) > > But now I need to figure out how to pass a non-default offset for the > "idb" part for rockchip platforms. > > In a system config.scm, you'd define it like so: > > (bootloader (bootloader-configuration > (bootloader u-boot-pinebook-pro-rk3399-bootloader) > (target "/dev/mmcblk0"))) > > u-boot-pinebook-pro-rk3399-bootloader is defined in > gnu/bootloader/u-boot.scm, which inherits from u-boot-bootloader, which > inherits from extlinux-bootloader in gnu/bootloader/extlinux.scm... > > And somewhere along the way I've lost track of how we get to > install-pinebook-pro-rk3399-u-boot... It's in the "bootloader" record, field "disk-image-installer". If you search for "bootloader-disk-image-installer" in the Guix source code, you find the (two) callers of it. > Is it possible to definte multiple bootloaders [in the same operating-system] currently, No--and I don't think that would have any advantages. If the thing is not a chain then Guix doesn't need to logically split the bootloaders in the first place. Ok: stage1 -> stage2 -> stage3 represented as (chain-bootloaders stage1 stage2 stage3). Not ok: stage1-arch1 stage1-arch2 represented as two different bootloaders that both are specified in the same operating-system inside the same list. Instead, I think it's fine to just model that as one "weird" bootloader (arm64-pinebook-generic-bootloader)--especially if both use u-boot anyway and also especially if they reuse some of their parts anyway (it's gonna have weird interdependencies in any case--so any apparent modularity would just be a ruse). > or if not, > what would need to change to be able to support that? Where would one > pass non-default offsets for a given platform? Could you elaborate on what you mean? Pass where? On the Guix command line? If you mean the disk-image-installer, that's just a procedure (which is run build-side). You can make it do whatever you want--including hardcoding weird offsets. I'm pretty sure it gets the entire image (one could potentially mangle) as a parameter anyway. > Strictly speaking, the extlinux.conf generation would be optional for an > EFI generated image(as u-boot can load grub-efi), although at the moment > I'd prefer using extlinux.conf if available as it makes for more > consistent matching of device-tree/.dtb file with the running kernel... If you do want to chainload grub-efi eventually, that's supported in Guix master, see "efi-bootloader-chain". It's meant for the end user to be able to use. > A related idea would be to generate an EFI bootable image with > sufficient emtpy space before the first partition (16MB) and then one > could manually install the appropriate u-boot, maybe with some helper > scripts to avoid having to do it completely manually... Yeah, that's possible right now. After all, you don't have to load the generated guix system disk image on bare metal. Just boot it in qemu and install u-boot there for example. Or even edit the image manually by using dd. (unfortunately, on almost every ARM system I set up Guix on so far, one or both of those were necessary) That said, it's nice to have officially supported ARM systems where you can just generate a disk image and it will boot without having to do weird extra stuff outside Guix. (In general, I want to reiterate that the buildroot project already has genimage scripts for almost all ARM boards--and Guix uses genimage anyway! It makes a lot of sense to write an importer for those instead of reinventing the wheel. You really do not want to develop & maintain u-boot installation recipes for all 34432 ARM variants out there yourself--just use the recipes already developed instead)