System crash in kernel_thread

[Wolfgang Denk]

Dear Flavio,

in message <742AC4678EF8464697DDDFE3B40F6ECD07E2CE at srv-mailrnd.azisa.co.za> you wrote:
>
> >One pretty common reason is that your SDRAM initialization sequence
> >may be buggy and/or incomplete, and you experience memory errors. Re-
> >member that more is required than just adapting the UPM tables.
>
> Hmmm, that is interesting. Does Linux require that burst mode access be
> enabled, right now I have the BI bit set in the OR register. I also

It is most likely that the RAM errors happen when you use  bust  mode
accesses - which happens a lot when Linux starts working.

> ported SD-RAM tests into u-boot, the tests the entire memory range with
> pattern and address and this looks good. I've obviously had to change

I guess you know that there are already pretty extensive memory tests
available in U-Boot (see the post/ code).

The problem is, all these tests will not exercise burts mode accesses
the same way as Linux will do it, especially when Linux starts moving
lot's of data over the network (DMA).

> the UPM config, OR, BR registers, MCR register, MAMR register. I can't
> think of anything else that would require some attention. Could this in
> any way be related to cache?

It has nothing to do with cache. As I  wrote  befor,  there  is  more
things  necessary  to  initialize  the  RAM  correctly. Read the chip
manufacturers documentation and  follow  the  init  sequence  TO  THE
LETTER.  This  may include certain delays, dummy accesses, etc. It is
_NOT_ sufficient to just program the UPM tables,  OR,  BR,  MCR,  and
MAMR registers.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
You see things; and you say ``Why?'' But I dream  things  that  never
were; and I say ``Why not?''
       - George Bernard Shaw _Back to Methuselah_ (1921) pt. 1, act 1

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/