Discussion:
[Arm-netbook] Regarding Improv, EOMA68, Free Software and Open Hardware.
Henrik Nordström
2014-06-26 01:50:52 UTC
Permalink
This is a response letter to the notice just received that the Improv
project is being warpped up. Only trivially editied to fit the context
of the mailinglist. (inital reply was sent privately)

I am sorry to see the Improv project being wrapped up but fully
understand and do not come as a surprise given the discussions over last
months.

Just not sure I agree on the conclusions expressed in this letter
however, claiming that "The Free software community does not seem ready
at this point to make a concerted stand on the pressing issue of
hardware freedom". The issues that have dragged this project down has
very little to do with free software as such, or even the community at
large.

EOMA68 have been dragged down mostly by lack of resources, being founded
as a garage project run on pocket money and begging, resulting in
endless delays and unfavorable compromises, plus numerous issues in
people relations. And in addition starting at the wrong end of the table
trying to make a standard for hardware without first being familiar with
hardware designs and considerations. Resulting in a project trying to
make a leap before it knew how to crawl or even less walk, with a very
high level of uncertainty as result. It will probably get there in the
end, but getting there takes a lot of time and experience.

As for Improv, by the time it entered (the hardware) it provided nothing
unique that developers could not find elsewhere. Also most people in my
humble opinion already had given up on EOMA68 as a serious initiative
due to the numerous problems that project had already seen. I still back
the basic ideas of EOMA68, but not sure about the current realization of
it, aiming purely at low end market in interface specifications. Also,
it has to be realized that any such specification do have a fairly
limited lifespan and needs to be revised regularly, which somewhat
nullifies the benefits.

A project like EOMA68 trying to break many new grounds needs early
adopters willing to spend both money and time on getting things
finalized, and I am fully convinced that early adopters are not the ones
looking for the low-end range specifications. And with such project
having a lifespan covering several years (not months like average Tablet
project) interface specifications need to be such that it can be
suitable for wide adoption in a two to three years time when enought is
in place and tested, not yesterday.

