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

[luke.leighton]

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

>>   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.
>
> Ah. So on reflection, I choose UEFI simply because it was already in the
> conversation. It was not a very well thought out choice for my question.

 oh ok :)

> More generally then, and you've started to illuminate some of it, what
> is your road map? What minimum feature set from a boot perspective have
> you considered?

 well, given that CPU Cards basically have to act as stand-alone
computers, where you simply don't know what's going to happen next -
could be a laptop one minute, could be a desktop computer the next or
a HDTV Media Centre - as a general rule it's the CPU Card that needs
to be able to boot from internal memory that it carries with it....

 ... and as such, it's not really a consideration to boot from
*external* media, therefore, goes the logic, it's entirely up to the
implementor of that CPU card to basically do whatever they want!

 .... on the other hand, however, is the possibility that the sheer
number of variations in OS "shifts" will require the OS - in full or
in part - to be stored on external media (hard drive of the laptop for
example).

 and that's a bridge we'll cross when we come to it.

 now where it gets *really* interesting is when this becomes
sufficiently popular - especially when we get access to Intel 22nm and
below SoCs - that microsoft wants in on the game.

 in that case, it will definitely be microsoft crossing that bridge
when they get to it.

> (It's okay if this is 'I'll cross that bridge when I
> come to it' answer.)

 partly :)

> UEFI at least gives us a working model in which to ask the questions.
>
> I would like to see the day when I can buy one of these cards and it
> boots and I can have my USB DVD rom or PXE boot server on standby and
> it's just a handful of keyboard clicks away from starting an install of
> favourite distro X.
>
> So the more precise question is do you plan to support that kind of boot
> environment in future EMOA-68 products (regardless of what software is
> used to do it)? Step 5 implies to me 'yes, to some degree of yes'.

 our primary focus is to sell as many CPU Cards and products as
possible, such that there is cheap commodity hardware available which
*you*, as a free software developer, had a hand in and were given the
opportunity (even if you didn't take it) right at the start, so that
the moment the products hit the shelves you know that there's a
community surrounding the CPU Card where those kinds of things are
being done day-in, day-out.

 if "PXE boot serving" fits into one of those mass-volume sales
opportunities, we'll do it - immediately.  heck, if selling lots of
CPU Cards makes a data centre more efficient then that might actually
even really happen.

 so there's nothing to stop *you* from replacing the OS with something
like that, and it'd be nice to think that we'd have enough funds to do
random research projects that are of interest to [relatively!!!]
smaller groups of free software developers, but things like that
*have* to be driven by "will this help make a MOQ 10k, 100k or 500k
order?"

> Clearly the A10 card once simple out of the necessity of bootstrapping.
>
> I see this issue gets a lot easier since as being at the OEM you can
> dictate the firmware/bios/uboot as you like. The buses are discoverable,
> severally limiting the "wonky" design choices down to reusable drivers
> for the I/O boards and quarantined uniqueness within the card which can
> be hidden by said dictated boot code.

 ... or it's isolated behind the EOMA-68 interface, the CPU Card works
across multiple products, so in effect why would you care if it had
something slightly "wonky" or a small spanner in the works.  as long
as it's EOMA-68 compliant and solves the huuuge issue of hardware
diversity at the right level - hardware level - i'll be hugely happy.
 anything else would be a bonus.

l.