-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Failed to write complete file to USB device" when using custom hardware #30
Comments
Is that 67R choke differential or common mode impedence? It should be 90R
differential on USB, although it also requires suitably good quality
cabling (we have found lots of cheap USB cables do not have anything like
this which can cause significant issues...)
If you've just picked up a random cable then try a nice quality one, at
least one with good twisted pairs and a continuous shield.
Gordon
…On 28 March 2018 at 11:11, FiesoDuck ***@***.***> wrote:
Hi
in an effort to streamline the process of programming multiple CMs we
designed a custom pcb following the official IO-Boards usb circuit.
[image: flash adapter]
<https://user-images.githubusercontent.com/5773030/38021342-d4e9f71a-327c-11e8-9dc6-98aa97e972d1.PNG>
[image: flasher3]
<https://user-images.githubusercontent.com/5773030/38022826-e002f1e8-3280-11e8-9196-9acf13a50328.png>
When booting the CMs as a mass storage device it works as intended.
Currently we are using 16x flash pcbs at once and some command line magic
to make it all happen.
Now we tried to boot the CMs with the directory option
sudo ./rpiboot -d /outputdir
This fails with following output:
***@***.***:~/usbboot$ sudo ./rpiboot -v -d /media/philip/ext4_
Entwicklung/scriptexecutor/output
Waiting for BCM2835/6/7
Device located successfully
Initialised device correctly
Found serial number 0
Sending bootcode.bin
libusb_bulk_transfer returned 0
Writing 50216 bytes
libusb_bulk_transfer returned 0
Successful read 4 bytes
Waiting for BCM2835/6/7
Device located successfully
Initialised device correctly
Found serial number 1
Second stage boot server
Received message GetFileSize: autoboot.txt
Cannot open file autoboot.txt
Received message GetFileSize: config.txt
File size = 47885 bytes
Received message ReadFile: config.txt
File read: config.txt
libusb_bulk_transfer returned 0
Received message GetFileSize: recovery.elf
Cannot open file recovery.elf
Received message GetFileSize: start.elf
File size = 2855972 bytes
Received message ReadFile: start.elf
File read: start.elf
libusb_bulk_transfer returned 0
Received message GetFileSize: fixup.dat
File size = 6669 bytes
Received message ReadFile: fixup.dat
File read: fixup.dat
libusb_bulk_transfer returned 0
Received message GetFileSize: recovery.elf
Cannot open file recovery.elf
Received message GetFileSize: config.txt
File size = 47885 bytes
Received message ReadFile: config.txt
File read: config.txt
libusb_bulk_transfer returned -7
Failed to write complete file to USB device
If i switch the exact CM to the official IO-Board and execute the exact
command it works as expected.
Tested on Ubuntu 17.10
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#30>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB9CHJM4p5R6Tw7aIl2GFRWJtzatT-T4ks5ti2HRgaJpZM4S-Xql>
.
|
Yes it is. Replacing with an 90R did not yield better results.
This helped but now i get this error:
While using the official IO-Board the dt-blob.bin is not needed to be present in the output folder. And even after compiling (
The command never finishes after that. The dt-blob.bin is compiled into the .elf files iirc, why is it necessary to supply the dt-blob.bin when using our custom design and not when using the official IO-Board? And why is the freshly compiled dt-blob.bin not accepted when copied to the output folder? |
I think the absence of dt-blob.bin is a red herring. There is no way to check for the presence of a file other than trying open it. As you've seen, providing a dt-blob.bin doesn't solve the problem, so attempting to load the dt-blob is just the last thing that the loader manages to do. |
Here is the output for the official IO-Board:
Especially this part:
As you can see the error is the same but the official board just continues to boot while our custom board hangs. |
If you are you able to get a shell prompt to the CM3 while it's in the CMIO board (either via serial port or ssh over ethernet), use
You may find it easier to send the output to a file and use an editor to read it:
On a 3B+ I see two reads of config.txt, followed by a read of cmdline.txt, etc. Linking that to your rpiboot log suggests that your booting is failing between those two config.txt reads. All I see in that gap are HDMI messages, but you might see something different. |
I tried that and got I am following this btw.: https://github.com/raspberrypi/scriptexecutor/wiki/Building-and-customizing |
You can copy the binary (the source isn't published for licensing reasons) from here: https://github.com/raspberrypi/firmware/blob/master/opt/vc/bin/vcdbg |
I downloaded the file, put it on a usb stick and mounted the drive. When i try to |
You must also be missing some of the dependencies:
I would start with the three from /opt/vc/lib. |
I replicated the directory structure and moved the corresponding files. (libdebug_sym.so, libelftoolchain.so, libvcos.so) Is it worth to mention, that /opt was empty before copying the files? |
Your installation isn't putting /opt/vc/lib in the LD path. Put the libraries in |
Same result as before. If libraries were missing, shouldn't the error be more like |
|
I am logged in as root |
|
As i stated above, same result as before. |
|
|
How about debugging your hardware issue with a known Raspbian Lite image? |
I am trying this as we speak. |
I copied the contents of the FAT partition from 2017-07-05-raspbian-jessie-lite.img to my output directory. When using the official IO-Board i get:
and then tries to boot. It gets stuck but that besides the point. When using my custom board i get:
And i just halts from here. Same thing as before with the custom image build with https://github.com/raspberrypi/scriptexecutor |
I am also curious as to why using I can "flash" the CMs and use them just fine in our application. We followed the original schematics closely when designing our board. If the hardware is faulty, how does the device boot in mass storage at all? How can this issue be hardware related? |
Very little is done between those two reads of config.txt (at least in terms of functionality - there's a fair amount of code involved). The initial startup is complicated due to some chicken vs egg sequencing problems when processing the config settings. As a result, an initial pass is performed to establish some facts about the platform. After this, just enough is done to determine which of the config,txt conditional sections to interpret and which to skip before it is parsed again, this time for real. The additional steps are:
Apart from reinitialising some internal state before the second pass, the next thing it does is attempt to find Specifying a directory affects the way that rpiboot locates files to send. The only way that should make a difference to the target device is if the files being downloaded are different. Compare the contents of your user directory with You can also get extra diagnostic output from rpiboot with |
It's possible it's the way you've handled the HDMI hotplug connection...
If this is wrong it may be stuck trying to read the EDID from HDMI.
Gordon
…On 3 April 2018 at 13:46, Phil Elwell ***@***.***> wrote:
Very little is done between those two reads of config.txt (at least in
terms of functionality - there's a fair amount of code involved). The
initial startup is complicated due to some chicken vs egg sequencing
problems when processing the config settings. As a result, an initial pass
is performed to establish some facts about the platform. After this, just
enough is done to determine which of the config,txt conditional sections to
interpret and which to skip before it is parsed again, this time for real.
The additional steps are:
1. reading the EDID from any attached HDMI device,
2. reading the serial number from OTP, and
3. reading and acting upon dt-blob.bin (external or embedded).
Apart from reinitialising some internal state before the second pass, the
next thing it does is attempt to find recovery.elf. To me this says that
the problem is all in the setting of the GPIO states and their effects on
the board.
Specifying a directory affects the way that rpiboot locates files to send.
The only way that should make a difference to the target device is if the
files being downloaded are different. Compare the contents of your user
directory with /usr/share/rpiboot/msd/.
You can also get extra diagnostic output from rpiboot with -vv.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#30 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB9CHGu9jPXUZFJp5pV7o1XF1SpzTCRrks5tk28jgaJpZM4S-Xql>
.
|
The fact that it goes on to look for dt-blob.bin suggests that can't be the case. |
When i Both boards (custom and official) then boot into MSD. Sorry but i am kinda lost here, what does that |
As shown in the schematics above we haven't customized the GPIOs or the usage of them in our board. What problems with the GPIO states are you referring to? |
Closed due to inactivity. |
Hi
in an effort to streamline the process of programming multiple CMs we designed a custom pcb following the official IO-Boards usb circuit.
When booting the CMs as a mass storage device it works as intended. Currently we are using 16x flash pcbs at once and some command line magic to make it all happen.
Now we tried to boot the CMs with the directory option
sudo ./rpiboot -d /outputdir
This fails with following output:
If i switch the exact CM to the official IO-Board and execute the exact command it works as expected.
Tested on Ubuntu 17.10
The text was updated successfully, but these errors were encountered: