Hi, Based on what you describe it seems like a stack configuration issue. About "but the `uint8_t i` variable I use as a counter in my for-loop is working just fine" -- I think that the compiler just optimizes out loop variable and does not use stack for it. There are a few things here to try here. You can try to add "static" to your strings that you are trying to print, so those will be not placed on stack (not sure if they are now). If you confirm that the issue is with printing strings located on stack then you can focus on making sure that stack pointer is pointing to valid memory.
Best regards, Petro чт, 1 серп. 2024 р. о 03:13 Matteo Golin <matteo.go...@gmail.com> пише: > Hello all, > > I've been working on this problem for a while now and I'm not quite sure > how to progress in my troubleshooting. > > I am trying to port NuttX to the Raspberry Pi 4B, which has been going well > thanks to the documentation suggestions from my previous email (especially > Lup's blogs which have been invaluable). > > There is an option for aarch64 to enable early printing within the NuttX > boot sequence. This enables the use of a PRINT macro > < > https://github.com/apache/nuttx/blob/fe45d8aace2683b212e4ca2b9166a5df93c760fe/arch/arm64/src/common/arm64_head.S#L63 > > > in the startup code which is quite useful to me as debug output to see how > far along the boot is getting. > > I have been able to implement the `lowputc` requirements to enable early > printing, but I am encountering what I consider to be a strange issue. > My `arm64_earlyprintinit` > function > < > https://github.com/apache/nuttx/blob/fe45d8aace2683b212e4ca2b9166a5df93c760fe/arch/arm64/src/common/arm64_head.S#L215 > > > is being called and executed just fine, and same for the `arm64_lowputc` > function. I expected to see the output of the PRINT macros in my serial > console, but just got some garbled output followed by a crash (indicated by > the Pi LED). I thought I had configured the UART wrong, but after some > debugging involving adding direct calls to `arm64_lowputc` at the end of > the `arm64_earlyprintinit`, I saw that UART was configured just fine > because I was able to see the characters printed by my direct calls. > > My next step was to print a string like "Hello NuttX!", so I did that by > using `arm64_lowputc` calls in a for loop. This didn't work, and I got some > garbled output again. After some more tinkering, I discovered that if I > marked the string literal as `static`, my printing in a for-loop succeeded. > I thought maybe this was a problem with the stack initialization, but the > `uint8_t i` variable I use as a counter in my for-loop is working just > fine. > > MESS:00:00:06.225070:0: Loaded 'nuttx.img' to 0x200000 size 0x46000 > > MESS:00:00:06.231469:0: Kernel relocated to 0x480000 > > MESS:00:00:06.235742:0: Device tree loaded to 0x2eff2000 (size 0xdf76) > > MESS:00:00:06.243988:0: uart: Set PL011 baud rate to 103448.300000 Hz > > MESS:00:00:06.251071:0: uart: Baud rate change done... > > MESS:00:00:06.253089:0:Hello from NuttX! > > > *The debug output of the Raspberry Pi start.elf program, followed by the > printing of a static "Hello from NuttX!" string. Immediately after should > be a second printed output, but it does not show because the string is > non-static and this seems to crash the boot process.* > > Other bare-metal kernels for the RPi that I've seen online do not have this > issue, and can print non-static strings over UART just fine. I've even > tried compiling one of the tutorial kernels to try on the Pi and it does > boot and print the non-static string (see here > <https://github.com/babbleberry/rpi4-osdev/tree/master/part3-helloworld>). > > I cannot wrap my head around why I would be able to print a static string, > but not a non-static one. Both strings appear in the `.rodata` section of > the image when I inspect it with `objdump` as well. Even the assembly > `PRINT` macro in the arm64_head.S startup code declares the strings as > rodata. I'm not sure what the difference is here, but it's preventing me > from continuing to debug the boot process. I'm by no means very > experienced, so I feel a bit stuck with this issue. I thought I would check > if anyone here has encountered something similar. > > In case it's of any use, my development branch can be found here: > https://github.com/linguini1/nuttx/tree/bcm2711 > You can compile the exact same image as me with `./tools/configure.sh > raspberrypi-4b:nsh && make` (in case you have a Pi 4B and want to try). > > Any tips or pointers of what else I can check would be really appreciated! >
