Closed ED6E0F17 closed 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
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
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.
"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.
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
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.
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.
I am seeing a control transfer failure when trying to send an overlay:
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.