search

raspberrypi / usbboot

Raspberry Pi USB booting code, moved from tools repository
Apache License 2.0
878 stars 221 forks source link

rpiboot hangs if CM4 is already booted #179

Closed klslz closed 1 year ago

klslz commented 1 year ago

Describe the bug

commit-level: https://github.com/raspberrypi/usbboot/commit/864863bc1944553f5a4a7dae5df9ea894afdf513 (Jan-20-2023)

rpiboot goes into infinite waiting if started on already booted CM4.

  1. rpiboot should be able to recognize the "already booted" state and bail out immediately or
  2. the todays infinite "waiting" period should run into a timeout
  3. an ERROR message should be issued that the CM4 is already booted and needs to be "repowered" to run rpiboot otherwise if you try (bash-)scripting the process, you need to do a lot of extra work to cope with the issue.

That brings me to a slightly different subject. I do also need to "repower" the CM4 if I e.g. first boot&mount and after that I'd like to run a firmware upgrade. The whole repowering thing is not nice. It would be nice if a hardware reset could be issued by the tool. This way the whole maintenance process could be scripted without the need for plugging cables all the time. If there is a solution to this please let me know. Since this repowering topic is closely related to the trouble ticket, perhaps both things could be looked at at once.

Gettings this fixed would help a lot to get the maintenance process automated without manual interaction (HW resets).

Steps to reproduce the behaviour

simply run rpiboot twice on attached device. First time it boots. Second time it hangs.

Device(s)

Raspberry Pi CM4

Compute Module IO board.

all

RPIBOOT logs

No response

Kernel logs

No response

Device UART logs

No response

pelwell commented 1 year ago

A CM4 (or any USB-bootable device) waiting for USB boot presents itself as a USB device/gadget over the OTG USB port. After the 2nd stage bootloader (bootcode*.bin) has been sent it appears as a different USB device because it is now running a different USB stack. If the downloaded image is to activate Mass Storage Device mode then you get a third kind of device - MSD.

The standard way to program a batch of devices is to run rpiboot in a loop, allowing it to detect new devices as they are attached. It is not possible to distinguish between a CM4 running an image which doesn't present a USB gadget and no CM4 - they look just the same, i.e. an absence of a USB device.

The CM4 hardware is working the way we want it to work, and unfortunately it doesn't support the features you think are important. If you want to switch to a mode where you attach a CM4 before starting rpiboot and get an error message about there being no device attached then you just need to write a wrapper script that runs lsusb and complains if it doesn't find something bootable. Alternatively you might be able to arrange that your custom images create yet another kind of USB gadget, which would then be able to be detected by your wrapper. Either way, we won't be changing the rpiboot source, but you can always fork it yourself - that's the beauty of open source software!

JamesH65 commented 1 year ago

If your aim is batch programming, you may be interested in the CM Provisioner which can work over USB or ethernet, depending on the target.

https://github.com/raspberrypi/cmprovision

klslz commented 1 year ago

Wow. I didn't expect such a rebuff.

Of course I can write a wrapper to steer around the flaw. (As anybody else of the thousands of admins out there can do . )

However. It'd be much simpler to introduce a very ,I'd expect , minor change to the program. Instead of having a program stalling forever it could simply bail out after a couple of seconds.

I am just saying.

Anyhow. Thx for listening.

pelwell commented 1 year ago

The code is here to view - tell me how it should work?