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 <[email protected]> schreibt:

Try again - it's all there (only, the naming is different)!

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

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

 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstra?e 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

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

Well, then you probably should replace this urloader by U-Boot ;)

Robert

 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstra?e 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

That's the plan! :o)

But I'll try the ATMEL solution first. To see if my board comes up at all.

Thanks,

Steven

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 <[email protected]>
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,

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