[Arm-netbook] device tree not the answer in the ARM world

[luke.leighton]

On Mon, May 6, 2013 at 7:55 PM, Scott Sullivan <scott at ss.org> wrote:

> Even in this case your citing the 'optional' third party firmware as
> 'see it can be done'. That's been known along time now, but until it
> ships in products in mass volume, and is profitable, the burden of
> making this crap bearable will always been on the shoulder of the open
> source community. We will continue to be ever in 'catch up' mode.

 .. which is a situation that i'm fed up of seeing.  massive amounts
of free software resources completely and utterly wasted, to the
benefit of corporations who don't even both to say "thank you", just
take take take.

 imagine what could be done if those resources were focussed instead
on something that they knew was going to go out in a few months to
millions of people, because they'd actually been *asked*, "scuse me
would you like to do some work on linux kernel drivers for a product
that's going to be sold in mass-volume soon?"

 which reminds me - i have to ask.

> Luke,

 ya.

> Question for you.

 ya.

>  Assuming down the road after the first (or even
> second) EMOA-68 card is being sold, would you dedicate resources to
> tackling a UEFI boot environment for future cards? The iMX6 care sounds
> like a candidate if it already has it as you say.

 *deep breath*.  hadn't considered the question before now.  let me
think it logically through.  what's the priority order:

 1) find a SoC where we know it's going to competitively sell in mass-volume.
 2) find a way to get through the "pain" barrier of allowing us access
to it [this will get easier, once there are sales underway].
 3) stop if they want us to sign GPL-violating NDAs, and go back to 1)
if they do.
 4) get hold of hardware schematics.  or find a way to get them at a
reasonable cost.  if not possible, go back to 1)
 5) modify the linux kernel for that SoC to get it to support the EOMA
libs and drivers [this will get easier once there is at least two
completely different SoCs, preferably with completely different
instruction sets]

 so, scott: against that background of tasks, what benefits would "6)
add a UEFI boot environment" add to that list of priorities?  would it
*have* to be added, because you could reasonably expect some SATA
drives to be formatted as UEFI partitions because they'd been made by
e.g. an x86 EOMA-68 CPU Card's OS.

l.