bootcode.bin broken for CM1

[l1k]

Commit d7b97b343fd09c68792f4f9a8975af261efda1a2 introduced a regression on the CM1. It looks like the device crashes after downloading bootcode.bin. This is with current master:

[12142.048382] usb 3-1: new full-speed USB device number 5 using xhci_hcd
[12142.189371] usb 3-1: New USB device found, idVendor=0a5c, idProduct=2763
[12142.192112] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[12142.194877] usb 3-1: Product: BCM2708 Boot
[12142.197646] usb 3-1: Manufacturer: Broadcom
# ./rpiboot
Waiting for BCM2835/6/7
Sending bootcode.bin
Successful read 4 bytes
[12145.072263] usb 3-1: USB disconnect, device number 5
[12146.448271] usb 3-1: new high-speed USB device number 6 using xhci_hcd
[12146.568294] usb 3-1: device descriptor read/64, error -71
[12146.796286] usb 3-1: device descriptor read/64, error -71
Waiting for BCM2835/6/7

The device appears dead afterwards. Switching to d7b97b343fd09c68792f4f9a8975af261efda1a2^ fixes the issue.

Since this seems to be caused by the closed-source bootcode.bin, it can't be fixed by the community but only by the Foundation.

[ghollingworth]

Can you try using the latest bootcode.bin from the firmware, there was a small bug fix there that may effect this:

https://github.com/raspberrypi/firmware/blob/master/boot/bootcode.bin

[l1k]

Unfortunately this one doesn't improve the situation with the CM1:

[ 4860.760906] usb 1-2: new full-speed USB device number 3 using xhci_hcd
[ 4860.901930] usb 1-2: New USB device found, idVendor=0a5c, idProduct=2763
[ 4860.905083] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 4860.908191] usb 1-2: Product: BCM2708 Boot
[ 4860.911295] usb 1-2: Manufacturer: Broadcom
# ./rpiboot
Waiting for BCM2835/6/7
Sending bootcode.bin
Successful read 4 bytes 
[ 4879.655752] usb 1-2: USB disconnect, device number 3
Waiting for BCM2835/6/7

At that point nothing happens anymore. Stopping and starting rpiboot results in nothing else but:

Waiting for BCM2835/6/7

So the device seems to be dead again.

In addition, this version of bootcode.bin breaks rpiboot for the CM3 (current master works fine):

[ 5207.435671] usb 1-2: new high-speed USB device number 5 using xhci_hcd
[ 5207.575962] usb 1-2: config index 0 descriptor too short (expected 55, got 32)
[ 5207.579257] usb 1-2: New USB device found, idVendor=0a5c, idProduct=2764
[ 5207.582146] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 5207.585156] usb 1-2: Product: BCM2710 Boot
[ 5207.585158] usb 1-2: Manufacturer: Broadcom
# ./rpiboot
Waiting for BCM2835/6/7
Sending bootcode.bin
Successful read 4 bytes 
Waiting for BCM2835/6/7
Sending bootcode.bin
Failed control transfer
Failed to write correct length, returned -7
Waiting for BCM2835/6/7
Sending bootcode.bin
Failed control transfer
Failed to write correct length, returned -7

The last 4 lines are repeated in an infinite loop.

Happy to try any other version you might have. Thanks!

[popcornmix]

In addition, this version of bootcode.bin breaks rpiboot for the CM3 (current master works fine):

The bootcode.bin @ghollingworth linked to is current master. It was updated yesterday. Do you the previous master version worked fine?

[l1k]

Sorry for not being clear, I meant to say the current master of this repo, raspberrypi/usbboot, which is c01bd3b4c29a5d19f09d1933b4ce45af3bf07c8b (committed by @ghollingworth Jan 25) works fine with the CM3, but not with the CM1.

The bootcode.bin @ghollingworth linked to above works on neither the CM1 nor CM3 when used with rpiboot.

[Thalhammer]

It seems to be not just broken for CM1 but also for CM3. I received my CM3 in the mail today and tried to flash it. I got the same read errors as l1k. I then tried the first commit that mentions support for CM3 and it worked on the first try. The commit I use now is 1deea82c759f80caa8f8c6b717833e6956d36997. I don't know if it is the last one that works but it is definitely one that works for CM3.

Sincerely, Thalhammer

[l1k]

@Thalhammer: Well that's odd, c01bd3b does work fine for me with the CM3.

[Thalhammer]

Well i tried it on 3 different pcs and it never worked. Maybe if I have time, I will try to pin down an exact commit after which it stopped working.

[ghollingworth]

It would be good if you could check out both commits into separate directories. Then from the good commit copy over just msd/bootcode.bin to the bad one...

Try again

If that fails then revert msd/bootcode.bin and copy over msd/start.elf

If that fails then revert start.elf and copy over main.c

I'm just trying to ascertain which file is causing the problem...

[Thalhammer]

I did some further experiments today. Using commit 1deea82c759f80caa8f8c6b717833e6956d36997 everything works as expected. dmesg-1deea82c759f80caa8f8c6b717833e6956d36997.txt rpiboot-1deea82c759f80caa8f8c6b717833e6956d36997.txt

I then copied usbbootcode.bin into the current commits msd/bootcode.bin. It correctly detects the Raspberry PI but then it just sits there and (apparently) does nothing. I had to cancel it using ctrl+c. Just to try I copied over start.elf as well, but the output didn't change. dmesg-both.txt rpiboot-both.txt

I reverted bootcode.bin and copied over only start.elf: Now I have the same as when I directly use the current commit without changing anything. It just sit's there not finding the raspberry pi, which sounds logical, because it seems as if the bootloader is restarted (look at the second new usb device in dmesg). dmesg-start.txt rpiboot-start.txt

I now tried to pin down a commit after which it stopped working and it seems that commit 18a89855866a97b2bdc899662bceeaeb267c1556 is the last commit that works for my module. I looked at the changes of the first broken commit (d7b97b343fd09c68792f4f9a8975af261efda1a2) and it looks like the only possible causes are main.c and bootcode.bin, which both were changed in that commit. However, I can't get any further since the USB communication seems to have changed quite drastically after this release.

I hope this helps a bit. I'll continue to use 18a89855866a97b2bdc899662bceeaeb267c1556 for now, because "it just works(tm)".

[ghollingworth]

Please try again, updated and fixed

[l1k]

Thanks @ghollingworth, I can confirm that current master works with a CM1 that it previously failed with.

However I notice that both with a CM1 and a CM3, rpiboot now no longer exits after having downloaded the fileserver firmware. The process seems to hang around indefinitely. It's possible to kill it and the module continues to be accessible as a fileserver.

[ghollingworth]

Yes,

The normal next step after loading start.elf (with a boot of a standard linux) is that the start.elf continues to read files such as config.txt and the ARM kernel. With the MSD start.elf though this doesn't happen and instead it just re-enumerates as a mass storage device.

So for the moment it just gets stuck waiting for the device to re-connect...

Gordon