Advanced Boot loader and usage of SRAM

5 posts / 0 new
Last post
CD
Offline
Last seen:3 years 10 months ago
加入:2015-11-18 02:51
Advanced Boot loader and usage of SRAM

Hi,

Please let me ask the questions about the Advanced Boot loader and usage of SRAM related things on DA14583.

We would like to create the Advanced Boot loader for DA14583. I’ve already read “UM-B-012” but I would like to comfirm these related things.

Our Scenario:
- We write two application images(bin) on Flash. The size of both images are almost 32kB(ROM)/8kB(RAM). When each image is executed 40kB RAM would be consumed.
——我们分配1个字节国旗Flash选择我mage should be loaded.
- Advanced boot loader will check this flag and decide which one to boot.

Questions:
1. I suppose that Advanced Boot Loader is loaded to SysRAM and it would be executed (from 0x2000000). Size of Advanced Boot Loader is approximately 6KB. Are these right?
2. When Advanced Boot Loader loads an appriication image to RAM, are there any rooms to load? (An application image size is 40kB on RAM, but Advanced Boolt Loader have also consumed 6kB RAM…) Does it work well? Is our scenario achievable???
3. When Advanced Boot Loader loads an apprication image to SRAM, can we assign the address to be loaded on SRAM? Or, is it fixed?
4. When Advanced Boot Loader resets itself, can we set the entry address of Program Counter? or is it fixed?

Sorry for many questions, but we wouled like to confirm whether our scenario is possible or not.

Thank you very much for your supports in advance.

Best Regards,
CD

Device:
Joacimwe
Offline
Last seen:1 year 5 months ago
Guru
加入:2014-01-14 06:45
You should check out the boot

You should check out the boot loader project in the SDK. It is located in utilities\secondary_bootloader. It does almost exactly what you want. Two images are located on flash and the one selected to run is copied into SysRAM and is then started.

The size of the advanced boot loader is about 6 kb, depending how you configure it. It is loaded to SysRAM and executed from address 0x0. Note that when address 0x0 is remapped to SysRAM, address 0x0 is mapped to the same memory cell as 0x20000000.

When you create an image, you have two sizes, the actual size of the image and the RAM usage of the application. The amount of RAM needed by the application is initialized when the application starts and does therefore not take up any space in the image. The initial PC is chosen by the linker and placed at offset 0x4 in the image and should not be changed.

If you look in the scatterfile of the advanced boot loader (startup\bootloader.sct), you will see that everything except startup code is placed in execution region 0x80000. That means the ARM linker generates code that when the advanced boot loader starts, all boot loader code is copied to 0x80000 and then runs from there. That means SysRAM is now free which the boot loader will fill in with the final application.

When your final application is then started (32 kb), the linker-generated code of the application will initiate the RAM sections you have declared (8 kb) with zeros. That means if you have variables at address 0x80000 the initialization code will overwrite the boot loader which is ok since it is not needed anymore.

I'm not sure what you mean or want to achieve with loading the application to a specific location in the memory. The ARM processor assumes it is initially placed at address 0x0 when the reset handler is called. All interrupt handlers must also be placed at the beginning of SysRAM to work. You can of course use the scatter file to put your functions and variables at specific addresses if you want to.
Note that applications are however normally designed to be run from 0x20000000 rather than 0x0. This will also work, even if 0x0 is remapped to ROM since (almost) all ROM interrupt handlers are trampolines into the interrupt handlers at 0x20000000.

Hope this answers your questions.

CD
Offline
Last seen:3 years 10 months ago
加入:2015-11-18 02:51
Hi Joacimwe,

Hi Joacimwe,

Thank you very much for your detailed comment. Now, I'm getting understood little by little.
You mentioned "Advanced boot loader except startup code is going to be placed 0x80000 region and executed", which is what I would like to know. Actually, I had not understood about scatter file and ARMLinker behaviors until you pointed them out.
Let me confirm whether my understanding about system boot and Image loading is correct or not, please:

- (Primary) Bootloader
Bootloader is hard-coded in ROM. When powered ON, Bootloader is executed and check whether Advanced bootloader is existing or not. If it exists, Bootloader loads Secondary bootloader which is burned in factory, and if it doesn't exist, Advanced bootloader and copy it to 0x20000000, then executes it. (then, advanced bootloader can located in OTP only.)

- Secondary Bootloader (Adcanced Bootloader)
Scatter file is defined to:
* two initializing files (startup_CMSDK_CM0.o and system_CMSDK.o) are addressed to 0x0000000.
* Rest of ROM, RAM, Stack parts are addressed to 0x80000.
So, ARMLinker allocates the objects and also generates the code to copy them to appropriate place. The code generated by ARMLinker is executes in advance of initializing files. (maybe..)

When Secondary bootloader copies the target image from the external memory to 0x20000000, Secondary bootloader itself is executed on 0x80000 region. So, it is ready to copy it at that time.

The above is what I've understood know... Is it correct?
Thank you so much for your cooperation again.

Best Regards,
CD

Joacimwe
Offline
Last seen:1 year 5 months ago
Guru
加入:2014-01-14 06:45
你完全正确

你完全正确about the second part.

For the first part, I agree the terms are a bit confusing. DA14580 and DA14583 have the exact same ROM code and therefore the same primary bootloader.
The "secondary bootloader" project is programmed by the customer on DA14580 into the OTP.
On DA14583, this project is instead called "advanced bootloader", since there is already a pre-programmed (completely different) secondary bootloader on the OTP.
On DA14583, the ROM code always boots the secondary bootloader since it is hardcoded to do so. Now, if there is an "advanced bootloader" programmed by the customer as well, the secondary bootloader will detect that (according to UM-B-012) and start it. So in the end, if you program the advanced bootloader and your application code, in total three bootloaders will be run before your application code runs ;)

CD
Offline
Last seen:3 years 10 months ago
加入:2015-11-18 02:51
Hi Joacimwe,

Hi Joacimwe,

Now all things are clear to me.
Thank you sooo much for sparing your time for my questions!

Best Regards,
CD