Misunderstanding about how a program is booted up

[doaaron]

Hi all,


I have been working with a development kit, and I have a working program, but now I want to try booting up my MCU with a program stored in an SD card. Up until now I have been using SAM-BA and the SAM-ICE to load my program into the MCU's 512-kB internal flash.

I have been reading through the SAM9G25 datasheet, and I have some misunderstandings about how the boot sequence works. According to the datasheet, the MCU will look for a boot.bin file in external memories, and copy the file to SRAM, and then run the program.

1) Is this boot.bin file the same binary file which I created when compiling my program, and the one I sent to the internal 512-kB flash?

2) According to the datasheet, the boot.bin is loaded into the internal SRAM and then run. Currently my program is 188 kB and it runs fine. However, the internal SRAM is only 32 kB, of which 24 kB is usable. So how is it possible to copy my .bin file to the SRAM?

3) I have been reading up about how to boot from an external SD card, but if anybody has good info, I would be grateful. My doubts are related to the above questions.

4) Assuming I am able to boot from the SD card, I want the program to be copied to the internal flash and subsequently booted from there. How would I go about doing this?


Thanks,
Aaron

[blue_z]

According to the datasheet, the MCU will look for a boot.bin file in external memories, and copy the file to SRAM, and then run the program.

That is not an accurate restatement of what is in the datasheet.
A boot.bin file is only used with a SDcard, which has to have a FAT filesystem in the first partition. I.E. the SDcard has to be partitioned like a HDD (with a MBR) and not like a floppy diskette.
For nonvolatile memory chips, the boot program is identified by the first 28 bytes of memory matching an ARM Exception Vector.

1) Is this boot.bin file the same binary file which I created when compiling my program, and the one I sent to the internal 512-kB flash?

That depends on whether your program conforms to the restrictions on the booted SRAM program.

2) According to the datasheet, the boot.bin is loaded into the internal SRAM and then run. Currently my program is 188 kB and it runs fine. However, the internal SRAM is only 32 kB, of which 24 kB is usable. So how is it possible to copy my .bin file to the SRAM?

Then your program fails to meet the size restriction for SRAM execution.
You unqualified "it runs fine" assessment is not warranted.
You will need to use an intermediate program (aka a bootstrap), so that your program can be loaded and executed in main memory (DRAM).
That's the purpose of the AT91Bootstrap program.

3) I have been reading up about how to boot from an external SD card, but if anybody has good info, I would be grateful. My doubts are related to the above questions.

Study the datasheet again and SD card boot for AT91SAM SoC.

4) Assuming I am able to boot from the SD card, I want the program to be copied to the internal flash and subsequently booted from there. How would I go about doing this?

Then you need a utility program that can erase and write to Flash.
You could use SAM-BA to install program in Flash, and then use a different version of boot.bin to load from Flash instead of SDcard.
Or go the flexible route and use U-Boot (aka Universal Boot). Its "standalone" program capability seems to fit whatever you're trying to do.
Study AT91 Boot sequence.

Regards

[doaaron]

Thank you for the help. Actually I have read the pages you suggested, but its very difficult for me to make sense of them as I'm quite new to all of this, and there is a lot of talk about installing Linux on the MCU which is not what I want to do. At the moment, I am using SAM-BA and SAM-ICE to load my program into flash. Since my program is more than 32 kB, does that mean it is being loaded into DRAM? How does the MCU know to do that? The program I wrote is heavily based on examples in the MCU's software package so is this already defined in the software package code?

Or perhaps more simply, could you explain how the MCU boots up when using a SAM9 evaluation kit when the program is larger than the internal SRAM, assuming I used SAM-BA and SAM-ICE?


thanks,
Aaron

[blue_z]

Since my program is more than 32 kB, does that mean it is being loaded into DRAM?

Probably. I'm not there to watch what you do.

How does the MCU know to do that?

It doesn't. What did you tell SAM-BA to do?

The program I wrote is heavily based on examples in the MCU's software package so is this already defined in the software package code?

Probably, check for yourself.
Where is the linker locating the start of the code? Is that address in SRAM or DRAM?

Or perhaps more simply, could you explain how the MCU boots up when using a SAM9 evaluation kit when the program is larger than the internal SRAM, assuming I used SAM-BA and SAM-ICE?

I rarely use the SAM-BA application, so I'm not that familiar with it.

Using the SAM-BA application will take you out of the boot framework as described in the various links I mentioned.
As described in the boot section of the SoC datasheet, when the SoC does not find a boot device, the RomBOOT program ends and the SAM-BA Monitor program begins execution. It is this on-board monitor program that is communicating with the SAM-BA utility executing on your PC. Technically the SoC is no longer in a "boot mode".

The SAM-BA utility can load its small programs into SRAM, and have tasks performed to initialize DRAM, transfer files from the PC to DRAM, initialize NAND Flash, erase NAND Flash and write from DDRAM to NAND Flash. The GUI obscures the underlying operations, and is a poor tool to learn from.

Download the SAM-BA source code and analyze it if you want to know how it works.

Regards

[lucywang]

Hi Aaron,

I'm overseas sales of ARM 9 , our MCU is 9G25 too, we also have development board of ARM 9. So I have some datasheets and schematic diagram. But I think our development is different from yours, maybe they have the same theory. If you need , I can send to you. Hope it is helpful. Thanks~

[doaaron]

It doesn't. What did you tell SAM-BA to do?

When I run SAM-BA, I do two things. I send my program to flash, and I execute a script to boot from flash. I didn't write the script, and I wasn't able to find the script in the SAM-BA installation folder so I'm not really sure what it does. Anyway, I will see if I can figure out exactly what the script is doing.

Where is the linker locating the start of the code? Is that address in SRAM or DRAM?

Thanks for the clue. I'll see what I can dig up. The initialization and startup code was included in the start-up code and so far I haven't tried to trace exactly what its doing.

The SAM-BA utility can load its small programs into SRAM, and have tasks performed to initialize DRAM, transfer files from the PC to DRAM, initialize NAND Flash, erase NAND Flash and write from DDRAM to NAND Flash. The GUI obscures the underlying operations, and is a poor tool to learn from.

I guess the SAM-BA program is doing a lot more than I originally thought.

thanks for the help.



Hi Lucywang,
thanks for the offer. I have datasheets and schematic diagrams for the development kits, but if you have something you think might help, I would love to see it. Thanks.

[uCSimply]

Maybe this would help a bit.
discussions/viewtopic.php/f,30/t,23486.html
The principle is equal as with SAM9G25.

[doaaron]

Thanks for the link. I've skipped through it and it looks interesting so I'll definitely read it more carefully soon.

In the meantime, I realise I had a pretty big misunderstanding about my code. The code is 180 kB, but as I now understand it, the amount that will be initially loaded into RAM is only around 1 kB.

Now I'm starting to wonder how MCU will differentiate between which parts of the code need to go into RAM and which don't. The reason I'm confused is because in the datasheet, it says the program needs to be named boot.bin. So how does a single program, only 1 kB of which gets loaded into RAM, get named with a single file name? Any hints/links would be appreciated.


thanks,
Aaron