On Mon, Jun 3, 2013 at 11:43 AM, erik quanstrom <quanstro@quanstro.net> wrote:
> It's more than that. Many board vendors will use a secured stage 1
> bootloader that assumes U-Boot. It's probably possible to shove in a

good point.  what are the secure loaders assuming?

I have no idea - those I've dealt with were always delivered as a binary image with little to no instruction. Presumably there is an assumption that the second stage loader is located at some offset at a minimum. We could work backward from the second stage loader if we had a mind to.

> Every SoC is going to have a different process - in the end, you'll have
> something that will probably look quite a bit like U-Boot without any real
> benefit. I'd rather tilt at other windmills...

that was my opinion, and i argued it pretty loudly—
until u-boot didn't cover my needs and i had to fix
u-boot.  i had to eat my words. 

u-boot is really terrible to work with.  there is no
danger of writing something that looks like u-boot.  :-)
but if u-boot works out of the box, i would totally agree,
why not use it?  but don't fall for the trap of modifying
it.  that's a terrible waste.  instead of learning about the
internals of u-boot, you could spend time learning how
the hardware in hand is really set up.

Really? I've had very little problem with modifying U-Boot - the code base is fairly common for most Linux-like projects. The code was consistent, and well documented. As far as setting up the hardware, it's certainly interesting, but of small utility in the grand scheme of things.

I think it's important to remember that U-Boot (and many other projects) all came into being out of necessity. As engineers (and hobbyists to some degree) we all tend to suffer from NIH. Decisions that some see as "mistakes" usually have a good reason for coming to being. Exitus acta probat, I suppose.

Cheers,

Steve