Bootloader

[Felipe Balbi]

On Wed, Mar 19, 2008 at 07:14:06PM +0000, Andy Green wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Somebody in the thread at some point said:
> > Andy Green wrote:
> >> and patch out any other junk that leaks in to get the
> >> same effect.
> > 
> > That gets messy very quickly. E.g., just look at cpu/arm920t/start.S
> > which, besides the storage driver, which only needs reading, is
> > about all the "difficult" code we can share. Most of the other
> > essential stuff, memory timing, GPIOs, PMU, PLL magic, etc., lives
> > in board/neo1973/.
> 
> Yeah.  I just saw grep only found s3c6400 because it was on the Linux
> list of machine types too.  I suppose any BSP can contain a U-Boot patch
> but I don't know what we will actually get.
> 
> The usual thing against building your own bootloader and "re-inventing
> the wheel" doesn't seem to apply here due to the reasoning of "getting
> rid of U-Boot" and discarding every single feature except the ones
> needed for pulling in and booting a kernel.
> 
> OK.  Here are some related points about this question.
> 
>  - If we have NAND back again, how are we going to manage the bad block
> stuff with this minimal bootloader? Can it end up we can't get away from
> U-Boot because of NAND or is it okay?

We can put some "intelligence" to let the bootloader handle that during
flashing.

>  - What about an environment?  U-Boot env seems to be a place where bugs
> can come from in terms of the same devices acting different.  But maybe
> we must allow kernel commandline customization pre-kernel.  If we start
> down that road maybe it should be U-Boot env.

I think we just change the kenrel commandline in the kernel and reflash
it.

-- 
Best Regards,

Felipe Balbi
me at felipebalbi.com
http://blog.felipebalbi.com