Update for BCM2711 / CM4 MSD #64

timg236 · 2020-10-12T20:09:49Z

@XECDesign

pelwell

A few minor nitpicks.

Readme.md

debian/control

main.c

burtyb · 2020-10-12T21:38:14Z

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 · 2020-10-13T07:11:52Z

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

* Add 2711 bootcode and FW binaries with the 4 suffix. * Use the device descriptor to select the correct bootcode and hack it so that bootcode.bin translates to bootcode4.bin on a Pi4 allowing the files to remain in the same directory. * Add the latest best for recovery.bin and pieeprom.bin for CM4 * Update the installer. Move the second stage preparation until after the device descriptor has been retrieved because BCM2711 needs a different bootcode.bin. If the '-d' argument specified then check for bootcode.bin in the specified directory and don't fail over to the embedded fmem files. Remove the default 'msd' directory and the references to /usr/share because the behaviour conflicts with the original change to use the fmem files.

burtyb · 2020-10-13T12:25:48Z

@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 · 2020-10-14T08:56:16Z

@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 · 2020-10-14T21:37:55Z

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 · 2020-10-14T21:40:48Z

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 · 2020-10-15T14:18:05Z

@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 · 2020-10-15T18:37:32Z

@ghollingworth

timg236 · 2020-10-16T12:34:46Z

@pelwell Can you merge this?

burtyb · 2020-10-18T10:44:59Z

@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 · 2020-10-20T07:01:59Z

I've submitted the changes via a separate PR
#65

pelwell reviewed Oct 12, 2020

View reviewed changes

Readme.md Outdated Show resolved Hide resolved

Readme.md Outdated Show resolved Hide resolved

debian/control Outdated Show resolved Hide resolved

main.c Outdated Show resolved Hide resolved

timg236 force-pushed the cm4 branch from e94a3f3 to 3321e10 Compare October 13, 2020 10:56

timg236 changed the title ~~WIP - Update for BCM2711 / CM4 MSD~~ Update for BCM2711 / CM4 MSD Oct 15, 2020

pelwell merged commit 7676463 into raspberrypi:master Oct 16, 2020

burtyb mentioned this pull request Nov 17, 2020

Unable to usb boot raspberry pi zero v1.3 #69

Closed

timg236 deleted the cm4 branch May 20, 2021 02:15

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update for BCM2711 / CM4 MSD #64

Update for BCM2711 / CM4 MSD #64

timg236 commented Oct 12, 2020

pelwell left a comment

burtyb commented Oct 12, 2020

timg236 commented Oct 13, 2020

burtyb commented Oct 13, 2020

timg236 commented Oct 14, 2020

burtyb commented Oct 14, 2020

burtyb commented Oct 14, 2020

timg236 commented Oct 15, 2020

timg236 commented Oct 15, 2020

timg236 commented Oct 16, 2020

burtyb commented Oct 18, 2020

timg236 commented Oct 20, 2020

Update for BCM2711 / CM4 MSD #64

Update for BCM2711 / CM4 MSD #64

Conversation

timg236 commented Oct 12, 2020

pelwell left a comment

Choose a reason for hiding this comment

burtyb commented Oct 12, 2020

timg236 commented Oct 13, 2020

burtyb commented Oct 13, 2020

timg236 commented Oct 14, 2020

burtyb commented Oct 14, 2020

burtyb commented Oct 14, 2020

timg236 commented Oct 15, 2020

timg236 commented Oct 15, 2020

timg236 commented Oct 16, 2020

burtyb commented Oct 18, 2020

timg236 commented Oct 20, 2020