[U-Boot-Users] Maintainer of AT91RM9200DK???

[U-Boot-Users] Maintainer of AT91RM9200DK???

[Steven Scholz]

Hi there,

who considers himself as the U-Boot maintainer of the AT91RM9200 cpu and the 
AT91RM9200DK eval board?
Rick, is that you?

I just porting U-Boot to our AT91RM9200 based board and it migth be necessary to 
change some code in the AT91RM9200 relevant stuff.
So I am looking for people to talk to before that.

Thanks a million.

Steven

[U-Boot-Users] Re: Maintainer of AT91RM9200DK???

[Rick Bronson]

Steven,

  That would be me.

  Rick

> Hi there,
> 
> who considers himself as the U-Boot maintainer of the AT91RM9200 cpu and the 
> AT91RM9200DK eval board?
> Rick, is that you?
> 
> I just porting U-Boot to our AT91RM9200 based board and it migth be necessary to 
> change some code in the AT91RM9200 relevant stuff.
> So I am looking for people to talk to before that.
> 
> Thanks a million.
> 
> Steven
> 
> 
> 

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

[Steven Scholz]

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 interessted?

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

imc Measurement & Control               imc Me?systeme GmbH
Voltastr. 5                             Voltastr. 5
13355 Berlin                            13355 Berlin
Germany                                 Deutschland
fon: +49 30 467090-0                    Tel: 030 / 467090-0
fax: +49 30 4631576                     fax: 030 / 4631576

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

[Rick Bronson]

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

> 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 interessted?
> 
> 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
> 
> imc Measurement & Control               imc Me?systeme GmbH
> Voltastr. 5                             Voltastr. 5
> 13355 Berlin                            13355 Berlin
> Germany                                 Deutschland
> fon: +49 30 467090-0                    Tel: 030 / 467090-0
> fax: +49 30 4631576                     fax: 030 / 4631576
> 
> 

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

[Steven Scholz]

Hi Rick,

>>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.
Hmm. But my boards has a completly different clocking scheme!
For instance: I use an 16MHz external clock oszillator. The eval board has an 
18,xxx MHz crystal...
So we need at least some CFG_'s for clock configuration.

Ok?

-- 
Steven Scholz

imc Measurement & Control               imc Me?systeme GmbH
Voltastr. 5                             Voltastr. 5
13355 Berlin                            13355 Berlin
Germany                                 Deutschland
fon: +49 30 467090-0                    Tel: 030 / 467090-0
fax: +49 30 4631576                     fax: 030 / 4631576

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

[Rick Bronson]

> 
> Hi Rick,
> 
> >>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.
> Hmm. But my boards has a completly different clocking scheme!
> For instance: I use an 16MHz external clock oszillator. The eval board has an 
> 18,xxx MHz crystal...
> So we need at least some CFG_'s for clock configuration.
> 
> Ok?

  No.

  I have completely different crystals than the AT91RM9200DK.  Do
you want me to put my clock settings in u-boot?  How about the 500
different AT91RM9200 boards that get designed this year?  Do you want
their specific stuff in u-boot?

  By necessity u-boot is already nearing #ifdef hell because it
supports so many devel boards (which is good).  If we all threw
our specific board design stuff in there, I don't think anyone in
their right mind would use u-boot.

  Just my opinion ;-)  Maybe Wolfgang disagrees.

  Rick

> 
> -- 
> Steven Scholz
> 
> imc Measurement & Control               imc Me?systeme GmbH
> Voltastr. 5                             Voltastr. 5
> 13355 Berlin                            13355 Berlin
> Germany                                 Deutschland
> fon: +49 30 467090-0                    Tel: 030 / 467090-0
> fax: +49 30 4631576                     fax: 030 / 4631576
> 
> 

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

[Steven Scholz]

Rick,

>>>>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.
>>
>>Hmm. But my boards has a completly different clocking scheme!
>>For instance: I use an 16MHz external clock oszillator. The eval board has an 
>>18,xxx MHz crystal...
>>So we need at least some CFG_'s for clock configuration.
> 
>   I have completely different crystals than the AT91RM9200DK.  Do
> you want me to put my clock settings in u-boot?  How about the 500
> different AT91RM9200 boards that get designed this year?  Do you want
> their specific stuff in u-boot?
> 
>   By necessity u-boot is already nearing #ifdef hell because it
> supports so many devel boards (which is good).  If we all threw
> our specific board design stuff in there, I don't think anyone in
> their right mind would use u-boot.

Probably a misunderstanding!

