-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: | Andy Green wrote: |> solution here is to continue to do that by default and abort that if AUX |> is seen during that time and go directly to backup kernel load. | | Okay, let's try this. If the fallback choice is always the same as | the "magic key" choice, there's also no problem if loading the default | fails very rapidly.
No need to "try" it, it will definitely solve this issue cleanly. Instead of loading the full kernel size in one call, Xiangfu can make a while() loop there loading 64KByte units for example, and inside the loop we check for AUX press. If seen we always abort the loop and jump to the last kernel source for the board, which is the backup one (and no longer look for AUX). |> I can't convince people that these commandline addons are not necessary, |> putting them into the rootfs is not the worst way. Although it means |> one less point to kexec... | | Rootfs also has the advantage that they travel with their kernel. | E.g., if you had an SD card with a kernel that tries something with | initrd, and your normal card that doesn't, it would be very | inconvenient if you had to change anything else when swapping cards. Agreed, what warmed me to it though is it gives the determinism back just from nuking rootfs on SD card. That's probably good enough that we drew the sting. But for NAND --> |> But I don't like the way it still requires management of raw partition |> in NAND case because we can't mount its rootfs. Kernel magic partition |> is bad enough. | | Hmm, I don't see any way how we could really avoid having at least | one partition, i.e., the point we say qi is never going to grow | beyond. No I meant after this pleasing talk of unification of kernel and commandline file under single rootfs, NAND leads to us having to handle raw type partitions for kernel and commandline separate from the rootfs. ~ Qi itself is mandated to be a raw partition by steppingstone action so there is really nothing to do there. |> We could reduce the size of GTA03 backup rootfs and |> go for mounting it jffs2 in Qi, then we unify the kernel location for |> NAND too into being inside rootfs. | | Heh, nice one :-) But are you sure you want to wrestle with JFFS2 ? | I thought you hated it too ;-) I just see it as more special pleading for NAND, it is "unusual file system". But, large NAND is currently a fact and then it means we ought to have fs for it that does wear levelling. By default that is going to be jffs2. |> GTA02 could follow all this really too and become SD-centric. | | That would be nice, yes. I think you've pretty much switched to an | SD-centric mode of operation already a while ago, haven't you ? | Does the system feel responsive enough ? All I can say is it feels the same, although I think Glamo MMC is actually slower than NAND a bit. Many other users now are booting SD for Debian and other rootfs and I didn't notice complaints about insane speed loss. So I think it is OK for customers. |> What happens if he put a bad thing in this commandline file... | | Just the same as putting a bad kernel. Of course, our users better | don't do that NAND kernel and command line upgrade while they're | having an emergency with their SD card(s) as well. | |> it seems clear that backup kernel itself should not have user modifiable |> commandline used to start it, there really is no reason for it anyway. | | Why create a special case where they have to supply the command | line at build time ? That kernel shouldn't even be special, so if | the command line is separate, you could just drop in a new one | from our daily build, and never even think about the command line. Huh? No Qi sythesizes a commandline anyway based on board and kernel source, so there's no special case. The synthesized commandline will continue to be what you get in the absence of the rootfs commandline file, and I expect we will not create a commandline file by default even. What I meant is that we do not want function of backup system to have dependency to anything it doesn't have to... there's zero legitimate case for end user to touch backup kernel commandline. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEUEARECAAYFAki0JXYACgkQOjLpvpq7dMpoJwCfZAODS9l7eBtS1VXtok5YqZ8D 1rYAmJI2HKI2ccCogEs9UY2IClz+a+Y= =lzbD -----END PGP SIGNATURE-----
