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

[Cedric BAIL]

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 ?

<snip>

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

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. To my knowledge there is only one toolkit that does implement
wl_dmabuf as a software backend (and also provide a drm/kms software
backend), Enlightenment Foundation Libraries
(https://www.enlightenment.org/). I have been running EFL, but not
Enlightenment/wayland, on a nommu arm system a few years back without
much trouble.

The reason why I asked if it is possible to provide hardware plane, is
that with 3 hardware planes, you can dedicate one for the compositor
background, one for the active application and one for the foreground.
Allowing zero copy not just for full screen application, but also for
just the active application. This would give some decent performance
over being forced to do compositing. Ideally if you can provide a
total of 6 hardware planes, even the application could use it to speed
up scrolling (In that case, you really want to have a clip and color
multiplier per hardware plane). I would bet that 640*480*32bpp is a
really doable rendering target and should be usable. Of course, it
shouldn't be able to do web stuff, but displaying a few controls,
doing IRC and a ssh terminal should be in the possibility of such a
hardware. Maybe some remote display with low or no compression could
be also doable.

> 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. For Enlightenment may
require more work as I don't think their is an option to statically
compile all the module, but it should be definitively doable as the
module infrastructure provide that for the rest of the stack
(Enlightenment being a wayland compositor able to run on a framebuffer
and also on a drm/kms in software, you wouldn't need anything else
than that to have multiple application on screen).

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 ?

Regards,
-- 
Cedric BAIL