[J-core] How crazy would a nommu debian port be?

[D. Jeff Dionne]

Turtle has as noted below HDMI, and I've tested the hardware.  Turtle also has composite video, which I have not tested.  Making a quick circuit that generates timing for VGA, HDMI or composite video is very simple (a few 10s lines of RTL), the question is really if you want to be able to alter that timing or if it is acceptable to have one or a small number of fixed resolutions (at first, this could be fine).

As Rich says, the DMA engine (which I don't think we've released yet, since there is no hardware that people can buy that could use it yet) can simply feed data into a smallish FIFO and out through any of these interfaces.  That hardware can be very thin, and it is a good idea to use the DMA chain mode to set up a display list to implement e.g. flip buffers or scrolling.  The size of the fifo need not be that large, in FPGA a single block RAM will give you a large enough buffer to allow the DMA block transfer size maximal to reduce overhead, and relax inter-transfer latency requirements.  If you're careful, you could even do sprites or similar.

The issue is drawing into the buffer in the first place.  Rich did some benchmarking on memory copy, and this is a similar problem set.  With come clever programming or hardware, one could get DMA assist on block copy.

But the real win would come from hardware assist on 2D primitives, which X or anything else could use.  That would make for an interesting project, but not something our team here will be able to spend time on, or even look into...

J.

> On Aug 20, 2016, at 1:38 PM, Rich Felker <dalias at libc.org> wrote:
> 
> On Fri, Aug 19, 2016 at 11:21:13AM -0700, Cedric BAIL wrote:
>> On Wed, Aug 10, 2016 at 5:03 PM, Rob Landley <rob at landley.net> wrote:
>>> On 08/10/2016 05:51 PM, Brian Bartholomew wrote:
>>>>> I'm just wondering how much interest there would be out there for
>>>>> something like that. The numato board only has 64M ram and nommu
>>>>> means no swap. I'm not sure how interesting modern debian is to run
>>>>> there?
>>>> 
>>>> If you build it, I will demonstrate it in my hackerspace.
>>> 
>>> Alas building it isn't trivial. Just getting a musl-based x86 debian is
>>> a bit of a challenge. Debian only builds from source under Debian, which
>>> means under an existing glibc-based debian. They have decent support for
>>> populating a chroot directory from existing _binaries_, but their source
>>> build environment is a lot less well documented.
>>> 
>>> Closest I've found to a debian source build guide is the "new package
>>> maintainer's guide":
>>> 
>>>  https://www.debian.org/doc/manuals/maint-guide/
>>> 
>>> Which shows how to turn a source build into a debian package build,
>>> under an existing debian system.
>>> 
>>> (Still easier with Debian than other distros I've looked at, though.)
>>> 
>>>> Getting X11
>>>> up on the VGA connector and ethernet up on the Numato extension board
>>>> would be a more visually compelling demonstration, even though I
>>>> expect X11 performance is not going to be useful.
>>> 
>>> There's two hardware issues there:
>>> 
>>> 1) VHDL vga driver with kernel framebuffer support. I talked about it
>>> with Rich and separately with Jeff, and it's doable but not yet done.
>>> 
>>> The turtle board has HDMI rather than vga, which Jeff actually hooked up
>>> a stub driver to that made a test pattern on the TV (in hardware).
>>> Hooking that up to a framebuffer wouldn't be a huge deal, we just
>>> haven't done it yet. (Main limiting factor is cycling back around to
>>> have the engineering time to do our second round of prototypes and then
>>> launch a kickstarter for Turtle. It's currently looking "Novemberish"
>>> but don't hold me to that.)
>> 
>> Would there be enough room to not just have a simple framebuffer
>> scanout, but maybe a few hardware plane scanout instead ?
> 
> Assuming it's dma-based with framebuffer in dram, which is the
> reasonable design I think, the dma controller should be sufficiently
> powerful to make this question a matter of driver functionality rather
> than hardware functionality. The only question is whether the dma
> chaining latency is sufficiently low to make switching source
> addresses work mid-line or only during hblank, but this can be solved
> with slightly increased buffering if it's a problem.
> 
>>> 3) getting x11 to work. Framebuffer driver's reasonably straightforward
>>> but I have no idea if modern x11 works on nommu at all. (In 2010 I found
>>> that statically linking x11 had bit-rotted pretty badly, although you
>>> could make it work with a large rock and some screaming. It was one of
>>> them "-lone -ltwo -lone -lthree -lone -ltwo -lone" situations because
>>> static linking is one pass that resoles what it needs NOW and moves on
>>> and dynamic linking remembers symbols it saw but didn't need yet, and
>>> the last time anybody had statically linked x11 was during Bill
>>> Clinton's presidency and there were circular dependencies out the wazoo
>>> that took like 5 passes to resolve...)
>> 
>> I have been thinking a bit about this and I would recommend to not go
>> with X11 on such a limited hardware. X11 force a memcpy and that will
>> impact performance in a very visible way.
> 
> Well X should work out of the box with fbdev driver, but if you prefer
> to use wayland that's 
> 
>> Wayland and especially the wayland dmabuf extention
>> (https://github.com/wayland-project/wayland-protocols/blob/master/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml)
>> allow for zero copy from application to screen if the hardware allow
>> it.
> 
> Interesting. I'll read up on it.
> 
>>> So how they deal with nommu I couldn't even begin to guess. It might
>>> "just work", but I wouldn't count on it. :)
>> 
>> EFL shouldn't be hard to get statically linked.
> 
> Static linking is not a requirement and in fact I think you'd quickly
> run out of (non-fragmented, at least) memory with static linking if
> you run multiple apps using large-ish libraries.
> 
>> I am personnally very interested to get Enlightenment setup running on
>> a nommu target. I have been looking for hardware with nommu and a
>> display output, but none of them have any good open source RTOS (not
>> even talking about Linux) support. Most RTOS don't even have a proper
>> framebuffer support, so hopping to get a kms/drm/dmabuf Linux with
>> nommu is a pretty big deal in my opinion (especially because I don't
>> have much time to play with a full new stack, fix drivers and finally
>> do what interest me). Getting a system where I can play in the user
>> space to get this going will be great. So my main question is how much
>> are you guys planning to invest in the display capability ? Will the
>> turtle board come with an easy way to hook a vga adapter ?
> 
> The Turtle has an hdmi port, no vga, though you could put an adapter
> on it if you want. The Numato Mimas v2 board has a vga port, but it
> only has 2/3/2 bits per channel in the dac output, which is pretty
> ugly. You might could remedy this via hardware dithering, i.e. running
> the video clock significantly higher than the actual pixel rate and
> modulating the low bits rapidly to simulate more color depth.
> 
> As far as I know, no work has been done on writing the vhdl for
> driving either of them, but I think the bulk of the work is the
> controller that receives samples over dma and buffers them for output,
> and that's shareable between boards with hdmi output and vga output.
> 
> Rich
> _______________________________________________
> J-core mailing list
> J-core at lists.j-core.org
> http://lists.j-core.org/mailman/listinfo/j-core