| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 28 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 47:35:26 |
| Calls: | 422 |
| Files: | 1,024 |
| Messages: | 90,399 |
Is there some sort of USB boot manager for Raspberry Pi versions
that don't have an EEPROM? I'm thinking of armv7 Pi2 and early Pi3.
Bootcode.bin on an otherwise blank msdos microsd partition works,
but seemingly only with a single USB drive connected. A second
USB disk left in place by mistake caused the machine to hang.
Something installed on a microSD that finds and reports bootable
USB drives, defaulting to the last one used, would be ideal.
This video from about 2016 suggests it's already been done: https://www.youtube.com/watch?v=bNL1pd-rwCU
But, no implementations turned up in a web search. All the boot
manager references I found seemed to involve the Pi4. I'm interested
in using older machines already on hand. As it happens, most of
my machines run FreeBSD which uses u-boot as an intermediate step
but I don't think that matters.
bp@www.zefox.net wrote:
Is there some sort of USB boot manager for Raspberry Pi versions
that don't have an EEPROM? I'm thinking of armv7 Pi2 and early Pi3.
Bootcode.bin on an otherwise blank msdos microsd partition works,
but seemingly only with a single USB drive connected. A second
USB disk left in place by mistake caused the machine to hang.
Something installed on a microSD that finds and reports bootable
USB drives, defaulting to the last one used, would be ideal.
This video from about 2016 suggests it's already been done:
https://www.youtube.com/watch?v=bNL1pd-rwCU
But, no implementations turned up in a web search. All the boot
manager references I found seemed to involve the Pi4. I'm interested
in using older machines already on hand. As it happens, most of
my machines run FreeBSD which uses u-boot as an intermediate step
but I don't think that matters.
There's no reason why you can't use u-boot as a boot manager for Linux too.
Many non-Pi Linux boards do this. However it'll only handle the Linux
kernel - if you have different firmware, config.txt etc then u-boot is unaware of that - it runs too late in the boot process to change those things. Really u-boot can only change the Device Tree, kernel,
initramfs and kernel environment (variables, command line). U-boot is running on the CPU, and so can't affect the GPU which is booted first on Pis 1-3.
EDK2, a UEFI bootloader (similar to a PC BIOS) is also a possibility, but
the same limitations will apply.
Theo <theom+news@chiark.greenend.org.uk> wrote:
Many non-Pi Linux boards do this. However it'll only handle the Linux kernel - if you have different firmware, config.txt etc then u-boot is unaware of that - it runs too late in the boot process to change those things. Really u-boot can only change the Device Tree, kernel,
initramfs and kernel environment (variables, command line). U-boot is running on the CPU, and so can't affect the GPU which is booted first on Pis
1-3.
AIUI, the
kernel=u-boot.bin
line in config.txt tells which binary to load and run from the msdos partition on the (single) USB disk found if there's nothing visible
on microSD.
EDK2, a UEFI bootloader (similar to a PC BIOS) is also a possibility, but the same limitations will apply.
There's been some discussion in the FreeBSD lists about using EDK2, but I believe it's still rather preliminary. I certainly didn't understand much.
At one time it was possible to allow bootcode.bin to start u-boot on the microSD card and then issue
run bootcmd_usb0
to start the bootchain on a USB drive. That command seems to have been dropped in the time since from the version of u-boot shipped with FreeBSD.
But, the problem with multiple connected disks remains.
I was hopeful that something like a microsd with grub (or equivalent)
for the Pi1-3 had been developed.
bp@www.zefox.net wrote:
Theo <theom+news@chiark.greenend.org.uk> wrote:
Many non-Pi Linux boards do this. However it'll only handle the Linux
kernel - if you have different firmware, config.txt etc then u-boot is
unaware of that - it runs too late in the boot process to change those
things. Really u-boot can only change the Device Tree, kernel,
initramfs and kernel environment (variables, command line). U-boot is
running on the CPU, and so can't affect the GPU which is booted first on Pis
1-3.
AIUI, the
kernel=u-boot.bin
line in config.txt tells which binary to load and run from the msdos
partition on the (single) USB disk found if there's nothing visible
on microSD.
OK, so that's u-boot dressed up as a Linux kernel. It then starts u-boot on the CPU. Until this point everything is GPU - bootcode.bin is code for the GPU (not to be confused with anything.bin for the CPU). Once you're in u-boot it then loads the kernel and jumps to it.
EDK2, a UEFI bootloader (similar to a PC BIOS) is also a possibility, but >> > the same limitations will apply.
There's been some discussion in the FreeBSD lists about using EDK2, but I
believe it's still rather preliminary. I certainly didn't understand much.
Best avoided I think.
At one time it was possible to allow bootcode.bin to start u-boot on the
microSD card and then issue
run bootcmd_usb0
to start the bootchain on a USB drive. That command seems to have been
dropped in the time since from the version of u-boot shipped with FreeBSD.
'bootcmd_usb0' is a script that's been set up somewhere in your u-boot environment. Try 'printenv bootcmd_usb0' and you'll see the u-boot commands it's issuing. You can issue them by hand if you like, or change them.
Often the scripts come from a file (*.scr? uEnv.txt?) on the storage that
the u-boot binary was loaded from. You can edit that file.
But, the problem with multiple connected disks remains.
Handy u-boot command reference: https://hub.digi.com/dp/path=/support/asset/u-boot-reference-manual/
If you do 'printenv' you can see all the u-boot variables and scripts that have been defined. This is RISC-V, but Arm is similar:
https://adventurist.me/posts/00315
That one is a bit convoluted, but usually you do something like:
fatload mmc 0:1 0x40000000 kernel.bin
fatload mmc 0:1 0x41000000 devicetree.dtb
booti 0x40000000 - 0x41000000
to load the kernel and the device tree from SD card (MMC) device 0:1 to a specific address and then boot from those addresses. I don't know what the Pi uses for base addresses but you should be able to find out from printenv. For USB the device name will be different, eg 'usb X:Y' for some numbers X and Y. If you take your existing script and type it in by hand while changing the 'mmc' to 'usb' then you may be able to boot from the kernel on the USB.
There is likely also a variable that contains the location of the rootfs.
On FreeBSD that would likely be /dev/mmcsdX for SD card and /dev/daX for
USB. You'd likely also need to fix that (via 'setenv') so it used the
rootfs on the USB and not the SD.
I was hopeful that something like a microsd with grub (or equivalent)
for the Pi1-3 had been developed.
Grub is mostly a PC thing. There's a version for EFI which will run on
Arm, but now you're adding two more bootloader steps (EDK2+Grub).