[PATCH 0/3] Qi booting control from rootfs

Andy Green andy at openmoko.com
Tue Nov 25 08:46:00 CET 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| On Sun, Nov 23, 2008 at 9:44 PM, Andy Green <andy at openmoko.com> wrote:
|> These patches allow some control over Qi booting actions
|> from the rootfs containing the kernel being considered.
|>
|> /boot/noboot-<device>, eg, /boot/noboot-GTA02 if present
|> will force the rootfs to be not considered for booting.
|
| Hi...
|
| I didn't see this at first, but this change will make booting from
| anything but EXT2 (i.e. NAND for now) always fail...

Huh nice find, teach me to overload something called "read_file" like that.

| When trying to see if the noboot-<device> file exists, read_file()
| will always return >0 if the file system is NAND and the block read
| was ok and then skip the NAND partition...
|
| from phase2.c:
| 		/* does he want us to skip this? */
|
| 		if (read_file(this_board->noboot, kernel_dram, 512) >= 0) {
| 			puts("    (Skipping on finding ");
| 			puts(this_board->noboot);
| 			puts(")\n");
| 			this_kernel = &this_board->kernel_source[kernel++];
| 			continue;
| 		}
|
| I was thinking about making a quick patch (adding a condition
| "this_kernel->filesystem != FS_RAW"), but run in to the "problem" of
| making a good solution.. :/
| It's not nice to let the otherwise generic kernel loading code
| suddenly check which file system the kernel is on..
|
| Andy.. got any nice idé?

I think we can get around it for now by checking for NULL filepath name
if it's RAW and erroring out if non-NULL.  I don't want to implement
"U-Boot environment in NAND".

The real issue is that NAND is odd guy out having no filesystem
containing the kernel, so we can't either update kernel or piggyback
these attribute files into the same filesystem as the kernel in a
regular way.

The reason we ended up with this RAW system was purely length of time to
mount main jffs2 NAND rootfs to get at the kernel; we'd have to sit
through that in bootloader and then again when the kernel started.

What we could better do to normalize this situation is make the 8MB NAND
kernel partition / allocation a small jffs2 filesystem itself, add jffs2
parsing to Qi, but all GTA01 and GTA02 out there, and NOR U-Boot are
"set in their ways".

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkrrTgACgkQOjLpvpq7dMqpywCff/Y0wctV0KvOF43T4YcrZ5W/
ZDAAn0XDGwl3IWgFxF8ydct1TjhYq6Vr
=Nlas
-----END PGP SIGNATURE-----



More information about the openmoko-kernel mailing list