On Fri, 22 Feb 2013, Miod Vallat wrote:
Date: Fri, 22 Feb 2013 22:48:47 +0000
From: Miod Vallat <m...@online.fr>
To: Rob Sciuk <r...@controlq.com>
Cc: arm@openbsd.org
Subject: Re: Any platform useful as a graphical desktop?
I used the tftp/bootp protocol to load the kernel, the initrd and
the fdt into RAM from u-boot (the auto-boot), and then pass the
three addresses (fixed) to the bootm command in order: bootm
0x100000 0x200000 0x3000000. Of course, I had to extend the BOOTP
protocol with an OEM extension to allow Bootp to know about the FDT,
but that facility was already in U-Boot -- you simply need to look.
So you had to extend an RFC protocol to boot some form of Linux. Sure,
that's the way thing go - I'm gonna fix my bootp server right now to
support the wicked way Linux on ARM does things, just so that I get a
thin chance for a kernel to recognize the world it's running in.
Am I the only one to think that we are trying to walk on our heads where
the way to boot a kernel is to chainsaw a good-old-comes-with-an-RFC
protocol to the greedy needs of a particular operating system?
They do risk being spoiled by their own success ... OK ... everyone
drop arm, and go to MIPS -- immediately! 8-)
I'd drink to that.
If you are serious about changing your dhcpd configuration, here at least
is the .conf file for dhcpd -- or a segment of it, which demonstrates the
mechanism I used:
option boot-device-tree code 132 = text ;
option boot-file-system code 133 = text ;
# hotwire1 boards
#
class "hotwire1" {
match if substring( dhcp-client-identifier, 0, 9 ) = "hotwire1_" ;
filename "hotwire1.uImage" ;
option boot-device-tree "hotwire1.fdt" ;
option boot-file-system "hotwire1.initrd" ;
}
I would have to dig to find the u-boot code to extend the protocol, but it
wasn't too difficult ...
Cheers,
Rob Sciuk
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=
Robert S. Sciuk http://www.controlq.com 259 Simcoe St. S.
Control-Q Research tel: 905.706.1354 Oshawa, Ont.
r...@controlq.com Canada, L1H 4H3
