--
You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To post to this group, send email to beagl...@googlegroups.com.
To unsubscribe from this group, send email to beagleboard...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.
Thanks.
Is the Wiki correct: 512Mbytes NAND and only 256Mbytes RAM?
--
Thanks,
Cliff
--
=================
http://bec-systems.com
What ends up shipping on the C5 boards today is a kernel built with
this recipe[1] which is based on this kernel baseline[2]. There was
some discussion on a TI support thread regarding 4-bit and 8-bit ECC
support[3]. The tag being pointed to by that thread nor the
particular patch in quesiton[4] is NOT in the history of the tree
being pulled in for this release of the boards.
So, no, we aren't handling it today. Looks like we should pull in
that[4] patch.
[1] http://git.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-omap-psp_2.6.32.bb?h=2011.03-maintenance
[2] http://arago-project.org/git/projects/linux-omap3.git?p=projects/linux-omap3.git;a=commit;h=5fc29e7b2a76a64a739f857858ef0b98294aa155
[3] http://e2e.ti.com/support/embedded/f/354/p/53309/196908.aspx
[4] http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=6a49a8032d94554909d4f14654675c67d71c9d8a
Even though your software may work, if you are using a part that is
rated assuming 4-bit ECC, and you are only doing 1-bit ECC, then the
life of the part will be drastically reduced. As NAND geometries get
smaller, the error rate goes up, so better ECC algorithms are required
to compensate.
We've been using the Micron embedded 4-bit ECC engine, and that seems
to work fairly well. I'm not sure how it compares to sw solutions,
but Micron suggested to us that 4/8-bit ECC gets pretty slow in sw.
Attached are my current patches. While they seem to function, they
need cleaned up, are not tested for error handling, and are in no way
guaranteed to be complete.