From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Mon, 3 Jun 2013 09:19:26 -0400 To: 9fans@9fans.net Message-ID: <2ef52570c9c6f8a5f541e1ab9465159e@brasstown.quanstro.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] ARM and u-boot Topicbox-Message-UUID: 61b6dd4c-ead8-11e9-9d60-3106f5b1d025 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