How I am supposed to setup clocks and PLLs and serial port in the AT91RM9200 if 
I don't have any informations?

I thought of something like this in start.S:

#ifdef CFG_USE_EXT_CRYSTAL
	enable_main_oscillator;
#endif

/* set up PLL */
	set PLLA to CFG_PLLAR
	set PLLB to CFG_PLLBR
...

And the user just has to define CFG_USE_EXT_CRYSTAL, CFG_PLLAR etc in his board 
specific header file. Of course without the need to submit his configuration to 
the U-Boot CVS.

Ok?

Steven

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

[Rick Bronson]

Steven,

  Isn't it true that the only reason you'd have this:

> #ifdef CFG_USE_EXT_CRYSTAL

  is so that you could configure non AT91RM9200DK hardware? (Since the
AT91RM9200DK uses a crystal) If the answer is yes than I would say it
doesn't belong in u-boot.  If there were a switch on the AT91RM9200DK
board that allowed different clock freq's then I would agree.

  Rick

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

[Wolfgang Denk]

In message <E1AD43F-0000xt-00@c-67-164-61-95.client.comcast.net> you wrote:
> 
>   Isn't it true that the only reason you'd have this:
> 
> > #ifdef CFG_USE_EXT_CRYSTAL
> 
>   is so that you could configure non AT91RM9200DK hardware? (Since the

Yes, probably  (or  can  I  use  an  external  clock  source  on  the
AT91RM9200DK board).

> AT91RM9200DK uses a crystal) If the answer is yes than I would say it
> doesn't belong in u-boot.  If there were a switch on the AT91RM9200DK

