Hi,
I have a bit out of the loop on the NAND ECC issues you are
mentioning. Is this for 4-bit ECC on DM355, or 1-bit ECC on DM6446?
We have patches for u-boot 1.2.0 for DM355 that fix the ECC HW issues
with mvl kernels. I can clean them up and publish them if required. If
this is for DM6446, then I'm a bit lost here.
Diego Dompe
RidgeRun Engineering.
On Jan 15, 2009, at 9:00 AM, [email protected] wrote:
Greetings,
I need some opinions from the kernel developers on a rather
difficult box
our development has painted me into.
The concerns were jogged by seeing some commons that Kevin and the
group
made about the Davinci HW ECC code
and by some bizarre behavior I've seen with the JFFS2 code that's in
the MV
2.6.10 kernel (how old is that BTW?).
Here's the rub:
We're using the latest u-boot from git with the broken HW ECC
enabled to be
compatible with the MV 2.6.10 kernel.
I really should have realized at that moment that we'd never be able
to
upgrade kernels past the old clunky kernel
because the HW ECC algorithms wouldn't match.
Considering there's no practical way to update u-boot other than a
recall,
I'm kinda stuck big time. I know from
experiments that using the new HW ECC layout in the kernel and not
using it
in U-Boot or vice versa will quickly
turn your nand into swiss cheese from all the bad block marking.
Also, after a few boots, I've been getting ECC failures and bad magic
number errors from JFFS2.
On a few occasions, they were so bad that the boot-up scripts starting
throwing bus errors like mad.
The weird thing is that after updating ld.so.cache, I remount read-
only for
the remainder of operation.
Am I mistaken that I could use the bad-block skipping feature of u-
boot and
nandwrite to put a
pre-canned image on a nand partition with bad blocks present? Is the
issue
related to using
newer mtd-utils package with the old JFFS2 code?
I've come up with some ideas that I've like a little feedback on.
First things first, these are the features in the MV 2.6.10 kernel
that
absolutely must work in any approach:
1. All 3 UARTS functional
2. Davinci resizer functional
3. Video capture via V4L2 using the TVP5146 that comes with the EVM
4. Solid MMC support... even if not high-speed
5. Solid NAND support + JFFS2 or UBIFS
Here's my ideas from what I deem most risky to least risky:
1. Move to the some version of the GIT kernel
2. Back-port the latest MTD code + JFFS2 code from git
3. Back-port only the nand HW ECC code from latest git and turn off
broken
support in u-boot
4. Patch u-boot to be able to select the HW ECC layout
5. Do nothing and watch as the davinci community moves on without us
Ok, I was serious about everything except #5, obviously I've got to do
something.
In a perfect world, I'd like to do #1, but my attempts to justify it
have
been an uphill battle.
Of course, only #1 and #2 address the JFFS2 issue, since if I go
with #1
I'll use UBIFS,
and #2 gives me newer JFFS2 code to test.
Sorry for the long post, but any suggestions or opinions are
welcome... in
the meantime,
I'm going to start diffing to see how bad the damage will be.
By the way, Kevin, David, and the other contributors have been
kicking ass
lately...
we may see a mainline davinci branch yet!
Regards,
David
DAVID A. KONDRAD
Software Design Engineer
On-Q/Legrand
Telephone (800) 321-2343 x311
www.onqlegrand.com
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
