Forums

ARM processors and remap

Started by Mark December 17, 2008
Hello

I'm going to port bootloader U-Boot on a ARM based platform (arm926ej-s 
specifically), my final goal is to lauch Linux on my board. I worked with 
arm7 CPU before, although this is my first experience with U-Boot. Now I'm 
gathering information on it.

Many MCUs built on arm7tdmi core (for example, SAM7 family from Atmel) 
involve remapping, i.e. 0x0 address points on ROM at reset and on RAM after 
remap. U-Boot usually resides in ROM storage at startup, after reset 
relocates itself to RAM. What I don't quite understand is -- does U-Boot 
need to do remap, if it'll later pass control to Linux (which itself is 
doing remap, isn't?).

In U-boot source tree some platform do remap, others don't (I assume because 
they have some sort of preliminary bootcode, initializing hardware, SDRAM 
and doing remap before copying uboot on to it -- but this is still my 
guess).

Hopefully, embedded experts may clarify my doubts and questions.

-- Mark 


Mark wrote:

> I'm going to port bootloader U-Boot on a ARM based platform (arm926ej-s > specifically), my final goal is to lauch Linux on my board. I worked with > arm7 CPU before, although this is my first experience with U-Boot. Now I'm > gathering information on it.
Why do you want to port it yourself? Some searches with Google shows, that this was already done, e.g. this board: http://www.taskit.de/produkte/stamp/index.htm uses an ARM926EJ-S microcontroller and the board has an U-Boot loader and Linux. They have to give you the U-Boot source (U-Boot is GPL licences, so all changes to U-Boot are public, too), if it is not already as a target included in the official U-Boot release. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
Hello, Frank
You wrote  on Wed, 17 Dec 2008 08:37:45 +0100:

 FB> Why do you want to port it yourself? Some searches with Google shows,
 FB> that this was already done, e.g. this board:

 FB> http://www.taskit.de/produkte/stamp/index.htm

Why do you think this board is similar with mine, so I might want to look at 
that?

-- Mark 


Mark wrote:

> Why do you think this board is similar with mine, so I might want to look at > that?
You mentioned as an example the SAM7 family. Would be easier to help, if you could say the CPU name. There are so many CPUs and boards already in U-Boot, that someone might point you to a similar one with which you can start. If you have a very different platform, it might be some work to add it to U-Boot, but this would be very simple, compared to the work you need for the Linux kernel :-) To answer your questions: I think the copy to RAM is done, because usually it is faster to execute programs from RAM. I don't think that you need to do this, because U-Boot is mostly C, which doesn't use self modifying code and should work from ROM, if your CPU supports it and if you initialize the stack etc. to RAM locations. For Linux it depends on your system. E.g. on a PC, Linux is uncompressed to 0x100000. On some embedded platforms it will be uncompressed to address 0. You can define for the uImage where you want it to start from. I don't think that memory remapping is required. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
Hello, Frank
You wrote  on Wed, 17 Dec 2008 15:03:23 +0100:

 ??>> Why do you think this board is similar with mine, so I might want to
 ??>> look at that?

 FB> To answer your questions: I think the copy to RAM is done, because
 FB> usually it is faster to execute programs from RAM. I don't think that
 FB> you need to do this, because U-Boot is mostly C, which doesn't use self
 FB> modifying code and should work from ROM, if your CPU supports it and if
 FB> you initialize the stack etc. to RAM locations.

My concern is how to define a memory map and consequently a valid TEXT_BASE 
value. For example, on my chip, after reset 0x0 and before remap points at 
NOR flash, RAM is mapped to 0x1000_0000. Therefore, U-Boot image should be 
linked to 0x0000_0000 address to properly start off the flash, i.e. 
TEXT_BASE defined in $(uboot)/board/my_board/config.mk should be 0x00000000.

But uboot usually copies itself to RAM, which is at 0x1000_0000 in my 
case -- it won't work as I understand, as my image is linked to 0x0000_0000. 
Then if we do remap first (making RAM at 0x0000_0000), then copy image to 
RAM, then there would not be a room for 'malloc' area and stack (which uboot 
allocates at lower addresses), as we specified TEXT_BASE=0x0, and this is 
the address U-Boot copies itself in memory at.

Perhaps I misunderstand something in a work of U-Boot...

-- Mark