[U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200

[U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200

[Steven Scholz]

Dear Wolfgang,

you wrote:

 > Instead of doing all  this  which  is  really  non-trivial  and  also
 > ineffficient you could just boot from flash. I've just checked in the
 > necessary patches for the AT91RM9200DK and CMC_PU2 boards ...

IIUC then part of this code is in cpu/at91rm9200/start.S wrapped in #ifdef 
CONFIG_BOOTBINFUNC.

As you know I'd like to move the at91rm9200 stuff into cpu/arm920t/at91rm9200.
The start.S already calls memsetup if CONFIG_INIT_CRITICAL is defined.

Do you mind moving out the at91 specific stuff?
You already call something like lowlevelinit. Clock init could be done there.

So I'd like to move out the clock specific stuff into
a) board depended memsetup.S or clocksetup.S or
b) a cpu dependend cpu/(arm920t/)at91rm9200/clock.{c,S}.

What do you think?

And:
I don't think CONFIG_BOOTBINFUNC is a good name!
U-Boot should not "include the functionality of boot.bin in u-boot" but include 
lowlevel, hardware dependend init functionality!
I don't know why Atmel introduced this two stage boot process with gzipped 
compressed u-boot images without clock or memory setup functions.
And actually I don't wanna know.
There already is CONFIG_INIT_CRITICAL. We can add CONFIG_INIT_CLOCKS or 
CONFIG_INIT_MEMORY or CONFIG_INIT_SDRAM or CONFIG_INIT_LOWLEVEL...

regards,

Steven Scholz