You are wrong. We are talking about CPU dependend code. If this  does
not  allow easy (non-#ifdef'ed) adaption to different boards the code
is broken and needs fixing.

> board that allowed different clock freq's then I would agree.

The AT91RM9200DK is just one out of many boards, right? Please do not
insist on your implementation if your board specific code is  in  CPU
common files.


There is a simple rule: CPU specific code shall go into CPU  directo-
ries, board specific stuff shall go into board directories.

If the clock intialization is board dependend (as  it  looks  to  me)
that it does not belong into the CPU directory.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
In any group of employed individuals the only naturally  early  riser
is  _always_  the office manager, who will _always_ leave reproachful
little notes ... on the desks of their subordinates.
                                - Terry Pratchett, _Lords and Ladies_

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

[Wolfgang Denk]

Dear Steven,

in message <3F993A32.80709@imc-berlin.de> you wrote:
> 
> >   By necessity u-boot is already nearing #ifdef hell because it
> > supports so many devel boards (which is good).  If we all threw
> > our specific board design stuff in there, I don't think anyone in
> > their right mind would use u-boot.
> 
> Probably a misunderstanding!

Yes, on Rick's side.

> How I am supposed to setup clocks and PLLs and serial port in the AT91RM9200 if 
> I don't have any informations?
> 
> I thought of something like this in start.S:
> 
> #ifdef CFG_USE_EXT_CRYSTAL
> 	enable_main_oscillator;
> #endif
> 
> /* set up PLL */
> 	set PLLA to CFG_PLLAR
> 	set PLLB to CFG_PLLBR
> ...

Looks  clean  to  me.  Probably  even  better  would   be   to   call
"init_clocks"  (or  a  function  with  a similar name) in start.S for
_all_ boards, including the "at91rm9200dk".


Just for the record: the "at91rm9200dk" ist  just  one  out  of  many
boards.  It  is in no way better than any other board. "at91rm9200dk"
dependend code shall be removed from the files in the  cpu/at91rm9200
directory.

> And the user just has to define CFG_USE_EXT_CRYSTAL, CFG_PLLAR etc in his board 
> specific header file. Of course without the need to submit his configuration to 
> the U-Boot CVS.

I don't understand this last sentence.

Either you are maintaining his own  private  version  of  U-Boot  (in
which  case we don't care, and you don't need to ask for help on this
mailing list which is dedicated to the _public_ source tree only), or
you are working with the public version of U-Boot, in which case your
board configuration obviously resides in the U-Boot CVS tree.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
You!  What PLANET is this!
	-- McCoy, "The City on the Edge of Forever", stardate 3134.0

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

[Steven Scholz]

Dear Wolfgang,

>>I thought of something like this in start.S:
>>
>>#ifdef CFG_USE_EXT_CRYSTAL
>>	enable_main_oscillator;
>>#endif
>>
>>/* set up PLL */
>>	set PLLA to CFG_PLLAR
>>	set PLLB to CFG_PLLBR
>>...
> 
> 
> Looks  clean  to  me.  Probably  even  better  would   be   to   call
> "init_clocks"  (or  a  function  with  a similar name) in start.S for
> _all_ boards, including the "at91rm9200dk".

???
Should the function init_clocks() be in start.S or in board specific files?
As it is done with memsetup() or platform() in other ARM implementations?
Or should we write cpu_init(), board_init() etc. like in the PPC code?

> Just for the record: the "at91rm9200dk" ist  just  one  out  of  many
> boards.  It  is in no way better than any other board. "at91rm9200dk"
> dependend code shall be removed from the files in the  cpu/at91rm9200
> directory.
It's better in that everybody could buy such a board and run U-Boot on it. :o)

>>And the user just has to define CFG_USE_EXT_CRYSTAL, CFG_PLLAR etc in his board 
>>specific header file. Of course without the need to submit his configuration to 
>>the U-Boot CVS.
> 
> I don't understand this last sentence.
> 
> Either you are maintaining his own  private  version  of  U-Boot  (in
> which  case we don't care, and you don't need to ask for help on this
> mailing list which is dedicated to the _public_ source tree only), or
> you are working with the public version of U-Boot, in which case your
> board configuration obviously resides in the U-Boot CVS tree.

IMHO:

U-Boot code should be written in a way to make it very easy to port it to new, 
custom hardware without making (too many) changes on the generic and common code 
(as for instance the stuff inc cpu/at91rm92000/ directory).

In the best case just creating a new board include file with the appropriate 
definitions (like #undef  CFG_USE_EXT_CRYSTAL; #define CFG_PLLA 0x12345678 etc.) 
should be enough to bring U-Boot up.

So if we write the code in cpu/at91rm92000/ generic enough then porting U-Boot 
to a new board is (at a first step) merely writing an new yourboard.h.
Now if that's all I did I see no need to "bloat u-boot with unnecessary code". 
(Of course the CFG_ and CONFIG_ stuff must be documented e.g. in 
doc/README.AT91RM9200).

That's what I meant. Do we realy need thousends of yourboard.h just containing 
different values for CFG_PLLAR? I think we need them for "standard" eval boards. 
And for boards with some special feature.
So I put my efford to provide generic code that could be used by others. That's 
why I rewrote my FPGA loading code, submitted a patch although my old board 
specific code was working good. And I will provide the code for our board in a 
while when I think it shows others how to use this code.

Argh... You know what I meant? I am not sure if I could make myself understood.

-- 
Steven Scholz

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

[Wolfgang Denk]

Hi,

in message <3F9BA845.8050505@imc-berlin.de> you wrote:
> 
> > Looks  clean  to  me.  Probably  even  better  would   be   to   call
> > "init_clocks"  (or  a  function  with  a similar name) in start.S for
> > _all_ boards, including the "at91rm9200dk".
> 
> ???
> Should the function init_clocks() be in start.S or in board specific files?

I understood your argumentation such  as  if  init_clocks()  requires
board  dependend  code.  If this is the case, it belongs into a board
specific file. If it is the same for (nearly) all  at91rm9200  boards
everything can stay as it is now.

> As it is done with memsetup() or platform() in other ARM implementations?
> Or should we write cpu_init(), board_init() etc. like in the PPC code?

Well, I certainly like the idea of clearly splitting this stuff up as
it was done on PowerPC. I do NOT intend to say that the PPC code  was
perfect.

> > Either you are maintaining his own  private  version  of  U-Boot  (in
> > which  case we don't care, and you don't need to ask for help on this
> > mailing list which is dedicated to the _public_ source tree only), or
> > you are working with the public version of U-Boot, in which case your
> > board configuration obviously resides in the U-Boot CVS tree.
> 
> IMHO:
> 
> U-Boot code should be written in a way to make it very easy to port it to new, 
> custom hardware without making (too many) changes on the generic and common code 
> (as for instance the stuff inc cpu/at91rm92000/ directory).

Agreeed.

> In the best case just creating a new board include file with the appropriate 
> definitions (like #undef  CFG_USE_EXT_CRYSTAL; #define CFG_PLLA 0x12345678 etc.) 
> should be enough to bring U-Boot up.

This will never work. There will always be board dependend stuff, and
you will have to select a specific board config name. I don;t  expect
that  there  will  ever be some common board specific code which will
work for many boards from  different  vendors.  There  are  too  many
things that can be implemented differently in hardware: RAM and Flash
size, chip types, and bus widths; network interface, RTC, EEPROM, ...

> So if we write the code in cpu/at91rm92000/ generic enough then porting U-Boot 
> to a new board is (at a first step) merely writing an new yourboard.h.

I don't think this would ever work...


> That's what I meant. Do we realy need thousends of yourboard.h just containing 
> different values for CFG_PLLAR? I think we need them for "standard" eval boards. 


The board config files contain many more things.  Simple  stuff  like
console  port  and  baudrate,  but also hardware dependend stuff like
memory map, chip types and bus width, etc.

> So I put my efford to provide generic code that could be used by others. That's 

The intention is good, and we agree on that. But don't let  it  carry
you too far. Be realistic.

> Argh... You know what I meant? I am not sure if I could make myself understood.

I think I understand what you mean, but I don't expect  that  we  can
get rid of board dependend code completely. Nor do I see the need for
that.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
The word "fit", as I understand it, means "appropriate to a purpose",
and I would say the body of the Dean is supremely appropriate to  the
purpose of sitting around all day and eating big heavy meals.
                                 - Terry Pratchett, _Moving Pictures_

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

[Wolfgang Denk]

Dear Rick,

in message <E1AD2xl-0000h1-00@c-67-164-61-95.client.comcast.net> you wrote:
> 
>   I have completely different crystals than the AT91RM9200DK.  Do
> you want me to put my clock settings in u-boot?  How about the 500

Yes, of course. If your board is supported by U-Boot you have to  put
your  clock  configuration  somewhere  in  the U-Boot code. Best idea
seems to be the board directory.

> different AT91RM9200 boards that get designed this year?  Do you want
> their specific stuff in u-boot?

Yes, of course. What else? If they are supported by U-Boot  you  have
to  put  their clock configuration somewhere in the U-Boot code. Best
idea seems to be the board directory.

>   By necessity u-boot is already nearing #ifdef hell because it
> supports so many devel boards (which is good).  If we all threw

There is no real need for an  #ifdef  hell.  I  agree  that  we  have
already  more than enough #ifdef's, but every now and then some parts
get cleaned up. And you can make a good contribution by avoiding  the
necessity  of  new #ifdefs by helping to implement a clean separation
of CPU and board dependend code.

> our specific board design stuff in there, I don't think anyone in
> their right mind would use u-boot.

If you don't throw in your board specific stuff  your  board  is  not
supported  by the public version of U-Boot. Which means you will have
to maintain your own version,  and  to  make  sure  to  publish  your
"private" version according to the GPL.

>   Just my opinion ;-)  Maybe Wolfgang disagrees.

As you can see, I do.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Be careful what you wish for. You never know who will be listening.
                                      - Terry Pratchett, _Soul Music_

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

[Steven Scholz]

Rick,

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

Ok. I see. So you're building a special version of U-Boot for this anyway (using 
make ram). Right?

I've seen:
         /*
          * we do sys-critical inits only at reboot,
          * not when booting from ram!
          */
#ifdef CONFIG_INIT_CRITICAL
         bl      cpu_init_crit
#endif

in cpu/arm920t/start.S and

#define CONFIG_INIT_CRITICAL         /* undef for developing */

in some board specific header file.

So. Would you agree on a mechanism like that?

You could still do something like that in your Makefile:

 > ram:
 > 	cd u-boot-0.4.0; \
 > 	echo TEXT_BASE = 0x21fa0000 > board/at91rm9200dk/config.mk; \
 > 	make at91rm9200dk_config; \
  	echo "#undef CONFIG_INIT_CRITICAL" >> include/config.h; \
 > 	make; \
 > 	cp -f u-boot.bin /tftpboot

I think this would better better than trying to autodetect if the system was 
already configured. Ok?

Steven

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

[Wolfgang Denk]

Dear Steven, Rick,

in message <3F9CC600.2080209@imc-berlin.de> you wrote:
> 
> >   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; \
...

> You could still do something like that in your Makefile:
> 
>  > ram:
>  > 	cd u-boot-0.4.0; \
>  > 	echo TEXT_BASE = 0x21fa0000 > board/at91rm9200dk/config.mk; \

STOP! NO!!

Please never ever modify any source files in the Make script!!!


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
What nonsense people talk about happy marriages! A man can  be  happy
with any woman so long as he doesn't love her.         -- Oscar Wilde

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

[Steven Scholz]

Dear Wolfgang , Rick,

>>>  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; \
> ...
>>You could still do something like that in your Makefile:
>>
>> > ram:
>> > 	cd u-boot-0.4.0; \
>> > 	echo TEXT_BASE = 0x21fa0000 > board/at91rm9200dk/config.mk; \
> 
> 
> STOP! NO!!
> 
> Please never ever modify any source files in the Make script!!!
:o)

