On Thu, Mar 20, 2008 at 07:32:19PM +0000, Andy Green wrote: > -----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.
yeah, i was following the thread. And I agree with you, working on 2 bootloaders will be too much :-s -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com
