On Tue, Apr 17, 2018 at 11:12 PM, Richard Wilbur richard.wilbur@gmail.com wrote:
I understand that people have been working on steps 2 and 4 for years and I had no diminution of their efforts in mind.
absolutely.
In my estimation the tasks that can be completed relatively quickly are 1 and 3 as they don't require convincing anyone else of the importance of the goal or merit of the implementation.
it is slightly more complex (3 that is) because a library and associated linux kernel device-driver has to also be written that reads from the I2C EEPROM (to be added to both u-boot and the linux kernel), in order to use the devicetree fragment merging... overlay! that's what it's called.
it is *not* going to be okay to just blop in one devicetree file for eoma68-a20-with-microdesktop, one devicetree file for eoma68-rk3288-with-microdesktop, one devicetree file for eoma68-a20-with-laptop-housing, one devicetree file for eoma68-rk3288-with-laptop-housing etc. etc.
preventing that kind of insane O(N * M) devicetree proliferation and reducing it down to O(N + M) *IS* the entire point of the EOMA68 initiative.
l.