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

[Rich Felker]

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