On Mon, Dec 16, 2013 at 11:34 AM, Marco Martin notmart@gmail.com wrote:
Hi all,
I would like to upstream the script.fex file (or the files?) for the eoma68 into https://github.com/linux-sunxi/sunxi-boards
my fex at the moment is: https://github.com/notmart/sunxi-boards/blob/master/sys_config/a20/eoma68_a2...
that seems to work correctly.
however I'll forward some comments on it that were made on the linux-sunxi irc channel (oliv3r that i think he maintains the sunxi-boards repo):
it has enabled several things that aren't available on the improv (wifi, touchscreen on i2c.so, enabled cameras) basically boils down to try to do a fex file that catches all the possible feature boards vs one fex file per feature board. Not knowing a lot about this in particular I can pretty much just refer what i was told and let you guys decide how we want the fex file, or the multiple fex files that would end up in that repository (at least i think it makes sense to put everything in that place)
marco: there's some... shall we say... eeenteresting issues raised by the nature of EOMA modular standards, in fact any on-demand user-swappable modules (of which EOMA68 really seems to be the only one)
the bottom line is that, really, *no* fex file may be "upstreamed" until there is infrastructure in place to deal with the dynamic modular nature of EOMA/EOMA68.
to catch "all possible feature boards" is flat-out impossible, and is completely against the direction that's been planned all along.
what's been planned is to use the EOMA68-compliance I2C EEPROM - the decision was taken to store device-tree "snippets" - and for those "snippets" to be stitched together along-side a "base" device-tree file. that "base" device-tree file *could* (and should) be upstreamed. the "snippets" likewise, in the extremely likely event that "feature boards" themselves are also upstreamed. but combining the two types (base and snippets) and hoping for the best is NOT on the table for discussion.
although it was considered, i am very, very reluctant to permit fex files to become part of the EOMA68 standard. i say that in pre-emption of any suggestion to instead permit storage of fex-file "snippets" in the EOMA68 compliance EEPROM, because once that decision is made, then *all* present and future EOMA68 CPU Cards *must* be capable of interpreting fex files, now and forever.
the other option would be to gateway script.fex into device-tree. however, the views of various contributors on the linux kernel mailing list regarding script.fex has been made explicitly clear. in one instance by attempting to illegally mass-mail-bomb my email account by making unauthorised use of 3rd party mailing list services to subscribe my email address several thousand times.
so the question becomes: which is more work - to convert all sunxi code over to device-tree (in the hope that future CPU Cards will also comply)? or is it more work to add - and maintain (in a non-upstream fashion) a script.fex'd array of linux kernels, of which the EOMA68-A20 will be the only one that will be "easy" in the immediate future, and where all other CPU Cards will need to be both "script.fex'd" and then maintained *outside* of the linux kernel infrastructure, non-upstream, pretty much forever?
... put [deliberately] like that, it's not really a choice... :)
i realise however that you need something to work with in the short-term. you are free to do that, but if you want to submit an "upstream" fex file, you are free to call it whatever you wish as long as it does not have the words "eoma" or "eoma68" in it. i trust that this is clear.
l.