From mboxrd@z Thu Jan  1 00:00:00 1970
From: Pantelis Antoniou <panto@intracom.gr>
Date: Thu, 19 Jun 2003 09:23:37 +0300
Subject: [U-Boot-Users] Re: [PATCH] 8xx: fix initialization bug/race condition between u-boot
 & linux
In-Reply-To: <3EF0B5E6.8050505@embeddededge.com>
References: <3EEF0CF6.70004@intracom.gr> <3EF0B5E6.8050505@embeddededge.com>
Message-ID: <3EF156E9.9000600@intracom.gr>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Dan Malek wrote:

> 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.

OK. Shouldn't there be at least a comment in the code to mention that?

>
>>  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.

Yep, it is a job for the bootloader. Wolfgang?

>
>
> Thanks.
>
>
>     -- Dan
>
>
>
>