Pantelis Antoniou wrote:
The u-boot loader upon finishing the decompression of the kernel image it just jumps into the kernel without resetting the CP. The kernel however resets the CP only when configured to apply a u-patch. The UART in the CP is still active however, and the descriptors in dpram end up overlapping.
The UART console has a number of subtle assumptions built around the initialization to support kgdb/xmon debugging. The quick answer is we don't want to reset the CPM so we can proper support this debugging. This has all been described in archives before...........
When the kernel is first booted, kgdb/xmon use the CPM as it was set up by the boot rom. There is a second initialization of the UART driver, but before the console is initialized. This changes the BDs, but the UART still operates for kgdb/xmon. The final stage initialization occurs when the console is initialized, and all of the "normal path" debugging and messages can occur after this point.
The attached patch fixes the common problem by performing the CP reset every time.
We don't want to do this and shouldn't need to do so except in the case of loading microcode patches.
This is only a bandaid however, because under network load at the time of booting, i.e. broadcast packets or rebooting after a crash and another end sending non TCP packets, we still crash.
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.
Thanks.
-- Dan