[U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200

[Steven Scholz]

Dear Wolfgang,

is there a standard way in U-Boot to prevent to the startup code from relocating 
into RAM?

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


So there might be no need for a define like CFG_DONT_RELOCATE. But how about 
other cpus?

(I am asking cause you wrapped the relocate code in cpu/at91rm9200/start.S with 
CONFIG_BOOTBINFUNC instead of using the above technique.

Thanks,

Steven

[U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200

[Wolfgang Denk]

In message <41A35A7E.1020605@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

[U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200

[Steven Scholz]

Wolfgang Denk wrote:

> In message <41A35A7E.1020605@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.
Why is that so bad? It makes it possible to debug U-Boot with just loading the 
image into RAM using BDI2000.

> All CPUs always relocate the code to RAM. This is the  general  case.
> Anything else is not supported.

But how would you debug U-Boot?
I though the common way is to disabled relocation and memsetup, load that U-Boot 
image with an BDI2000 into RAM and execute it - skipping the init code...

--
Steven

[U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200

[Wolfgang Denk]

In message <41A36A80.2070608@imc-berlin.de> you wrote:
> 
> > I wish that code was never written.
> Why is that so bad? It makes it possible to debug U-Boot with just loading the 
> image into RAM using BDI2000.

Which is an unsupported mode of operation which works for a  handfull
of experts and causes confusion with many, many newbees.

> But how would you debug U-Boot?

As I always do. Attach the BDI, burn to flash, start in GDB.

> I though the common way is to disabled relocation and memsetup, load that U-Boot 
> image with an BDI2000 into RAM and execute it - skipping the init code...

No. This is not the way things should be done. You can do this if you
know exactly what you're doing, but it does not help you nor will  it
save you any time. On contrary. It will cost additional time.

Anyway, this is a FAQ, so please RTFM.

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
Consultants are mystical people who ask a company for  a  number  and
then give it back to them.

[U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200

[Wolfgang Denk]

In message <41A34505.4030209@imc-berlin.de> you wrote:
> 
> So I'd like to move out the clock specific stuff into
> a) board depended memsetup.S or clocksetup.S or
> b) a cpu dependend cpu/(arm920t/)at91rm9200/clock.{c,S}.
> 
> What do you think?

If you submit a patch, and I find that it works on all systems I  can
test, then it is OK with me.

> And:
> I don't think CONFIG_BOOTBINFUNC is a good name!
> U-Boot should not "include the functionality of boot.bin in u-boot" but include 
> lowlevel, hardware dependend init functionality!

OK, ok, ok.

> There already is CONFIG_INIT_CRITICAL. We can add CONFIG_INIT_CLOCKS or 
> CONFIG_INIT_MEMORY or CONFIG_INIT_SDRAM or CONFIG_INIT_LOWLEVEL...

The current setup allows to change a single #define to switch between
two different modes of  operation:  using  boot.bin,  and  not  using
boot.bin.  I  don't  really  care about the name of theis variable as
long as it's decoumented and works. But please don;t split it into 15
different names that must be set in a consistent way.

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
"We have the right to survive!"
"Not be killing others."
	-- Deela and Kirk, "Wink of An Eye", stardate 5710.5

[U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200

[Steven Scholz]

Wolfgang Denk wrote:

>>And:
>>I don't think CONFIG_BOOTBINFUNC is a good name!
> OK, ok, ok.

;-)

>>There already is CONFIG_INIT_CRITICAL. We can add CONFIG_INIT_CLOCKS or 
>>CONFIG_INIT_MEMORY or CONFIG_INIT_SDRAM or CONFIG_INIT_LOWLEVEL...
> 
> The current setup allows to change a single #define to switch between
> two different modes of  operation:  using  boot.bin,  and  not  using
> boot.bin.  I  don't  really  care about the name of theis variable as
> long as it's decoumented and works. But please don;t split it into 15
> different names that must be set in a consistent way.

Then I think CONFIG_INIT_CRITICAL is the best choice!

--
Steven

[U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200

[Wolfgang Denk]

In message <41A35C81.20709@imc-berlin.de> you wrote:
> 
> Then I think CONFIG_INIT_CRITICAL is the best choice!

Definitely not - CONFIG_INIT_CRITICAL is such an  ugly  name  that  I
wonder who accepted a patch to introduce such a name ;-)

There is no documentation what it does or means; there is not even  a
definitian   what   "sys-critical   inits"   might   be   -  all  the
initializations are "system critical". This is bullsh*i.

We should not use this name, but try to get rid of it.

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
"To take a significant step forward, you must make a series of finite
improvements." - Donald J. Atwood, General Motors

[U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200

[Steven Scholz]

Wolfgang Denk wrote:

> In message <41A35C81.20709@imc-berlin.de> you wrote:
> 
>>Then I think CONFIG_INIT_CRITICAL is the best choice!
> 
> 
> Definitely not - CONFIG_INIT_CRITICAL is such an  ugly  name  that  I
> wonder who accepted a patch to introduce such a name ;-)
> 
> There is no documentation what it does or means; there is not even  a
> definitian   what   "sys-critical   inits"   might   be   -  all  the
> initializations are "system critical". This is bullsh*i.
> 
> We should not use this name, but try to get rid of it.

Hmm. So I suggest replacing it with CONFIG_INIT_LOWLEVEL or CONFIG_LOWLEVEL_INIT.

But then: these init steps (clocks and memory) are vital for U-Boot to run. So 
why do we need this define anyway if these steps should be done always... ?

-- 
Steven Scholz

[U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200

[Wolfgang Denk]

In message <41A36CFE.9050900@imc-berlin.de> you wrote:
> 
> Hmm. So I suggest replacing it with CONFIG_INIT_LOWLEVEL or CONFIG_LOWLEVEL_INIT.

Hmmm.. CONFIG or CFG? And what exactly is low (vs. high?) level here?

> But then: these init steps (clocks and memory) are vital for U-Boot to run. So 
> why do we need this define anyway if these steps should be done always... ?

Good question. The only reason I can think of  is  to  allob  such  a
two-stage boot loader as used by Atmel on the AT91RM9200DK.

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
There's no sense in being precise  when  you  don't  even  know  what
you're talking about.                             -- John von Neumann

[U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200

[Steven Scholz]

Wolfgang Denk wrote:

> In message <41A36CFE.9050900@imc-berlin.de> you wrote:
> 
>>Hmm. So I suggest replacing it with CONFIG_INIT_LOWLEVEL or CONFIG_LOWLEVEL_INIT.
> 
> 
> Hmmm.. CONFIG or CFG? And what exactly is low (vs. high?) level here?
> 
> 
>>But then: these init steps (clocks and memory) are vital for U-Boot to run. So 
>>why do we need this define anyway if these steps should be done always... ?
> 
> 
> Good question. The only reason I can think of  is  to  allob  such  a
> two-stage boot loader as used by Atmel on the AT91RM9200DK.

So we check if all other arm920t boards have an implementation of memsetup(). 
Then kick out CONFIG_INIT_CRITICAL and introduce 
CONFIG_DO_NOT_MAKE_LOWLEVEL_INIT or something like that !? ;-)


-- 
Steven Scholz

[U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200

[Wolfgang Denk]

In message <41A48489.80203@imc-berlin.de> you wrote:
> 
> So we check if all other arm920t boards have an implementation of memsetup(). 
> Then kick out CONFIG_INIT_CRITICAL and introduce 
> CONFIG_DO_NOT_MAKE_LOWLEVEL_INIT or something like that !? ;-)

Sounds like a plan to me - but let's use a better name, please.

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
Why can you only have two doors on a chicken coop? If it had four  it
would be a chicken sedan.

[U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200

[Friedrich, Lars]

> > Why is that so bad? It makes it possible to debug U-Boot
> > with just loading the image into RAM using BDI2000.
> Which is an unsupported mode of operation which works for a handfull
> of experts and causes confusion with many, many newbees.

How do these lines of code confuse a newbie more than any other code
in the file?

> > But how would you debug U-Boot?
> As I always do. Attach the BDI, burn to flash, start in GDB.

There are 53982 other hardware debuggers out there and only the
minority (is there actually one besides the BDI?) support the
burn to flash feature you rely on. So if you need to start U-Boot
to flash U-Boot, you either do those few lines of code to skip
the relocation or get/use another piece of actually redundant
software to get the image on the flash. I don't know why the
latter should save me time.

> You can do this if you know exactly what you're doing,

Isn't this what is assumed here anyway?

Best regards,
Lars Friedrich

-- 

[U-Boot-Users] CONFIG_BOOTBINFUNC for AT91RM9200

[Wolfgang Denk]

Dear Lars,

in message <AB4979EC12A5EB419810807434495A17283C1E@svex01001.wago.local> you wrote:
>
> > Which is an unsupported mode of operation which works for a handfull
> > of experts and causes confusion with many, many newbees.
> 
> How do these lines of code confuse a newbie more than any other code
> in the file?

It's not the lines of code, but the mode of operation. People tend to
underestimate the complexity of  the  task  and  the  impact  of  the
required modifications.

> > As I always do. Attach the BDI, burn to flash, start in GDB.
> 
> There are 53982 other hardware debuggers out there and only the
> minority (is there actually one besides the BDI?) support the
> burn to flash feature you rely on. So if you need to start U-Boot

C'me on. You must be joking. Please name a few  commercial  debuggers
which do not support flash programming. Maybe we should add a list of
such broken devices to our wiki so people can avoid them?

Let me check:

* Abatron BDI2000: ok (of course)
* Windriver visionICE II: ok	
* Lauterbach Trace32: ok
* Macraigor Wiggler / Raven / usbDemon: ok
* Agilent 3070 Series etc: ok

Even the free BDM4GDB project suports flash programming.

Please be specific: which BDM/JTAG debugger cannot program  flash?  I
really would like to know to be able to warn our customers.

> > You can do this if you know exactly what you're doing,
> 
> Isn't this what is assumed here anyway?

Yes. People should think, machines should work ;-)

There are areas, where small errors have small consequences which are
easy to spot. AQnd there are really nasty problems. If you look  back
at  the archives you will see that this is one of these nasty problem
domains. And it's a FAQ.

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
The only thing necessary for the triumph of evil is for good  men  to
do nothing.                                            - Edmund Burke

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