Bootloader

Felipe Balbi me at felipebalbi.com
Thu Mar 20 20:53:28 CET 2008


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
me at felipebalbi.com
http://blog.felipebalbi.com




More information about the openmoko-kernel mailing list