What's the purpose of AT91Bootstrap after all?

Discussion around products based on ARM Cortex-A5 core.

Moderator: nferre

arudzins
Posts: 9
Joined: Tue Oct 03, 2017 11:29 am

What's the purpose of AT91Bootstrap after all?

Tue Oct 03, 2017 3:22 pm

Hi,

as I wrote a post or two earlier, I'm trying to port AT91Bootstrap to a custom SAMA5D2-based board. My impression is that the build process is terribly complicated, so there must be a reason for that. I can think of two possibilities: 1) either this bootloader does much more than I think or 2) it just is configured for automated compilation for a large number of predefined boards, which makes its configuration much more complicated than it could be. I did some reading on the subject, but no description was as concise and precise as I would like.

If my understanding is correct, AT91Bootstrap is a bare-metal application, which is (automatically) put by the 1st bootloader (the one from ROM, which comes with the chip) into RAM under address 0x00000000, then configures system clock(s), then does some hardware init just sufficient to make the next step, then grabs from a predefined medium, from a predefined address, a predefined number of bytes, and whatever it finds there, puts it into RAM under a predefined address, and jumps there to execute the code. (It also might de-init the previously initialized peripherals before the final jump.)

Please, let me know if that's it, or I am missing something important.

Best regards,
Adam
blue_z
Location: USA
Posts: 1504
Joined: Thu Apr 19, 2007 10:15 pm

Re: What's the purpose of AT91Bootstrap after all?

Wed Oct 04, 2017 12:56 am

arudzins wrote:If my understanding is correct, AT91Bootstrap is a bare-metal application,
To me "bare-metal application" is an oxymoron.
I prefer "standalone" over "bare-metal", which seems like jargon trying to be clever.
"Application" is a type of program on the opposite side of the spectrum from OS and supervisory programs.
AT91Bootstrap is a standalone program.
arudzins wrote:... which is (automatically) put by the 1st bootloader (the one from ROM, which comes with the chip) into RAM under address 0x00000000, then configures system clock(s), then does some hardware init just sufficient to make the next step, then grabs from a predefined medium, from a predefined address, a predefined number of bytes, and whatever it finds there, puts it into RAM under a predefined address, and jumps there to execute the code. (It also might de-init the previously initialized peripherals before the final jump.)

Please, let me know if that's it, or I am missing something important.
Bonus points to you for recognizing the Atmel RomBOOT as the first stage of boot. You'll encounter some documents (including some from Atmel) that ignore the RomBOOT stage.

You fail to distinguish between the two different types of RAM involved in the boot sequence.
AT91Bootstrap is loaded into the static RAM (SRAM), which is internal to the SoC (and therefore will exist for all installations), is limited in size, and requires no initialization.
The RAM that the image is written to by AT91Bootstrap is main memory implemented with dynamic RAM (e.g. DDR3 SDRAM) which is external to the SoC (and therefore is board specific) and requires (a board-specific) configuration prior to use.

If the image that AT91Bootstrap loads is another standalone program, e.g. U-Boot, then such a program typically has no special requirements before being executed.
However booting a Linux kernel image does have its requirements. See Documentation/arm/Booting in the kernel source.

Regards
arudzins
Posts: 9
Joined: Tue Oct 03, 2017 11:29 am

Re: What's the purpose of AT91Bootstrap after all?

Wed Oct 04, 2017 8:56 am

As a primarily hardware guy I've always wondered why it's "bare-metal", not "bare-semiconductor". I like the name "standalone program".

Right, I've missed the initialization of the external RAM. It is necessary for the Linux kernel (which is large) or U-Boot (which expects to be located under a specific address, which probably is out of the internal RAM).

However, the list of duties is still not long. So it looks like it might be actually easier to prepare an alternative bootloader crafted only for my board than to learn how to configure AT91Bootstrap.

In my case the list seems to be something like this:
1) Initialize "system things", like clocks, disable watchdog.
2) Initialize something and check if there is a condition (like an emergency button pressed) for wiping out the bootstrap program (to return to default bootloader from ROM and start again).
3) Initialize DDR2.
4) Initialize eMMC.
5) Copy "the next stage program" from eMMC to RAM.
6) Prepare ground for executing "the next stage program": deinitialize eMMC? initialize some other things.
7) Run "the next stage program".