For the sake of software development Improv isn't really needed, and was
not needed at the time of launch. There is and was fully OSHW solutions
available that covers the hardware functionality of Improv (minus the
exchangeable "CPU module" part). In particular I am thinking of Olimex
Olinuxino A20 MICRO (and it's related cousins), giving the same
performance specifications as the selected EOMA68-A20 module, but with
much richer hardware interfacing capabilities and of course 100% OSHW,
by a established manufacturer who works with believes in OSHW.

I have much more to say on the subject, but enough for tonight. Feel
free to contact me if you want me to elaborate further.

Regarding refund of my Improv "investment". Don't sweat over it. I'd
rather see you focus on moving forward than how to cover the refunds.
Failures are all natural path of moving forward and learning.

Regards
Henrik
joem
2014-06-26 08:59:47 UTC
Permalink
Post by Henrik Nordström
This is
SAD.

So many things wrong in various positions being taken
by all the players in that post.

There is enough resources and money to see the EOMA68
or something like it
to completion (meaning batch production ready).
And then it can go kickstarter to go commercial
if anyone wants to.

Quite a few distros have been made on the Cubieboard
awaiting release that will run on EOMA68.
It would be good if KDE plasma can be working
on EOMA68 and a touch LCD.
Or better still, cubieboard and touch LCD
because that can transfer to EOMA with just
a few minor changes, whilst in parallel
Mr. Cubie (Tom) reaps some benefits from
Plasma/touch LCD working.
Any ideas anyone for costs to make it happen?
(Paypal ready question!)
Henrik Nordström
2014-06-26 16:13:05 UTC
Permalink
Post by joem
Quite a few distros have been made on the Cubieboard
awaiting release that will run on EOMA68.
It would be good if KDE plasma can be working
on EOMA68 and a touch LCD.
Or better still, cubieboard and touch LCD
because that can transfer to EOMA with just
a few minor changes, whilst in parallel
Mr. Cubie (Tom)
Tom is no longer involved in Cubietech afaik.

In personally I prefer Olimex boards for development. A little bigger,
but all open and more I/O exposed. Plus a much wider range of boards
available depending on your needs.
Post by joem
reaps some benefits from
Plasma/touch LCD working.
Any ideas anyone for costs to make it happen?
(Paypal ready question!)
If it can run ontop of Android MALI drivers then not much should be
missing.

The state for non-Android GNU/Linux MALI drivers is a bit of a mess
unfortunately. Getting this in production shape requires cooperation of
Allwinner and maybe ARM as well.

LIMA is doing good progress, but will likely take a while before it's
capable of running Plasma.

Regards
Henrik
joem
2014-06-27 07:11:47 UTC
Permalink
Post by Henrik Nordström
Post by joem
Quite a few distros have been made on the Cubieboard
awaiting release that will run on EOMA68.
It would be good if KDE plasma can be working
on EOMA68 and a touch LCD.
Or better still, cubieboard and touch LCD
because that can transfer to EOMA with just
a few minor changes, whilst in parallel
Mr. Cubie (Tom)
Tom is no longer involved in Cubietech afaik.
In personally I prefer Olimex boards for development. A little bigger,
but all open and more I/O exposed. Plus a much wider range of boards
available depending on your needs.
Thank you - will look into evaluating one.
Post by Henrik Nordström
Post by joem
reaps some benefits from
Plasma/touch LCD working.
Any ideas anyone for costs to make it happen?
(Paypal ready question!)
If it can run ontop of Android MALI drivers then not much should be
missing.
The state for non-Android GNU/Linux MALI drivers is a bit of a mess
unfortunately. Getting this in production shape requires cooperation of
Allwinner and maybe ARM as well.
LIMA is doing good progress, but will likely take a while before it's
capable of running Plasma.
Its an utter shame the current plan is to let all this drag on.

The mass market for which the EOMA and touch display, and plasma
will sell billions of, and
which the trolls here have missed during their fierce
holy wars of late is fitted to this product:


Personally I don't mind calling Luke, Aaron, Allwinner, ARM
and everyone a troll until this problem is repaired.
Reading all the stuff posted,
they have zero understanding of what they are missing out on.

Still, I got to the stage where Gambas is working on
LCD with EOMA68 / Cubieboard and if I find
enough time, the touch LCD will work.
The gambas GUI software will have to
provide what plasma hasn't yet delivered.

The sliding screen effects could probably
get implemented by Gambas. If we ask
the Gambas community for a graphical control that can
do that effect, it would probably get built in.

Luke: I got the latest board costed up and its <$50
per EOMA with 2GB (not going split resources
at this stage to make the 1GB).
But it comes with a lead balloon MOQ of 2000 for
the PCMCIA case because they are only made in Taiwan.
Luke Kenneth Casson Leighton
2014-06-27 08:26:58 UTC
Permalink
Post by joem
Luke: I got the latest board costed up and its <$50
per EOMA with 2GB (not going split resources
at this stage to make the 1GB).
samples testing. we cannot go to production levels without sample
testing, 5pcs.
Post by joem
But it comes with a lead balloon MOQ of 2000 for
the PCMCIA case because they are only made in Taiwan.
litkconn is not taiwanese. the factory's in guangdong.
joem
2014-06-27 08:51:19 UTC
Permalink
Post by Luke Kenneth Casson Leighton
Post by joem
Luke: I got the latest board costed up and its <$50
per EOMA with 2GB (not going split resources
at this stage to make the 1GB).
samples testing. we cannot go to production levels without sample
testing, 5pcs.
It costs factories between USD1000 to USD2000 to try to organise
something like this. I normally place order for between 10 and 20 pieces
to meet these expenses.

I check with them for best quantity.
Post by Luke Kenneth Casson Leighton
Post by joem
But it comes with a lead balloon MOQ of 2000 for
the PCMCIA case because they are only made in Taiwan.
litkconn is not taiwanese. the factory's in guangdong.
Thank you, I run that past them again.
Luke Kenneth Casson Leighton
2014-06-27 18:32:37 UTC
Permalink
,
Post by joem
Post by Luke Kenneth Casson Leighton
Post by joem
Luke: I got the latest board costed up and its <$50
per EOMA with 2GB (not going split resources
at this stage to make the 1GB).
samples testing. we cannot go to production levels without sample
testing, 5pcs.
It costs factories between USD1000 to USD2000 to try to organise
something like this. I normally place order for between 10 and 20 pieces
to meet these expenses.
I check with them for best quantity.
that gives between 10 to 20 people to get units to... which may or
may not work. i want roughly a 30:70% mix of 1gbyte and 2gbyte of
samples - it's just in case the 2gbyte doesn't work.
Post by joem
Post by Luke Kenneth Casson Leighton
Post by joem
But it comes with a lead balloon MOQ of 2000 for
the PCMCIA case because they are only made in Taiwan.
litkconn is not taiwanese. the factory's in guangdong.
Thank you, I run that past them again.
the connector is from litkconn, it's on the BOM, so why did they go to
the trouble of finding a manufacturer with whom we have absolutely no
relationship?? i mean, it's good to know that there are still
companies out there not just litkconn, but the chances are that they
would order completely and utterly the wrong PCMCIA connector at
totally the wrong height.

been through this already with litkconn, selected the right part, even
designed the PCB and chose the PCB thickness to be *precisely* inside
the litkconn housing.

so litkconn already know exactly which part - it's their part number
68F. price for case, plastic and connector should be around $1.50.
that's plastic with the middle cut out. if we get over 2k orders we
can get the punch made with them for $6k to make the proper holes.

l.
Stefan Monnier
2014-06-27 12:56:08 UTC
Permalink
Post by Henrik Nordström
LIMA is doing good progress, but will likely take a while before it's
capable of running Plasma.
Hmm... did I miss some good news? Last I checked Lima was
sadly dormant.


Stefan
Tom Cubie
2014-06-30 04:41:47 UTC
Permalink
On Fri, Jun 27, 2014 at 12:13 AM, Henrik Nordström
Post by Henrik Nordström
Post by joem
Quite a few distros have been made on the Cubieboard
awaiting release that will run on EOMA68.
It would be good if KDE plasma can be working
on EOMA68 and a touch LCD.
Or better still, cubieboard and touch LCD
because that can transfer to EOMA with just
a few minor changes, whilst in parallel
Mr. Cubie (Tom)
Tom is no longer involved in Cubietech afaik.
Confirmed.
Post by Henrik Nordström
In personally I prefer Olimex boards for development. A little bigger,
but all open and more I/O exposed. Plus a much wider range of boards
available depending on your needs.
Post by joem
reaps some benefits from
Plasma/touch LCD working.
Any ideas anyone for costs to make it happen?
(Paypal ready question!)
If it can run ontop of Android MALI drivers then not much should be
missing.
The state for non-Android GNU/Linux MALI drivers is a bit of a mess
unfortunately. Getting this in production shape requires cooperation of
Allwinner and maybe ARM as well.
LIMA is doing good progress, but will likely take a while before it's
capable of running Plasma.
Regards
Henrik
_______________________________________________
arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbook at files.phcomp.co.uk
--
radxa rock - quad core arm computer that rocks

radxa.com
Luke Kenneth Casson Leighton
2014-06-26 20:49:41 UTC
Permalink
Post by joem
Post by Henrik Nordström
This is
SAD.
So many things wrong in various positions being taken
by all the players in that post.
don't sweat it. silver lining.
Post by joem
There is enough resources and money to see the EOMA68
or something like it
to completion (meaning batch production ready).
And then it can go kickstarter to go commercial
if anyone wants to.
ack. you got those PADS files, can you get them quoted up? pick any
decent PCB manufacturer. 5PCs MicroDesktop, 5PCs EOMA68-A20, 2 with
2Gb RAM, 3 with 1Gb RAM.

l.
Luke Kenneth Casson Leighton
2014-06-26 20:47:20 UTC
Permalink
On Thu, Jun 26, 2014 at 2:50 AM, Henrik Nordström
Post by Henrik Nordström
This is a response letter to the notice just received that the Improv
project is being warpped up. Only trivially editied to fit the context
of the mailinglist. (inital reply was sent privately)
Just not sure I agree on the conclusions expressed in this letter
however, claiming that "The Free software community does not seem ready
at this point to make a concerted stand on the pressing issue of
hardware freedom".
that's actually very sensible i think to say because it either a)
wakes people up or b) makes them think "hang on is it true??"
Post by Henrik Nordström
people relations. And in addition starting at the wrong end of the table
trying to make a standard for hardware without first being familiar with
hardware designs and considerations. Resulting in a project trying to
make a leap before it knew how to crawl or even less walk, with a very
high level of uncertainty as result. It will probably get there in the
end, but getting there takes a lot of time and experience.
and you know what? i'm actually relieved, because this is supposed to
be a decade-long standard. if we'd had the funding, we would have
gone ahead, the EOMA68 standard would have SATA and it would have
about one SoC available per two years *or less*.

