On Fri, 22 Feb 2013, Miod Vallat wrote:
Date: Fri, 22 Feb 2013 22:27:58 +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?
Every ARM gimmick you can find over the last 10 years runs either
a custom configuration of RedBoot, or a custom configuration of U-Boot,
or something different. There is no way to write a design-agnostic
kernel which will be able to figure out its environment (firmware,
configuration data, devices). Passing an FDT file to describe the
devices is not an option, because there is no well-defined way to pass
arguments to the kernel, due to all these conflicting and/or subtly
incompatible firmwares.
Actually, FDT's have a specific node which is used to pass argments
to the kernel, and arbitrary values are simple to pass via the
device tree. U-Boot in particular has FDT editing capabilities which
allow a run-time change to the kernel params via the FDT from the
console.
But how do you pass an FDT to the kernel? Oh, that's easy, it's at
0xff000000. Unless it's at 0xf0000000, that is. Which it is, except when
it's at 0xf800f000. But did I mention it might reside at 0xfd000000?
When it's not at 0xe2000000 of course, but you knew this because it was
not at 0xc2001000. Or was it?
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.
Given that Arm is fabless, perhaps *THEY* should be the ones to
drive a vendor agnostic boot platform??
Let me tell you a secret. But please don't tell anyone.
THEY FSCKING DON'T CARE!
...because either way they'll sell their ugly chip anyway.
They do risk being spoiled by their own success ... OK ... everyone drop
arm, and go to MIPS -- immediately! 8-)
My latest experience in the PowerPC (Firmware/board bringup for a
new P4080/FPGA design) world was a positive one, and the key to this
is simple:
- Adopt OpenFirmware
This item currently does not fit the ARM world. Convince them to adopt
sane standards and you'll be my hero (for at least a whole year).
Your perspective has more than a granule of truth to it. I know it
resonates for me, and I'd love to see the BSD's (all of them) band
together to solve the problem 8-).
BSD bonding together? Even for something which would benefit them?
You're smoking way too much weed.
Miod
Given that a single device tree, describing a target board could be used
by each of the 3 distros, they could share OF drivers and trivially
support new targets ... yup. You're right, it is not compelling enough to
get Theo and the other kids to play nicely.
Oh well.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=
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