[U-Boot-Users] Startup for ARM boards?

[U-Boot-Users] Startup for ARM boards?

[Steven Scholz]

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

[U-Boot-Users] Startup for ARM boards?

[Anders Larsen]

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

[U-Boot-Users] Startup for ARM boards?

[Robert Schwebel]

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
-- 
 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

[U-Boot-Users] Startup for ARM boards?

[Steven Scholz]

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

[U-Boot-Users] Startup for ARM boards?

[Robert Schwebel]

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
-- 
 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

[U-Boot-Users] Startup for ARM boards?

[Steven Scholz]

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

[U-Boot-Users] Startup for ARM boards?

[Marius Groeger]

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

[U-Boot-Users] Startup for ARM boards?

[Steven Scholz]

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