the changes i've made since it started open it up to 23or more SoCs
*per year*. i am also considering - reluctantly - reserving the 5.0mm
card height for 1280x800 capable SoCs and the 3.3mm card height for
1920x1080 SoCs (over the 24-pin RGB/TTL that is)
Post by Henrik Nordström
As for Improv, by the time it entered (the hardware) it provided nothing
unique that developers could not find elsewhere. Also most people in my
humble opinion already had given up on EOMA68 as a serious initiative
due to the numerous problems that project had already seen. I still back
the basic ideas of EOMA68, but not sure about the current realization of
it, aiming purely at low end market in interface specifications.
but henrik, this is entirely entirely missing the point. the entire
point for end-users is that you buy 1 CPU Card and share them across
products, saving 30 to 40% for doing so *and* having consistent user
applications and data across all products.
Post by Henrik Nordström
Also,
it has to be realized that any such specification do have a fairly
limited lifespan and needs to be revised regularly, which somewhat
nullifies the benefits.
no. the interfaces were picked because they have all been around for
over a decade, and they are anticipated to be around and in
mass-production use for at least another decade.

do you see USB being retired in the next 10 years? (serious question)

with over 2,000 active LCD panels on panellook.com do you see RGB/TTL
being retired in the next 10 years?

likewise I2C, likewise GPIO, likewise SD/MMC, likewise SPI, likewise
UART, likewise ethernet.

