[U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200

[Paugam Luc]

Dear Steven & Wolfgang,

There is perhaps a confusion between _relocation_ and _copy_.

Beware to the fact that actually the AT91RM9200 starter code (especially 
start.S) does not relocate any code from Flash to RAM (as we can see it
into PowerPC starter code, for example) but rather do a simple copy of 
u-boot code from Flash to RAM.

_TEXT_BASE is still defined with a RAM address!

This way to do is unfortunately inherited from ATMEL with their 2 stages boot process.

Regards - Luc

> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Wolfgang
> Denk
> Sent: mardi 23 novembre 2004 17:43
> To: Steven Scholz
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200 
> 
> 
> In message <41A35A7E.1020605 at imc-berlin.de> you wrote:
> > 
> > is there a standard way in U-Boot to prevent to the startup 
> code from relocating 
> > into RAM?
> 
> No. U-Boot will always relocate itself to RAM. Well, nearly always  -
> in any halfway sane implementation.
> 
> > I know that arm920t figures out the currebt address. 
> compares it to _TEXT_BASE 
> > and decides wether to relocate or not.
> > 
> > relocate:				/* relocate U-Boot to 
> RAM	    */
> > 	adr	r0, _start		/* r0 <- current 
> position of code   */
> > 	ldr	r1, _TEXT_BASE		/* test if we run from 
> flash or RAM */
> > 	cmp     r0, r1                  /* don't reloc during 
> debug         */
> 
> I wish that code was never written.
> 
> > So there might be no need for a define like 
> CFG_DONT_RELOCATE. But how about 
> > other cpus?
> 
> All CPUs always relocate the code to RAM. This is the  general  case.
> Anything else is not supported.
> 
> > (I am asking cause you wrapped the relocate code in 
> cpu/at91rm9200/start.S with 
> > CONFIG_BOOTBINFUNC instead of using the above technique.
> 
> Please consider the CONFIG_BOOTBINFUNC as an optimization  of  effort
> and  effect (read: quick & dirty hack). Feel free to clean up as long
> the result is working code, too.
> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Fools ignore complexity. Pragmatists suffer it. Some  can  avoid  it.
> Geniuses remove it.
>      - Perlis's Programming Proverb #58, SIGPLAN Notices, Sept.  1982
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from 
> real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>