| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 28 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 52:38:35 |
| Calls: | 422 |
| Files: | 1,025 |
| Messages: | 90,577 |
Twice now a Paspberry Pi 2 v1.1 using the bootcode.bin-only
method to boot from usb mass storage has abruptly
stopped finding the mass storage device, or so it seems.
The machines are actually running freebsd, but the failures
are seemingly too early in the boot process to get anywhere
close to freebsd files.
In both cases, the failures occurred "out of the blue" during
a normal reboot with no change to the system. I've monitored
power supply voltage during boot, it stays above 5.2 volts,
measured via one of the usb ports, on both powered hub and Pi2.
Here's a transcript:
Raspberry Pi Bootcode
Found SD card, config.txt = 0, start.elf = 0, recovery.elf = 0, timeout = 0 Trying USB
Set address 4
Num devices = 1, addr = 4
get_config_descriptor 41 bytes
Initialise hub
Found 5 ports, multi_tt = 1
Setting interface 0
Enabling PORT POWER on port 1
Enabling PORT POWER on port 2
Enabling PORT POWER on port 3
Enabling PORT POWER on port 4
Enabling PORT POWER on port 5
Waiting for devices to respond to reset
Found device on port 1
Found highspeed device
Set address 5
Num devices = 2, addr = 5
get_config_descriptor 39 bytes
device class = 255
Device found: type = Ethernet adapter, addr = 5
Found device on port 3
Found highspeed device
Set address 6
Num devices = 3, addr = 6
get_config_descriptor 41 bytes
device class = 9
Hub device found at addr 6, enumerating HUB
Initialise hub
Found 4 ports, multi_tt = 1
Setting interface 0
Enabling PORT POWER on port 1
Enabling PORT POWER on port 2
Enabling PORT POWER on port 3
Enabling PORT POWER on port 4
Waiting for devices to respond to reset
Found device on port 3
Ignoring low speed device
Found device on port 2
Ignoring low speed device
Found device on port 4
Ignoring low speed device
Found device on port 4
Device failed to respond to reset
Trying booting from Ethernet device addr 5
At this point the Pi goes into a netboot loop. It doesn't seem to
activate the disk drive apart from one blink of the activity LED.
The Pi still boots from a Bookworm microSD, so
it doesn't look like a broken Pi2. I've been
using the version of bootcode.bin linked at https://github.com/raspberrypi/firmware/blob/master/boot/bootcode.bin
from the page at https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#raspberry-
pi-boot-modes
but didn't change anything betwen working and not.
I notice that the narrative at that page is somewhat tangled.
In one, and so far only one, instance the Pi booted sucessfully
during a sequence of tests while makeing and re-making USB connections.
That led me to suspect a loose plug, but multiple repetitions, moving
all plugs, didn't repeat the success.
Can bootcode.bin pick up any parameters (other than noting the
presence of a timeout file) from any files placed on the microSD?
Thanks for reading,
bob prohaska
Can bootcode.bin pick up any parameters (other than noting the
presence of a timeout file) from any files placed on the microSD?
On 25/03/2025 14:48, bp@www.zefox.net wrote:
Twice now a Paspberry Pi 2 v1.1 using the bootcode.bin-only
method to boot from usb mass storage has abruptly
stopped finding the mass storage device, or so it seems.
The machines are actually running freebsd, but the failures
are seemingly too early in the boot process to get anywhere
close to freebsd files.
In both cases, the failures occurred "out of the blue" during
a normal reboot with no change to the system. I've monitored
power supply voltage during boot, it stays above 5.2 volts,
measured via one of the usb ports, on both powered hub and Pi2.
Here's a transcript:
Raspberry Pi Bootcode
Found SD card, config.txt = 0, start.elf = 0, recovery.elf = 0, timeout = 0 >> Trying USB
Set address 4
Num devices = 1, addr = 4
get_config_descriptor 41 bytes
Initialise hub
Found 5 ports, multi_tt = 1
Setting interface 0
Enabling PORT POWER on port 1
Enabling PORT POWER on port 2
Enabling PORT POWER on port 3
Enabling PORT POWER on port 4
Enabling PORT POWER on port 5
Waiting for devices to respond to reset
Found device on port 1
Found highspeed device
Set address 5
Num devices = 2, addr = 5
get_config_descriptor 39 bytes
device class = 255
Device found: type = Ethernet adapter, addr = 5
Found device on port 3
Found highspeed device
Set address 6
Num devices = 3, addr = 6
get_config_descriptor 41 bytes
device class = 9
Hub device found at addr 6, enumerating HUB
Initialise hub
Found 4 ports, multi_tt = 1
Setting interface 0
Enabling PORT POWER on port 1
Enabling PORT POWER on port 2
Enabling PORT POWER on port 3
Enabling PORT POWER on port 4
Waiting for devices to respond to reset
Found device on port 3
Ignoring low speed device
Found device on port 2
Ignoring low speed device
Found device on port 4
Ignoring low speed device
Found device on port 4
Device failed to respond to reset
Trying booting from Ethernet device addr 5
At this point the Pi goes into a netboot loop. It doesn't seem to
activate the disk drive apart from one blink of the activity LED.
The Pi still boots from a Bookworm microSD, so
it doesn't look like a broken Pi2. I've been
using the version of bootcode.bin linked at
https://github.com/raspberrypi/firmware/blob/master/boot/bootcode.bin
from the page at
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#raspberry-
pi-boot-modes
but didn't change anything betwen working and not.
I notice that the narrative at that page is somewhat tangled.
In one, and so far only one, instance the Pi booted sucessfully
during a sequence of tests while makeing and re-making USB connections.
That led me to suspect a loose plug, but multiple repetitions, moving
all plugs, didn't repeat the success.
Can bootcode.bin pick up any parameters (other than noting the
presence of a timeout file) from any files placed on the microSD?
Thanks for reading,
bob prohaska
Have tried another known good USB cable?
Theo <theom+news@chiark.greenend.org.uk> wrote:
bp@www.zefox.net wrote:
Can bootcode.bin pick up any parameters (other than noting the
presence of a timeout file) from any files placed on the microSD?
No idea, but one problem I've had in the past is that USB devices can take a
while to initialise, and it varies quite a bit between devices. This could be a reason why boots will sometimes fail - especially with eg spinning HDD.
Often it was necessary to add an explicit delay so that system didn't try to
read them before they were ready. I think on Linux the kernel cmdline options were 'rootwait' and 'rootdelay' but I don't know if bootcode.bin has
any kind of setting like that.
I've tried with and without the presence of a timeout file on the
fat32 partition of the microSD, far as I can tell it makes no
difference once things start going wrong. I do use it out of habit.
Does bootcode.bin pay any attention to config.txt? I thought it did,
but am not sure it has any effect on USB mass storage boot. The docs
say don't use any extra files on the fat32 partition.
bp@www.zefox.net wrote:
Can bootcode.bin pick up any parameters (other than noting the
presence of a timeout file) from any files placed on the microSD?
No idea, but one problem I've had in the past is that USB devices can take a while to initialise, and it varies quite a bit between devices. This could be a reason why boots will sometimes fail - especially with eg spinning HDD.
Often it was necessary to add an explicit delay so that system didn't try to read them before they were ready. I think on Linux the kernel cmdline options were 'rootwait' and 'rootdelay' but I don't know if bootcode.bin has any kind of setting like that.
I've even tried different usb-sata bridges. One in particular
with an ASMT chipset that seemed to work everywhere else I tried
it fails to boot. Plugged into a running Pi, or any other host,
the disk seems to work fine with whatever bridge I try.
Probably this is just a limitation of the Pi2 v1.1 USB system.
I've got another Pi2v1.1 with an old PATA disk roughly as old
as the Pi2, that combo seems to work fine.
It just crossed my mind that I have another USB hard disk nearly
as old as the Pi2. Maybe that could serve as a sanity check.
Oops, guess not. It's a Western Digital MyBook, a NAS device.
Rats!
It may still work on the Pi 2B, but being slower you may need to
increase the value of rootwait in cmdline.txt - particularly if it is a spinning disc rather than an SSD - it could take 60 seconds before the
drive is readable.
druck <news@druck.org.uk> wrote:
It may still work on the Pi 2B, but being slower you may need to
increase the value of rootwait in cmdline.txt - particularly if it is a
spinning disc rather than an SSD - it could take 60 seconds before the
drive is readable.
I think the problem here is that start.elf, config.txt, the kernel and cmdline.txt are all on the USB device - you can't put a timeout in cmdline.txt because by that point you already need the USB device up to read that file.
The alternative approach would be to have a regular bootcode.bin, start.elf, kernel, etc on the SD card and then tell the kernel to find its rootfs on a USB drive, at which point rootwait may help. (I think Bob is using FreeBSD but there is probably an equivalent option there). Or to interpose u-boot for the 'kernel' on the SD card, and then tell u-boot to find the kernel on USB.
I believe that config.txt is consumed by the GPU-side firmware, which is start*.elf. bootcode.bin is just enough to be able to load start.elf
and config.txt from storage. I'd guess that if that storage is USB, it's
too early to have read config.txt.
Theo <theom+news@chiark.greenend.org.uk> wrote:
I believe that config.txt is consumed by the GPU-side firmware, which is
start*.elf. bootcode.bin is just enough to be able to load start.elf
and config.txt from storage. I'd guess that if that storage is USB, it's
too early to have read config.txt.
It looks like the path of least resistance is to let FreeBSD boot from microSD, mount that as root and then mount the USB disk as /usr, with
/var/, /tmp/ and swap mounted from the USB device, either as links
to /usr or maybe as hard partitions.
That worked fine in the very early days of FreeBSD on the Pi2.
There isn't much write activity to the root filesystem in a
"production" environment, only during OS upgrades. If the microSD
is sufficiently oversized it'll last long enough.
I'd hoped bootcode.bin could be upgraded/tuned to boot from a
USB3 disk on a Pi2, but apparently not.
Thanks to everyone for writing!
bob prohaska
On 27/03/2025 15:53, Theo wrote:
druck <news@druck.org.uk> wrote:
It may still work on the Pi 2B, but being slower you may need to
increase the value of rootwait in cmdline.txt - particularly if it is a
spinning disc rather than an SSD - it could take 60 seconds before the
drive is readable.
I think the problem here is that start.elf, config.txt, the kernel and cmdline.txt are all on the USB device - you can't put a timeout in cmdline.txt because by that point you already need the USB device up to read
that file.
The alternative approach would be to have a regular bootcode.bin, start.elf,
kernel, etc on the SD card and then tell the kernel to find its rootfs on a USB drive, at which point rootwait may help. (I think Bob is using FreeBSD but there is probably an equivalent option there). Or to interpose u-boot for the 'kernel' on the SD card, and then tell u-boot to find the kernel on USB.
That's the only way it works on older devices.
On 29/03/2025 04:47, bp@www.zefox.net wrote:
I've yet to figure out what the FreeBSD equivalent to cmdline.txt
is. That might be the key to making your approach work.
Fbsd 13.x on a pi4, booting off a usb disk:
# cat /boot/msdos//config.txt
[all]
arm_64bit=1
dtparam=audio=on,i2c_arm=on,spi=on
dtoverlay=mmc
dtoverlay=disable-bt
device_tree_address=0x4000
kernel=u-boot.bin
[pi4]
hdmi_safe=1
armstub=armstub8-gic.bin
At least, I assume that's the equivalent file. :-)
On 28/03/2025 at 15:19, bp@www.zefox.net wrote:
Theo <theom+news@chiark.greenend.org.uk> wrote:Perhaps I'm coming here too late, but the way I did it was to keep the
I believe that config.txt is consumed by the GPU-side firmware, which is >>> start*.elf. bootcode.bin is just enough to be able to load start.elf
and config.txt from storage. I'd guess that if that storage is USB, it's >>> too early to have read config.txt.
It looks like the path of least resistance is to let FreeBSD boot from
microSD, mount that as root and then mount the USB disk as /usr, with
/var/, /tmp/ and swap mounted from the USB device, either as links
to /usr or maybe as hard partitions.
That worked fine in the very early days of FreeBSD on the Pi2.
There isn't much write activity to the root filesystem in a
"production" environment, only during OS upgrades. If the microSD
is sufficiently oversized it'll last long enough.
I'd hoped bootcode.bin could be upgraded/tuned to boot from a
USB3 disk on a Pi2, but apparently not.
Thanks to everyone for writing!
bob prohaska
whole of the /boot directory on the SD card and put the whole of /
(minus /boot contents) onto the USB SSD. Change the PARTUUID parameter
in cmdline.txt to the new SSD partuuid and of course update the SSD /etc/fstab to the new values. Worked fine for Pi2B and Pi2B+.
I've yet to figure out what the FreeBSD equivalent to cmdline.txt
is. That might be the key to making your approach work.
Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
On 29/03/2025 04:47, bp@www.zefox.net wrote:
I've yet to figure out what the FreeBSD equivalent to cmdline.txt
is. That might be the key to making your approach work.
Fbsd 13.x on a pi4, booting off a usb disk:
# cat /boot/msdos//config.txt
[all]
arm_64bit=1
dtparam=audio=on,i2c_arm=on,spi=on
dtoverlay=mmc
dtoverlay=disable-bt
device_tree_address=0x4000
kernel=u-boot.bin
[pi4]
hdmi_safe=1
armstub=armstub8-gic.bin
At least, I assume that's the equivalent file. :-)
AIUI, config.txt sets up the Pi, cmdline.txt furnishes
runtime arguments to the kernel when that kernel is
linux. If this isn't true somebody please correct me!
Thanks for writing,
bob prohaska
Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
On 29/03/2025 04:47, bp@www.zefox.net wrote:
I've yet to figure out what the FreeBSD equivalent to cmdline.txt
is. That might be the key to making your approach work.
Fbsd 13.x on a pi4, booting off a usb disk:
# cat /boot/msdos//config.txt
[all]
arm_64bit=1
dtparam=audio=on,i2c_arm=on,spi=on
dtoverlay=mmc
dtoverlay=disable-bt
device_tree_address=0x4000
kernel=u-boot.bin
[pi4]
hdmi_safe=1
armstub=armstub8-gic.bin
At least, I assume that's the equivalent file. :-)
AIUI, config.txt sets up the Pi, cmdline.txt furnishes
runtime arguments to the kernel when that kernel is
linux. If this isn't true somebody please correct me!
Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
On 29/03/2025 04:47, bp@www.zefox.net wrote:
I've yet to figure out what the FreeBSD equivalent to cmdline.txt
is. That might be the key to making your approach work.
Fbsd 13.x on a pi4, booting off a usb disk:
# cat /boot/msdos//config.txt
[all]
arm_64bit=1
dtparam=audio=on,i2c_arm=on,spi=on
dtoverlay=mmc
dtoverlay=disable-bt
device_tree_address=0x4000
kernel=u-boot.bin
[pi4]
hdmi_safe=1
armstub=armstub8-gic.bin
At least, I assume that's the equivalent file. :-)
AIUI, config.txt sets up the Pi, cmdline.txt furnishes
runtime arguments to the kernel when that kernel is
linux. If this isn't true somebody please correct me!
Thanks for writing,
bob prohaska
bp@www.zefox.net wrote:
Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
On 29/03/2025 04:47, bp@www.zefox.net wrote:
I've yet to figure out what the FreeBSD equivalent to cmdline.txt
is. That might be the key to making your approach work.
Fbsd 13.x on a pi4, booting off a usb disk:
# cat /boot/msdos//config.txt
[all]
arm_64bit=1
dtparam=audio=on,i2c_arm=on,spi=on
dtoverlay=mmc
dtoverlay=disable-bt
device_tree_address=0x4000
kernel=u-boot.bin
[pi4]
hdmi_safe=1
armstub=armstub8-gic.bin
At least, I assume that's the equivalent file. :-)
AIUI, config.txt sets up the Pi, cmdline.txt furnishes
runtime arguments to the kernel when that kernel is
linux. If this isn't true somebody please correct me!
Does it show the FreeBSD beastie text-mode screen? https://docs.freebsd.org/images/books/handbook/virtualization/qemu-freebsd02.png
In which case you can probably set things up in loader.conf: https://docs.freebsd.org/en/books/handbook/boot/index.html#boot-loader
the same way you do on x86.
Theo <theom+news@chiark.greenend.org.uk> wrote:
bp@www.zefox.net wrote:
AIUI, config.txt sets up the Pi, cmdline.txt furnishes
runtime arguments to the kernel when that kernel is
linux. If this isn't true somebody please correct me!
Does it show the FreeBSD beastie text-mode screen?
https://docs.freebsd.org/images/books/handbook/virtualization/qemu-freebsd02.png
In which case you can probably set things up in loader.conf:
https://docs.freebsd.org/en/books/handbook/boot/index.html#boot-loader
the same way you do on x86.
Might it be possible to let the machine boot from microSD to the
loader prompt, next re-load the kernel from the USB drive, then
start the new kernel and finally mountroot from USB?
That seems too easy. I must be missing something.
The method is to interrupt boot just before the kernel starts.
Next, unload the kernel, set the currdev to disk0s2a, set
the root device to da0s2a, load the kernel again (from the
new root device and boot.
Setting currdev and rootdev can be done in /boot/loader.conf
on the microSD's FreeBSD, I've asked on the freebsd-arm mailing
list where the unload and load commands should go.
There are still some problems with usb disk discovery failing,I think that is the rootwait switch on the Linux system
but this is a big improvement.
On 31/03/2025 01:10, bp@www.zefox.net wrote:
The method is to interrupt boot just before the kernel starts.Ugly...
Next, unload the kernel, set the currdev to disk0s2a, set
the root device to da0s2a, load the kernel again (from the
new root device and boot.
Setting currdev and rootdev can be done in /boot/loader.confSo that is the same as cmdline.txt
on the microSD's FreeBSD, I've asked on the freebsd-arm mailing
list where the unload and load commands should go.
There are still some problems with usb disk discovery failing,I think that is the rootwait switch on the Linux system
but this is a big improvement.
https://forums.freebsd.org/threads/how-to-delay-mountroot.92152/
Has some info that might be useful
So I seem to be running with no cmdline.txt. Boots happily off the
attached usb drive, no sdcard.
Chris Elvidge <chris@internal.net> wrote:
On 28/03/2025 at 15:19, bp@www.zefox.net wrote:
Theo <theom+news@chiark.greenend.org.uk> wrote:Perhaps I'm coming here too late, but the way I did it was to keep the
I believe that config.txt is consumed by the GPU-side firmware, which is >>>> start*.elf. bootcode.bin is just enough to be able to load start.elf
and config.txt from storage. I'd guess that if that storage is USB, it's >>>> too early to have read config.txt.
It looks like the path of least resistance is to let FreeBSD boot from
microSD, mount that as root and then mount the USB disk as /usr, with
/var/, /tmp/ and swap mounted from the USB device, either as links
to /usr or maybe as hard partitions.
That worked fine in the very early days of FreeBSD on the Pi2.
There isn't much write activity to the root filesystem in a
"production" environment, only during OS upgrades. If the microSD
is sufficiently oversized it'll last long enough.
I'd hoped bootcode.bin could be upgraded/tuned to boot from a
USB3 disk on a Pi2, but apparently not.
Thanks to everyone for writing!
bob prohaska
whole of the /boot directory on the SD card and put the whole of /
(minus /boot contents) onto the USB SSD. Change the PARTUUID parameter
in cmdline.txt to the new SSD partuuid and of course update the SSD
/etc/fstab to the new values. Worked fine for Pi2B and Pi2B+.
I've yet to figure out what the FreeBSD equivalent to cmdline.txt
is. That might be the key to making your approach work.
Is this what fstab would look like?
/dev/da0s2a mounted on /
/dev/mmcsd0s2a mounted on /boot
/dev/mmcsd0s1 mounted on /boot/efi
/dev/da0s2d mounted on /usr
That doesn't look impossible, but .....
Somehow it seems wrong to me, as it requires access to /boot
"out of order". Maybe the loader can do it.
