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. 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 :/
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. and of course that is only applicable to the application board: what is on the EOMA68 card itself is well documented. so not the end of the world...
putting the (non-autodiscoverable) device tree on the EEPROM is just to remove the hand-configuration process. but it is not required to getting an OS on one of the EOMA68 cards.