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

[Joseph Honold]

On 09/16/2016 09:53 PM, Luke Kenneth Casson Leighton wrote:
> On Fri, Sep 16, 2016 at 5:30 PM, Joseph Honold <mozzwald at gmail.com> wrote:
>> I poked #linux-sunxi on irc and found out u-boot (mainline) sets up the SSD2828 device and passes it over to linux (mainline) SimpleFB driver. The MSI Primo 8.1 tablet uses the SSD2828 and has an example configuration
>>
>  oo good!  if you're intending to do that as GPLv3+ i would like to
> put you in touch with manuel (gacuest) as he's using the SSD2828 for
> the EOMA68 hand-held games console.

Hopefully Miguel can join in the discussion here and give some pointers. I wonder if he has working drivers for it yet (or even a hardware prototype). I dunno what license I would use, but i will post schematics/board files.

>> The eoma68-A20 card is shipping with linux 3.4 and is (of course) possible to upgrade to u-boot/linux mainline.
> 
>  yes... because it's the only kernel that fully supports all the
> hardware in a stable fashion.  bear in mind that i've done
> approximately 50 kernel compiles searching for a stable mainline linux
> kernel.  the problem is somewhere around 4.0rc5 and 4.0rc6.  i.e.
> 4.0rc5 works, 4.0rc6 doesn't.
> 
> 
>> How would a special configuration like this be handled
>> by the standard where your housing requires a special bootloader/kernel?
> 
>  knock yourself out: do whatever you like.  the only thing is, if you
> want to be able to call it an "EOMA68-compliant Housing" that's a
> totally different matter.
> 
>> Is it just a matter of having a boot device on the housing
>> (sd card, usb, etc)?
> 
>  mmm this came up a couple years ago: it was concluded that this
> practice - of putting boot devices onto Housings - would be a Bad Idea
> (for EOMA68 compliance)... but that, obviously, if you are not
> interested in making a formal declaration "Compliant With The EOMA68
> Standard", you're free to do whatever you like.
> 
>  the reason why it would be a bad idea to have boot devices on the
> housing is of course that when you take the EOMA68 card out and put a
> different one in.... now the new card has no idea how to boot.
> 
>  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? 

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.

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

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? 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. So, would you deny that the router housing EOMA compliance?

Can you just require all source code and shipped binaries be available before compliance is approved?