--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, Sep 21, 2016 at 10:59 PM, Joseph Honold mozzwald@gmail.com wrote:
so, they really do have to be self-contained... [if you want to be able to make a formal declaration, "compliant with the EOMA68 standard"].
I don't see how a housing that needs a particular libre bootloader, kernel or driver is non-compliant with the standard (as it is currently written). Perhaps there needs to be more clarification of the boot process and software requirements for compliance?
there is: mainly the burden is on the Cards (not the Housings), but it is essential that the I2C EEPROM at address 0x51 contain the required "identification" information... and that hasn't yet been completely implemented yet.
so until that's work's been done, people implementing Housings need to be keenly aware of that... if they would like to be able to claim "compliance".
u-boot can boot from just about anything now (except maybe punched cards :). You could easily write the boot process to check for boot devices in a specific order, lastly to internal NAND. We use this process on the Zipit Z2: if u-boot script on sdcard, boot from it, else if uboot script on usb, boot from it, else boot internal NOR. This can work on the EOMA cards as well.
there are some source code modifications required to both the linux kernel and u-boot, to add the patch that can load device-tree binary fragments, but then also there is the specific specialisation that needs to be added which reads the EOMA68 I2C EEPROM in order to be able to ascertain *which* dtb binary fragment shall be added in.
so, part of the compliance of Housings manufacturers *will* be that they will need to provide a device-tree fragment that is kept up-to-date. if the linux kernel devicetree format changes suddently (in linux version 9.999 for example) they'll be required to provide an update if they would like to keep their Housing Certification up-to-date.
Have you considered creating two standards instead of one? Make one a hardware compliance (physical, electrical, mechanical, etc) and a separate software compliance? That way one could be hardware compliant but use it's own software. (as I finish that sentence I can already hear the big NO to that question :)
no :) that would bring the standard into disrepute, by violating the tagline "Just Plug It In: It Will Work". now you have to replace that with: "First You Must Check If The Hardware Is Compliant With The Hardware Standard, Then You Must Check If The Software Is Compliant With The Software Standard, Oh And If Both Those Things Are True Then Yes You Can Plug It In and It Will Work. Or, You Could Just Try Plugging It In And Guessing".
... that's a clear violation of the basic underlying principle of the EOMA68 standard's simplicity, isn't it?
It just doesn't make sense (to me) to effectively lock someone to a particular bootloader/kernel that is potentially less capable by denying them compliance. As long as my housing works with free/libre software, what's the problem?
the EOMA68 standard is not merely about "working with free / libre software". it's about making **100 MILLION AND ABOVE PER YEAR** free/libre Housings (and Cards) and ensuring that the returns rate is well below 0.001% (0.001% of 100 million a year is a hundred THOUSAND units a year, which is absolutely insanely large, and could well represent the entire profit margin for that year. mass-volume is radically different).
you cannot possibly expect, with those kinds of numbers, that people will be capable of compiling their own kernels etc. etc. or even that they are capable of installing a new OS. they want something that "just works". if it don't work, they'll return it (or discard it).
In a case where a housing is designed to be a router, if I plug my A20 cpu card that ships with a desktop gui OS, it is in no way configured to be usable as a router.
that's absolutely fine and permitted: i would expect the user to plug in an OTG Cable, plug in an HDMI cable, boot from internal NAND or internal MicroSD and off they go. in effect they would merely be using the router for "power provision". if the desktop OS is kept properly patched and up-to-date, the device-tree binaries would already be on the CPU Card, so it would even recognise the USB devices and other hardware of the Housing. not that there might necessarily be any applications installed which could take advantage of the extra hardware, but that's the user's problem to deal with by installing the applications that they require.
the key bit that's glossed over there is: the user should be keeping the OS (specifically the u-boot and linux kernel) up-to-date so that it is capable of recognising all Housings. for _that_ to work, all Housings implementers / designers *must* keep the device-tree fragments up-to-date.
any end-user that doesn't keep their OS up-to-date (stops automatic updates from being installed, for example) is "on their own".
the envisaged process isn't perfect, by any means: we do have to be realistic about that.
So, would you deny that the router housing EOMA compliance?
of course not, because the question is a misunderstanding of the process.
anyone who is plugging in (for example) an EOMA68-A20 into a (for example) router Housing is probably the kind of expert who knows what they're doing. if they're even *remotely* contemplating that kind of re-purposing / mixing-and-matching (and are the first or one of the first to consider doing it) i think it's safe to assume that they would be capable of customising (or entirely replacing) the OS with one that is more suited to the job of "being a router" as opposed to "being a desktop OS".
several years ago, we looked at the possibility of adding "a large software trove" to Housings, placing basically multiple OSes and/or drivers onto some special MANDATORY storage within EVERY housing. as you might imagine, that was deemed totally impractical, very very quickly.
now, it would be _really nice_ if each "Housing Community" had some sort of pre-compiled OSes for all the different Cards out there, but realistically that's also not going to be totally practical either: a specialist FPGA Card for example we could not possibly expect every compliant Housing Designer to purchase absolutely every single Card (especially if some of them costs thousands of dollars).
and that's where the role "Guardian of the EOMA68 Standard" comes into play, because that *is* the responsibility of the Guardian(s) to ensure that all Housing and all Card designers who seek to be compliant with the EOMA68 Standard provide samples (on an ongoing basis) to the Guardian(s) so that they *can* do testing and/or OS setups etc. etc. which the independent manufacturers simply could not.
basically, there's a roadmap in my head which hasn't really been written down yet. or, it was... it was written ad-hoc on the mailing list several years ago as part of a discussion amongst the prominent responding members of that time. i don't believe any of those people are still active on the list: i'm the last one remaining so i am the last one who still actively remembers those discussions.
now, ta-daaa! congratulations: you are :)
Can you just require all source code and shipped binaries be available before compliance is approved?
in light of the above, the question may need to be reworded / rethought. just as the Bill of Ethics points out: entropy will require to be continuously overcome in order to achieve [continuous] compliance. it's not a one-off "fire-and-forget" process.
l.