if one of them was e.g. Firewire i would say there was a problem.
Post by Henrik Nordström
For the sake of software development Improv isn't really needed, and was
not needed at the time of launch. There is and was fully OSHW solutions
available that covers the hardware functionality of Improv (minus the
exchangeable "CPU module" part). In particular I am thinking of Olimex
Olinuxino A20 MICRO (and it's related cousins), giving the same
performance specifications as the selected EOMA68-A20 module, but with
much richer hardware interfacing capabilities and of course 100% OSHW,
by a established manufacturer who works with believes in OSHW.
... except doesn't take a stand on GPL violations, and distributes
illegal copyright-violating product, but _apart_ from that they
"believe in OSHW", yes.

no i am fully aware that the CPU Cards have "less interfaces" quotes.
that is entirely deliberate, as the interfaces had to be:

* lowest-common-denominator
* hardware-level upwardly self-negotiating (faster rates over more wires)
* decade-long lifespans

then the base-board uses e.g. Embedded Controllers to "fan out" the
missing functionality in a way that is *guaranteed* to be available
*regardless* of the SoC in the CPU Card.

in this way we can ensure that even the lowliest SoC (for example the
IC1T which is barely struggling to meet the absolute minimum of EOMA68
requirements) stands a chance.

if we had put e.g. CSI or TS on, or eDP or MIPI, then only the
absolute absolute top-end SoCs could be included, and even then some
of *those* would be excluded simply because they were so specialist
that they did not have the interfaces available.

look at the example of SATA. i wanted it - everyone wanted it - but
in the end it had to go, because it's not lowest-common-denominator
(and USB3-to-SATA ICs can do a good enough replacement job).
Post by Henrik Nordström
I have much more to say on the subject, but enough for tonight. Feel
free to contact me if you want me to elaborate further.
Regarding refund of my Improv "investment". Don't sweat over it.
you need to tell the improv team that, not me. remember, they were
just a 3rd party client, so we were waiting for the cash order. all
the money is held by that 3rd party. so you need to tell *them*, not
me, ok?
Post by Henrik Nordström
I'd
rather see you focus on moving forward than how to cover the refunds.
Failures are all natural path of moving forward and learning.
true. ain't quitting.
Miguel Garcia
2014-06-26 21:28:18 UTC
Permalink
Post by Luke Kenneth Casson Leighton
i am also considering - reluctantly - reserving the 5.0mm
card height for 1280x800 capable SoCs and the 3.3mm card height for
1920x1080 SoCs (over the 24-pin RGB/TTL that is)
I do not understand this well. Why you would do this separation?
Post by Luke Kenneth Casson Leighton
no. the interfaces were picked because they have all been around for
over a decade, and they are anticipated to be around and in
mass-production use for at least another decade.
do you see USB being retired in the next 10 years? (serious question)
with over 2,000 active LCD panels on panellook.com do you see RGB/TTL
being retired in the next 10 years?
likewise I2C, likewise GPIO, likewise SD/MMC, likewise SPI, likewise
UART, likewise ethernet.
I agree with you. Perhaps my only doubt is that I think that in 5
years all new screens will MIPI.

Thanks.
Miguel Garcia
2014-06-27 10:07:40 UTC
Permalink
Post by Luke Kenneth Casson Leighton
i am also considering - reluctantly - reserving the 5.0mm
card height for 1280x800 capable SoCs and the 3.3mm card height for
1920x1080 SoCs (over the 24-pin RGB/TTL that is)
I do not understand this well. Why you would do this separation?

Thanks.
Alexander Stephen Thomas Ross
2014-06-26 22:57:14 UTC
Permalink
Post by Luke Kenneth Casson Leighton
Post by Henrik Nordström
For the sake of software development Improv isn't really needed, and was
not needed at the time of launch. There is and was fully OSHW solutions
available that covers the hardware functionality of Improv (minus the
exchangeable "CPU module" part). In particular I am thinking of Olimex
Olinuxino A20 MICRO (and it's related cousins), giving the same
performance specifications as the selected EOMA68-A20 module, but with
much richer hardware interfacing capabilities and of course 100% OSHW,
by a established manufacturer who works with believes in OSHW.
... except doesn't take a stand on GPL violations, and distributes
illegal copyright-violating product, but _apart_ from that they
"believe in OSHW", yes.
so what, the kernel(s) or the software stack or drivers,firmware or etc
have GPL violated code in them? Is it for things like video
acceleration? if so, urrgh hypocrites. thats tyipical of the open source
mind set :( . Admittedly I've been trying to decide (for weeks) on
weather I get the LIME board for a version of a diy pockect computer :\
Luke Kenneth Casson Leighton
2014-06-27 08:16:11 UTC
Permalink
On Thu, Jun 26, 2014 at 11:57 PM, Alexander Stephen Thomas Ross
Post by Alexander Stephen Thomas Ross
so what, the kernel(s) or the software stack or drivers,firmware or etc
have GPL violated code in them?
the bootloader.
Henrik Nordström
2014-06-27 08:26:08 UTC
Permalink
Post by Luke Kenneth Casson Leighton
On Thu, Jun 26, 2014 at 11:57 PM, Alexander Stephen Thomas Ross
Post by Alexander Stephen Thomas Ross
so what, the kernel(s) or the software stack or drivers,firmware or etc
have GPL violated code in them?
the bootloader.
That's a very thin case. The bulk of all the bootloader sources are
published. Sure, AW is not so good in publishing current sources, but
there is not really any more bootloader sources for A20 that we have
interest in at this stage. (thanks to you btw for getting confirmation
on GPL status of the A20 SDK version).

If you had said NAND drivers then I maybe might agree with you as they
holding back later NAND driver sources may impact interoperability with
free software, but not on the bootloader. We are way past that stage.

Regards
Henrik
Alexander Stephen Thomas Ross
2014-06-27 13:33:39 UTC
Permalink
I'm surprised it's the bootloader. I hate to distract but you face
giving a bit more info/history?
thanks
Henrik Nordström
2014-06-26 23:09:48 UTC
Permalink
Post by Luke Kenneth Casson Leighton
and you know what? i'm actually relieved, because this is supposed to
be a decade-long standard. if we'd had the funding, we would have
gone ahead, the EOMA68 standard would have SATA and it would have
about one SoC available per two years *or less*.
Agreed.
Post by Luke Kenneth Casson Leighton
the changes i've made since it started open it up to 23or more SoCs
*per year*. i am also considering - reluctantly - reserving the 5.0mm
card height for 1280x800 capable SoCs and the 3.3mm card height for
1920x1080 SoCs (over the 24-pin RGB/TTL that is)
Why? I don't get it.

For 1920x1080+ LVDS / DSI / eDP is much better suited interfaces imho.
Unfortunately all (including RGB/TLL, but except eDP) is plauged by
configuration issues and vendor extension dependencies which makes then
somewhat troublesome for EOMA.
Post by Luke Kenneth Casson Leighton
Post by Henrik Nordström
As for Improv, by the time it entered (the hardware) it provided nothing
unique that developers could not find elsewhere. Also most people in my
humble opinion already had given up on EOMA68 as a serious initiative
due to the numerous problems that project had already seen. I still back
the basic ideas of EOMA68, but not sure about the current realization of
it, aiming purely at low end market in interface specifications.
but henrik, this is entirely entirely missing the point. the entire
point for end-users is that you buy 1 CPU Card and share them across
products, saving 30 to 40% for doing so *and* having consistent user
applications and data across all products.
No I am not missing the point at all.

My point is that Improv is a development platform. EOMA68 is at this
point in time a niche product. The combination of the two makes an
extremely small market for Improv. The primary group that Improv targets
have other choices that fulfill their needs better.

EOMA68 needs something like Improv.

The majority of the users Improv targets do not need EOMA68 or even
benefit from it.
Post by Luke Kenneth Casson Leighton
Post by Henrik Nordström
Also,
it has to be realized that any such specification do have a fairly
limited lifespan and needs to be revised regularly, which somewhat
nullifies the benefits.
no. the interfaces were picked because they have all been around for
over a decade, and they are anticipated to be around and in
mass-production use for at least another decade.
Agreed that the selected interfaces is going away any time soon, but
these specifications forces the lower end of the spectrum, which also
makes it an uninteresting path for the tech-sawy people you need to get
the whole thing flying.
Post by Luke Kenneth Casson Leighton
do you see USB being retired in the next 10 years? (serious question)
No. But RGB/TTL is likely fading quickly as display density increases.
Post by Luke Kenneth Casson Leighton
with over 2,000 active LCD panels on panellook.com do you see RGB/TTL
being retired in the next 10 years?
Outside the low-end product spectrum yes, obviously.
Post by Luke Kenneth Casson Leighton
likewise I2C, likewise GPIO, likewise SD/MMC, likewise SPI, likewise
UART, likewise ethernet.
No, but I question our ability to today define which of these is really
needed.
Post by Luke Kenneth Casson Leighton
... except doesn't take a stand on GPL violations, and distributes
illegal copyright-violating product, but _apart_ from that they
"believe in OSHW", yes.
It's a hardware company, not a software company. Their software
development resources are very limited, and do take these infringements
seriously.
Post by Luke Kenneth Casson Leighton
no i am fully aware that the CPU Cards have "less interfaces" quotes.
And I was not critizing EOMA there.
Post by Luke Kenneth Casson Leighton
in this way we can ensure that even the lowliest SoC (for example the
IC1T which is barely struggling to meet the absolute minimum of EOMA68
requirements) stands a chance.
Is that at all a desireable goal?

Timewarp two years, would such device have any reuse value at all by
then?

Same applies to the other half of EOMA, the base-board (or perhaps
better named base-device). The EOMA idea only makes sense if pieces are
up to a level that reuse and upgrade makes sense.

Or in other words, any EOMA device designed today need to be designed
with the goal of being valuable to reuse in at least 2-3 years time.

Any device manufactured at the lower range of todays standard is very
unlikely to have any meaningful value in two to three years in the same
consumer group.
Post by Luke Kenneth Casson Leighton
if we had put e.g. CSI or TS on, or eDP or MIPI, then only the
absolute absolute top-end SoCs could be included,
today yes, unless you accept to throw in a converted chip, which is hard
doe to the extreme tight space requirements in the EOMA standards.
Post by Luke Kenneth Casson Leighton
look at the example of SATA. i wanted it - everyone wanted it - but
in the end it had to go, because it's not lowest-common-denominator
(and USB3-to-SATA ICs can do a good enough replacement job).
Heck, even storage over USB2 works well for most practical uses today in
the target focus of EOMA.
Post by Luke Kenneth Casson Leighton
you need to tell the improv team that, not me. remember, they were
just a 3rd party client, so we were waiting for the cash order. all
the money is held by that 3rd party. so you need to tell *them*, not
me, ok?
And I did. As stated in the first paragraph this message was a public
copy of my response to their letter with only minimal edits to fit the
mailinglist.
Post by Luke Kenneth Casson Leighton
Post by Henrik Nordström
I'd
rather see you focus on moving forward than how to cover the refunds.
Failures are all natural path of moving forward and learning.
true. ain't quitting.
Neither am I. Just temporarily held up in other completely crazy
business and learning a lot more about hardware side of things than I
ever thought I would be doing.. and mixed together with free software.
But almost entirely outside the scope of this mailinglist even if we did
cause noticeable shortage of Beaglebone Blacks on the market..

Regards
Henrik
Luke Kenneth Casson Leighton
2014-06-27 08:23:50 UTC
Permalink
On Fri, Jun 27, 2014 at 12:09 AM, Henrik Nordström
Post by Henrik Nordström
Post by Luke Kenneth Casson Leighton
and you know what? i'm actually relieved, because this is supposed to
be a decade-long standard. if we'd had the funding, we would have
gone ahead, the EOMA68 standard would have SATA and it would have
about one SoC available per two years *or less*.
Agreed.
Post by Luke Kenneth Casson Leighton
the changes i've made since it started open it up to 23or more SoCs
*per year*. i am also considering - reluctantly - reserving the 5.0mm
card height for 1280x800 capable SoCs and the 3.3mm card height for
1920x1080 SoCs (over the 24-pin RGB/TTL that is)
Why? I don't get it.
For 1920x1080+ LVDS / DSI / eDP is much better suited interfaces imho.
.. for which there exist conversion ICs. if however you try to get
anything *other* than an RGB/TTL-to-{INSERT-INTERFACE-HERE} IC you run
into huge costs and licensing issues.
Post by Henrik Nordström
No. But RGB/TTL is likely fading quickly as display density increases.
... for which there exist conversion ICs.
Post by Henrik Nordström
Post by Luke Kenneth Casson Leighton
with over 2,000 active LCD panels on panellook.com do you see RGB/TTL
being retired in the next 10 years?
Outside the low-end product spectrum yes, obviously.
and above that low-end product spectrum there exist conversion ICs.
Post by Henrik Nordström
Post by Luke Kenneth Casson Leighton
... except doesn't take a stand on GPL violations, and distributes
illegal copyright-violating product, but _apart_ from that they
"believe in OSHW", yes.
It's a hardware company, not a software company. Their software
development resources are very limited, and do take these infringements
seriously.
not seriously enough. you know the law. if you cannot comply, you
must cease and desist distribution.

or you operate as a criminal cartel.
Post by Henrik Nordström
Post by Luke Kenneth Casson Leighton
no i am fully aware that the CPU Cards have "less interfaces" quotes.
And I was not critizing EOMA there.
Post by Luke Kenneth Casson Leighton
in this way we can ensure that even the lowliest SoC (for example the
IC1T which is barely struggling to meet the absolute minimum of EOMA68
requirements) stands a chance.
Is that at all a desireable goal?
Timewarp two years, would such device have any reuse value at all by
then?
as a lower-spec'd reusable board for someone else? yes, absolutely.
that's the whole point: down-stream the hardware.
Post by Henrik Nordström
Same applies to the other half of EOMA, the base-board (or perhaps
better named base-device). The EOMA idea only makes sense if pieces are
up to a level that reuse and upgrade makes sense.
Or in other words, any EOMA device designed today need to be designed
with the goal of being valuable to reuse in at least 2-3 years time.
Any device manufactured at the lower range of todays standard is very
unlikely to have any meaningful value in two to three years in the same
consumer group.
i expect the 2nd-hand market on ebay to take care of that.
Post by Henrik Nordström
Post by Luke Kenneth Casson Leighton
if we had put e.g. CSI or TS on, or eDP or MIPI, then only the
absolute absolute top-end SoCs could be included,
today yes, unless you accept to throw in a converted chip, which is hard
doe to the extreme tight space requirements in the EOMA standards.
.... exactly, which is why that problem is moved to the base-board.

it's the base-board where you put the converter ICs.

take a look on chrontel's web site.

tell me how many DVI-to-{INSERTINTERFACE} converter ICs there are.

tell me how many eDP-to-{INSERTINTERFACE} converter ICs there are.

_now_ compare that to how many RGB/TTL-to-{INSERTINTERFACE} converter
ICs there are.

ok. too much time being spent. gotta go.
Luke Kenneth Casson Leighton
2014-06-27 18:51:39 UTC
Permalink
On Fri, Jun 27, 2014 at 12:09 AM, Henrik Nordström
Post by Henrik Nordström
Post by Luke Kenneth Casson Leighton
the changes i've made since it started open it up to 23or more SoCs
*per year*. i am also considering - reluctantly - reserving the 5.0mm
card height for 1280x800 capable SoCs and the 3.3mm card height for
1920x1080 SoCs (over the 24-pin RGB/TTL that is)
Why? I don't get it.
For 1920x1080+ LVDS / DSI / eDP is much better suited interfaces imho.
Unfortunately all (including RGB/TLL, but except eDP) is plauged by
configuration issues and vendor extension dependencies which makes then
somewhat troublesome for EOMA.
ok, i have a bit more time, so can explain further. the logic is as follows:

* SoCs are on the market at 1280x800 maximum resolution over RGB/TTL
* SoCs are on the market at 2048x2048 @ 30fps max res over RGB/TTL
* RGB/TTL is the lowest common denominator and is present on all but
the absolute absolute specialist SoCs such as mobile smartphone ones,
high-end high-power SoCs (Calxeda, TI etc.)
* LVDS is fraught with choice between 1 or 2 channels
* RGB/TTL, precisely because it is lowest-common-denominator,
may be converted to just about anything with an IC that costs between
$1 for a single-channel LVDS to $3.50 or $5 for a 1920x1080 DVI/HDMI
and someone recently found an eDP one for $3 which is awesome.

so the cases we want to cover are:

* 320x240 RGB/TTL screen at very low cost (these are all RGB/TTL)
* 1024-1280 x 600-1024 screen at reasonable cost (these are all
LVDS 1x but a _few_ eDPs are becoming available)
* 1440x900 to 1920x1080 at not unreasonable cost (these are
usually Dual or Triple LVDS with some now 4-lane eDP and so on)

remember that EOMA interfaces are *mandatory*.

* if you make even LVDS mandatory, you just screwed 2 out of 3 of
those options (pick any 2: the 320x240 one is my favourite because
you will need an LVDS converter on the SoC *and* a down-converter
on the base-board, and you just screwed any chance of having a low
cost system!)

* if you make eDP mandatory you just screwed 2 out 3 of those options,
the 320x240 is screwed on cost, and 1 out of 2 of the others are
screwed on the number of eDP lanes.

also you are royally screwed on the pricing of eDP ICs vs the cost
of RGB/TTL-to-LVDS ICs.

* if you make MIPI mandatory it's the same thing

* if you make HDMI mandatory it's *worse* because now you have
two $5 ICs _and_ you have a $50,000 up-front HDMI manufacturer's
extortion^Wlicense to pay.

* if however you make RGB/TTL mandatory you may:

- use direct RGB/TTL (zero cost) to connect to the 320x240 LCD

- use a $1 RGB/TTL to LVDS IC or a $3 RGB/TTL to MIPI IC for
the 1024x600 to 1280x1024 LCDs

- use a $3 to $5 RGB/TTL to LVDS or eDP IC to connect to the 1440x900
and the 1920x1080 LCDs.

so overall it is actually very simple: RGB/TTL is the only remaining
logical choice once you have considered all the options from all the
angles covering all the products and all SoC families. the cost of
the converter ICs is a manageable quantity that is relative to the
cost of the LCD it is connecting to and the sale price of the product.

l.
joem
2014-06-28 18:29:59 UTC
Permalink
Post by Luke Kenneth Casson Leighton
* 320x240 RGB/TTL screen at very low cost (these are all RGB/TTL)
* 1024-1280 x 600-1024 screen at reasonable cost (these are all
LVDS 1x but a _few_ eDPs are becoming available)
* 1440x900 to 1920x1080 at not unreasonable cost (these are
usually Dual or Triple LVDS with some now 4-lane eDP and so on)
hmmmp.

Yesterday this may have been true.
Today the starting point is something like
a 7" tablet with retail price of $50 and min 800x600.
With tablet guts removed and a HDMI/VGA/Composite input
board fitted, that price shrinks to $30 retail.

Also if tablets were a little more open,
load an OS that turns the tablet
into a USB monitor may be possible = another
opportunity for EOMAs to sell in their beeellions.
Luke Kenneth Casson Leighton
2014-06-28 19:59:15 UTC
Permalink
Post by joem
Post by Luke Kenneth Casson Leighton
* 320x240 RGB/TTL screen at very low cost (these are all RGB/TTL)
* 1024-1280 x 600-1024 screen at reasonable cost (these are all
LVDS 1x but a _few_ eDPs are becoming available)
* 1440x900 to 1920x1080 at not unreasonable cost (these are
usually Dual or Triple LVDS with some now 4-lane eDP and so on)
hmmmp.
Yesterday this may have been true.
Today the starting point is something like
a 7" tablet with retail price of $50 and min 800x600.
With tablet guts removed and a HDMI/VGA/Composite input
board fitted, that price shrinks to $30 retail.
Also if tablets were a little more open,
load an OS that turns the tablet
into a USB monitor may be possible = another
opportunity for EOMAs to sell in their beeellions.
exactly.. with a pass-through card any device with a screen,
touchpanel, mouse, internal hard drive etc basically becomes an
extension system for desktop PCs, other devices - anything.

i did a case study where hilariously if you have 2 devices, one CPU
Card and one pass-through card it actually doesn't matter what you
plug in to what, you still end up with one computer with 2 screens.

l.
joem
2014-06-29 23:58:57 UTC
Permalink
Post by Luke Kenneth Casson Leighton
Post by joem
Post by Luke Kenneth Casson Leighton
* 320x240 RGB/TTL screen at very low cost (these are all RGB/TTL)
* 1024-1280 x 600-1024 screen at reasonable cost (these are all
LVDS 1x but a _few_ eDPs are becoming available)
* 1440x900 to 1920x1080 at not unreasonable cost (these are
usually Dual or Triple LVDS with some now 4-lane eDP and so on)
hmmmp.
Yesterday this may have been true.
Today the starting point is something like
a 7" tablet with retail price of $50 and min 800x600.
With tablet guts removed and a HDMI/VGA/Composite input
board fitted, that price shrinks to $30 retail.
Also if tablets were a little more open,
load an OS that turns the tablet
into a USB monitor may be possible = another
opportunity for EOMAs to sell in their beeellions.
exactly.. with a pass-through card any device with a screen,
touchpanel, mouse, internal hard drive etc basically becomes an
extension system for desktop PCs, other devices - anything.
i did a case study where hilariously if you have 2 devices, one CPU
Card and one pass-through card it actually doesn't matter what you
plug in to what, you still end up with one computer with 2 screens.
There is also a need to CPU + dedicted customized OS that turns
the tablet into a graphics computer (e.g. running X window)
and taking compressed commands from the USB directly.
If it can talk, even more better.

Got the talking bit sorted with Ubuntu, gambas and espeak.
Next step is to get gambas into a crude graphics rendering
system that takes crude commands like circle(x,y,r).
The idea is that an embedded CPU with very little resources,
or a headless computer with a USB link can connect
to this device and speak out of it / turn it into a monitor
without having to have large amounts of graphics processing
software or the RAM in the embedded controller.

The ideas are similar to a graphical version of a VT100 terminal,
but with more features, open, and ultra simple embedded CPU
friendly interface. Suitable for Arduino to little PIC chip.

Dream on I guess :)
Luke Kenneth Casson Leighton
2014-06-30 02:39:49 UTC
Permalink
Post by joem
There is also a need to CPU + dedicted customized OS that turns
the tablet into a graphics computer (e.g. running X window)
and taking compressed commands from the USB directly.
weelll... the first easily-achievable way to do that is to use any
SoC with USB-OTG. the other way is using a DisplayLink IC. but, both
ways _do_ need some amounts of RAM otherwise you severely saturate the
USB bus and/or overload the main processor. DisplayLink's first IC
does very basic 2D primitives (line, rectangle, image) which is a
half-way compromise. the second (which is USB3) i don't know exactly
what they do.

... yes been thinking quite a lot how to do this, joe :)

l.
joem
2014-06-30 10:41:45 UTC
Permalink
Post by Luke Kenneth Casson Leighton
Post by joem
There is also a need to CPU + dedicted customized OS that turns
the tablet into a graphics computer (e.g. running X window)
and taking compressed commands from the USB directly.
weelll... the first easily-achievable way to do that is to use any
SoC with USB-OTG. the other way is using a DisplayLink IC. but, both
ways _do_ need some amounts of RAM otherwise you severely saturate the
USB bus and/or overload the main processor. DisplayLink's first IC
does very basic 2D primitives (line, rectangle, image) which is a
half-way compromise. the second (which is USB3) i don't know exactly
what they do.
... yes been thinking quite a lot how to do this, joe :)
OK - stretch to next level:

