On 12/13/16, dumblob dumblob@gmail.com wrote:
Hi Luke,
sorry for the few months delay - I was stuck with moving, family, job applications, etc.
I would like to bring up again the painful topic of a long-sustainable graphical interface in the EOMA68 specification ( http://rhombus-tech.net/whitepapers/ecocomputing_07sep2015/ ) as the RGB/TTL solution is so utterly bad choice.
nope. been over this many many times.
RGB/TTL is way too slow
no it's not. most mid-end SoCs can do up to 2048x2048 @ 30fps, and can certainly do 1920x1080p60 over RGB/TTL.
it's nonsense to say that it's too slow.
and highly limited (alone, but even more in EOMA specifications):
no it's not. the 3.3mm card height is reserved for 1920x1080p60.
c) maximum color depth 18 bits (3x6)
that's because if you look at most mid-end LCDs they only do 18 bpp anyway. it also means that the extra 6 pins which were saved could be dedicated to SPI and two more EINTs, which turned out to be crucial.
most people's eyes are incapable of telling the difference. really.
f) easy (not requiring a chip) conversion to VGA output; conversion chips to all (!) other interfaces (which are modern, serial, and ubiquitous) is needed (and is more expensive than a serial->RGB/TTL because of very low purchaser interest)
yep. very easy. or, for the low-cost products, it's not even needed at all: 320x240, 480x320, 640x480, 800x480 and 800x600 LCDs are all RGB/TTL.
go look it up on panelook.com.
g) easy implementation in FPGA (few hundreds of LUTs)
Yet EOMA does not even allow adding any better display interface, because there are not enough "free" pins for any modern serial interface (MIPI DSI, eDP, HDMI, ...). This effectively totally (!) disallows manufacturers of EOMA cards to add an SoC <-> MIPI/eDP/HDMI circuity on an EOMA card
nonsense. they can always add a MIPI-to-RGB converter or an eDP-to-RGB converter IC on-board the Card.
to provide at least mainstream (!) resolution output with 24 bit colors for internal displays (not talking about 2017, when it will supposedly be 4K at 30 fps with 24 bit colors).
the processors you're referring to are so power-hungry that they require special cooling and/or fans. in other words, they're *well* beyond the thermal design capability of EOMA68 anyway.
also, the attention to design when dealing with 4k displays is EXTREME. not even rockchip's own EVB for the RK3288 is capable of driving a 4k HDMI display... because there's too much noise, degrading the signal.
the data rates you're talking about here are ... well, let's work it out. it's 1920*2*1080*2*60*8 = 3981312000. that's close to FOUR gigahertz.
to create boards where the data rates are that high requires extreme special care and attention to layout. it's radio frequencies, basically.
now, here's the thing: at this early stage of the project, i can cope with designing boards that are up to a maximum frequency of... 100mhz for RGB/TTL, and even 1ghz for HDMI 1.4 (1920x1080x60*8), by following some strict design rules that have taken me a long while to learn...
... but 3.7 ghz? fuck no. you must be joking. with the upcoming RK3288 prototype of course i'm going to try it out, but if it actually works i'm literally going to end up laughing on the floor, manically and hysterically at the complete fluke.
bear in mind that for a standard to be successful its interface capability must be MANDATORY, if you start FORCING the standard to support 3.7 ghz data transfer rates, you just raised the bar - the cost of development to a whooole new level.
EOMA68 is designed to be *affordably* implementable (by even someone like me who is self-taught).
In other words, this only one fact degrades the whole EOMA
repeat after me: there is NO SUCH THING as an EOMA standard. there is only a FAMILY of EOMA standards, of which EOMA68 was chosen as the first "easily and affordably implementable" one.
to the category of yet another toy (as every other libre general-purpose user computer HW failed up until now). By the way I had to publicly confess this during my talk at the conference OpenAlt 2016 (https://openalt.cz/2016 , there is a full recording).
After reading through all the important emails from Arm-netbook beginning in 2010 (yeah, 571509 lines of text),
ye gods man!
many of your posts on different web servers, and watching nearly all your videos, I did some research on display interfaces. Few quick facts based on my findings follow (yes, I focus on lower mainstream and mainstream "fat" embedded and mobile segment, not on total low-end, because there we have zillion of existing PCBs all offering basically the same HW interfaces - some of them even libre).
yeahyeah. the 72mhz ECs. none of them are capable of driving LCDs - the framebuffer alone overwhelms their capacity both for internal memory, internal bus rate and external data transfer rate.
many of the low-cost ECs actually use SPI-based or MCU-based (8080) LCDs (with something like an HX8357D controller IC) because these have their own internal framebuffer RAM (on-board)... quite cool, basically. it's like a tiny embedded version of the x86 IBM PC with its AT Bus....
...but i digress.
From panelook.com (size >= 7.0", px density >= 160 PPI):
- LVDS: 382 panels in MP YEAR 2016 (2015: 53) => ratio (the higher the
better) 53/382 = 0.138
- MIPI DSI: 239 panels in MP YEAR 2016 (2015: 50) => ratio 50/239 = 0.209
- eDP: 233 panels in MP YEAR 2016 (2015: 66) => ratio 66/233 = 0.283
- RGB/TTL: 15 panels in MP YEAR 2016 (2015: 2) ratio 2/15 = 0.133
great: you _did_ look it up! errr... except you didn't divide them up by resolution. that throws your enquiries off completely. basically, RGB/TTL is only common for 320x240 up to 800x600 (which is the low-cost end). above 800x600 the parallel data bus skew is too much... which is why these differential-pair serial buses were created in the first place.
(the ratio shows how much is the certain interface on rise)
Video interfaces from data sheets of few tens of more performant (i.e. having more computing power) mobile SoCs (no AMDs, no Intels) in 2015 & 2016:
- LVDS: nearly nowhere
- MIPI DSI: everywhere (!)
- eDP: nearly nowhere (in contrast to big chips like Intel i5/i6/i7, where
eDP is largely prevalent)
- RGB/TTL: nearly everywhere (but especially on smaller SoCs)
yes. so, as predicted, the decision to go with RGB/TTL makes sense... and still stands.
lower-cost SoC manufacturers don't like spending the money on royalty licenses for MIPI or eDP, plus it makes absolutely no sense to use MIPI or eDP for 320x240, 480x320 or 640x480 LCDs.
plus, the cost of a converter IC is a far greater ratio of the BOM at the lower-cost end than it is at the higher-end... and RGB/TTL is the de-facto interface of choice at the lower end.
... you _did_ read the "interface selection" section in the white paper, right?
bridges for his SoCs. Based on all that I'm confident, that in the upcoming 10 years, the SoC market will use MIPI DSI everywhere as the main standard and eDP for the few biggest chips.
... which we'll get to.... *with another standard*... with the 3.3mm card height variant being an interim stand-in to cover the intervening time... where profits from sales of designs based around the *CURRENT* standard will help fund the next one.
... you didn't think i was going to stop at just the one standard, did you?
Can we provide both interfaces (RGB/TTL + MIPI DSI) on the same pins while having a HW way to choose from these?
NO.
Yes we can!
NO. absolutely not.
EOMA already counts on several types of PC Cards (originally called PCMCIA). At minimum two - thinner (Type I - 3.3 mm) and thicker (Type II - 5 mm). Let's declare the thicker cards to be high-end and offer only MIPI DSI while thinner cards low-end with just RGB/TTL. Problem solved!
massive problem *created* which DESTROYS the standard even before it's implemented.
allow me to go through it.
(updated: i spotted another problem, which is that it would be impossible to prevent the 3.3mm "low end" cards from being inserted into 5.0mm "high end" slots... potentially electrically damaging both Card and Housing. on this point alone what you're suggesting is a non-starter. even if you tried to make them interoperable it would have to be 3.3mm which was the "high" end and 5.0mm the low end, because 5.0mm low-end Cards would NOT PHYSICALLY FIT into a 3.3mm slot.. so now we proceed to explain why *that* idea does not work, either... ).
af first glance, it seems like a great idea: add two different video interfaces on the same pins. so.
which pins do you use for which functionality?
* pin 1: RGB Red 0 *AND* MIPI lane 0 tx- * pin 1: RGB Red 1 *AND* MIPI lane 0 tx+
.... ....
now let's design the housing boards around that. let's make one which has RGB/TTL, and the other which has MIPI.
so, we've got hard-wired pins for RGB on say a 7in tablet
and we've got hard-wired pins for MIPI on say a 14in laptop.
great!
ok, so now let's select some SoCs.
right. first SoC we pick... we find that it has dedicated pins for MIPI, and dedicated pins for RGB/TTL. so we are forced to find an ultra-high-speed multiplexer SoC. problem "solved".
second SoC we pick... we find that it has shared pins (multiplexed) for MIPI and RGB/TTL. they DO NOT MATCH OUR ARBITRARILY CHOSEN ARRANGEMENT. now we try to use the same high-speed multiplexer SoC... only to find that it requires SEPARATE inputs... and... err... now we have to wire the same pins from the SoC to two sets of pins on the multiplexer IC... now we have signal-bounce to deal with (dual path)... and double-impedance-matching.... and it's getting alarmingly complex.
third SoC we pick... we find that it has shared pins which are COMPLETELY DIFFERENT FROM THE SECOND SoC.
fourth SoC we pick... has MIPI but does not even have RGB/TTL.
fifth SoC we pick... has RGB/TTL but does not have MIPI.
in ALL of these instances, it's simply flat-out impossible to do the board layout... why? because there's simply not enough room to fit the converter IC onto the board. have you _seen_ how tiny the EOMA68 PCBs are? 78.1 x 47.3mm with a height limit of 1.9mm on TOP and 1.6mm on BOTTOM, that's with a 1.2mm PCB. i don't even want to know how much 0.8mm PCBs cost.
can you see how this quickly gets into absolute hell on earth, with costs rapidly escalating?
what converter IC do you pick? does one even exist? is it common enough so that it has alternative competition so that we don't end up with the entire standard being critically dependent on ONE company's IC and them going out of business?
can you also see how it would create total confusion for end-users, thus DESTROYING all and any possibility of being a successful and simple mass-volume standard?
can you imagine the conversations of the sales people, "oh i'm sorry, you bought that 7in tablet which only does RGB/TTL? i'm sorry, you can't use the more modern MIPI Computer Card, you have to THROW AWAY that 7in tablet housing".
it's total nonsense... and in direct violation of the purpose of the standard: to reduce e-waste.
so... NO. not going to happen.
what *is* going to have to happen however is a new standard's created [and it will either use MIPI or it will use eDP... or it will have both on separate pins]. this would be much more suitable for the incoming mid-end SoCs (intel and amd are going to have to take a back seat until they sort out their backdoor co-processors and proprietary hardware drivers].
but, it is necessary first to find a suitable connector. funnily enough there's a guy who has located games cartridge connectors... i forget which one... NES? Game Boy? which has 100 pins....
http://old.pinouts.ru/Game/CartridgeGameBoy_pinout.shtml
nope, not that one, it's only 32...
https://wiki.nesdev.com/w/index.php/Cartridge_connector#Pinout_of_72-pin_NES...
NES - 72, ah HA! err... except they're enormous:
https://en.wikipedia.org/wiki/Nintendo_Entertainment_System_Game_Pak#60-pin_...
13.3 x 12 x 2cm or something mad.
so, back to the drawing board on that one.
basically it's not as simple as it sounds. just add an extra interface, right? no problem, right? wrong. there's *really* good reasons why the functions on EOMA68 only have GPIO multiplexing, and it's because GPIO is the lowest common denominator function that can reasonably be expected of any arbitrarily-chosen pin.
we can't even multiplex say SPI and UART onto the same pins, because there's absolutely no guarantee that any arbitrarily-chosen SoC *has* SPI and UART multiplexed onto *EXACTLY* the same arbitrarily-chosen pins [for a standard]. that leaves the burden on *software* to do bit-banging of either UARt or SPI... and god help you if the SoC doesn't support EINT capability on the chosen pins (because the others had to be used for other purposes), and you have to do high-frequency CPU-intensive polling.
and the moment you start saying "ohh it's okay to have one function but not the other on any given card" you've just fucked the entire standard in the "salesman" scenario above. nobody would EVER trust the standard to be "eco-conscious" if you told them that they were forced to throw out perfectly good Housings.
i appreciate your thoughts, but there's far more to take into consideration here than whether a particular interface is "up-to-date". at least six completely different inter-related criteria had to be satisfied, with *none* of them being "open for negotiation".
Speaking about thermal dissipation, I'm not sure that in case of the high-end card type, this limit should be a fixed one.
again it comes down to what the boards (chassis manufacturers) can cope with. remember, whatever is picked *has* to be covered by *ALL* chassis manufacturers.
so if you picked up to 15W, *ALL* chassis manufacturers *MUST* provide up to a maximum of 15W...
... or it is necessary to put in the EOMA68 I2C EEPROM, "this chassis can provide up to N watts power if needed, and has the thermal dissipation capability to deal with it".
it gets complicated, quite quickly, but would be doable.
hmmm, and the nice thing is, it's an upwards-compatible expansion of the EOMA68 standard which doesn't interfere with the existing release.
i like it.
l.