[U-Boot-Users] Re: [PATCH] 8xx: fix initialation bug/race condition between u-boot & linux

[Dan Malek]

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