Re: [Gumstix-users] boot failure after running for a long time CRITICAL FIX NEEDED!

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

Henry,

How many of your boards have you deployed, and how accessible are  
those boards for in-field updates?  The easiest way to push updates  
out to the boards would be to use the gumstix-factory.script system  
with a new u-boot (and possibly uImage/rootfs), if you can get an MMC/ 
SD/CF card to the boards -- I'm not sure what kind of setup we're  
talking about.  Is it possible to completely reflash the boards, or  
is there important data on them which needs to be kept?  The best  
solution would probably be to build a new u-boot/rootfs/uImage using  
the kernel-at-top stuff I recently added to u-boot; then write a  
gumstix-factory.script which will automate the installation of those  
files onto the boards.  But if there's stuff on the flash which needs  
to be preserved, some alteration to that method will be necessary.

C

On May 4, 2007, at 10:39 AM, Henry Beblo wrote:

>  Thanks Craig,  for the info but alas the fix is something that I  
> cannot do. I do not have the knowlege to modify the bootloader.  
> this is a showstopper for us. I have had to ask the client to halt  
> installation of any further units until this problem is resolved.  
> How can we fix this problem? Do I have to hire someone and if so is  
> there someone who knows how to modify the bootloader to fix this  
> problem.
>
> Your urgent assistance is muchly appreciated.
>
> Henry Beblo
> Selcom Industries Inc.
>
>
> ----- Original Message ----
> From: Craig Hughes <cr...@gu...>
> To: General mailing list for gumstix users. <gumstix- 
> us...@li...>
> Cc: Dave Hylands <dhy...@gm...>
> Sent: Monday, April 30, 2007 5:41:27 PM
> Subject: Re: [Gumstix-users] boot failure after running for a long  
> time
>
> On Apr 30, 2007, at 5:08 PM, Henry Beblo wrote:
>
>> Thanks for the info. I was hoping for a software solution that does
>> not require a boot loader change. I have units out in the field and
>> it would be a bit dificult to reflash the boot loader. Is there a
>> good explanation that is causing this problem and how to minimize it?
>
> Yes -- the JFFS2 filesystem is getting highly fragmented,
> essentially.  When the bootloader tries to parse the JFFS2 node
> headers in order to find out where boot/uImage is located, it needs
> to allocate RAM for all the headers it finds.  If you do a lot of
> writing over a long period of time with JFFS2, you'll end up getting
> lots of these headers, and u-boot doesn't have enough heap allocated
> to deal with it.
>
> Dave's initial suggestion of "Just increase the heap size" is fine,
> except that you need then to be aware in u-boot of not accidentally
> writing into that portion of RAM which u-boot considers its heap.
> Probably a better change to make (and the one I've made now in the
> verdex buildroot branch) is to move uImage out of the JFFS2
> filesystem, so u-boot doesn't need to parse the FS.  An added benefit
> of this latter approach is to dramatically speed up boot time, since
> u-boot doesn't need to scan all of flash building its view of JFFS2-
> land.
>
> C
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> gumstix-users mailing list
> gum...@li...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>
>
>