9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@9fans.net
Subject: Re: [9fans] ARM and u-boot
Date: Mon,  3 Jun 2013 09:19:26 -0400	[thread overview]
Message-ID: <2ef52570c9c6f8a5f541e1ab9465159e@brasstown.quanstro.net> (raw)
In-Reply-To: <d0105a56edac3bce2077e03b20bc05c3@hamnavoe.com>

On Mon Jun  3 06:42:31 EDT 2013, 9fans@hamnavoe.com wrote:
> > there's something just a little annoying about having a boot
> > loader that is much larger than the kernel than you're loading.
>
> Thanks to /dev/reboot you can alternatively use plan 9 itself
> as a loader, thus guaranteeing the loader is no bigger than
> the kernel.  I've found this useful when loading requires a
> bit of extra sophistication (eg booting over wifi).

unfortunately, as far as i know plan 9 can't be used as a primary
loader most of the environments where uboot is used because
we haven't written the (usually small) memory initialization code, etc.

i know using uboot has generally worked out, but ....
i recently worked on an arm project.  for some reason uboot
was used.  i thought this wouldn't be a problem, so left it alone.
as it turned out we had a few bugs that required messing with
uboot, and those were costly.  writing our own would have been
much cheeper.

to a lesser extent i see this problem on the pc.  the drivers needed
for boot are not necessarly the ones one is interesting in writing.
also, interacting with the bios drivers allows one to capture info
from bios like which nic was used to boot.  in our network this is
a massive time saver, since i never have to set ether0=type= any
more.  this is also how i've set up automatic usb / disk boot.

- erik



  reply	other threads:[~2013-06-03 13:19 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-01  7:19 tlaronde
2013-06-01  8:04 ` lucio
2013-06-01  9:30   ` tlaronde
2013-06-01 13:31 ` erik quanstrom
2013-06-01 15:02   ` tlaronde
2013-06-01 19:29   ` tlaronde
2013-06-01 22:10     ` erik quanstrom
2013-06-02  6:14       ` tlaronde
2013-06-02  4:06 ` Steven Stallion
2013-06-02  6:02   ` tlaronde
2013-06-02 13:09   ` erik quanstrom
2013-06-02 15:50     ` Richard Miller
2013-06-03  3:53       ` erik quanstrom
2013-06-03  4:29         ` Skip Tavakkolian
2013-06-03 10:35           ` Richard Miller
2013-06-03 12:34             ` Skip Tavakkolian
2013-06-03 16:58             ` Bakul Shah
2013-06-03 18:21               ` Richard Miller
2013-06-03 18:35                 ` Bakul Shah
2013-06-03 18:40                   ` Richard Miller
2013-06-03 10:41         ` Richard Miller
2013-06-03 13:19           ` erik quanstrom [this message]
2013-06-03 18:21             ` Steven Stallion
2013-06-03 18:43               ` erik quanstrom
2013-06-03 20:02                 ` Steven Stallion
2013-06-03 20:13                   ` erik quanstrom
2013-06-03 20:19                     ` erik quanstrom
2013-06-03  5:40     ` Steven Stallion

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2ef52570c9c6f8a5f541e1ab9465159e@brasstown.quanstro.net \
    --to=quanstro@quanstro.net \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).