* [U-Boot-Users] Maintainer of AT91RM9200DK???
@ 2003-10-18 13:12 Steven Scholz
2003-10-18 13:45 ` [U-Boot-Users] " Rick Bronson
2003-10-18 20:39 ` [U-Boot-Users] Maintainer of AT91RM9200DK??? Wolfgang Denk
0 siblings, 2 replies; 28+ messages in thread
From: Steven Scholz @ 2003-10-18 13:12 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] Re: Maintainer of AT91RM9200DK???
2003-10-18 13:12 [U-Boot-Users] Maintainer of AT91RM9200DK??? Steven Scholz
@ 2003-10-18 13:45 ` Rick Bronson
[not found] ` <3F914731.1000207@imc-berlin.de>
2003-10-18 20:39 ` [U-Boot-Users] Maintainer of AT91RM9200DK??? Wolfgang Denk
1 sibling, 1 reply; 28+ messages in thread
From: Rick Bronson @ 2003-10-18 13:45 UTC (permalink / raw)
To: u-boot
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
>
>
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] Maintainer of AT91RM9200DK???
2003-10-18 13:12 [U-Boot-Users] Maintainer of AT91RM9200DK??? Steven Scholz
2003-10-18 13:45 ` [U-Boot-Users] " Rick Bronson
@ 2003-10-18 20:39 ` Wolfgang Denk
2003-10-20 13:49 ` [U-Boot-Users] about arm7tdmi Joe
1 sibling, 1 reply; 28+ messages in thread
From: Wolfgang Denk @ 2003-10-18 20:39 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] about arm7tdmi
2003-10-18 20:39 ` [U-Boot-Users] Maintainer of AT91RM9200DK??? Wolfgang Denk
@ 2003-10-20 13:49 ` Joe
2003-10-20 15:10 ` Wolfgang Denk
0 siblings, 1 reply; 28+ messages in thread
From: Joe @ 2003-10-20 13:49 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] about arm7tdmi
2003-10-20 13:49 ` [U-Boot-Users] about arm7tdmi Joe
@ 2003-10-20 15:10 ` Wolfgang Denk
2003-10-21 4:58 ` [U-Boot-Users] one by one problem " Joe
0 siblings, 1 reply; 28+ messages in thread
From: Wolfgang Denk @ 2003-10-20 15:10 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] one by one problem about arm7tdmi
2003-10-20 15:10 ` Wolfgang Denk
@ 2003-10-21 4:58 ` Joe
2003-10-21 9:25 ` Wolfgang Denk
0 siblings, 1 reply; 28+ messages in thread
From: Joe @ 2003-10-21 4:58 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] one by one problem about arm7tdmi
2003-10-21 4:58 ` [U-Boot-Users] one by one problem " Joe
@ 2003-10-21 9:25 ` Wolfgang Denk
0 siblings, 0 replies; 28+ messages in thread
From: Wolfgang Denk @ 2003-10-21 9:25 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] U-Boot for AT91RM9200DK
[not found] ` <E1AAsEW-0000fj-00@c-67-164-61-95.client.comcast.net>
@ 2003-10-24 9:01 ` Steven Scholz
2003-10-24 14:05 ` [U-Boot-Users] " Rick Bronson
2003-10-25 18:32 ` [U-Boot-Users] " Wolfgang Denk
0 siblings, 2 replies; 28+ messages in thread
From: Steven Scholz @ 2003-10-24 9:01 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] Re: U-Boot for AT91RM9200DK
2003-10-24 9:01 ` [U-Boot-Users] U-Boot for AT91RM9200DK Steven Scholz
@ 2003-10-24 14:05 ` Rick Bronson
2003-10-24 14:18 ` Steven Scholz
2003-10-27 7:15 ` Steven Scholz
2003-10-25 18:32 ` [U-Boot-Users] " Wolfgang Denk
1 sibling, 2 replies; 28+ messages in thread
From: Rick Bronson @ 2003-10-24 14:05 UTC (permalink / raw)
To: u-boot
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
>
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] Re: U-Boot for AT91RM9200DK
2003-10-24 14:05 ` [U-Boot-Users] " Rick Bronson
@ 2003-10-24 14:18 ` Steven Scholz
2003-10-24 14:30 ` Rick Bronson
2003-10-27 7:15 ` Steven Scholz
1 sibling, 1 reply; 28+ messages in thread
From: Steven Scholz @ 2003-10-24 14:18 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] Re: U-Boot for AT91RM9200DK
2003-10-24 14:18 ` Steven Scholz
@ 2003-10-24 14:30 ` Rick Bronson
2003-10-24 14:41 ` Steven Scholz
2003-10-25 18:41 ` Wolfgang Denk
0 siblings, 2 replies; 28+ messages in thread
From: Rick Bronson @ 2003-10-24 14:30 UTC (permalink / raw)
To: u-boot
>
> 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
>
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] Re: U-Boot for AT91RM9200DK
2003-10-24 14:30 ` Rick Bronson
@ 2003-10-24 14:41 ` Steven Scholz
2003-10-24 15:40 ` Rick Bronson
2003-10-25 18:52 ` Wolfgang Denk
2003-10-25 18:41 ` Wolfgang Denk
1 sibling, 2 replies; 28+ messages in thread
From: Steven Scholz @ 2003-10-24 14:41 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] Re: U-Boot for AT91RM9200DK
2003-10-24 14:41 ` Steven Scholz
@ 2003-10-24 15:40 ` Rick Bronson
2003-10-25 18:45 ` Wolfgang Denk
2003-10-25 18:52 ` Wolfgang Denk
1 sibling, 1 reply; 28+ messages in thread
From: Rick Bronson @ 2003-10-24 15:40 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] U-Boot for AT91RM9200DK
2003-10-24 9:01 ` [U-Boot-Users] U-Boot for AT91RM9200DK Steven Scholz
2003-10-24 14:05 ` [U-Boot-Users] " Rick Bronson
@ 2003-10-25 18:32 ` Wolfgang Denk
1 sibling, 0 replies; 28+ messages in thread
From: Wolfgang Denk @ 2003-10-25 18:32 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] Re: U-Boot for AT91RM9200DK
2003-10-24 14:30 ` Rick Bronson
2003-10-24 14:41 ` Steven Scholz
@ 2003-10-25 18:41 ` Wolfgang Denk
1 sibling, 0 replies; 28+ messages in thread
From: Wolfgang Denk @ 2003-10-25 18:41 UTC (permalink / raw)
To: u-boot
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_
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] Re: U-Boot for AT91RM9200DK
2003-10-24 15:40 ` Rick Bronson
@ 2003-10-25 18:45 ` Wolfgang Denk
0 siblings, 0 replies; 28+ messages in thread
From: Wolfgang Denk @ 2003-10-25 18:45 UTC (permalink / raw)
To: u-boot
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_
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] Re: U-Boot for AT91RM9200DK
2003-10-24 14:41 ` Steven Scholz
2003-10-24 15:40 ` Rick Bronson
@ 2003-10-25 18:52 ` Wolfgang Denk
2003-10-26 10:56 ` Steven Scholz
1 sibling, 1 reply; 28+ messages in thread
From: Wolfgang Denk @ 2003-10-25 18:52 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] Re: U-Boot for AT91RM9200DK
2003-10-25 18:52 ` Wolfgang Denk
@ 2003-10-26 10:56 ` Steven Scholz
2003-10-26 12:17 ` Wolfgang Denk
0 siblings, 1 reply; 28+ messages in thread
From: Steven Scholz @ 2003-10-26 10:56 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] Re: U-Boot for AT91RM9200DK
2003-10-26 10:56 ` Steven Scholz
@ 2003-10-26 12:17 ` Wolfgang Denk
0 siblings, 0 replies; 28+ messages in thread
From: Wolfgang Denk @ 2003-10-26 12:17 UTC (permalink / raw)
To: u-boot
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_
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] Re: U-Boot for AT91RM9200DK
2003-10-24 14:05 ` [U-Boot-Users] " Rick Bronson
2003-10-24 14:18 ` Steven Scholz
@ 2003-10-27 7:15 ` Steven Scholz
2003-10-27 8:02 ` Wolfgang Denk
2003-10-27 15:38 ` Rick Bronson
1 sibling, 2 replies; 28+ messages in thread
From: Steven Scholz @ 2003-10-27 7:15 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] Re: U-Boot for AT91RM9200DK
2003-10-27 7:15 ` Steven Scholz
@ 2003-10-27 8:02 ` Wolfgang Denk
2003-10-27 8:25 ` Steven Scholz
2003-10-27 15:38 ` Rick Bronson
1 sibling, 1 reply; 28+ messages in thread
From: Wolfgang Denk @ 2003-10-27 8:02 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] Re: U-Boot for AT91RM9200DK
2003-10-27 8:02 ` Wolfgang Denk
@ 2003-10-27 8:25 ` Steven Scholz
2003-10-27 10:16 ` Wolfgang Denk
0 siblings, 1 reply; 28+ messages in thread
From: Steven Scholz @ 2003-10-27 8:25 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] Re: U-Boot for AT91RM9200DK
2003-10-27 8:25 ` Steven Scholz
@ 2003-10-27 10:16 ` Wolfgang Denk
2003-10-27 11:23 ` Steven Scholz
0 siblings, 1 reply; 28+ messages in thread
From: Wolfgang Denk @ 2003-10-27 10:16 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] Re: U-Boot for AT91RM9200DK
2003-10-27 10:16 ` Wolfgang Denk
@ 2003-10-27 11:23 ` Steven Scholz
2003-10-27 11:53 ` Wolfgang Denk
0 siblings, 1 reply; 28+ messages in thread
From: Steven Scholz @ 2003-10-27 11:23 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] Re: U-Boot for AT91RM9200DK
2003-10-27 11:23 ` Steven Scholz
@ 2003-10-27 11:53 ` Wolfgang Denk
2003-10-27 14:58 ` Steven Scholz
0 siblings, 1 reply; 28+ messages in thread
From: Wolfgang Denk @ 2003-10-27 11:53 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] Re: U-Boot for AT91RM9200DK
2003-10-27 11:53 ` Wolfgang Denk
@ 2003-10-27 14:58 ` Steven Scholz
0 siblings, 0 replies; 28+ messages in thread
From: Steven Scholz @ 2003-10-27 14:58 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] Re: U-Boot for AT91RM9200DK
2003-10-27 7:15 ` Steven Scholz
2003-10-27 8:02 ` Wolfgang Denk
@ 2003-10-27 15:38 ` Rick Bronson
2003-10-27 16:21 ` Wolfgang Denk
1 sibling, 1 reply; 28+ messages in thread
From: Rick Bronson @ 2003-10-27 15:38 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot-Users] Re: U-Boot for AT91RM9200DK
2003-10-27 15:38 ` Rick Bronson
@ 2003-10-27 16:21 ` Wolfgang Denk
0 siblings, 0 replies; 28+ messages in thread
From: Wolfgang Denk @ 2003-10-27 16:21 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2003-10-27 16:21 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-18 13:12 [U-Boot-Users] Maintainer of AT91RM9200DK??? Steven Scholz
2003-10-18 13:45 ` [U-Boot-Users] " Rick Bronson
[not found] ` <3F914731.1000207@imc-berlin.de>
[not found] ` <E1AAs6Y-0000eT-00@c-67-164-61-95.client.comcast.net>
[not found] ` <3F914F82.3060502@imc-berlin.de>
[not found] ` <E1AAsEW-0000fj-00@c-67-164-61-95.client.comcast.net>
2003-10-24 9:01 ` [U-Boot-Users] U-Boot for AT91RM9200DK Steven Scholz
2003-10-24 14:05 ` [U-Boot-Users] " Rick Bronson
2003-10-24 14:18 ` Steven Scholz
2003-10-24 14:30 ` Rick Bronson
2003-10-24 14:41 ` Steven Scholz
2003-10-24 15:40 ` Rick Bronson
2003-10-25 18:45 ` Wolfgang Denk
2003-10-25 18:52 ` Wolfgang Denk
2003-10-26 10:56 ` Steven Scholz
2003-10-26 12:17 ` Wolfgang Denk
2003-10-25 18:41 ` Wolfgang Denk
2003-10-27 7:15 ` Steven Scholz
2003-10-27 8:02 ` Wolfgang Denk
2003-10-27 8:25 ` Steven Scholz
2003-10-27 10:16 ` Wolfgang Denk
2003-10-27 11:23 ` Steven Scholz
2003-10-27 11:53 ` Wolfgang Denk
2003-10-27 14:58 ` Steven Scholz
2003-10-27 15:38 ` Rick Bronson
2003-10-27 16:21 ` Wolfgang Denk
2003-10-25 18:32 ` [U-Boot-Users] " Wolfgang Denk
2003-10-18 20:39 ` [U-Boot-Users] Maintainer of AT91RM9200DK??? Wolfgang Denk
2003-10-20 13:49 ` [U-Boot-Users] about arm7tdmi Joe
2003-10-20 15:10 ` Wolfgang Denk
2003-10-21 4:58 ` [U-Boot-Users] one by one problem " Joe
2003-10-21 9:25 ` Wolfgang Denk
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.