-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: | On Sunday, 3. August 2008 04:33:11 Andy Green wrote: |> Liek so much else, that's just waiting on someone saying DO IT. What |> else is it waiting on precisely? | | Correct me if I'm wrong: | Our booting process is a bit complicated - we have this dynamic table of bad | blocks, some uboot partitions, a kernel partition and root fs partition.
Linux can blow through all this, nand_write is the magic ingredient. There is NOTHING stopping a single package for monolithic kernel and modules. | It would be nice to have _one_ image for (at least) the kernel and the rootfs. | Your config change affects a vital part of the debug tools of the system | because it is easy to break. Simply flash a new kernel (without knowing that | the ethernet does not work anymore!) and big suprise ... Yeah, but that is a packaging issue, not a config change issue. The kernel package could easily have gone out with a REQUIRES for the new module packages pulling them in automatically. I do not control that. | In the long run it would be even handier to have only one partition for all | the interesting stuff which affect the boot (I don't know to what extend that | would be possible). Changing uboot options, getting a new uboot, changing | images, etc would be much easier ... In the very long run this will happen. In the merely "long run" with U-Boot it ain't gonna happen. |> Really? Well, I guess you never tried mounting what we had before as a |> block device, echoing something into it as a tty, printing to it, as we |> can now either. | | Well, that is not exactly the same thing ... Just saying you are not considering the whole picture. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiU0rUACgkQOjLpvpq7dMp4DQCfV8OyOXRb5u2Kz05JAp65t1Na qzUAnjGF6Qtmyu6i9ZU53lLDuIk6278t =Lrms -----END PGP SIGNATURE----- _______________________________________________ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support