Maintainer of AT91RM9200DK???

U-Boot-Users Steven Scholz 4 participants 28 messages Oct 18, 2003 – Oct 27, 2003 4 messages not in the archive

Share & tools

Steven Scholz

author

2003-10-18 13:12 UTC #0 lore raw

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

Rick Bronson

2003-10-18 13:45 UTC #1 lore raw

Steven,

That would be me.

Rick

Quoted 16 lines

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Steven Scholz

author

2003-10-24 09:01 UTC #6 lore raw

[U-Boot-Users] 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:

Quoted 3 lines

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!

Signature · 8 lines

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

Rick Bronson

2003-10-24 14:05 UTC #7 lore raw

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

Hi Steven,

It's totally okay with me.

Quoted 2 lines

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

Quoted 2 lines

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

Quoted 66 lines

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:
Quoted 3 lines
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!
Signature · 8 lines
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

Steven Scholz

author

2003-10-24 14:18 UTC #8 lore raw

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

Hi Rick,

Quoted 4 lines

Quoted 2 lines
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?

Signature · 8 lines

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

Rick Bronson

2003-10-24 14:30 UTC #9 lore raw

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

Quoted 6 lines

Hi Rick,
Quoted 3 lines
Quoted 2 lines
Should we put all the init code into cpu/at91rm9200/{start.S} and use CONFIG_ and CFG_?

Quoted 7 lines

Quoted 1 line
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

Quoted 12 lines

Signature · 9 lines

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

Steven Scholz

author

2003-10-24 14:41 UTC #10 lore raw

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

Rick,

Quoted 15 lines

Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
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?

Quoted 4 lines

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

Rick Bronson

2003-10-24 15:40 UTC #11 lore raw

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

Steven,

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

Quoted 1 line

#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

Wolfgang Denk

2003-10-25 18:45 UTC #12 lore raw

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

Quoted 6 lines · In message <[email protected]> you wrote:

Isn't it true that the only reason you'd have this:
Quoted 1 line
#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).

Quoted 2 lines

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.

Quoted 1 line

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

Signature · 6 lines

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_

Wolfgang Denk

2003-10-25 18:52 UTC #13 lore raw

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

In reply to Steven Scholz

Dear Steven,

Quoted 7 lines · in message <[email protected]> you wrote:

Quoted 5 lines
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.

Quoted 5 lines

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:

Quoted 8 lines

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

Quoted 3 lines

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

Signature · 4 lines

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

Steven Scholz

author

2003-10-26 10:56 UTC #14 lore raw

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

Dear Wolfgang,

Quoted 12 lines

Quoted 10 lines
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
...

Quoted 3 lines

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?

Quoted 4 lines

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)

Quoted 11 lines

Quoted 3 lines
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.

Signature · 1 line

Steven Scholz

Wolfgang Denk

2003-10-26 12:17 UTC #15 lore raw

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

Hi,

Quoted 7 lines · in message <[email protected]> you wrote:

Quoted 4 lines
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.

Quoted 2 lines

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.

Quoted 11 lines

Quoted 5 lines
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.

Quoted 3 lines

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

Quoted 2 lines

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

Quoted 2 lines

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.

Quoted 1 line

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.

Quoted 1 line

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

Signature · 6 lines

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_

Wolfgang Denk

2003-10-25 18:41 UTC #16 lore raw

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

In reply to Rick Bronson

Dear Rick,

Quoted 3 lines · in message <[email protected]> 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.

Quoted 2 lines

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.

Quoted 2 lines

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.

Quoted 2 lines

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.

Quoted 1 line

Just my opinion ;-) Maybe Wolfgang disagrees.

As you can see, I do.

Best regards,

Wolfgang Denk

Signature · 4 lines

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_

Steven Scholz

author

2003-10-27 07:15 UTC #17 lore raw

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

In reply to Rick Bronson

Rick,

Quoted 21 lines

Quoted 2 lines
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

Quoted 4 lines

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:

Quoted 4 lines

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

Quoted 2 lines

	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

Wolfgang Denk

2003-10-27 08:02 UTC #18 lore raw

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

Dear Steven, Rick,

Quoted 7 lines · in message <[email protected]> you wrote:

Quoted 7 lines
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; \

...

Quoted 5 lines

You could still do something like that in your Makefile:
Quoted 3 lines
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

Signature · 4 lines

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

Steven Scholz

author

2003-10-27 08:25 UTC #19 lore raw

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

Dear Wolfgang , Rick,

Quoted 9 lines

Quoted 6 lines
Quoted 6 lines
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; \
...
Quoted 2 lines
You could still do something like that in your Makefile:

Quoted 8 lines

Quoted 3 lines
Quoted 3 lines
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

Wolfgang Denk

2003-10-27 10:16 UTC #20 lore raw

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

Quoted 10 lines · In message <[email protected]> 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

Quoted 7 lines

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

Signature · 4 lines

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

Steven Scholz

author

2003-10-27 11:23 UTC #21 lore raw

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

Wolfgang,

Quoted 4 lines

Quoted 4 lines
ifndef TEXT_BASE
TEXT_BASE = 0xBLABLUB
endif

Quoted 8 lines

Quoted 3 lines
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

Wolfgang Denk

2003-10-27 11:53 UTC #22 lore raw

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

Dear Steven,

Quoted 6 lines · in message <[email protected]> you wrote:

Quoted 4 lines
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).

Quoted 2 lines

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.

Quoted 3 lines

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

Signature · 3 lines

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

Steven Scholz

author

2003-10-27 14:58 UTC #23 lore raw

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

Dear Wolfgang,

Quoted 8 lines

board/trab/config.mk does NOT include the noard config file (which in this case would be include/configs/trab.h).
Quoted 2 lines
...
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

Rick Bronson

2003-10-27 15:38 UTC #24 lore raw

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

In reply to Steven Scholz

Steven & Wolfgang,

Quoted 5 lines

Quoted 2 lines
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.

Quoted 3 lines

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

Wolfgang Denk

2003-10-27 16:21 UTC #25 lore raw

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

Dear Rick,

Quoted 5 lines · in message <[email protected]> you wrote:

Quoted 2 lines
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

Signature · 3 lines

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.

Wolfgang Denk

2003-10-25 18:32 UTC #26 lore raw

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

In reply to Steven Scholz

Hi,

Quoted 5 lines · in message <[email protected]> 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.

Quoted 2 lines

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

Quoted 2 lines

What do you think?
Anyone interessted?

Yes, me :-)

Quoted 6 lines

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.

Quoted 3 lines

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

NO !!!!

Best regards,

Wolfgang Denk

Signature · 4 lines

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.

Wolfgang Denk

2003-10-18 20:39 UTC #27 lore raw

In reply to Steven Scholz

Quoted 4 lines · In message <[email protected]> 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?

Quoted 1 line

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

There is always this mailing list.

Best regards,

Wolfgang Denk

Signature · 7 lines

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

Joe

2003-10-20 13:49 UTC #28 lore raw

[U-Boot-Users] about arm7tdmi

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

Wolfgang Denk

2003-10-20 15:10 UTC #29 lore raw

[U-Boot-Users] about arm7tdmi

Quoted 4 lines · In message <[email protected]> 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.

Quoted 4 lines

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

Signature · 5 lines

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

Joe

2003-10-21 04:58 UTC #30 lore raw

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

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

Wolfgang Denk

2003-10-21 09:25 UTC #31 lore raw

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

Dear Joe,

Quoted 6 lines · in message <[email protected]> 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

Signature · 4 lines

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