[U-Boot-Users] How to compile uBoot in ADS

[U-Boot-Users] How to compile uBoot in ADS

[Yu JunMiao-r61929]

Hello there,

One of my friend need to compile uBoot in ADS IDE for OMAP platform,
Does anyone have done semilar job or give me some hint about it? 
Thanks a lot!

Best Regards,
Mark

[U-Boot-Users] How to compile uBoot in ADS

[Wolfgang Denk]

In message <3578894547A2D511A82500D0B7F0FF9C0CF198BB@zch01exm02.sps.mot.com> you wrote:
> 
> One of my friend need to compile uBoot in ADS IDE for OMAP platform,
> Does anyone have done semilar job or give me some hint about it? 

It's a two stage job. In the first stage, chose a known to be working
environment. For example, install Linux and the ELDK.

Seriously - why going through all the  trouble  to  get  some  exotic
toolchain working if you can do the job in half an hour with existing
free tools?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
To understand a program you must become  both  the  machine  and  the
program.

[U-Boot-Users] UART 16654

[Jonas Dietsche]

Hello list,

I try to use an external UART with an ARM9 of NetSilicon. The driver for 
Linux works fine. In u-boot I thougt about using the NS16550 driver and 
it workes fine, too. I see the output and can use the console to make 
changes to the u-boot commands.
Now my problem:
Using an u-boot with the NS16550 makes linux not booting any more. The 
last message I get is "Starting kernel ...". It is not possible to ping 
the target any more. Using an u-boot without the NS16550 driver works. I 
don't see the u-boot output but linux starts normal.

Any ideas what's going wrong?

regards,

--
Jonas

[U-Boot-Users] cmd_pcmcia.c

[richard at uclinux.net]

Evening again...


Is there any reason that most of the board specific PCMCIA code
resides in "common/cmd_pcmcia.c" ?


rick

[U-Boot-Users] cmd_pcmcia.c

[Wolfgang Denk]

In message <r02010400-1037-702545FA582F11D99E9A00039387ACB6@[10.0.1.1]> you wrote:
> 
> Is there any reason that most of the board specific PCMCIA code
> resides in "common/cmd_pcmcia.c" ?

Yes, there is: that was what I found  in  the  Linux  kernel  when  I
started working on this, and from then on the file has just grown. So
it's historical reasons once again.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
When you die, the first thing you lose is your life. The  next  thing
is the illusions.                       - Terry Pratchett, _Pyramids_

[U-Boot-Users] CFG_FPGA_ALTERA

[richard at uclinux.net]

And one for tthe night (o;


I see there exists CFG_FPGA_ALTERA and some altera fpga code in
latest u-boot...obvioulsy no existing board in the cvs is using it...

So nobody using it at all or has there been no feedback to the cvs?


rick

[U-Boot-Users] cmd_pcmcia.c

[richard at uclinux.net]

> In message <r02010400-1037-702545FA582F11D99E9A00039387ACB6@[10.0.1.1]> you wrote:
> > 
> > Is there any reason that most of the board specific PCMCIA code
> > resides in "common/cmd_pcmcia.c" ?
> 
> Yes, there is: that was what I found  in  the  Linux  kernel  when  I
> started working on this, and from then on the file has just grown. So
> it's historical reasons once again.
> 

So you wouldn't mind if I place the board specific code into
"board/Opus103/pcmcia.c" ? (o;

Just don't like messing around with things in "common/" (o;



best regards
rick

[U-Boot-Users] cmd_pcmcia.c

[Wolfgang Denk]

In message <r02010400-1037-C5A9F124585411D983EB00039387ACB6@[10.0.1.1]> you wrote:
> 
> So you wouldn't mind if I place the board specific code into
> "board/Opus103/pcmcia.c" ? (o;

Not really. I also wouldn't object against a patch that  cleans  this
up for all boards ;-)

> Just don't like messing around with things in "common/" (o;

A laudable attitude.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You can do this in a number of ways.     IBM chose to do all of them.
Why do you find that funny?        -- D. Taylor, Computer Science 350

[U-Boot-Users] UART 16654

[Wolfgang Denk]

In message <41D03CB0.2020306@fsforth.de> you wrote:
>
> Using an u-boot with the NS16550 makes linux not booting any more. The 
> last message I get is "Starting kernel ...". It is not possible to ping 
> the target any more. Using an u-boot without the NS16550 driver works. I 
> don't see the u-boot output but linux starts normal.
> 
> Any ideas what's going wrong?

You have a problem in your Linux kernel. The Linux drivers  must  not
make any assumptions about any initialization done or not done by any
boot loader. Fix your Linux driver.

See also the related FAQ at
http://www.denx.de/twiki/bin/view/DULG/EthernetDoesNotWorkInLinux

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A day without sunshine is like night.

[U-Boot-Users] UART 16654

[Sam Song]

Wolfgang Denk <wd@denx.de> wrote?
> Jonas Dietsche <maillist@fsforth.de> wrote:
> > Using an u-boot with the NS16550 makes linux not
> > booting any more. The 
> > last message I get is "Starting kernel ...". It is

It seems that NS16550 driver in kernel wasn't enabled
or work right.

> The Linux drivers  must  not make any assumptions 
> about any initialization done or not done by any
> boot loader. Fix your Linux driver.

But one exception for serial console driver. I found
there wasn't enable control of UART receiver in 8xx
kerenl serial console driver uart.c. Maybe this driver
make a assumption that boot loader does this job? At
least I ported the driver work right on my 8xx custom
board without any change in it:-)

Also, sometimes we could initialize some status in
U-Boot for ready and then change it in kerenl to
finish some special work. I once made the LCD
backlight in boot process of my target like PC did to
aviod seeing the LCD screen flickering. First enable
and then shut down in u-boot, open it later in LCD
kernel driver:-)

