[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
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.
More information about the U-Boot
mailing list