cflashy: macos compatibility #501
Conversation
macOS supports fewer serial baud rates than Linux, and so the incompatible baud rates have been removed when compiling under macOS.
|
That's a better solution. Thanks! I don't know, if you have an USB-to-serial adapter, which can be connected between your Mac and RPi? That would be required for a test. Otherwise I would merge the PR without a bootloader test, because it's already an improvement. |
|
I'm on a trip with just my laptop for the next couple of weeks, so feel free to merge, thanks Rene! I'm happy to also test it when I am back in Germany. |
|
OK, no problem. Have a nice trip, Pete! |
|
Hi Rene! I'm back home and finally got round to trying this out, but am getting the rainbow splash screen on my rpi400 when booting the bootloader. Any idea what I might be doing wrong? Many thanks! |
|
Welcome back, Pete! It's normal, that the rainbow screen is displayed, when
the serial bootloader is active. It is displayed by the firmware and the
bootloader does not touch the display.
|
|
Ah thanks Rene. I tested with 08-usbkeyboard but wasn't able to get it working ( I also tried manually running cflashy with Normally when I tail logs I run |
|
Pete, honestly I don't know, if cFlashy works on MacOS. It was written and
tested for Linux and Windows. Even if it builds, this does not mean, that it
will work on MacOS.
Perhaps we should check first, if the bootloader is installed all right on your
RPi and connected properly to your Mac. You can test this with a normal
terminal program. When the RPi with bootloader is connected, you should be
able to send the upcase letter 'R' (Reset) in the terminal program and, if it
works, the bootloader will respond with "IHEX-F". Only when this works, we can
continue to search for the problem in cFlashy.
|
|
Thanks Rene! Indeed it seems to be a problem with my setup then, since I have strange results. I then start recording the output (Ctrl-A, H). Then I turn on the RPI, and 6 bytes are immediately received in the terminal, which produce garbled output, but the raw bytes can be seen in the recording: Then I hit Then I quit screen (Ctrl-A, k, y). To test the USB/serial configuration, I built sample/08-usbkeyboard and replaced |
|
I have an assumption, what happens. I guess you have updated the eeprom
firmware of your RPi 400 not long ago? There was a recent change to the
firmware, which enables the setting initial_turbo=60 automatically. This affects
the calculation of the divider for the mini UART, which is used by the serial
bootloader. Circle samples itself do not use the mini UART, but they use the
PL011 UART, which have its own clock generator. Can you please try the
following setting in config.txt for a test with the serial bootloader:
initial_turbo=0
I hope this disables this firmware change, otherwise I have a problem.
|
|
Hi Rene, I'm afraid it didn't change anything. 😬 The hexdump looks to be consistent with the previous version. |
|
(I don't know if it is related, but I've configured my rpi400 to TFTP boot if (and only if) there isn't an SD card present, this is how I normally do my bare metal dev, could there be settings in the EEPROM that are interfering?) |
|
I booted into Raspberry Pi OS to have a look at the EEPROM, I'm not sure if it offers any clues... |
|
(I don't know if it is related, but I've configured my rpi400 to TFTP boot
if (and only if) there isn't an SD card present, this is how I normally do
my bare metal dev, could there be settings in the EEPROM that are
interfering?)
I don't think so, but I haven't used TFTP boot so far.
I need some time now to find a solution. I have an RPi 400 here to test this.
Can you tell me the date of your EEPROM firmware? It's displayed with
$ rpi-eeprom-update
on Raspberry Pi OS. Thanks, also for testing so far!
|
|
Sure, no problem, and thank you for looking into it! |
|
Thanks. This is much older than expected. I will try to downgrade my RPi 400 to it for a test. |
|
I have downgraded my EEPROM firmware to the same version, that is installed on your RPi 400, and I compared the SHA256 checksum of all files on my SD card with the checksums, you have posted. They are identical. Nevertheless everything (cFlashy, test with terminal program) works here. That's difficult to explain. If the setup is the same, it should behave identically. What I don't know is, if there are slightly different versions of the RPi 400. There are no Product Change Notifications for the RPi 400 on the Product Information Portal. It looks to me, that the baud rate is not set properly in the serial bootloader. This can be caused by the property mailbox call, which fetches the core clock rate from the firmware. The core clock is the base clock for the Mini UART and in a test, it did run at 200 MHz. I would like to make a test with a fixed divider, which is written to the baud rate register of the Mini UART. For 200 MHz core clock and a target rate of 115200 Bps the divider should be 216 (200 MHz / (8 * 115200) - 1). Would you please extract the attached .zip archive, copy the kernel8-rpi4.img file in it to your SD card and run another test with screen and (if it works) with cFlashy. Thanks! |
|
I did also change the boot configuration to your config. There was no change in behavior. Everything worked here. |
|
Hi Rene! During the day I upgraded my firmware: Unfortunately the SD card broke today 😬. However, I was able to serve the new kernel you provided from the TFTP server, and to my surprise, got exactly the same result as before. Even the transmitted bytes were identical: And the files served: At this point I started digging a bit deeper and I saw that circle uses ARM PL011 rather than Mini UART, so then I had a look at my own project to remind myself what I'm using (as my project logging is working for me on this rpi400). It turns out I'm using Mini UART, like the bootloader. I compared registry settings, and noticed that I am setting AUX_MU_BAUD_REG to 541 rather than 216 (indicating a 500MHz system clock). I tried patching this value directly into bootloader/periph.c but unfortunately it did not improve the situation. I then looked for other register differences between my code and the bootloader, and noticed that I'm setting AUX_MU_IIR_REG to 0x6 whereas the bootloader is setting it to 0xc6. I checked the BCM 2835 ARM Peripherals docs but saw that bits 6 and 7 are read only, and always read as 1, so the two values should be equivalent on write. Applying both changes also did not fix the problem. I did spot a reference to a 250MHz setting here but I haven't had time to see if it is related. I think I can probably keep digging, but I should probably get some sleep now! Just wanted to give you an update as to where I am at right now... This is my own Mini UART code for reference which is working for me on the rpi400. My plan is to continue comparing my uart code and the bootloader code until I establish which difference(s) cause the issue. I'll report back if I find the culprit! :-) Thanks Rene! btw - do you have any ideas about https://forums.raspberrypi.com/viewtopic.php?t=380418 ? (sorry, unrelated topic!) |
|
Thanks Pete, for looking into this deeper! That's really a strange problem. The core clock (base clock for Mini UART) changes, when the CPU clock is modified by the firmware. I think on the RPi 400 it's 200 MHz, when the CPU runs at 600 MHz. This should be the setup for the serial bootloader, when it gets control. The CPU clock can be risen to 1800 MHz on the RPi 400, the system clock should be 500 MHz then as you say, I haven't tested this. This I will have a look onto your MMU problem soon. |
|
So this fixed things for me... In my terminal on startup I see I realise this might not be the best way of fixing the timing issue, just wanted to let you know it worked for me. I'll test the macOS cflashy build now... |
|
Note, cflashy still doesn't seem to work: I could try adding some debugging output in |
Before the Mini UART was used on RPi 1-4, which depends on the core clock, which varies with the ARM CPU clock. There have been problems with setting the clock divider before, which should be fixed with using the PL011 UART. Further modifications: * Set RxD to pull-up and TxD to pull-none on RPi 1-4 * Use ARM system timer for go delay on RPi 1-4 * Convert ARM address to bus address for mailbox access on all models * Slightly increase delay before mailbox access See: #501
|
Thanks for testing! Good to know, how it can get to work. Unfortunately this fix does not directly lead to a solution, because the core clock may be different on other models and requiring to explicitly setting it in config.txt is error prone and may collide with the requirements of the program to be loaded. That's why I modified the serial bootloader to use the PL011 UART on all RPi models. It was already used on the RPi 5. This UART does not rely on the core clock and has its own clock with a known default clock rate (48 MHz). There are also more fixes (see the commit message) and I hope, that the bootloader will now work for you. It's on the branch bootloader-pl011 at the moment. I guess cFlashy hangs in the It would be great, if you could cFlashy get to work on MacOS. Thanks! |
It seems that macOS supports fewer serial baud rates than Linux, and so the incompatible baud rates have been removed when compiling under macOS.
I've only tested that this fixes the compilation. I have not tested the compiled binary, please let me know if that is required. Many thanks Rene!
Originally raised in #499.