Full Version: Padi bootloader info
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I'm trying to develop a minimal application made by a "main" while loop. I've followed the Makefile shipped with the SDK sample application, but did not bring in all of the sw libraries that are linked in in the original sample sdk app.

The resulting binary is correctly flashed onto padi, but when I debug the application with gdb, after the "monitor reset 0" I'm not able to reach the main() code.
If I do force the program counter with "set $pc = main" I manage to run the proper code.

I've properly stripped the ram_1.r.bin sections into an object file

arm-none-eabi-objcopy --rename-section,contents,alloc,load,readonly,data
-I binary -O elf32-littlearm -B arm tools/bootloader//ram_1.r.bin build/bootloader.o

and linked such objfile `bootloader.o` in:

arm-none-eabi-g++ -mcpu=cortex-m3 -mthumb -g --specs=nano.specs -nostartfiles -O0
-ffunction-sections -fdata-sections -std=c++11 -fno-use-cxa-atexit
-L../sdk/component/soc/realtek/8195a/misc/bsp/lib/common/GCC/ -L./env/
-L./arm-none-eabi/lib/thumb/ -nostdlib -nodefaultlibs -nostartfiles -Wl,--cref
-Wl,-Map=build/ -Wl,--entry=Reset_Handler -l_wlan -l_p2p -l_wps -l_rtlstd
-l_websocket -l_xmodem -T rlx8195A-symbol-v02-img2.ld -o build/app.axf
build/main.o build/bootloader.o -lstdc++ -lm -lgcc -lc -lnosys

I've objcopied sections of the image_2 text area stuff as in the sample app into a binary file

arm-none-eabi-objcopy -j .image2.start.table  -j .ram_image2.text  -j .ram_image2.rodata  -j
-Obinary build/app.axf build/app.bin

And I've "picked" the text and sdram image stuff with IAR pick tool (still don't understand what its role is):

tools/iar_utils/pick "0x"`grep __ram_image2_text_start__ build/app.nmap | cut -f 1 -d " "` \
        "0x"`grep __ram_image2_text_end__ build/app.nmap | cut -f 1 -d " "` \
        build/app.bin build/app.text.bin body+reset_offset+sig > /dev/null
tools/iar_utils/pick "0x"`grep __sdram_data_start__ build/app.nmap | cut -f 1 -d " "` \
        "0x"`grep __sdram_data_end__ build/app.nmap | cut -f 1 -d " "` \
        build/sdram.bin build/ body+reset_offset > /dev/null

I've then padded the "ram_1.p.bin" image with "padding" tool:

tools/iar_utils/padding 44k 0xFF tools/bootloader//ram_1.p.bin > /dev/null

and set the RamFileSize:

echo 'set $RamFileSize = '`du -b build/img.bin |cut -f1 -d 'b'` > build/fwsize.gdb

And finally I've concatenated the various outputs as in sample Makefile app

cat build/ram_1.p.bin > build/img.bin
cat build/app.text.bin >> build/img.bin
cat build/ >> build/img.bin

Still I cannot get to run the main code. I've tried to disassemble and gdb debug the sample app and mine, and can observe that the "main" is invoked from an "_AppStart" routine called from some place in ram_1.p.bin or ram_1.r.bin, I believe.

My question:
what is the key point where "main" is actually invoked? What happens before main and what am I skipping/doing wrong?
Moreover, what about ctors and dtors global vars etc..? I've seen the bneq loop of the bss zone clean up, but can't get the whole picture right.

The obscure parts are, I think


What do they do exactly?

Also, I'd like some clarification of the role of the following files


Thanks in advance
It came out I had to poke nose in bootloader stuff
bootloader apparently looks for a "RTKWin" strings located at 0x10006004 address
That's image2 validation signature (or so I understood).
If the comparison matches, the bootloader code tries to load and jump to the address found in 0x10006000.
So: if you fill the address with &main addr, you are good to go

Here's the piece of code to do the job:
extern "C" {

int main();

int (* const RAM_MAIN_ADDR)()  __attribute__ ((section (""))) = &main;
const char RAM_IMG2_VALID_PATTEN[7] __attribute__ ((section (".image2.validate.rodata"))) = "RTKWin";

This tells the linker to put things in the right places. With those two lines I'm able to boot to main
Let me add the  RTKWin string is *very* obscure.
And also.. I cannot find any correlation to the linker script .ld memory areas with respect to UM0034 mem layout

Now I will focus on having a better understanding on mem layout and bootloader job.

Anyhow, gcc 7.3 (30% smaller .text footprint without any -O) with c++ and STL support.. starting to get some grip.. Big Grin
Thanks for investigating and writing the update, I am also interested in 'bare-metal' programming...
I'm trying to collect my understanding, since I'm feeling more and more confused about RTK memory
The UM0034 doc says :

[Image: H922FYW.png]
Currently data and program code is uploaded in region starting from 0x10006000 (verification code) up to 0x1000A758 (end of my bss data). The linker script calls this region "BD_RAM", which I'm afraid I don't know the acronym's meaning, nor have seen any documentation about. I assume this is what the UM0034 describes as SRAM (0x10000000~0x1006FFFF).

Now, if I try to move the $pc to 0x30000000 and "layout asm" I cannot even see the asm instruction being run and I lose control of the MCU with the first step instruction.

So how am I supposed to run something on that address ?