[Arm-netbook] Future case idea: subnotebook/PDA with QWERTY keyboard

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Wed, Sep 21, 2016 at 10:59 PM, Joseph Honold <mozzwald at 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.