[U-Boot-Users] Re: [PATCH] 8xx: fix initialization bug/race condition between u-boot & linux
wd at denx.de
Thu Jun 19 12:09:34 CEST 2003
In message <3EF180AB.3030304 at intracom.gr> you wrote:
> The problem was introduced while testing the SPI/UART driver
> and using the SMC uart on u-boot.
> Since the SMC uart was disabled in linux it's dpram memory area was used by
> the next CP driver, the ethernet. However it was still active and both
> the ethernet and SMC ended up using the same dpram.
It is indeed an unusual configuration to use different devices for
console in the boot loader and in Linux.
> When both u-boot and the kernel use the SPI/UART for console there is no
> Granted it is an obscure case, but the whole thing was surprising.
If you do such a thing you are supposed to know what you are doing. I
don't think it is worth the effort to protect against all possible
> And since the whole mess was produced by kgdb, which was not
> configured in could we at least reset the CP if we don't use kgdb?
> It will save some poor sucker some hair.
I disagree. As Dan Malek has explained, there is good reason NOT to
perform a CPM reset. Instead, the console port _shall_ be passed
initialized and usable to Linux. I think it is not wise to assume
that only kgdb may use it.
A CPM reset is a too drastic measure. Neither U-Boot nor Linux are
designed this way. Instead, normally a driver will enable just a
single port/channel at init, and disable it again in the
release/close function - see for example the ethernet drivers. The
fact that this is not done for the console is intentional. If you use
a SMC UART port in U-Boot and do not pass this as console up to
Linux, it is IMHO your responsibility to disable exactly this channel
But this is an exotic setup, and IMHO not worth a patch.
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
You're dead, Jim.
-- McCoy, "Amok Time", stardate 3372.7
More information about the U-Boot