Re: [Gumstix-users] uBoot scanning of Jffs2 - too efficient?

[Craig H. <cr...@gu...>]

On Jun 11, 2006, at 2:47 AM, James Coxon wrote:

> Dear all, I've been using my gumstix to read from the gps and then  
> enter it
> into a log file but everytime I pull the power (i can't constantly  
> login
> and close everything down) i manage to corrupt the filesystem so  
> that the
> initial uboot scan fails and stops it loading: add_node: malloc failed
> add_node failed! load: Failed to scan JFFSv2 file structure ###  
> JFFS2 LOAD
> ERROR<0> for boot/uImage! If i then type boot in the command line  
> it boots
> perfectly fine. Has the uboot check become more efficient and fails on
> simple things now? I never use to have a problem with pulling the  
> power and
> the filesystem being okay. I'm using revision 1003.
>
> Any ideas so that i don't have to keep reflashing my gumstix?

I don't think the u-boot code has changed in a way that's making this  
happen -- the problem is that when you do lots of tiny write to  
JFFS2, due to its wear-leveling, it ends up fragmenting the existing  
files and directories all over the entirety of flash, which slows  
down the initial scan, and also causes u-boot to run out of heap  
space (u-boot has quite a small heap by default) when it's trying to  
build an in-RAM representation of the JFFS2 directory layout and the  
location of all the nodes.

I'll play around a bit with seeing if raising the u-boot heap size  
solves this problem; since we have more RAM on a 'stix than flash by  
a fair margin, it shouldn't be an impossible problem to solve...

C