raspberrypi / usbboot

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

Overlay Subdirectory. #10

Closed ED6E0F17 closed 7 years ago

ED6E0F17 commented 7 years ago

I am seeing a control transfer failure when trying to send an overlay:

$ sudo ./rpiboot -l -d ./boot/
Waiting for BCM2835/6/7
Sending bootcode.usb
Failed : 0x0Waiting for BCM2835/6/7
Second stage boot server
File read: config.txt
File read: start.elf
Waiting for BCM2835/6/7
Second stage boot server
File read: config.txt
File read: config.txt
File read: cmdline.txt
File read: kernel.img
File read: bcm2708-rpi-b-plus.dtb
File read: config.txt
File read: overlays/dwc2.dtbo
Failed control transfer

Looking at the log it seems to be sending config.txt every time that start.elf wants to read it. That makes sense to me, but perhaps the firmware could cache that file.

ED6E0F17 commented 7 years ago

Running in Verbose mode I can see that it is asking for overlays that do not exist. This is my fault.: I should be using "dtparam=spi", not "dtoverlay=spi"

But it should have failed for "File not found."

Received message GetFileSize: overlays/spi.dtbo
Cannot open file overlays/spi.dtbo
Received message GetFileSize: overlays/spi-overlay.dtb
Cannot open file overlays/spi-overlay.dtb
Received message GetFileSize: overlays/spi.dtb
Cannot open file overlays/spi.dtb
ghollingworth commented 7 years ago

Even if it was trying to open a file that didn't exist it should still work...

I'll have a look at this tomorrow so will reopen

ED6E0F17 commented 7 years ago

The missing files are not the issue here, so I don`t know what is. There is no need to make the code more or less verbose than the existing options, since there are several optional files that start.elf is also checking for.

As far as I can tell it is transferring all the files that it needs to, and is reaching "Received message Done:" BEFORE the "Failed control transfer" message. I think I have done everything I needed to by copying start.elf, bootcode.bin, and fixup.dat onto the files from a working boot partition; but I am not seeing any sign of the kernel starting.

ED6E0F17 commented 7 years ago

"Without changing anything" it is now working on my other PiZero - so thank you very much this was worth waiting for.

The two harmless warnings in the log are due to the NULL message length, so there is no need for the user to see those.

ghollingworth commented 7 years ago

I've just pushed a change into the next firmware, it should make it's way out soon... This should fix the requirement of the '-l' and simultaneously fix the limited memory on a Pi 3

Can you try again with this when the firmware is updated?

Gordon

ED6E0F17 commented 7 years ago

The new firmware fixes the missing Ram on my PiZero 1.2, and the loading process is much smoother now that it completes in two loops. I have had to rebuild Busybox for another issue but I will test again on the PiZero 1.3 with the assumption that the new firmware will fix that issue.

ED6E0F17 commented 7 years ago

Still having issues with the new firmware on Pi Zero 1.3, but the usbboot code is working well otherwise. I have a kernel patch pending for gadget mode on monolithic builds, and I have hit another issue with gadget serial but all my problems are open source now.