JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slo w:(

[Jonas Holmberg]

> Currently we have to scan the whole thing on startup because we know 
> nothing about its state. By occasionally writing a checkpoint 
> - a brain 
> dump of the jffs2 code's internal state, we can speed up the mount.
> 
> You'd only ever write a checkpoint at the beginning of an 
> erase block. 
> The mount code would look at the beginning of each block, and 
> would note 
> the most recent checkpoint. It can suck in the state from 
> that checkpoint 
> and then go on to read every node in the blocks which were 
> written _after_ 
> that checkpoint.

I get it, thanks.

> Not really. Why not just upgrade bootloader and jffs2 fs 
> using two separate 
> character devices?

Two reasons:

1. To be able to write to both devices the partitions must start on eraseblock
block boundary. The bootloader I would use with this configuration is less than
10kB and my eraseblocks are 64kB. I would waste to much space on the loader
partition.

2. I would like to keep my old partitioning so I don't have to change the way
upgrade works. And right now I have a partitiontable, bootloader, compressed
kernel and cramfs-image all on the same mtd partition. And mtd is only used for
upgrading the whole lot on that partition.

I would like to put the contents of the cramfs partition and the kernel in a
jffs2 fs instead and modify the bootloader so that it can find the kernel
in the jffs2 fs. And still have the partitiontable and the bootloader at the
beginning of the partition. I was hoping that jffs2 would treat the partition
table and bootloader as garbage and just ignore it.

/Jonas