Current Bootchart / breaking SD boot
Carsten Haitzler (The Rasterman)
raster at openmoko.org
Tue Jul 8 20:35:52 CEST 2008
On Tue, 08 Jul 2008 18:45:33 +0100 Andy Green <andy at openmoko.com> babbled:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Somebody in the thread at some point said:
> |> Otherwise sounds fine to make it a module. You can't use NFS rootfs on
> |> it AFAIK due to needing association sorted out first, that was the only
> |> reason I could think to keep it in monolithic kernel for normal use.
> | imho everything we can make a module - should be. sd card drivers, all fs
> | handling other than jffs2, sysfs and procfs, wifi, etc. etc.
> | yes - you can't boot the sd kernel off sd card then with rootfs
> there, but
> | root on sd is not something our production systems need. we can change the
> | packaging to build 2 kernels, 1 modular, 1 monolithic for kernel devs to
> | quickly test things with.
> That doesn't make any sense, SD card boot is really valuable and even
> appears in the U-Boot menu, what's the point of breaking it? SD Card
> boot is very nice for customers and definitely not some weird low level
1. we dont ship with that uboot menu - or we shouldnt be. the uboot env i know
we ship waits 3 seconds then just boots.
2. if users really want it they can use the monolithic kernel. thats why i said
we build different images. one that is streamlined for fast boot - everything is
a module where we can manage it to avoid having to wait for things like sdio
init, wlan init etc. before even starting to run userspace init.
3. why is it nice? seriously how may customers do u expect to boot off sd card.
i have in fact never booted off sd card for example. i know some people do -
like you, thus provide images for them that can do it - for the rest, move sd
to a module.
remember i said to build DIFFERENT images. one i suggested was
"monolithic" (everything there as we have it now) and another where everything
we can put into a module is one. that does include sdio...
> For example, customers can choose to give community builds a test run
> like that without nuking the NAND with it. Of course it should not be
> broken in normal builds.
> - -Andy
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> -----END PGP SIGNATURE-----
Carsten Haitzler (The Rasterman) <raster at openmoko.org>
More information about the openmoko-devel