-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
>> I agree that if we define the bootloader as just a kernel loader, then >> the only legitimate settings in there would be directly to do with how >> to run the kernel. But isn't it a serious problem that we need a >> different kernel image to run from SD (root=mmcblk<n>p<m>...) in that >> case than from NAND? And then the kernels will only function when >> coming from a specific partition index on their specific media? > > In the worse case, we keep u-boot for development purposes, but devices > will ship with a minimal bootloader. If we had to still use U-Boot to do something serious we admitted defeat on the effort I think. Working on two kinds of bootloader is not a great idea. If it panned out like that we should just use U-Boot configured without any features. But I don't think it panned out like that. Werner pointed out later we can at least infer the device for root= and patch the commandline (since we know what device we are pulling the kernel image from). So we have a fixed kernel part index really which we could live with if also done by device (so it is always mmcblk0p1 and mtdblock3 for example). But then not having a soft commandline means we have to also fix the filesystem type and worse the init=. That is a bit of a cramp although we could live with it I suppose. Later we figured we could have a soft commandline (alone) in an "environment block" and get this flexibility. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFH4rvDOjLpvpq7dMoRAorLAJ9mro310ZX+4q5FMymtPc9TGhW86ACfX04J LdXyzHQZGKaw1LWi5MHwrvk= =KLqr -----END PGP SIGNATURE-----
