public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Pantelis Antoniou <panto@intracom.gr>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Re: [PATCH] 8xx: fix initialization bug/race condition between u-boot & linux
Date: Thu, 19 Jun 2003 09:23:37 +0300	[thread overview]
Message-ID: <3EF156E9.9000600@intracom.gr> (raw)
In-Reply-To: <3EF0B5E6.8050505@embeddededge.com>

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

  reply	other threads:[~2003-06-19  6:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-17 12:43 [U-Boot-Users] [PATCH] 8xx: fix initialation bug/race condition between u-boot & linux Pantelis Antoniou
2003-06-17 18:54 ` [U-Boot-Users] " Tom Rini
2003-06-18  7:00   ` Pantelis Antoniou
2003-06-18  7:16     ` Wolfgang Denk
2003-06-18  7:35       ` Pantelis Antoniou
2003-06-18  8:32       ` Jaap-Jan Boor
2003-06-18 14:18         ` Tom Rini
2003-06-18 18:56 ` Dan Malek
2003-06-19  6:23   ` Pantelis Antoniou [this message]
2003-06-19  8:31     ` [U-Boot-Users] Re: [PATCH] 8xx: fix initialization " Wolfgang Denk
2003-06-19  9:21       ` Pantelis Antoniou
2003-06-19 10:09         ` Wolfgang Denk
2003-06-19 14:40     ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3EF156E9.9000600@intracom.gr \
    --to=panto@intracom.gr \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox