Fwd: Hello -- NAND/NOR Flash design for GTA02

Neng-Yu Tu (Tony Tu) tony_tu at fic.com.tw
Fri Jan 11 15:01:26 CET 2008

> > I think we should consider early boot into smaller than 32 MB as target,
> > only for GTA02 release, but also we do not need 32 MB data/apps during
> > ;)
> Currently we use 45MB of the rootfs.  Also with JFFS2 it writes it and
> later compresses it AIUI, you need some free space or things go very
> slowly or not at all when you try to fill it.  So we will need some
> headroom over what the actual compressed final footprint is.

Yes, but I remember initial GTA01 image is about 27 MB, and without any new
function added, now already 45 MB.

> > Well, I thing Werer really got something during hxd8 war :) Maybe he
> > also consider mount different type of file system then.
> >
> > 5% is too easy for Werner, I would say save 80% current time is ideal
> > challenge for Werner ;)
> Excellent then :-)  Mickey would like to see yaffs in there instead
> which doesn't have the slow behaviour -- but it doesn't have compression
> either (there's probably a way around that).
> http://www.yaffs.net/comparison-between-yaffs-yaffs2-and-jffs2

If I remember correct, yaffs has some loyalty if embedded within products.
It is free if use as end user, but not free for commercial products.

Werner has done yaffs integrate before, he knows much detail than I am :)

> Either way we need to do whatever we are doing in the next week, and if
> we don't do anything else for some reason, we will need to be doing the
> JFFS2/split method.  I'll be super happy not to have to do it because
> Werner gave a magic solution.

Well, we might need to provide more chocolate to burst his idea.

> >> If we go that way, we need to consider the impact on packaging paths.
> >> Probably we should leave all the packages to point where they are, and
> >> have /usr and so on in the "early boot" partition.  Then other packages
> >> should place stuff in something like /opt or /usr/local which is
> >> or mounted --bind to the second, larger partition.
> >>
> >
> > I think this way might affect _installer_ design, if want to install
> > want to start during boot, this might be potential constraint for app
> > developer.
> It's just a packaging issue.  If the package wants to deliver an
> initscript that depends on the larger partition being mounted, it will
> be able to block in the background until the partition is mounted.
> Apparently we move to upstart for initscripts which allows expression of
> initscript dependency and parallel execution, it has a
> "block-device-added" event that fits this situation.
> http://www.linux.com/articles/57213

Hmm, it recall me some device virtual machine idea from some company for
some device/notebook.

Tony Tu

> - -Andy
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> iD8DBQFHh20uOjLpvpq7dMoRAhiPAJ9CXlhQ0Eym5NkT36bGQqxDy+N01wCdG
> MsN
> qobJLAfYP//2CzzUGClKyDA=
> =K3Ni

More information about the openmoko-kernel mailing list