[U-Boot-Users] [PATCH] jffs2 indirect access.

[Woodruff, Richard]

Hi,

I had considered doing something similar to support NAND.  After reading
though Dave's comments as attached below (speed, size, ...) and some other
reading I decided from my perspective it wasn't worth it.  For the most part
memory is abundant at the boot loader so copying a moderately sized kernel
partition doesn't seem that bad, especially given the speed cost.  In my
board I've added a ram entry flash device array and copy data there.

Regards,

Richard W. 


----------------------------------------------------------------------------
--
Richard Woodruff [mailto:r-woodruff2 at ti.com] wrote: 
> Has anyone used adapted/used any of the u-boot JFFS2 code to be NAND
aware?
> A very quick look at the JFFS2 code (called by fsload, fsinfo, ..) 
> seems
to
> indicate to me that reading of raw data is done via a straight memcpy 
> (direct dereference, assuming linear flash).  I'm wondering if making 
> it work might be as simple as conditionalizing that code to call the 
> nand_mtd read.j equivalents....unfortunately few things are ever just 
> simple...

I have it working, but in a simpler way. I have a 2 MiB boot partition at 
the start of the nand flash (with just the kernel image and maybe a backup
kernel). I read the whole partition to RAM and let JFFS2 read it from there.


nand read.j 400000 0 200000; fsload 200000 image; bootm 200000

The only tricky part is that the configuration options for JFFS2 only work
with memory in NOR flash, so I used CFG_JFFS_CUSTOM_PART and implemented
jffs2_part_info() so it points to RAM.

Someday it would be good (IMHO) to accept CFG_JFFS2_BASE and CFG_JFFS2_SIZE
as an alternative (even for NOR flash) to the sector/bank scheme
(CFG_JFFS2_FIRST_SECTOR, etc.).

Copying the NAND to RAM means each sector is only read from NAND once, which
is good since both reading the NAND and doing the ECC calculations can be
slow.

> The ideal case is to just allow the kernel to be part of the 
> filesytem, though I suppose it might not be strictly necessary and a 
> raw partition which ignores bad blocks might be enough....at the 
> moment I'm wondering
how
> one safely draw the lines of how big a partition would need to be at 
> the "physical" level to guarantee that your kernel will always fit, 
> assuming some of the blocks go bad over time.
 
If you use a separate boot partition very few blocks should wear out, since
they won't be written very often. The safest way to update the kernel is to
load the new kernel without deleting the old one, so if you allow twice the
largest possible size of your kernel plus 15 or 20 erase blocks for 
JFFS2 overhead and bad blocks, you should be OK. But NAND is cheap and
kernels grow, so I would allocate more if possible.

With the kernel in a larger partition with lots of files booting is slow,
since both reading the flash and sorting all of the file fragments take a
lot of time.

Dave

Dave Ellis
~~~~~~~~~~~~~~~~~~~~~~~~~~
SIXNET - "Leading the Industrial Ethernet Revolution"
331 Ushers Road,   P.O. Box 767, Clifton Park, NY 12065 USA
Tel +1 (518) 877-5173   Fax +1 (518) 877-8346
Email me at: dge at sixnetio.com 
Detailed product info: www.sixnetio.com 
~~~~~~~~~~~~~~~~~~~~~~~~~~

> -----Original Message-----
> From: Kenneth Johansson [mailto:kenneth.johansson at etx.ericsson.se] 
> Sent: Thursday, July 24, 2003 7:35 AM
> To: u-boot-users at lists.sourceforge.net
> Subject: [U-Boot-Users] [PATCH] jffs2 indirect access.
> 
> 
> This is a patch that alters the jffs2 code to work on flash 
> devices that is not directly memory mapped without the need 
> to copy the whole flash to RAM.
> 
> It is not ready for inclusion and I do not think I will push 
> it as it was quite a bit slower than I expected. It also 
> needs a little more cleanup.
> 
> A callback function is added to struct part_info that works 
> like memcpy and is the thing actually reading the flash. The 
> offset member is gone and the jffs2 code always uses 0 as the 
> start address for the filesystem. It is up to the callback 
> function to remap that into something useful.
> 
> This code however uses less memory than copying the flash to 
> ram but it is slower. jffs2_scan_empty() could use some 
> speedup but even in situations when that one is not taking 
> mush time this is slower by a factor of 2-3. It's only faster 
> if you happens to have ridiculously slow flash.
> 
> I'm going on vacation and is not going to work more on this 
> so if someone wants this added to u-boot you have to fix a 
> proper patch yourself. 
> 
> 
> -- 
> Kenneth Johansson	
> Ericsson AB                       Tel: +46 8 719 70 20
> Tellusborgsvägen  90              Fax: +46 8 719 29 45
> 126 25 Stockholm                  ken at switchboard.ericsson.se
>