GTA02 u-boot and kernel status

Mike (mwester) mwester at dls.net
Wed Mar 5 03:05:42 CET 2008



Werner Almesberger wrote:
> Here's a quick status update on open issues and problems I know of in
> the lower reaches of the system (in no particular order):
>   
[snip]
> - JFFS2 suffers gradual corruption
>
>   The corruption manifests itself mainly in an increasing number of
>   complaints from JFFS2, but it may also be possible that it causes
>   a performance degradation or data loss/corruption (although I
>   haven't observed any of the latter).
>
>   I believe this is a mismatch between mkfs.jffs2 parameters and the
>   actual NAND geometry, but I don't have a good way to predictably
>   reproduce this yet (and thus couldn't tell if an attempt at solving
>   it is really effective or not).
>
>   Suggested resolution: I'll give this one more try later today, and
>   when I get back home. In the worst case, this may not get resolved
>   before we have to provide an image to the factory. Since we'll want
>   to do a complete application update for new devices anyway, that
>   update could take the form of a new rootfs (maybe this is the plan
>   anyway ?), which would then have the correct settings.
>
>   (Related to this is also the use of hardware-accelerated ECCs. I've
>   turned them off until the corruption is resolved, just to make sure
>   we don't add yet another potentially destablizing factor. HW ECCs
>   are probably perfectly fine, though, so we'll also have a
>   performance win once all this is solved.)
...
For what it's worth, I suffered a series of nasty JFFS2 corruptions that 
seem to be similar (progressive) while debugging some boot and shutdown 
issues on the GTA01 this past week.   I was appending to a log file on 
the jffs2 filesystem during the shutdown process, but I've done that 
many times before both on the Neo with the 2.6.22 kernel and many many 
times on other devices.  I expect a truncated logfile (at worst!); 
there's no reason for the jffs2 corruption to occur.  (FWIW, a "sync" 
after the log file was written and closed did nothing to change the 
frequency with which the problem appeared.)

Unfortunately I'm off on a business trip again in a few hours and won't 
be able to work on this until the weekend, but it does indicate that 
perhaps there are some software issues remaining.

Mike (mwester)




More information about the openmoko-kernel mailing list