Bootloader

Andy Green andy at openmoko.com
Fri Mar 21 09:51:17 CET 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

>>  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.

U-Boot suggests a particular way of doing things and it is easy to get
hung up on that.  For example DFU-ing stuff about is great, but it is
just one way to get the actual functionality that is interesting.

Step back a minute and spectate upon yourself "hacking U-Boot" in a
shimmering future (not on GTA02)... say you recook it and for whatever
reason it is broken and you brick your box.  U-Boot is not going to help
you any further, right?  In fact the ultimate hacking tool and insurance
at this low level is not U-Boot but JTAG.

We plan to provide "debug board" functionality on the main board one way
or another including JTAG so you can overwrite the bootloader from there.

So if you want to meddle with memory timings or whatever in the
bootloader, U-Boot or not, you are going to be able to with just
software on a standard device and with a get out of jail card.  And that
is *increasing* the hackability of the device, since meddling with or
even updating the bootloader is something most people are reasonably a
bit scared of when they don't have JTAG to magic them out of trouble.

>>  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.

Wah you could at least spend 2 whole cents on it :-)

I had three moments where I took against U-Boot in this product.

First was when I saw many not really maintained features (hey try
"neo1973 gsm version" in GTA02 U-Boot) added into U-Boot for test that
would then be duplicated in Linux, but not removed from U-Boot.  I said
to myself, we should do all this in Linux.

Second was when I looked at the code in U-Boot and what goes in there.
I described before how U-Boot is like a sinful Ibiza where the normally
upright folk throw off their workaday restraint and quality rule
following and "just do it" with whatever is at hand.

Third was when I had to cut and paste the SD driver from Linux with its
layered MCI stuff to U-Boot (and the Glamo framebuffer) and had to dumb
it down badly and provide my own SD protocol action in there, and I saw
it would not be maintained properly, we had two copies of the same
drivers.  Well, we need the SD driver in the minimal bootloader, but
that is it.

>>  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.

U-Boot is not the only way to get that functionality, do not forget
there is a backup kernel and entirely separate backup rootfs you can
boot into, look into /proc for *really* "standard info available".  It
will always ship with a definitely working kernel to fall back on.

> 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

"Unconventional" itself is neutral, the whole product is definitively
"unconventional".

> 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.

Yep Harald likes U-Boot and explained that if we don't have it we are
Linux-centric not-very-Free folk.  Please have a look at this subthread

http://www.mail-archive.com/openmoko-kernel%40lists.openmoko.org/msg00891.html

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFH43cFOjLpvpq7dMoRAs/4AJsEtZ3OUYOpHgXcdXqXHu4xf0OY0QCeO/eO
473hOll8+2opN6qqQSvk7MM=
=+/d9
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list