Bootloader

[robert lazarski]

On Thu, Mar 20, 2008 at 6:42 PM, Andy Green <andy at openmoko.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Somebody in the thread at some point said:
> > On Thu, Mar 20, 2008 at 4:21 PM, Andy Green <andy at openmoko.com> wrote:
>  >> -----BEGIN PGP SIGNED MESSAGE-----
>  >>  Hash: SHA1
>  >
>  > At least the way I use drivers in bootloaders and in u-boot in
>  > particular is to validate the hardware without a kernel. Once a
>
>  Understood, and it is not a crazy way.
>
>
>  > Memory is arguably the most tricky part in
>  > bringing up an OS and something that the kernel expects to be ready to
>  > go, and u-boot 's community and code is a good asset here.
>
>  We will hopefully get handed working bootup code to set this up tailored
>  by the vendor to the on-chip memory.  So we can reasonably expect that
>  part to not be too tricky for us.
>

I'd like the ability to debug it if I had to or wanted to, get all the
SPD info out, single step thru u-boot relocation - where most memory
problems occur - etc. Under certain kernel loads, burst mode issues
may pop up over new hardware and I'd like to have something powerful
to explore them. The idea IMHO of openmoko is to provide hardware that
can be debugged and fixed when needed with software. u-boot can do a
good job of making that process easier, since a lot of people use it.
IOW, its new hardware that's hackable, could have problems in the
first batch, and I want to hack it.

>  If the prototypes need U-Boot to get straightened out, we will use it
>  until it is straightened out and hopefully replace it with a minimal
>  version of our own or if that plan breaks for some reason, a forced
>  minimal configure of U-Boot.
>

A "minimal version of our own" is something up to you. What I'm
advocating is that u-boot is more mature and well known and therefore
easier to follow, but that's just my .02 brazilian cents.

>
>  >>  > And you're right, we could write a dozen of minimal bootloaders by the
>  >>  > same time we spend fixing/maintaining u-boot.
>  >>
>  >>  Well if U-Boot already came patched and working, to start with it would
>  >>  be quicker to use it.  But I prefer to get rid of it.
>  >
>  > By getting rid of u-boot you'd IMHO be losing one of the attractions
>  > to openmoko: a low barrier to-entry hackable device. In my case I'm a
>
>  No I don't see that at all.  What we will be doing is providing one
>  common OS for the hackability: Linux[1].  You're not saying that the
>  Linux kernel is "not hackable", right?

I'm saying its easier to hack the kernel from u-boot because you can
establish a well understood starting point with proven working
hardware, something the u-boot shell can do via looking into all the
standard info available, protocols, buses etc. If you can't boot the
kernel while porting a new version, u-boot can help quite alot.  Its
quite popular to port u-boot first to your hardware before the kernel
and there's a reason for that - code reuse and a community.

>
>  I appreciate what U-Boot has done for me over the years including on
>  GTA02, but I see U-Boot as fundamentally a wannabe Linux, it is
>  constantly bloating out with travesty-dumbed-down-drivers from Linux,
>  adding faux APIs from Linux and generally wanting to be Linux when it
>  grows up.  Let's just go straight to full-on Linux and get ALL the
>  drivers full strength with just one tree and API set for us to maintain.
>

Lets just agree to disagree here, as I doubt we'll change each others minds ;-)
<snip>

>  > contributor to u-boot, knows how it works a bit, and am looking
>  > forward to hacking it on openmoko. Writing your own bootloader or
>
>  You can stick U-Boot on whatever we do if you want.  I suspect we might
>  find that Samsung give us U-Boot patches in which case you should be
>  away real easy and I am sure we would make patches available.  And as I
>  said if we can benefit to bring up prototypes and so on we won't
>  hesitate to use it either.  Just we would rather not ship and maintain it.
>
>  - -Andy

We'll I'll have to start from somewhere, and its either new code
you'll "ship and maintain" which seems so far to me as an
unconventional way of doing things, or use something that is well
understood and supported like u-boot. I guess I'll wait until the
hardware gets in my hand to find out. I'm not sure I'll follow what
you're going to do, but I wish you luck.

Interestingly, I just talked to some people at the bossa conference
who implied that u-boot was in openmoko's future, so maybe some more
people will comment when they get back online.

Cheers,
Robert