[libre-riscv-dev] KCP53010 in danger

[Luke Kenneth Casson Leighton]

On Friday, August 2, 2019, Samuel Falvo II <sam.falvo at gmail.com> wrote:

> On Thu, Aug 1, 2019 at 10:23 AM Luke Kenneth Casson Leighton <
> lkcl at lkcl.net>
> wrote:
>
> > it's *known* for both being utterly simple and small yet
> > extraordinarily complex at the same time, so don't beat yourself up
> > about it, ok?
> >
>
> Thank you.  I try not to!  But, sometimes, the depression just becomes too
> much to handle.
>
> What follows is not intended to be taken as a pity-party, nor is it written
> while I was depressed.  I'm just trying to be as honest and as objective
> about my projects as I can be.
>
> I do get impatient with myself for not having made any progress, though,
> even when not in a state of depression.  I have a number people who follow
> my progress on both Hackaday as well as on Mastodon, and I increasingly see
> them exploring other options which increasingly obsoletes my project (as if
> it weren't already obsolete in terms of feature set, now their prices are
> starting to come down to my ideal price point too).  Popular projects like
> the PineBook64 have lead me to question whether I can make anything
> resembling a lasting contribution in the very niche I find myself most
> comfortable.
>
> Please don't take this the wrong way; but, I've been asked before, "Sam,
> why don't you just use EOMA68?"


Ngggh they've missed the point of EOMA68, bless em.  It's designed for mass
volume product interoperability.

It is most definitely NOT designed for specialist markets such as
professional audio or video processing and editing.

Now, if you put an FPGA into EOMA68 form dactor, it would be possible to
repurpose all of the pins and use them for just about anything, making your
own custom Housing to do anything

However by doing so it would NOT be permitted to claim that the "does
anything" is EOMA68 Compliant... *unless* it happened to have some sort of
dual switching capability that allowed precisely that.

At one point I gave serious consideration to allowing advanced hardware to
"switch" the LCD signals over to e.g eDP or MIPI or something, however the
only way to also be backwards compatible would be to make the use of an
FPGA *mandatory* on the Housings in order to perform the necessary rewiring
/ routing.

The mistake that was made by the 96boards Corporation was to make it
"optional" to have both MIPI and LVDS and RGB/TTL *on the same pins*.

The probability that any given SoC has *EXACTLY* that matching pinouts for
ALL pins, in the EXACT order for ALL THREE interfaces is precisely zero.

The EOMQ68 tagline "just plug it in, it will work" is extremely tough to
meet, technically, and required some limitations on the kinds of markets
that EOMA68 can reach. "Good enough Computing" markets  - fine. "High end
Western 1st World markets" with 4k HD and 16 core 4ghz CPU territory: no
chance.

L.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68