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