From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <2b4a6ce59f768eb51d6df3d9024427a6@ladd.quanstro.net> References: <2ef52570c9c6f8a5f541e1ab9465159e@brasstown.quanstro.net> <2b4a6ce59f768eb51d6df3d9024427a6@ladd.quanstro.net> Date: Mon, 3 Jun 2013 13:02:05 -0700 Message-ID: From: Steven Stallion To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=047d7b16014151b55504de45706c Subject: Re: [9fans] ARM and u-boot Topicbox-Message-UUID: 62c5ca72-ead8-11e9-9d60-3106f5b1d025 --047d7b16014151b55504de45706c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Jun 3, 2013 at 11:43 AM, erik quanstrom wrot= e: > > 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=97 > 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 --047d7b16014151b55504de45706c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 3, 2013 at 11:43 AM, erik quanstrom <qua= nstro@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. =A0what are the secure loaders assuming?
=

I have no idea - those I've dealt with were a= lways delivered as a binary image with little to no instruction. Presumably= there is an assumption that the second stage loader is located at some off= set 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'l= l 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=97
until u-boot didn't cover my needs and i had to fix
u-boot. =A0i had to eat my words.=A0

u-boot is really terrible to work with. =A0there is no
danger of writing something that looks like u-boot. =A0:-)
but if u-boot works out of the box, i would totally agree,
why not use it? =A0but don't fall for the trap of modifying
it. =A0that's a terrible waste. =A0instead 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 c= ode base is fairly common for most Linux-like projects. The code was consis= tent, and well documented. As far as setting up the hardware, it's cert= ainly 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=A0necessity. As engineers = (and hobbyists to some degree) we all tend to suffer from NIH. Decisions th= at some see as "mistakes" usually have a good reason for coming t= o being. Exitus acta probat, I suppose.

Cheers,

Steve
--047d7b16014151b55504de45706c--