--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Fri, Sep 16, 2016 at 5:30 PM, Joseph Honold mozzwald@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_Pri...
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.