With storage being cheap ($4 for 16GB flash)
its reasonable to start a project to let the users of
this type of 'terminal' to upload their
graphics, command sets and limited animations
and it would get compressed and incorporated
into the 16GB 'distro' (with emphasis on reuse of existing
stuff). The user plugs it into
the relevant hardware, the hardware sends 32 bit
identifier through serial port or USB
to locate its command set, and then
any further signals are known to the 'terminal'
which then does the grunt work to update the
terminal with graphics. Even a simple multimeter
with embedded CPU could then do a lot of magical
functions knowing a serial port can be used to send
the presentation of voltage, current, etc. this 'terminal'
which will know how to render the graphical screen and make it
very interesting. An open source tool by the techies
for the techies working with embedded stuff at the coal face
to get projects out to the market asap without trying to source
custom LCD and bits needed to make it work correctly.

If I could buy a terminal like that, I'd buy 10 terminals today,
at cost of $50 each and do my own graphics from re-usable stuff that
others have done and/or do my own and upload for incorporation
into the 16gb distro.

I'd never have to worry about adding full colour LCDs for all my
gadgets again! As an EE, such a terminal would be more valuable to me
than any other gadget right now.

Speech is also important - all my gadgets now talk to me
if they detect a problem. Speeds up debugging by a factor
of a million. The severity level and types of messages
are selectable to avoid being bombarded with geek speaking
screaming boards.

Loading...