Ok. Ok. Maybe the better way would be:

RICKs_RAM_config:          unconfig
         @./mkconfig $(@:_config=) arm at91rm9200 RICKSBOARDS
         @echo '#define TEXT_BASE 0xFOOBAR' >>include/config.h;
         @echo '#undef CONFIG_INIT_CRITICAL' >>include/config.h;

and then

ifndef TEXT_BASE
TEXT_BASE = 0xBLABLUB
endif

in board/at91rm9200dk/config.mk.

Ok?

Steven

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

[Wolfgang Denk]

In message <3F9CD66E.8040701@imc-berlin.de> you wrote:
> 
> Ok. Ok. Maybe the better way would be:
> 
> RICKs_RAM_config:          unconfig
>          @./mkconfig $(@:_config=) arm at91rm9200 RICKSBOARDS
>          @echo '#define TEXT_BASE 0xFOOBAR' >>include/config.h;
>          @echo '#undef CONFIG_INIT_CRITICAL' >>include/config.h;
> 
> and then
> 
> ifndef TEXT_BASE
> TEXT_BASE = 0xBLABLUB
> endif
> 
> in board/at91rm9200dk/config.mk.
> 
> Ok?

No, this will not  work,  as  include/config.h  is  a  C  heaer  file
following  C  preprocessor syntax, while board/at91rm9200dk/config.mk
is included by a Makefile and thus follows Makefile syntax.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"Whoever undertakes to set himself up as a judge of Truth  and  Know-
ledge is shipwrecked by the laughter of the gods."  - Albert Einstein

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

