[U-Boot-Users] Startup for ARM boards?
Hi there,
I am trying to figure out how ARM based board start up.
PPC boards basicly have a board_init_f(), doing initialization, then relocating the code from flash to ram using relocate_code(), and then continue in ram with board_init_r().
I can't find anything like this in the ARM based files?
How is that done? Is that the same for all ARM boards?
Thanks a million,
Steven
Steven Scholz steven.scholz@imc-berlin.de schreibt:
PPC boards basicly have a board_init_f(), doing initialization, then relocating the code from flash to ram using relocate_code(), and then continue in ram with board_init_r().
I can't find anything like this in the ARM based files?
Try again - it's all there (only, the naming is different)!
How is that done? Is that the same for all ARM boards?
Execution starts in cpu/<your-cpu-here>/start.S which does the initial initialization, helped by board/<your-board-here>/memsetup.S When memsetup.S has set up the (S)(D)RAM, start.S relocates the code from flash to RAM and continues with start_armboot() in lib_arm/board.c
This is practically identical for all ARM boards, yes (but watch out for the details ;-).
HTH Cheers Anders
On Wed, Sep 24, 2003 at 11:09:27AM +0200, Steven Scholz wrote:
I am trying to figure out how ARM based board start up.
PPC boards basicly have a board_init_f(), doing initialization, then relocating the code from flash to ram using relocate_code(), and then continue in ram with board_init_r().
I can't find anything like this in the ARM based files?
How is that done? Is that the same for all ARM boards?
Unfortunately, ARM is still different. For example, for the PXA it works like this:
- cpu/pxa/start.S: reset code; relocate U-Boot to RAM (no probing); setup stack; clear BSS
- lib_arm/board.c: start_armboot(): all kinds of uggly initialisation steps; init_sequence has a call to board_init().
Robert
Thanks very much for these hints!
It's getting a bit clearer now.
I will have a AT91RM9200 based board real soon now. But apparently the eval board AT91RM9200DK uses a different approach. They have a separate urloader to decompress and copy an U-Boot image into RAM and then jump there...
Thanks,
Steven
On Wed, Sep 24, 2003 at 12:12:01PM +0200, Steven Scholz wrote:
I will have a AT91RM9200 based board real soon now. But apparently the eval board AT91RM9200DK uses a different approach. They have a separate urloader to decompress and copy an U-Boot image into RAM and then jump there...
Well, then you probably should replace this urloader by U-Boot ;)
Robert
Robert Schwebel wrote:
On Wed, Sep 24, 2003 at 12:12:01PM +0200, Steven Scholz wrote:
I will have a AT91RM9200 based board real soon now. But apparently the eval board AT91RM9200DK uses a different approach. They have a separate urloader to decompress and copy an U-Boot image into RAM and then jump there...
Well, then you probably should replace this urloader by U-Boot ;)
That's the plan! :o)
But I'll try the ATMEL solution first. To see if my board comes up at all.
Thanks,
Steven
On Wed, 24 Sep 2003, Steven Scholz wrote:
Robert Schwebel wrote:
On Wed, Sep 24, 2003 at 12:12:01PM +0200, Steven Scholz wrote:
I will have a AT91RM9200 based board real soon now. But apparently the eval board AT91RM9200DK uses a different approach. They have a separate urloader to decompress and copy an U-Boot image into RAM and then jump there...
Well, then you probably should replace this urloader by U-Boot ;)
Actually this "urloader" is called Thunderboot and is a ripped version of ARMboot (a practice which seems to be quite fashionable these days.) I never got round to asking them for the sources, nor do I understand why they concealed it so pathetically :-) The flash images even contain references to ARMboot. Maybe you want to have a go at them?
Regards, Marius
-- Marius Groeger mgroeger@sysgo.de Software Engineering
SYSGO Real-Time Solutions AG | Embedded and Real-Time Software Am Pfaffenstein 14 55270 Klein-Winternheim, Germany
Voice: +49-6136-9948-0 | FAX: +49-6136-9948-10 www.sysgo.de | www.elinos.com | www.osek.de
Marius,
I will have a AT91RM9200 based board real soon now. But apparently the eval board AT91RM9200DK uses a different approach. They have a separate urloader to decompress and copy an U-Boot image into RAM and then jump there...
Actually this "urloader" is called Thunderboot and is a ripped version of ARMboot (a practice which seems to be quite fashionable these days.) I never got round to asking them for the sources, nor do I understand why they concealed it so pathetically :-) The flash images even contain references to ARMboot. Maybe you want to have a go at them?
Ehm. Nope. That's not what I meant. They replace Thunderboot by their so called "AT91RM9200-Boot". Then they build a U-Boot version for the eval board AT91RM9200DK and gzip it. The AT91RM9200-Boot and the zipped version of AT91RM9200-U-Boot are stored in flash. Now all that AT91RM9200-Boot does when power-on is init the hardware (especially SDRAM), decompress u-boot.gz into SDRAM and jump to it.
Atmel said:
"We chose, to put a compressed boot due to memory mapping constraints. We need to keep a sector for environment variables the 8Kbyte-size sector is enough."
IMHO this wasn't nessesary at all since they do seem to have flash with a few small sectors. But nevermind.
They even provide a "AT91RM9200-Loader" which could be used to download the above files via the DEBUG UNIT (DBGU).
I got these sources from Atmel. Now that I have these source I hope I can get this working on my board as well. Then when this two-(or three)-step version works I want to make U-Boot working like for all the other plattforms: init SDRAM, relocate and start.
Ok?
Steven
participants (4)
-
Anders Larsen -
Marius Groeger -
Robert Schwebel -
Steven Scholz