Hello to everyone!! I need some advices about scatter loading; In my application I have a scatter file to load a binary in external SDRAM (0xA0000000) by a bootloader; i would place some piece of
code in FLASH, but leave the mail LOAD REGION in SDRAM; According to ARM Linker Manual, chapter 8, I made up this file:
LR_ERAM1 0xA0000000 0x00100000 { ER_ERAM1 0xA0000000 0x00100000 { *.o (RESET, +First) *(InRoot$$Sections) } RW_IROM1 0x00000000 0x00010000 { ; RW data .ANY (+RO) } RW_ERAM1 0xA1000000 0x00010000 { ; RW data .ANY (+RW +ZI) } RW_IRAM1 0x10000000 0x00010000 { ; RW data .ANY (+RW +ZI) } }
One Load Region in SDRAM, more than one execution region in FLASH, SRAM and SDRAM. According with the linker documentation, RO region placed first and after RW and ZI. Soon as I put the FLASH region, with RO inside application HANGS; if I leave the RO inside the first ER_ERAM1 all is OK.
I have LPC1788 Cortex-M and KEIL uVision 4.72.
Any advice?
Pier, I didn't noted before You said "two IROM region describing SDRAM and FLASH/ROM"
Are You talking about TWO LOAD REGION FLASH BASED (0x0) one including execution regions in ext. SDRAM? This is correct, but still get the room limitation in FLASH, that is why I was routing toward EXTERNAL RAM loading... Thanks a lot. Again.. Paolo.
Yes, TWO IROM or ROM sections for the CODE, and TWO IRAM or RAM sections for the DATA (SRAM, and portion of SDRAM). For a 32MB SDRAM you could split the first 8MB for code, and the remaining 24MB for data.
If you can't separate your code into portions that are in ROM and those in RAM, then you will need to add some custom startup code in the ROM portion to load the SDRAM content from some kind of backing storage like a serial flash, or SD Card.
The code in ROM could call the code in SDRAM, and the code in SDRAM could call the code in ROM. All the linkage is provided by the linker. Getting the code/data into the right place is the job of a LOADER.
The linker will generate a .HEX or .AXF(ELF) file, and you will need to post-process that into the image that goes directly into the flash within the part, and a file containing the code to be loaded into SDRAM. For example you could burn the ROM part of the .HEX to FLASH, and then store the whole .HEX on an SD Card, and then using ROM based code to load and parse the .HEX file and place the SDRAM bound data there, after that memory has been initialized.
This might be better implemented in a small boot loader, perhaps ~16KB, with code to initialize SDRAM and support a file system on an SD Card. It could load the SDRAM bound code, and jump to the entry point of the ROM application.
Actually this was the first idea (and the first release), and in some part is already working; I have a .BIN file created from the AXF that is bootloaded in FLASH by a quite larger bootloader (~40K) but I went out of space in FLASH. After that would like to place ALL in SDRAM, the same way plus MPU etc etc but got speed issues. So I thought to separate regions, and first idea was to use a "double" bootloader, quite the same as your solution, to load separate modules, just like an OS. The hope, was to be able to let the linker do the dirty job by a special crafted scatter file, but docs and threads let a dark region about separating ROM/RAM (INT/EXT).
Anyway, Pier I really wish to tank You for the time spent. I'm still investigating...
In your model, how do you plan on storing and delivering the code/data you need into the SDRAM at start up?
The other thing that is done for speed is to create a ROM (mask level, in my case) with a lot of the library, and standard functions. There is a clear abstraction, and the linker imports these like external library calls via a definition file. The code never gets into the other RAM/FLASH based code, it just calls out the the addresses specified.
This is a bit like the model used by Stellaris to ROM CRC/AES functions and tables.
The linker can do a lot of the dirty work, but the Load Region might not be the way to go, as it infers a container from which other volatile memory area have their data/code/statics copied from. And you can't copy data out of a region into a Read Only memory. The idea is to be in Read Only memory and copy out each time the code starts.
As noted, a small boot loader in flash that loads in a program from a SD card can't/shouldn't make use of any flash space. It is a bit strange situation to have a small boot loader use IAP to flash parts of the loaded application (which would require CRC-32, MD-5, full content compare or similar to make sure the flash only gets reprogrammed after a change of the binary on the SD card) while copying the rest into DRAM.
It would be more logical if the SD card contained two image files.
One (optional) image file represents a "BIOS" update with help code that should be IAP-stored into flash and run there.
One image file represents the actual application that is 100% copied into RAM - potentially splitted between SRAM and DRAM if the processor supports it and can make use of higher SRAM execution speeds.
And the actual application then either uses a pointer table or is hard-linked to make use of functions within the flash region. Hard-linking would then require that the boot loader only accepts a situation where the two image files have a matching version, while the use of a pointer table would remove the need for the "BIOS" and application to have lock-step version releases.
But the scatter load files can't be used to distribute code from RAM into flash because the scatter loading is performed by help functions within the Keil library - and this code assumes that the scatter loading can be done with normal memcpy() while flash updates require special code. So any code to run in the flash must be stored there from factory or by some code you write that can perform IAP to refresh the flash content.
If the functions accessible from flash isn't required for the startup of the application, then the IAP code to verify the contents of the flash and optional update of the flash region from an SD file could be inside the DRAM-run code loaded from SD instead of in the boot loader. This allows the boot loader to be smaller and simpler. So the boot loader just loads a file from SD into DRAM and starts the program and custom code in the application then checks for a second SD file and verifies if it needs to be written to flash before making use of the pointer table to start to access flash code.
Pier and Per, those are realistic expansions of what I was thinking about; a sort of kernel loaded and run in FLASH/ROM, stored on SD card and IAP-ed when needed (update time) AND a second "layer" usually taken from SD card and stored at BOOT-time in EXT.SDRAM (INT SRAM if necessary for speed issues). Maybe first layer more a Bios than a Kernel, as noted. This requires a bit more time to be spent analyzing the structure of the code originally born to be loaded or flashed whole in a single region, in FLASH. I'll keep this thread updated soon as I'll have updates. Fell free to contribute!
Again, Thanks a lot to everyone, a great job is done in this forum.
Paolo.