Which way to store log in flash on mpc8xx?

[David Ho]

Hi, just catching up on this problem as I have another unit that
showed the same symptom.
My system looks like this

MPC852T
128Mbytes SDRAM
64Mbytes Flash

Flash partitions
2*1.25Mbytes partitions for Kernel
61.5Mbytes for rootfs and applications.
Remaining 1Mbyte for U-boot, u-boot env and spare.

I get that same problem as well.  kernel BUG at gc.c: 139

I have compiled Perl, Openssl, Openssh, etc running NFS so SDRAM is
definitely not the issue.

David: have you gotten any new insights since?

Regards,
David Ho


On 9/20/05, Wolfgang Denk <wd at denx.de> wrote:
> In message <200509201117.40454.david.jander at protonic.nl> you wrote:
> >
> > Is there something like memtest86 for linux-ppc (i.e. written in portable C)?
>
> Yes, there is. Run the system with root file system mounted over NFS,
> and then put some load on the system, like  by  compiling  the  linux
> kernel  on  the  target.  Anything  else which adds DMA load does not
> hurt, either. In such a situation, with a lots of  context  switches,
> stress  on  the  memory  management  system  and having a lots of DMA
> traffic going on you may see some memory problems. Unfortunately none
> of the standard memory tests will catch thse, as  the  tests  usually
> provide  only plain read / write accesses, while the problems show up
> only in burst mode, i. e. when filling the caches and/or doing DMA.
>
> There is an attempt of a burst mode memory test in the  U-Boot  code,
> but  I  have to admit that I didn't work to show the exact problem on
> the system it was written for.
>
> > Hmm, but.... there is no data corruption. I have not seen one file on flash
> > that had other data than intended, and that inspite of the GC freaking out.
>
> Maybe there is no corruption of the data in flash. But are  you  sure
> that  correct  data are loaded to and read from RAM? We had a similar
> problem on a board where data got corrupted only when doing a lot  of
> transfers flash->RAM.
>
> > That commit only changed 3 files, non of them directly related to jffs2 code,
>
> This is correct.
>
> > and only seemed to add support for FUJITSU flash chips. What am I missing?
> > MTD developers say that cvs from march-2005 _is_ broken, so there must be some
>
> Yes, of course it's broken. Like  all  computer  code.  There  are  a
> couple  of  known  issues  (especially  with NAND flash), but I don't
> think they could explain the type of problems you are seeing.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Einstein argued that there must be simplified explanations of nature,
> because God is not capricious or arbitrary. No  such  faith  comforts
> the software engineer.                             - Fred Brooks, Jr.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>