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

[Pantelis Antoniou <panto@intracom.gr>]

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