[Arm-netbook] crowdfunding page is live -- and different CPUs for the future

[Luke Kenneth Casson Leighton]

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


On Mon, Jul 18, 2016 at 10:10 PM, Manuel A. Fernandez Montecelo
<manuel.montezelo at gmail.com> wrote:
> 2016-07-18 20:57 Luke Kenneth Casson Leighton:
>>>
>>> I suppose that using custom co-processors/accelerators is an alternative
>>> possibility for video/display, but probably not easy.  Some uses of the
>>> SoC (e.g. micro-servers) probably don't care anyway,
>>
>>
>> yeah they wouldn't.  that U500 would actually make a great EOMA200
>> processor.
>>
>>> but I understand
>>> that it's part of the EOMA68 standard.
>>
>>
>> it's not that, it's that the power requirements to run a separate
>> video IC are just as heavy if not heavier than the actual processor
>> itself.  even just running the PCIe lanes between the video and main
>> processor - driving the voltages up and down - can take up a
>> significant proportion of the EOMA68 power budget.
>
>
> Yeah, got that.
>
> What I meant is that even if many people who would use it as a
> micro-server wouldn't be worried about the lack of video acceleration,
> it always was (AFAIK) a hard requirement for the EOMA68 standard itself
> -- being able to render video at FullHD or similar.

 nono, not at all, that's a misunderstanding: the actual requirement
is about the maximum resolution that the LCD interface has to be
driven at (1366x768 for type II 5mm cards, 1920x1080 for type I 3.3mm
cards).

 an FPGA-based card using a zynq 7030 could do 18-bit or just 15-bit
RGB/TTL and not have any kind of acceleration at all.

 there's even an ATSAM4 that operates at only 200 mhz which has an
RGB/TTL interface: that would qualify... it's just that pricing is
completely mad (somewhere around $9!) so it's not financially viable
or justifiable.

 the IC1t was *barely* able to drive 1024x768 16bpp @ 50hz due to the
internal memory bandwidth: amazingly they used the OpenCores LCD/VGA
library but they didn't update its memory bandwidth.  they were only
expecting people to run it @ 640x480 @ 32bpp, or at most 800x600 @
24bpp, but because the OpenCores VGA driver is publicly documented i
was able to work out how to put it into 8-bit mode (2 bits red, 3 bits
green, 3 bits blue) and because of the reduced internal bus bandwidth
of dropping to one byte per pixel i was actually able to drive all the
way up to 1440x900!  there is even a monochrome mode but i didn't
investigate that.

 so yeah, point is: Full HD (or any kind of 2D or 3D or Video
acceleration at all) is *not* part of the EOMA68 hardware standard.

 at some point i really want to do an Ingenic M150 EOMA68 card and see
how low the BOM can really be pushed.  it'll be a 2-layer PCB (!)
because the M150 is designed for 2-layer.  their EVB is
postage-stamp-sized, it's pretty amazing.

l.