1. Home
  2. Embedded Programming
  3. ARM processors and remap

ARM processors and remap

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

Reply to
Mark
Loading thread data ...

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

formatting link

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
Reply to
Frank Buss

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>

formatting link

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

-- Mark

Reply to
Mark

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
Reply to
Frank Buss

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

Reply to
Mark

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.