raspberrypi / firmware

This repository contains pre-compiled binaries of the current Raspberry Pi kernel and modules, userspace libraries, and bootloader/GPU firmware.
5.15k stars 1.68k forks source link

PXE boot fails if any USB mass storage is present #907

Closed mikemccabe closed 6 years ago

mikemccabe commented 6 years ago

(moved here from tail comments of #825)

When we do a full PXE boot (bootcode.bin on SD card), if there's a USB storage device of any kind, the boot process halts. (Green light blinks 3? times, repeatedly.) We want to keep a homogenous readonly PXE environment on all our devices, but some have USB keys for storage of IDs, etc.

It doesn't matter if the USB key is FAT, blank (dd if=/dev/zero-ed out), ext4, NTFS, etc. ('FAT32 partition decoded successfully' is always there.)

It looks from the PXE trace in #825 that full back-out retries are possible with this bootcode.bin, could it make sense to re-try from a different device (ethernet) on the USB hub?

Here's the trace: (this is with 'debug' bootcode.bin mentioned in #825 )

Raspberry Pi Bootcode

Found SD card, config.txt = 0, start.elf = 0, recovery.elf = 0, timeout = 0 Trying USB Hub device found at addr 4, enumerating HUB 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 Device found: type = Ethernet adapter, addr = 5 Found device on port 4 Found highspeed device Device found: type = Mass storage, addr = 6 Trying booting from MSD device addr 6 Retrieving the config descriptor Found ep_in = 00000002, ep_out = 00000001 GetMaxLun returned 0, max_lun = 0 Sending and retrying TEST_UNIT_READY Sending SCSI_COMMAND_INQUIRY Sending READ_CAPACITY init_msd returned 0 USB device configuration set Initisalised mass storage, block size = 512, block count = 62668800 MBR read and decoded successfully FAT32 partition decoded successfully

Raspberry Pi Bootcode

(hang)

We've tried setting OTP bits and pulling GPIO pins (and made some progress), but we have a strong preference for keeping our hardware interchangeable.

An option like the 'timeout' file (touch pxe) could also work for the above issue. Obviously not appropriate to a bootrom approach, but we're OK with SD/mmc bootcode.bin for now.

ghollingworth commented 6 years ago

Thanks,

Will try to get the fix pushed soon, just working on other things right now...

This obviously can only be fixed when having bootcode.bin stored on an SD card...

mikemccabe commented 6 years ago

Any update? This will shortly be a production issue for us.

ghollingworth commented 6 years ago

Sorry no it had dropped off my radar, will have a look this afternoon, since I've got to look into bootcode.bin booting

ghollingworth commented 6 years ago

Can you try this version? I'm unable to test it myself (working from home) but it should do what you need. Basically it was returning with the MSD as a valid partition to boot from, so I've added a test to look for start.elf If there is a start.elf file then it will try to boot from MSD otherwise it'll continue on to ethernet...

bootcode.zip

mikemccabe commented 6 years ago

That version works! I can now bring up a pxe-booted pi with a connected (non-boot) USB mass storage device. I also verified that it retains the retry behavior that fixes #825. (It still comes up when powered up at the same time as in-between networking hardware, which is part of our deployment.)

Thank you Gordon!

ghollingworth commented 6 years ago

No problem, it'll be pushed to the main firmware in the next release. Be interested in your deployment, email me on gordon@raspberrypi.org