[Steven Scholz]

Wolfgang,

>>ifndef TEXT_BASE
>>TEXT_BASE = 0xBLABLUB
>>endif
>>
>>in board/at91rm9200dk/config.mk.
>>
>>Ok?
> 
> 
> No, this will not  work,  as  include/config.h  is  a  C  heaer  file
> following  C  preprocessor syntax, while board/at91rm9200dk/config.mk
> is included by a Makefile and thus follows Makefile syntax.

Hmm. board/trab/config.mk contains such lines.
If it does not work anyway the maintainer should remove it as not to send other 
down the wrong path! ;-)

Or is the trick done by the line

sinclude $(TOPDIR)/board/$(BOARDDIR)/config.tmp

???

Steven

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

[Wolfgang Denk]

Dear Steven,

in message <3F9D0045.3040106@imc-berlin.de> you wrote:
> 
> > No, this will not  work,  as  include/config.h  is  a  C  heaer  file
> > following  C  preprocessor syntax, while board/at91rm9200dk/config.mk
> > is included by a Makefile and thus follows Makefile syntax.
> 
> Hmm. board/trab/config.mk contains such lines.

board/trab/config.mk does NOT include the noard config file (which in
this case would be include/configs/trab.h).

> If it does not work anyway the maintainer should remove it as not to send other 
> down the wrong path! ;-)

board/trab/config.mk does work.

> Or is the trick done by the line
> 
> sinclude $(TOPDIR)/board/$(BOARDDIR)/config.tmp

This is no trick at all. It's just one of the possible ways  to  pass
config options into config.mk

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Lack of skill dictates economy of style.                - Joey Ramone

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

[Steven Scholz]

Dear Wolfgang,

> board/trab/config.mk does NOT include the noard config file (which in
> this case would be include/configs/trab.h).
>> ...
>>sinclude $(TOPDIR)/board/$(BOARDDIR)/config.tmp
> 
> 
> This is no trick at all. It's just one of the possible ways  to  pass
> config options into config.mk

Ah. Ok I see now.

Thanks,

Steven

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

[Rick Bronson]

Steven & Wolfgang,

> > tftp 21fa0000 u-boot.bin # load u-boot
> > go 21fa0000			   # run u-boot
> 
> Ok. I see. So you're building a special version of U-Boot for this anyway (using 
> make ram). Right?

  Yes.

> STOP! NO!!
> 
> Please never ever modify any source files in the Make script!!!

Don't worry, it's in a Makefile that not in the u-boot tree.  And I
  promise not to send a patch ;-)

  Rick

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

[Wolfgang Denk]

Dear Rick,

