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

[Cedric BAIL]

On Fri, Aug 19, 2016 at 10:02 PM, D. Jeff Dionne
<Jeff at se-instruments.co.jp> wrote:
> 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).

Well, HDMI is kind of an overkill, but if it is there, it is
definitively enough :-) As for a small number of fixed resolutions,
does that means we could change the supported resolution in the VHDL
and just rebuild it to match the output ? Or would it requires more
work ? If it would be the first case, I believe that would be
perfectly fine in my opinion.

> 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.

I haven't played with VHDL in a decade, and never with real hardware
(FPGA) only simulation... This would be an interesting project to look
at. Will need serious recommendation on what to read and where to
start. It would maybe be a good thing to have some guidance page on
the web site. Like recommended documentation to read, example and
coding style.

> 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.

Yes, I am expecting that. memcpy and memset are usually the limit on
every hardware when doing graphics anyway. That's why the most
important technic is to not draw anything if possible :-) Partial
update and hardware plane are usually the best helper there. If you
look at your screen how many pixels do really change at once. That's
the only thing your CPU really need to work on. With clever UI design
and proper cut off on the useless drawing, a J2 should provide enough
possibility, but you are indeed pointing to an interesting point.
Would it be possible to speedup memcpy and memset with some DMA assist
? It is usually not possible as the cost of going into the kernel and
setting up MMU destroy all possible gain, but maybe on a J2 it makes
sense.

Also do you have any idea of the energy consumption of the J2 on an
ASIC ? I am believing it should be pretty low right now. If it is the
case, it really could be an interesting target for wearable display.

> 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...

Hum, I don't know. Today, none of the major toolkit use X primitive
and they are badly supported by all major GPU driver. I don't even
know if a 2D raster accelerator (something that would allow arbitrary
line compositing) would be beneficial, as the maintenance and porting
of pixman and cairo will be quite tricky. It may be easier to maintain
some hardware acceleration for decompressing jpeg/png as that doesn't
evolve over time and the API of the related libraries are really
stable. This would likely speedup startup time of any
desktop/application and be more maintenable over time. The main
question would be, could that fit inside the Turtle FPGA along with
the DMA hadrware plane ?

Thanks,
  Cedric

> 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
>
>



-- 
Cedric BAIL