From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] UART 16654
Date: Tue, 28 Dec 2004 02:49:57 +0100 [thread overview]
Message-ID: <20041228015002.3C010C1430@atlas.denx.de> (raw)
In-Reply-To: Your message of "Tue, 28 Dec 2004 09:36:54 +0800." <20041228013654.47236.qmail@web15602.mail.cnb.yahoo.com>
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.
next prev parent reply other threads:[~2004-12-28 1:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-27 8:15 [U-Boot-Users] How to compile uBoot in ADS Yu JunMiao-r61929
2004-12-27 13:29 ` Wolfgang Denk
2004-12-27 16:47 ` [U-Boot-Users] UART 16654 Jonas Dietsche
2004-12-27 17:47 ` [U-Boot-Users] cmd_pcmcia.c richard at uclinux.net
2004-12-27 20:14 ` Wolfgang Denk
2004-12-27 21:59 ` [U-Boot-Users] CFG_FPGA_ALTERA richard at uclinux.net
2004-12-27 22:15 ` [U-Boot-Users] cmd_pcmcia.c richard at uclinux.net
2004-12-28 1:44 ` Wolfgang Denk
2004-12-27 20:10 ` [U-Boot-Users] UART 16654 Wolfgang Denk
2004-12-28 1:36 ` Sam Song
2004-12-28 1:49 ` Wolfgang Denk [this message]
2005-01-03 3:30 ` Sam Song
2004-12-28 8:40 ` Jonas Dietsche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041228015002.3C010C1430@atlas.denx.de \
--to=wd@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox