search

raspberrypi / usbboot

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

Update for BCM2711 / CM4 MSD #64

Closed timg236 closed 3 years ago

timg236 commented 3 years ago

@XECDesign

burtyb commented 3 years ago

Since using rpiboot with bootcode.bin files newer than March don't get to stage two with a Pi Zero/CM3+/etc. any chance it could still fall back to using the old built-in bootcode.bin when -d is used and there's no bootcode.bin in the directory?

timg236 commented 3 years ago

Since using rpiboot with bootcode.bin files newer than March don't get to stage two with a Pi Zero/CM3+/etc. any chance it could still fall back to using the old built-in bootcode.bin when -d is used and there's no bootcode.bin in the directory?

@burtyb I think it would be better to fix bootcode.bin bootcode.bin.zip

Please could you try the attached? It looks like fallout from the move to the common branch where BCM2711 PHY behaviour was selected on 2835

burtyb commented 3 years ago

@burtyb I think it would be better to fix bootcode.bin

I agree :).

bootcode.bin.zip

Please could you try the attached? It looks like fallout from the move to the common branch where BCM2711 PHY behaviour was selected on 2835

No joy using this bootcode.bin but it's different to what I'd reported in the issue as it doesn't have any "new full-speed USB device number" lines.

==> /var/log/kern.log <== Oct 13 13:21:45 cnat kernel: [ 3579.166278] usb 1-1.1.4: new full-speed USB device number 10 using xhci_hcd Oct 13 13:21:45 cnat kernel: [ 3579.272304] usb 1-1.1.4: New USB device found, idVendor=0a5c, idProduct=2763, bcdDevice= 0.00 Oct 13 13:21:45 cnat kernel: [ 3579.272320] usb 1-1.1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Oct 13 13:21:45 cnat kernel: [ 3579.272333] usb 1-1.1.4: Product: BCM2708 Boot Oct 13 13:21:45 cnat kernel: [ 3579.272343] usb 1-1.1.4: Manufacturer: Broadcom ==> /var/log/daemon.log <== Oct 13 13:21:45 cnat rpiboot[1466]: Device located successfully Oct 13 13:21:45 cnat rpiboot[1466]: libusb: error [udev_hotplug_event] ignoring udev action bind Oct 13 13:21:46 cnat rpiboot[1466]: Initialised device correctly Oct 13 13:21:46 cnat rpiboot[1466]: Found serial number 0 Oct 13 13:21:46 cnat rpiboot[1466]: Sending bootcode.bin Oct 13 13:21:46 cnat rpiboot[1466]: libusb_bulk_transfer sent 24 bytes; returned 0 Oct 13 13:21:46 cnat rpiboot[1466]: Writing 52480 bytes Oct 13 13:21:46 cnat rpiboot[1466]: libusb_bulk_transfer sent 52480 bytes; returned 0 Oct 13 13:21:47 cnat rpiboot[1466]: Failed : 0x0 ==> /var/log/kern.log <== Oct 13 13:21:47 cnat kernel: [ 3581.392094] usb 1-1.1.4: USB disconnect, device number 10 ==> /var/log/daemon.log <== Oct 13 13:21:48 cnat rpiboot[1466]: Waiting for BCM2835/6/7/2711...

timg236 commented 3 years ago

@burtyb I think it would be better to fix bootcode.bin

I agree :).

bootcode.bin.zip Please could you try the attached? It looks like fallout from the move to the common branch where BCM2711 PHY behaviour was selected on 2835

No joy using this bootcode.bin but it's different to what I'd reported in the issue as it doesn't have any "new full-speed USB device number" lines.

==> /var/log/kern.log <== Oct 13 13:21:45 cnat kernel: [ 3579.166278] usb 1-1.1.4: new full-speed USB device number 10 using xhci_hcd Oct 13 13:21:45 cnat kernel: [ 3579.272304] usb 1-1.1.4: New USB device found, idVendor=0a5c, idProduct=2763, bcdDevice= 0.00 Oct 13 13:21:45 cnat kernel: [ 3579.272320] usb 1-1.1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Oct 13 13:21:45 cnat kernel: [ 3579.272333] usb 1-1.1.4: Product: BCM2708 Boot Oct 13 13:21:45 cnat kernel: [ 3579.272343] usb 1-1.1.4: Manufacturer: Broadcom ==> /var/log/daemon.log <== Oct 13 13:21:45 cnat rpiboot[1466]: Device located successfully Oct 13 13:21:45 cnat rpiboot[1466]: libusb: error [udev_hotplug_event] ignoring udev action bind Oct 13 13:21:46 cnat rpiboot[1466]: Initialised device correctly Oct 13 13:21:46 cnat rpiboot[1466]: Found serial number 0 Oct 13 13:21:46 cnat rpiboot[1466]: Sending bootcode.bin Oct 13 13:21:46 cnat rpiboot[1466]: libusb_bulk_transfer sent 24 bytes; returned 0 Oct 13 13:21:46 cnat rpiboot[1466]: Writing 52480 bytes Oct 13 13:21:46 cnat rpiboot[1466]: libusb_bulk_transfer sent 52480 bytes; returned 0 Oct 13 13:21:47 cnat rpiboot[1466]: Failed : 0x0 ==> /var/log/kern.log <== Oct 13 13:21:47 cnat kernel: [ 3581.392094] usb 1-1.1.4: USB disconnect, device number 10 ==> /var/log/daemon.log <== Oct 13 13:21:48 cnat rpiboot[1466]: Waiting for BCM2835/6/7/2711...

Can I check exactly rpiboot was run? To test this I used a PI4 and copied the attached recovery.bin and the start.elf from the msd directory into a temporary directory then ran the new rpiboot executable pointed at this directory.

burtyb commented 3 years ago

Can I check exactly rpiboot was run? To test this I used a PI4 and copied the attached recovery.bin and the start.elf from the msd directory into a temporary directory then ran the new rpiboot executable pointed at this directory.

I'm using the overlay option which is what caused my confusion as previously with -o enabled it would load bootcode.bin from the -d directory once but with this patch it's checking bootcode.bin exists in the "-d" directory on startup and then tries loading it from the overlay directory if there's a bootcode.bin in there (which I hadn't updated when I tested yesterday).

For me (probably the main/only user of the overlay option) I'd be happy for bootcode[4].bin to only load from the "-d" dir by ignoring the bootcode files on the overlay check with something like

if(overlay&&(pathname[0] != 0)&&(strcmp(fname, "bootcode4.bin") != 0)&&(strcmp(fname, "bootcode.bin") != 0))

Or alternatively skip the bootcode[4].bin exists check when overlay is enabled and remove the "(bootcode.bin is always preloaded from the base directory)" help line.

burtyb commented 3 years ago

Sorry, I forgot to say with the bootcode.bin in the zip it works OK now once I'd updated it in all locations.

timg236 commented 3 years ago

@burtyb I have to admit that I didn't try the overlay option :) I've added the patch that you suggested and made the logging slightly more verbose to indicate where the file was actually loaded from.

timg236 commented 3 years ago

@ghollingworth

timg236 commented 3 years ago

@pelwell Can you merge this?

burtyb commented 3 years ago

@burtyb I have to admit that I didn't try the overlay option :) I've added the patch that you suggested and made the logging slightly more verbose to indicate where the file was actually loaded from.

@timg236 looks like these changes are missing in the merged code?

timg236 commented 3 years ago

I've submitted the changes via a separate PR https://github.com/raspberrypi/usbboot/pull/65