Wolfgang Denk wrote:
In message 3EF156E9.9000600@intracom.gr you wrote:
OK. Shouldn't there be at least a comment in the code to mention that?
Feel free to submit a patch.
OK
This is a common problem of all bootloaders that don't disable the Ethernet controller after they have performed the network load operation. You must disable any kind of DMA operation that could write into memory while any software outside of the boot rom is initializing. Performing the CPM reset in the kernel doesn't solve this problem, it only makes the window of opportunity smaller. With sufficient network traffic and coincidental buffer locations, you will always crash even with the CPM reset in the kernel.
Yep, it is a job for the bootloader. Wolfgang?
Can you please explain again under which conditions the problem happened? As Dan explained there is good reason NOT to perform a global CPM reset, but to leave the console UART enabled (which should be not critical). Regarding network transfers I think that U-Boot will call eth_halt() after all (attempted) network transfers; eth_halt() in turn calls driver functions (like scc_halt() or fec_halt()) that should disable the network controller.
You wrote:
My troubles began when for dpram conflict reasons we moved from using a console on an SMC to a max3100 SPI/UART converter chip.
I have never seen a crash like the one you reported, and in fact I am not convinced that it is a global problem. Maybe the problem is only introduced by your own SPI/UART driver code?
In any case: if you find a place where a CPM device is not shut down before booting Linux please submit a patch. But I would like to avoid a global CPM reset.
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.
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.
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.
Best regards,
Wolfgang Denk
Regards
Pantelis