In message 3EF180AB.3030304@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 problem.
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 things.
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 only.
But this is an exotic setup, and IMHO not worth a patch.
Best regards,
Wolfgang Denk