The reason for the change was that Micron stopped producing the memory that we were using on the Rev C4. So, we had to change the memory. We will no longer be building the Rev C4 version.
This new revision results in a change being required to the UBoot and Xloader. As I understand it, you should be able to replace the UBoot and the Xloader and your current SW should work, but no guarantees. The board ships from the factory with a GNOME desktop in it and will boot to the desktop from NAND.
To get the new UBoot and xloader, you can create an SD card using the.img file from the link above and then create a new card using the Uboot and xloader from that SD card. Check back at the link above often for SW updates. We anticipate a newer release in the coming days.
If you have any issues please post your questions to the mailing list or IRC.
The Micron MT29C4G48MAZAPAKQ-5 IT appears to require 4-bit ECC (please
correct if this is not accurate). Have there been any efforts made to
support this level of ECC in the beagleboard sw?
We are using the MT29C4G48MAZAPAKQ-5 IT Micron part on an OMAP3530 in
our custom design. It was necessary to modify the x-loader and u-boot,
because the old Micron PoP had two 128MB RAM parts, one on each chip
select line. The new one has only one of 256MB. However, no
modification to the ECC code in u-boot was made, so it seems that the
new part does not require any changes beyond this. Writing MLO, u-boot
and kernel from u-boot to NAND works just fine.
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.
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.
After reading up on the issue I realized that I didn't really
understand the problem (which I now do).
Cliff, could you give me any pointers on how you are using the Micron
ECC? Is this something you can enable during NAND init, or will I have
to patch the relevant ECC routines in the kernel to take advantage of
the hardware?
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.