IMHO, if one person did u-boot and kernel port both,
he would have the chance to consider the harmony
between U-Boot and Kernel. So some initialization like
receiver enable in kernel driver could be omitted. Is
this an informal idea?

Thanks for your nice time,

=====
Best regards,

Sam

_________________________________________________________
Do You Yahoo!?
150??MP3????????????
http://music.yisou.com/
???????????????????
http://image.yisou.com
1G??1000???????????
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/

[U-Boot-Users] UART 16654

[Wolfgang Denk]

In message <20041228013654.47236.qmail@web15602.mail.cnb.yahoo.com> you wrote:
>
> > The Linux drivers  must  not make any assumptions 
> > about any initialization done or not done by any
> > boot loader. Fix your Linux driver.
> 
> But one exception for serial console driver. I found
> there wasn't enable control of UART receiver in 8xx
> kerenl serial console driver uart.c. Maybe this driver
> make a assumption that boot loader does this job? At

It should not. But there are bugs and bugs and ...

> Also, sometimes we could initialize some status in
> U-Boot for ready and then change it in kerenl to
> finish some special work. I once made the LCD
> backlight in boot process of my target like PC did to
> aviod seeing the LCD screen flickering. First enable
> and then shut down in u-boot, open it later in LCD
> kernel driver:-)

Of course there are many situations where an (intentional)  deviation
from these rules may be necessary - loading a splash screen in U-Boot
and  passing  a  pre-initialized framebuffer to Linux is one of these
areas.

> IMHO, if one person did u-boot and kernel port both,
> he would have the chance to consider the harmony
> between U-Boot and Kernel. So some initialization like
> receiver enable in kernel driver could be omitted. Is
> this an informal idea?

Actually it is a bad idea if the kernel makes assumptions about which
boot loader  is  used,  or  which  initializations  the  boot  loader
performes.  Yes, we all like U-Boot more than every other boot oader,
but why knows what sort of boot loader  the  next  guy  booting  your
kernel  wants  or  has to use? Don't make life more difficult for him
than absolutely necessary.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Virtual" means never knowing where your next byte is coming from.

[U-Boot-Users] UART 16654

[Sam Song]

Wolfgang Denk <wd@denx.de> wrote?
> > But one exception for serial console driver. I
> > found there wasn't enable control of UART receiver
> > in 8xx kerenl serial console driver uart.c. Maybe
> > this driver make a assumption that boot loader 
> > does this job?
>
> It should not. But there are bugs and bugs and ...

So I know what the driver could be... 

> > IMHO, if one person did u-boot and kernel port
> > both, he would have the chance to consider the 
> > harmony between U-Boot and Kernel. So some 
> > initialization like
> > receiver enable in kernel driver could be omitted.
> > Is this an informal idea?
> 
> Actually it is a bad idea if the kernel makes
> assumptions about which boot loader  is  used,  or 
> which  initializations the  boot  loader
> performes. Yes, we all like U-Boot more than every
> other boot oader, but why knows what sort of boot 
> loader  the  next guy  booting  your
> kernel  wants  or  has to use? Don't make life more
> difficult for him than absolutely necessary.

Hi, Wolfgang. I appreciate your reply in the view of
kernel rather than u-boot. Well, sounds a little bit
late to answer your help but after a deep
consideration:-)

Thanks very much and Happy New Year!

=====
Best regards,

Sam

_________________________________________________________
Do You Yahoo!?
150??MP3????????????
http://music.yisou.com/
???????????????????
http://image.yisou.com
1G??1000???????????
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/

[U-Boot-Users] UART 16654

[Jonas Dietsche]

Wolfgang Denk wrote on 12/27/04 21:10:
> You have a problem in your Linux kernel. The Linux drivers  must  not
> make any assumptions about any initialization done or not done by any
> boot loader. Fix your Linux driver.
I just tried to take out the serial driver of the kernel. Still the same 
problem, last message "Starting kernel..." (ok, have to be the last one, 
because I have no console...). But I am still not able to ping the 
target. Using an u-boot without the serial driver and linux boots. Is it 
really a misconfigured linux driver, or should I focus on my u-boot driver?

Regards,

--
Jonas