problem with 2k page NAND with squashfs

problem with 2k page NAND with squashfs

[Adams Richard-W36112]

 I have an arm-based embedded system running a 2.6.10 kernel. I'm using
a squashfs file system (read only) on the Flash device. The system was
working fine with a 512 byte page Flash part. I started having problems
when I upgraded to a 2048 byte page Flash part. When I mount the squash
file system, it can successfully find the super block, but squashfs
fails (unable to read inode [5ff3:120]) when it try's to finish the
mount. My suspicions are that with the older kernel (2.6.10) it may not
fully support the larger page devices. Is there an achieve of patches
that are applicable for a 2.6.10 kernel? I tried to look through the
mailing list archive, but without a search tool and not knowing what
month I'm looking for the task became tedious.
 
Rick Adams
(858) 404-3091  -- Motorola Office
(858) 775-1136  -- cell phone

Re: problem with 2k page NAND with squashfs

[Josh Boyer]

On Tue, 22 Jan 2008 09:15:29 -0500
"Adams Richard-W36112" <rgadams@motorola.com> wrote:

>  I have an arm-based embedded system running a 2.6.10 kernel. I'm using
> a squashfs file system (read only) on the Flash device. The system was
> working fine with a 512 byte page Flash part. I started having problems
> when I upgraded to a 2048 byte page Flash part. When I mount the squash
> file system, it can successfully find the super block, but squashfs
> fails (unable to read inode [5ff3:120]) when it try's to finish the
> mount. My suspicions are that with the older kernel (2.6.10) it may not
> fully support the larger page devices. Is there an achieve of patches
> that are applicable for a 2.6.10 kernel? I tried to look through the
> mailing list archive, but without a search tool and not knowing what
> month I'm looking for the task became tedious.

http://linux-mtd.infradead.org/source.html#kernelversions

2.6.10 pre-dates git even, so you are likely stuck doing diffs from
kernel tarballs.

josh

RE: problem with 2k page NAND with squashfs

[Adams Richard-W36112]

> On Tue, 22 Jan 2008 09:15:29 -0500
> "Adams Richard-W36112" <rgadams@motorola.com> wrote:
> 
> >  I have an arm-based embedded system running a 2.6.10 kernel. I'm 
> > using a squashfs file system (read only) on the Flash device. The 
> > system was working fine with a 512 byte page Flash part. I started 
> > having problems when I upgraded to a 2048 byte page Flash 
> part. When I 
> > mount the squash file system, it can successfully find the super 
> > block, but squashfs fails (unable to read inode [5ff3:120]) when it 
> > try's to finish the mount. My suspicions are that with the older 
> > kernel (2.6.10) it may not fully support the larger page 
> devices. Is 
> > there an achieve of patches that are applicable for a 
> 2.6.10 kernel? I 
> > tried to look through the mailing list archive, but without 
> a search 
> > tool and not knowing what month I'm looking for the task 
> became tedious.
> 
> http://linux-mtd.infradead.org/source.html#kernelversions
> 
> 2.6.10 pre-dates git even, so you are likely stuck doing 
> diffs from kernel tarballs.
> 
> josh
> 

Before I went through the effort I wanted to check with the list to see
if anyone knows that there is or isn't an issue with the 2k NAND page
size on this vintage kernel.

RE: problem with 2k page NAND with squashfs

[Ricard Wanderlof]

On Tue, 22 Jan 2008, Adams Richard-W36112 wrote:

>> On Tue, 22 Jan 2008 09:15:29 -0500
>> "Adams Richard-W36112" <rgadams@motorola.com> wrote:
>>
>>>  I have an arm-based embedded system running a 2.6.10 kernel. I'm
> ...
> Before I went through the effort I wanted to check with the list to see
> if anyone knows that there is or isn't an issue with the 2k NAND page
> size on this vintage kernel.

You could check in drivers/mtd/nand/nand_ids.c and see if your flash chip, 
or indeed any chip with that page size is listed there. Even if it is, 
there could still be a bug of course.

I seem to remember some kernel of similar vintage failing with large-page 
flash chips because the driver tried to kmalloc a buffer the size of a 
block, which failed for chips with 128 KiB blocks, because of limitations 
of the amount of memory that could allocated in one go with kmalloc.

/Ricard
--
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30