And, if I understand correctly, the code of this bootstrap program is never ever needed again, so the next programs are free to use the memory initially occupied by the code, right?
blue_z
Location: USA
Posts: 1504
Joined: Thu Apr 19, 2007 10:15 pm

Re: What's the purpose of AT91Bootstrap after all?

Fri Oct 06, 2017 8:56 pm

arudzins wrote:So it looks like it might be actually easier to prepare an alternative bootloader crafted only for my board than to learn how to configure AT91Bootstrap.
That attitude is so last century.
Modern software engineering advocates portability and re-usability. So if you're going to use open-source software, prepare to configure it.

Also beware of the copyright and license issues when developing "your" code derived from open-source (e.g. GPL) software.

Regards
arudzins
Posts: 9
Joined: Tue Oct 03, 2017 11:29 am

Re: What's the purpose of AT91Bootstrap after all?

Sat Oct 07, 2017 1:35 am

There's a thin line between "reuse" and "misuse". I might prefer to "reuse" C header files and documentation of the processor. That's not possible in every case, of course.
arudzins
Posts: 9
Joined: Tue Oct 03, 2017 11:29 am

Re: What's the purpose of AT91Bootstrap after all?

Wed Oct 11, 2017 7:30 pm

OK, I think I've ported AT91Bootstrap to my board.
I'll know for sure when I have U-Boot as well.

However, here is a handful of hints for other newcomers.

First, prepare a standalone a.k.a. bare-metal program which sends something via UART. The program should only: enable clocks of PIO controller and the UART, initialize necessary PIOs and the UART itself. The UART here is the one which you're going to use as a "console" during boot. Translate this code so that it didn't use any processor specific header files, i.e. use addresses instead of register names.

To start with AT91Bootstrap, I've found this presentation useful:
http://free-electrons.com/pub/conferenc ... on-arm.pdf
It explains where to add files and what is their expected contents. For me it was more informative than the readme file.

Knowing that, prepare the necessary files. If I remember correctly, the presentation doesn't mention file Config.in.boardname, which is also necessary. Use a board name which doesn't contain any spaces etc., it defines also names of files.

Prepare default selections and allowed values in Config.in.board. It seems that the config preprocessor macros are not documented, so you need to have a look inside similar files of other boards. Similarly, you define default choices in <board>*config file. Try to determine which board has the same resonator, and which has the same DDR memory, which has the same NVM, and copy the relevant CONFIG_*'s. Try to generate a default config (make ...config, this is documented everywhere) for any board and have a look inside the generated .config file, I don't know if this provides a complete list, but I found some CONFIG_*'s there.

Now comes the time to generate the prepared config for your board, and then run make menuconfig. In contrast to what I would expect to use this for, I used it to check if the config is complete. I found some options which I couldn't have set, and that was a sign that my configuration was missing something. make menuconfig had no other use for me.

Check .config generated for your board. I don't know if that's a rule, but to disable some CONFIG_*'s I had to add line
# CONFIG_... is not set
in the file with the default choices.

Among other files, you should've created .c and .h files in the directory of your board. The .h file will contain further configuration preprocessor macros, defining "hardware stuff" (what a surprise, no?). The .c file will contain functions responsible for initialization of the board. Large parts of these files will be copied from respective files for the other boards which you've found similar. Use your common sense here! Not everything is "reusable". In particular, the sources from git contained header files different than the software package for the processor, and the header files didn't define USARTs using FLEXCOMs, so I had to add "extra" code here. I recommend compilation in small steps. See what's missing, and find where it is defined (grep comes in handy), one thing at a time.

You also need to know that not all the sources get rebuilt, so if something doesn't work, you may need to wipe the source code tree clean of any built object files. In my case the build didn't update address of the UART. Disassemble the code and compare it with the "reference UART" program I've mentioned up there at the beginning of the hints.

Once you are able to build the code, there is a chance that it will work. For me it was not like that. For debugging I have used the basic UART program. It needs to use addresses instead of defined register names to avoid any problem with incompatibility of header files. I've added the procedure to init and send string via the UART, and invoked it as the first thing in the .c file. Now you expect to see something at the UART, and eventually I did. Then it's like normal debugging.

I hope I remembered about the important pitfalls and that my description is "human readable".

Return to “SAMA5D Cortex-A5 MPU”

Who is online

Users browsing this forum: No registered users and 1 guest