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

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

[Kenneth Johansson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jffs2.diff
Type: text/x-patch
Size: 24509 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20030724/12f8e620/attachment.bin 

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

[Wolfgang Denk]

Dear Kenneth,

in message <1059050105.31114.89.camel@spawn> you wrote:
> 
> 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.

OK, just for the record: I will NOT merge this patch into the  public
tree. Please let me know when you decide otherwise.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"Wish not to seem, but to be, the best."                  - Aeschylus

[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
> 

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

[Kenneth Johansson]

On Thu, 2003-07-24 at 16:20, Woodruff, Richard wrote:
> 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.

Yes when you have NAND flash an extra partition or two is not going to
cost you much. And when you are using NOR flash you probably is going to
have a lot more DRAM than flash anyway.

I should mention that most of the work on this patch was done by a
summer intern named Michal Cendrowski I just dotted the i's and crossed
the t's well actually I freed the mallocs and moved some things out of
loops.

It should be possible to change the code in a why that makes it a
compile time option to use the callback function or directly map the
filesystem. I think that would be the only acceptable change as the
overhead otherwise is just to large for situations when copying the
whole thing is not a problem.

hmm That should almost be possible now just changing the jffs2copy
macro.

-- 
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