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

[Joseph Honold]

On 09/21/2016 10:46 PM, Luke Kenneth Casson Leighton wrote:
>> 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".

ok, so it's not written in the spec yet.

> 
>> 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?

seems simple enough to me. two shiny stickers, one says EOMA68 HW Compliant, other says EOMA68 SW Compliant. If it's missing the SW, the manufacturer should supply you software :P

>> 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).

I don't expect the average consumer to compile any software. If you allowed housings to be bootable, (via sd card for example), a manufacturer can supply a sd card with the device and provide their own update channel.

>> 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".

If an average consumer buys a housing that claims it is a router and plugs in their old A20 cpu card (that contains a pre-installed desktop style OS) the hardware may be configured correctly per the dtb, but they surely won't be happy when they find out they need to setup a firewall, dhcp server, etc, etc, and much much more. The definition of "plug it in and it works" here is sketchy at best. IMO, "works" means, works as a router like the housing packaging said it would, and I expect most consumers would think the same. Now, average consumer tosses cpu card and housing in the trash and never buys EOMA again because it didn't *just work*.

Consumers should expect some kind of setup for any new hardware, especially a networking appliance, but asking them to install and properly configure a router OS is preposterous. If you allow a provision for housings to boot, the router housing manufacturer can provide a suitable OS (eg openwrt) and average consumer can be happy.

>> 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.
> 

Here's a totally different question instead :) Let's say someone makes a non-compliant housing and wants to market it to tech minded folk who can handle installing their own bootloader/kernel. Will it be legal to market it as non-compliant and use the EOMA name? "This housing accepts EOMA cpu cards but is non-compliant with the official specifications" or some such warning?