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)
Cheers, Marco Martin
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.
On Monday 16 December 2013, Luke Kenneth Casson Leighton wrote:
... 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.
ok..
right now i'm packaging an eoma68 fex as part of a clone repository (so not upstreamed yet)
is this ok?
or i can do a different separated package with it with a different name
Cheers, Marco Martin
On Mon, Dec 16, 2013 at 3:53 PM, Marco Martin notmart@gmail.com wrote:
On Monday 16 December 2013, Luke Kenneth Casson Leighton wrote:
... 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.
ok..
right now i'm packaging an eoma68 fex as part of a clone repository (so not upstreamed yet)
if you were helping to develop the base eoma68 fex file pending conversion to a base device-tree: yes.
is this ok?
now that you mention it - i hadn't thought about this before that's why! - really, no, it isn't, because people may become confused and think that the fex file was authoritative, and it isn't.
or i can do a different separated package with it with a different name
probably a better idea, now that it's come up :)
l.
arm-netbook@lists.phcomp.co.uk