[U-Boot-Users] INFO: U-Boot for AT91RM9200DK

[U-Boot-Users] INFO: U-Boot for AT91RM9200DK

[Paugam Luc]

Hi all,

I am currently working on the port of U-Boot onto a custom board 
containing a ATMEL AT91RM9200. From now I use the ATMEL evaluation 
board (AT91RM9200-DK).

To do that, I grabbed the sources of U-Boot from the CVS server 
and looked at the mailing archive.
I found the following mail from Steven Scholz which explained that
ATMEL use a primary bootstrap code 'boot.bin' before booting U-Boot 
(considered as the secondary bootstrap) from SDRAM.

I would like to see U-Boot as the unique boot code and get rid of 
the ATMEL booting method for their AT91RM9200-DK evaluation board.

Does someone already do this job? 
As I don't see it inside the current sources of U-Boot?

Many thanks for your collaboration.

Regards - Luc

> -----Original Message-----
> From: Steven Scholz [mailto:steven.scholz at imc-berlin.de]
> Sent: vendredi 24 octobre 2003 11:02
> To: Rick Bronson; u-boot-users; Wolfgang Denk
> Subject: [U-Boot-Users] INFO: U-Boot for AT91RM9200DK
> 
> 
> Hi Rick et al.,
> 
> as I mentioned before U-Boot is running on our AT91RM9200 
> based board. I went 
> down the path ATMEL was suggesting. They use this memory map 
> on their eval board 
> AT91RM9200DK:
> 
> 24k	Boot Image
> 32KB	free
> 8KB	Environment
> 64KB	gzipped U-Boot image
> 
> The "Boot image" is a small (11k) piece of code which 
> initialises clocks, flash, 
> SDRAM and serial port. Then it decompresses the "gzipped 
> U-Boot image" into 
> SDRAM and jumps to it. The reason for that seems to be:
> 
>  > 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.
> 
> They probably overlooked that you could embedded the 
> environment into U-Boot. By 
> using a correct u-boot.lds linker file one can reserve an 
> 8Kbyte-size sector in 
> the middle of U-Boot. So instead one could use this memory map:
> 
> 56KB	U-Boot
> 8KB	Environment
> 64KB	U-Boot
> 
> using the same 128KB of flash.
> 
> Since the CPU was setup by the bootloader there's no init and 
> relocation code 
> for the AT91RM9200 in U-Boot (yet).
> 
> So I spend a day, "wrote" some init and relocation code and 
> now U-Boot is 
> starting directly from flash and relocates itself to RAM. No 
> Preboot needed. Nor 
> gzipped image of U-Boot.
> 
> I would like to change the official U-Boot code for the 
> AT91RM9200 and 
> AT91RM9200DK so that it can be used without the need of 
> another bootloader.
> This way it would be a lot easier for people to port U-Boot 
> to their hardware.
> 
> What do you think?
> Anyone interested?
> 
> I'd love to hear suggestion, where to put specific parts of 
> the init code. Other 
> ARM cpus use a board specific memsetup.S file.
> For an AT91RM9200 we have to setup more than just the SDRAM.
> Should we put all the init code into cpu/at91rm9200/{start.S} 
> and use CONFIG_ 
> and CFG_?
> Or should every AT91 based board copy the same code again and 
> again into thier 
> own subdirectory?
> 
> Looking forward to your ideas!
> 
> Thanks. And sorry for the long mail!
> 
> -- 
> Steven Scholz
> 
> ______________________________________________________________
> ________________
> 
> ===> From:		Rick Bronson [rick at efn.org]
> 
> Hi Steven,
> 
>   It's totally okay with me.
> 
> > Should we put all the init code into 
> cpu/at91rm9200/{start.S} and use CONFIG_ 
> > and CFG_?
> 
>   I'd put it all in start.S and not define any CONFIG for it.  But one
> thing you might check is if it will start up when the clocks are
> already configured.  In other words, make sure your new u-boot can be
> started from an already running u-boot.  This is necessary because the
> AT91RM9200 can be started from SPI DataFlash (or EEPROM) which
> requires a preloader.  The preloader sets up clocks for SDRAM, etc and
> then launches u-boot.
> 
>   I have a sperate entry in a Makefile for compiling u-boot up to run
> in ram so that I can fire a new u-boot while inside u-boot:
> 
> ram:
> 	cd u-boot-0.4.0; \
> 	echo TEXT_BASE = 0x21fa0000 > board/at91rm9200dk/config.mk; \
> 	make at91rm9200dk_config; \
> 	make; \
> 	cp -f u-boot.bin /tftpboot
> 
>   And then from u-boot I do:
> 
> tftp 21fa0000 u-boot.bin # load u-boot
> go 21fa0000			   # run u-boot
> 
> > Or should every AT91 based board copy the same code again 
> and again into thier 
> > own subdirectory?
> 
>   I'd make it (optimistically) so they didn't have to copy.
> 
>   Thanks for your work!
> 
>   Rick
> 

[U-Boot-Users] INFO: U-Boot for AT91RM9200DK

[Steven Scholz]

Paugam Luc wrote:

> Hi all,
> 
> I am currently working on the port of U-Boot onto a custom board 
> containing a ATMEL AT91RM9200. From now I use the ATMEL evaluation 
> board (AT91RM9200-DK).
> 
> To do that, I grabbed the sources of U-Boot from the CVS server 
> and looked at the mailing archive.
> I found the following mail from Steven Scholz which explained that
> ATMEL use a primary bootstrap code 'boot.bin' before booting U-Boot 
> (considered as the secondary bootstrap) from SDRAM.
> 
> I would like to see U-Boot as the unique boot code and get rid of 
> the ATMEL booting method for their AT91RM9200-DK evaluation board.
> 
> Does someone already do this job? 
> As I don't see it inside the current sources of U-Boot?

Of course.
When my ta91_soc.patch from Oct 10 2004 finally gets applied (Wolfgang?), then 
the AT91RM9200 is just an SoC based on ARM920T. And all you have to do is
#define CONFIG_INIT_CRITICAL 1 and write you board specific memsetup() function 
to init clocks and SDRAM.

--
Steven