[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 Fri, Sep 16, 2016 at 5:30 PM, Joseph Honold <mozzwald at gmail.com> wrote:
> On 09/02/2016 09:33 AM, Joseph Honold wrote:
>> I've been looking at various LCD options and all of the RGB ones that are 3.5"-4" have low resolution (320x240, 480x320, and expensive 640x480). This lead me to look at MIPI DSI displays which are cheaper with higher resolution but more complicated requiring a conversion IC. I see mention of the SSD2828 RGB to MIPI chip in the mailing list which seems low cost and it is already used in a couple A20 devices. Has anyone had experience with this chip? It seems u-boot enables it but I'm not sure how linux interacts with it.
>>
>> http://arm-netbook.phcomp.co.narkive.com/tTYfuse7/rgb-to-mipi
>> http://linux-sunxi.org/SSD2828
>
> 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
>
> https://github.com/linux-sunxi/u-boot-sunxi/blob/mirror/next/configs/MSI_Primo81_defconfig
>
> I currently have a Marsboard A20 and was able to get u-boot/linux mainline running on it the other day. My plan is to create a ssd2828 breakout board that I can do some testing with the Marsboard in preparation for designing an EOMA68 housing.

 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.


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


> Does the eeprom fit in this process somehow?

 the eeprom we concluded that it would act merely like the USB / PCI
"id".  nothing else.  that would be sufficient to identify the
Housing, with its associated hardware peripherals.  must properly
document that.  from there, u-boot and linux kernel would use that to
pull in "device-tree fragments": https://lkml.org/lkml/2015/11/10/593

Pantelis Antoniou is (has) implemented the required "live devicetree
reconfiguring / adding" hooks that will allow per-housing pre-compiled
BINARY fragments to be selected and incorporated.

 the eeprom's contents (an 8 byte number) will be used exactly as is
done with USB ids to select which "fragment" shall be added.

 the discussion with pantelis included the question, "what happens
when the Housing is live-unplugged or the device is suspended,
resumed, and discovers that it's in a completely different Housing?" -
he'd not considered that as a possibility.

 basically there's a "roadmap"... we're not there yet, but the pieces
are in place.

l.