Re: U-Boot for Raspberry Pi

[phodina <phodina@protonmail.com>]

Hi vagrant,

On Sunday, October 31st, 2021 at 12:05 AM, Vagrant Cascadian <vagrant@debian.org> wrote:

> On 2021-10-30, phodina via wrote:
>
> > I'm trying to run Guix System on Raspberry Pi. In order to do that we
> >
> > need a way to boot it up.
> >
> > There is the nonfree Broadcom bootloader, which does the job and it's
> >
> > used by many distributions.
> >
> > However, there is also an open source alternative as U-Boot supports
> >
> > the BCM SoCs.
>
> Well, you still need to load u-boot from the broadcom
>
> firmware/bootloader...

Yes, unfortunately you are right. The VC4 GPU core is started first and requires
the closed source binaries (bootcode.bin, start.elf and fixup.dat).

Also no disrespect was meant to the Guix help mailing list. I thought the closed source code could
be avoided.

>
> > If I inherit from the u-boot itself and specify the name, it's then in the list and I can build it.
> >
> > But the I can't use the package for the bootloader record.
> >
> > There must be something trivial I had overlooked.
> >
> > Could you please guide me on the procedure for porting the u-boot to new board as a new Guix package?
>
> There are install targets defined in gnu/bootloader/u-boot.scm, though
>
> most (all?) of those targets install to a raw device offset, whereas
>
> u-boot for the rpi needs u-boot.bin to be copied to your firmware
>
> partition and needs to be specified as a "kernel" in config.txt, if I
>
> recall correctly.

As you correctly pointed out that you can specify in the config.txt the next executable
to be loaded which in this case is the u-boot.

Also with U-boot it's the usually the case that you place it at specific flash location.

However, Raspberry Pi has BootRom which is able to access FAT file system
and load files from there. Therefore the SD card has to be formatted with
MBR layout, FAT boot partition and then let's say Linux root partition.

>
> > (define-public u-boot-raspberry-pi-4
> >
> > (make-u-boot-package "rpi_4" "aarch64-linux-gnu"))
>
> I would also try to keep the u-boot-BOARD matching the defconfig,
>
> e.g. u-boot-rpi-4 instead of u-boot-raspberry-pi-4. Not for any
>
> technical reason, per se, just keeping the u-boot target naming
>
> consistent.

Good idea. Though the longer version would be more readable.

>
> You might want to just build the u-boot package, and then manually copy
>
> it to your firmware partition and configure that appropriately once, and
>
> then just use guix to generate and update the extlinux.conf... I forget

That's the point of my original question as I created this package definition.
It builds fine and all the files are there. But as stated above can't be passed
to the bootloader record in the operating-system.

(define-public u-boot-rpi-2
  (let ((base (make-u-boot-package "rpi_2" "arm-linux-gnueabihf")))
  (package
  (inherit base)
  (name "uboot-rpi-2"))))

The contents of the package are here:

tree /gnu/store/77syxs86n0c52pslnzfsn9xzv1dzmxhc-uboot-rpi-2-2021.10/libexec
/gnu/store/77syxs86n0c52pslnzfsn9xzv1dzmxhc-uboot-rpi-2-2021.10/libexec
├── arch
│   └── arm
│       └── dts
│           ├── bcm2835-rpi-a.dtb
│           ├── bcm2835-rpi-a-plus.dtb
│           ├── bcm2835-rpi-b.dtb
│           ├── bcm2835-rpi-b-plus.dtb
│           ├── bcm2835-rpi-b-rev2.dtb
│           ├── bcm2835-rpi-cm1-io1.dtb
│           ├── bcm2835-rpi-zero.dtb
│           ├── bcm2835-rpi-zero-w.dtb
│           ├── bcm2836-rpi-2-b.dtb
│           ├── bcm2837-rpi-3-a-plus.dtb
│           ├── bcm2837-rpi-3-b.dtb
│           ├── bcm2837-rpi-3-b-plus.dtb
│           └── bcm2837-rpi-cm3-io3.dtb
├── doc
│   └── README.commands.spl
├── dts
│   └── dt.dtb
├── lib
│   └── efi_loader
│       └── helloworld.efi
├── scripts
│   └── Makefile.spl
├── tools
│   └── binman
│       └── test
│           └── descriptor.bin
├── u-boot
├── u-boot.bin
└── u-boot-nodtb.bin

>
> the exact syntax to generate extlinux.conf without actually installing
>
> u-boot, but I've done it in the past.

So do I now need to define a new bootloader target in gnu/bootloader/u-boot.scm,
where instead of writing directly to the image follow more the pattern of function
install-grub-efi, where based on the UEFI you also need to have EFI FAT partition
and just copy the files over to their correct location?

>
> Another option would be to build the raspberry pi UEFI (not 100% sure of
>
> the licensing, but reasonably free) instead of u-boot, and then use
>
> guix's standard UEFI configuration with grub-efi and such.

Then I can treat the closed source firmware to boot as UEFI and
just package the u-boot, right?

>
> live well,
>
> vagrant