Closed 0xF16 closed 4 months ago
Not a bug, it's simply reporting the probing of a non-existent file.
Not a bug, it's simply reporting the probing of a non-existent file.
Do you know how can I upload it (it this is what is not existing on eMMC on RPi)?
Edit1: I have also just noticed that there are more files missing in the log: autoboot.txt
, config.txt
and recovery.elf
in addition.
Actually, I've spotted something. Please could you get the latest version of usbboot and try again. It may be a conflict caused by having bootfiles.bin in the same directory as rpiboot.
See: https://github.com/raspberrypi/usbboot/commit/d485c497d5379fb15d0a22d3b70595072d26aae9
Actually, I've spotted something. Please could you get the latest version of usbboot and try again. It may be a conflict caused by having bootfiles.bin in the same directory as rpiboot.
See: d485c49
Unfortunately it didn't fix my issue. But thank you for trying
Logs (they seem identical to me):
Waiting for BCM2835/6/7/2711/2712...
Device located successfully
Loading embedded: bootcode.bin
Initialised device correctly
Found serial number 0
last_serial -1 serial 0Sending bootcode.bin
libusb_bulk_transfer sent 24 bytes; returned 0
Writing 52456 bytes
libusb_bulk_transfer sent 52456 bytes; returned 0
Successful read 4 bytes
Waiting for BCM2835/6/7/2711/2712...
Device located successfully
Loading embedded: bootcode.bin
Failed to open the requested device
Device located successfully
Loading embedded: bootcode.bin
Initialised device correctly
Found serial number 1
last_serial -1 serial 1Second stage boot server
Received message GetFileSize: autoboot.txt
libusb_bulk_transfer sent 0 bytes; returned 0
Cannot open file autoboot.txt
Received message GetFileSize: config.txt
libusb_bulk_transfer sent 0 bytes; returned 0
Cannot open file config.txt
Received message GetFileSize: recovery.elf
libusb_bulk_transfer sent 0 bytes; returned 0
Cannot open file recovery.elf
Received message GetFileSize: start.elf
Loading embedded: start.elf
File size = 523192 bytes
Received message ReadFile: start.elf
File read: start.elf
libusb_bulk_transfer sent 523192 bytes; returned 0
Received message GetFileSize: fixup.dat
libusb_bulk_transfer sent 0 bytes; returned 0
Cannot open file fixup.dat
libusb: error [submit_control_transfer] control request failed: no connection to an IOService
Second stage boot server done
libusb: warning [darwin_release_interface] USBInterfaceClose: no connection to an IOService
libusb: warning [darwin_close] USBDeviceClose: no connection to an IOService`
Unfortunately, I think that looks more like a USB interop issue between the VPU MSD driver and OSX.
With Pi4 onwards the mass-storage-gadget seems ok with OSX. It might be worth running the following. I think someone reported that it worked on CM3.
cd mass-storage-gadget sudo ../rpiboot -v -d .
@timg236 cm3 has afaik no support for booting the packed msg image. With the files extracted it works
Unfortunately, I think that looks more like a USB interop issue between the VPU MSD driver and OSX.
With Pi4 onwards the mass-storage-gadget seems ok with OSX. It might be worth running the following. I think someone reported that it worked on CM3.
cd mass-storage-gadget sudo ../rpiboot -v -d .
I have tried that on and it does not help. Is there any way to provide some more logs from my end? If there is anything that I can help with, let me know.
I'd suggest running rpiboot on a Raspberry Pi - this is the officially supported / tested platform
Closed as can't reproduce. The posted instructions worked for me on an M2 latest OS
Describe the bug
I'm trying to run:
sudo rpiboot
on my MacOS M1, end I got an errorCannot open file fixup.dat
The blue LED goes off at some point. I'm connected while having a USB hub.Tried and got the same issue on Windows 10 machine where a cable is connected directly to one of the USB ports.
Steps to reproduce the behaviour
Complile the latest
usbboot
. Set jumpers to the correct position. Runsudo ./rpiboot
in terminal.Device(s)
Raspberry Pi CM3+
Compute Module IO board.
No response
RPIBOOT logs
Kernel logs
No response
Device UART logs
No response