On Fri, 22 Feb 2013, Miod Vallat wrote:
Date: Fri, 22 Feb 2013 21:27:50 +0000
From: Miod Vallat <m...@online.fr>
To: max stalnaker <max.stalna...@gmail.com>
Cc: Laurence Rochfort <laurence.rochf...@gmail.com>, arm@openbsd.org
Subject: Re: Any platform useful as a graphical desktop?
Related question
Ok, I'll bite, but don't take it personnaly.
There are thousands arm-based designs available today. Every one of them
tries to be better than the others in at least one area.
But none of their manufacturer address the real problem.
The problem is that all those ARM designs lack a non-braindead, usable,
firmware interface.
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.
Compare this to the PowerPC or SPARC world, where every decent system
can expect to have an OpenFirmware interface.
A good thing IMHO. I believe that the FreeBSD boot process still uses
FICL, a forth interpreter which I believe was inspired by OpenFirmware.
The OpenBSD ports to the various arm devices have been trying to cover
the devices developers were interested in first (i.e. zaurus), and then
the devices developers *expected* to be more commonly encountered (i.e.
armish).
Were Open, and indeed *ALL* the 'BSDs to adopt a similar OpenFirmware
interface on ALL embedded, it would provide the impetus to move to a
device tree model regardless of architecture. Essentially, one need
simply define the SoC and on board devices of a new target board within
the device tree, and the drivers would find registers. Drivers could be
largely platform agnostic (at least to the extent that they can be), and
even shared between OSes (licensing issues aside).
Do you get the feeling that I like the device tree approach??
The second part turns out to be a huge farce. A few new ARM board
designs appear everyday, and these new devices amazingly manage to be
gratuitously incompatible, firmwarewise, with all the existing devices.
This is a sick game OpenBSD developers do not want to play.
If ARM wants to exist as a *platform* (as opposed to a `source of
gimmicks which gets replaced every two years without any concern for the
obsolete ones'), it needs to be more than just a cpu design.
Given that Arm is fabless, perhaps *THEY* should be the ones to drive a
vendor agnostic boot platform??
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
- DOCUMENT the fdt tree for a few reference designs
- produce OF drivers
- stand back and see that it is good!
Do you think the x86 processors would have been so successful without
every x86 vendor working hard to provide an IBM-compatible BIOS?
And do not expect the upcoming 64-bit ARM chips (AArch64) to fix this.
None of the ARM vendors want to use a common firmware interface, because
none of them wants fair competition. A captive customer is worth so much
more than a customer with a choice.
In the embedded Linux world, I'm seeing some multi-vendor convergence upon
the Yocto project (Freescale/Mentor/WindRiver) for BSPs. Perhaps U-Boot's
support for OF on PowerPC can be leveraged into an ARM based initiative
for BSD?
ARM is about to become the PC of the 21st century, with a minor tweak.
The PC world was `closed mind, crap architecture, high
interoperability', while the ARM world is becoming `closed mind,
not-so-crap-and-becoming-decent architecture, who cares about
interoperability'.
Miod
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-).
Cheers,
Rob.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=
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