in message <E1AE9RV-0000fx-00@amazonia.efn.org> you wrote:
> 
> > Please never ever modify any source files in the Make script!!!
> 
> Don't worry, it's in a Makefile that not in the u-boot tree.  And I
>   promise not to send a patch ;-)

I would never accept it. I consider it a VERY  BAD  idea  to  have  a
Makefile modyfying files which are under source control (CVS).

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng.

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

[Wolfgang Denk]

Hi,

in message <3F98EA80.9040302@imc-berlin.de> you wrote:
> 
> 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 need
> ed. Nor 
> gzipped image of U-Boot.

Thanks. I really appreciate this effort, especially since  it  allows
to run a "pure" U-Boot on this architecture.

> 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.

I''d appreciate such an effort.

Just for my understanding: the  AT91RM9200DK  is  just  one  specific
board  usingt he AT91RM9200 (AT91RM9200DK == AT91RM9200 "D"evelopment
"K"it?).

> What do you think?
> Anyone interessted?

Yes, me :-)


> 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 CON
> FIG_ 
> and CFG_?

In cases where board-specific code is required the common code  (like
cpu/at91rm9200/start.S)  should  call  board-specific  init functions
which will have to be implemented by  code  in  the  board  dependend
directories.

> Or should every AT91 based board copy the same code again and again into
> thier 
> own subdirectory?

NO !!!!

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Our management frequently gets lost in thought.   That's because it's
unfamiliar territory.

[U-Boot-Users] Maintainer of AT91RM9200DK???

[Wolfgang Denk]

In message <3F913C5A.8070303@imc-berlin.de> you wrote:
> 
> who considers himself as the U-Boot maintainer of the AT91RM9200 cpu and the 
> AT91RM9200DK eval board?
> Rick, is that you?

Guess why he's listed in the MAINTAINERS file?

> So I am looking for people to talk to before that.

There is always this mailing list.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Hello! I'm from outer space,  and I've made myself look like a signa-
ture.  While  you  are reading this, I'm having sex with your eyes. I
know it feels good to you, because you're smiling. I'm very horny, so
send me to someone else when you've had enough. Thanks!
                              Sincerely, A Stranger in a Strange Land

[U-Boot-Users] about arm7tdmi

[Joe]

hi all!
    We are porting u-boot to a no mmu board with cpu
arm7tdmi.
    Now,all is ok when u-boot run in ram.But it seem
have problem whem burned to flash!Some not regulation
ascii code are printed to my terminal! 
    Debug it and find no bug in it. 
    Are there someone know this problem?
                           thanks
                                joe.2003.10.20

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

[U-Boot-Users] about arm7tdmi

[Wolfgang Denk]

In message <20031020134915.50389.qmail@web41111.mail.yahoo.com> you wrote:
>
>     We are porting u-boot to a no mmu board with cpu
> arm7tdmi.
>     Now,all is ok when u-boot run in ram.But it seem

Obviously you have some  external  tool  (JTAG  debugger?)  which  is
initializing your RAM so that you can use it to load and run U-Boot.

> have problem whem burned to flash!Some not regulation
> ascii code are printed to my terminal! 
>     Debug it and find no bug in it. 
>     Are there someone know this problem?

When run from flash, probably  your  RAM  initialization  is  instead
performed by U-Boot. Probably there is some problem in that area...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"Do we define evil as the absence of goodness? It seems only  logical
that shit happens--we discover this by the process of elimination."
                                                        -- Larry Wall

[U-Boot-Users] one by one problem about arm7tdmi

[Joe]

WD and all:
    At first,Thanks the WD that help me to solve the
last problem!
    the other problem is why I set the 
#define CFG_ENV_ADDR (PHYS_FLASH_1 +0x20000)
in my head file.
    but after link ,the environments are at the
(PHYS_FLASH_1 + 0x15900) of ppcboot.bin instead?


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

[U-Boot-Users] one by one problem about arm7tdmi

[Wolfgang Denk]

Dear Joe,

in message <20031021045845.85144.qmail@web41108.mail.yahoo.com> you wrote:
>
>     the other problem is why I set the 
> #define CFG_ENV_ADDR (PHYS_FLASH_1 +0x20000)
> in my head file.
>     but after link ,the environments are at the
> (PHYS_FLASH_1 + 0x15900) of ppcboot.bin instead?

Because your board config file (the definitions of CFG_ENV_ADDR etc.)
do not match the linker script u-boot.lds in your board directory?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Fascinating is a word I use for the unexpected.
	-- Spock, "The Squire of Gothos", stardate 2124.5