On Mon, Nov 4, 2013 at 7:16 PM, Aaron J. Seigo aseigo@kde.org wrote:
On Monday, November 4, 2013 14:04:43 Christopher Havel wrote:
I was under the impression that the EEPROM served to fix the autoprobe issue -- that is, to identify what devices and capabilities were present on the MEB (or any other 'carrier board') and tell the OS about it.
there are two possible approaches here. one is a "cooperative" approach - the OS is aware and adapts. the other is a Virtual Machine approach (lxc, xen, other). each guest OS is brought up as-and-when depending on the type of underlying hardware.
last resort - reboot. this would be generally bad.
Was I mistaken...?
well yes, if you want to be able to bring up all devices on a random application board then getting to the EEPROM will be necessary, though that will hopefully also be handled by provided tools (bootloader, etc.). i’d hate to see that have to be adapted to for every target OS one by one :/
eventually that's what will be needed. there are ways to cope in the meantime. KDE / Plasma is by far and above the furthest along of all the software-libre eco systems that will handle the radical changes of screen and hardware.
even then, if you don’t care to be able to see every device automatically, you don’t even need that. we’ve obviously all been working with EOMA68 boards with that so far, right?
what you are limited to are things like USB devices and the rest has to be hand-configured.
RGB/TTL, gpio, i2c - all of those will need (by way of the EOMA68 EEPROM) to be "turned into" discoverable udev-event-driven "buses", giving them auto-discoverability just like USB, SATA and Ethernet have automatic hotplugging.
l.