[U-Boot-Users] UART 16654

Wolfgang Denk wd at denx.de
Tue Dec 28 02:49:57 CET 2004

In message <20041228013654.47236.qmail at 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

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

More information about the U-Boot mailing list