This is great!
bztsrc opened this issue · 5 comments
Hi,
Not really an issue, I'd just like to say how much I like what you did with my little tutorials! Good job, well done! I've recommended your repo in the README in case someone is looking for Rust examples.
I was wondering if your 07_uart_chainloader example could be used with USBImager -S. That works with my 14_raspbootin64 example, so I think it should work with yours too out-of-the-box!
Cheers,
bzt
Thanks a lot! If I wouldn't have stumbled over your nice tutorials, I might have never started this one here! They got me started quickly.
USBImager sounds interesting for Windows chainloader support that I am currently not providing at all.
From your README, I see that the baud rate is fixed at 115200. The tuts here use 230400 because later on the kernels get quite big, so this would be an issue.
When I pre-select COM1 and later connect my USB Serial, will Windows automatically map it to COM1 so that USBImager discovers the connection?
Best,
Andre
Hi,
USBImager sounds interesting for Windows chainloader support that I am currently not providing at all.
Then feel free to use it :-) By default it does a very dump receive protocol with "-s", and with "-S" it does a raspbootcom hand shake. See https://gitlab.com/bztsrc/usbimager#advanced-functionalities
From your README, I see that the baud rate is fixed at 115200. The tuts here use 230400 because later on the kernels get quite big, so this would be an issue.
Yes, the original Motorola 16550 chip had 11500 baud as the maximum rate, so I set that for compatibility. I can imagine a "-b " flag to set any arbitrary baud rate if there's a need.
When I pre-select COM1 and later connect my USB Serial, will Windows automatically map it to COM1 so that USBImager discovers the connection?
I'm sure I follow. This is how it works: under each OS, USBImager gets a list of serial devices, and then offers those in the device select box. When you press the "Send" button, it opens and configures the selected device. Then with "-s" it starts the selected image right away, but with "-S" it first awaits for the client to send "\003\003\003", and when it's done, it closes the device. That's all (there's no mapping involved). You can select COM1, COM2 whatever from the list. USB serial ports being the main targets, but old-fashioned RS-232 ports also supported on all OSes.
Cheers,
bzt
Ok, I've added configurable baud rate. Just append it to the flag, like "-S230400". Supports up to 4M (if your device supports it). I'm pushing the new release today.
Cheers,
bzt
Hi @bztsrc,
let me quickly lay out how the serial boot flow works in my case:
When I start the host tool, I give it a commandline argument telling what the device node name of the serial will be once it is connected. For example, I start it with
ruby ../utils/minipush.rb /dev/ttyUSB0
The tool will then pool the file system for the node to appear: https://github.com/rust-embedded/rust-raspberrypi-OS-tutorials/blob/master/utils/minipush.rb#L37-L44
I do that because in my case, the USB serial cable also powers the raspberry. That means once I connect the USB serial, the chainloader binary immediately boots and sends the raspboot request token to the host.
I think with the current version of your tool, I would have the problem that there would only be a very small window of time between connecting the USB serial, and the selecting the serial's name in the dropdown menu once Windows discovered it. If that happens too slow, the tool probably misses the request for the binary.
What do you think?
Hi,
Looks like an interesting problem. I've never used the USB serial port (on the RPi), only the GPIO pins 14/15. This way it doesn't matter if I supply the Pi with power from a PC with an USB cable, or from an adapter (which is the recommended way). Also using a separate cable makes both Windows and Linux to display the serial device, so that I can easily select it, press on Send, and only after that I power on the Pi.
Do you have any suggestions? If you have an idea how to create a workaround in USBImager, let me know. I'd like not to overload the command line too much if possible (the first argument is already used for the backup directory's path).
Cheers,
bzt