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

[Rob Landley]

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

2) vhdl ethernet driver with corresponding kernel driver. The parts
exist but haven't been wired up for numato with the external ethernet
adapter, we'd need to add a config to the build and define the pinouts,
tweak the device tree to know about it. (Not as big a deal but still
some missing plumbing.)

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

So how they deal with nommu I couldn't even begin to guess. It might
"just work", but I wouldn't count on it. :)

> As someone here pointed out, emacs needs an mmu.  But, I assume (?) a
> distribution build system that will build for J2 will also do J3, so
> the distribution compile time is lost but the build system is reused.

Try Linus's microemacs fork and see how that does:

https://git.kernel.org/cgit/editors/uemacs/uemacs.git/

> Another member of my hackerspace and I are designing an FPGA laptop.
> Goals are that the hardware does not have backdoors, to experiment
> with CPU design, and to expand our skills and resume.  The FPGA, PCB
> design, and signal integrity aspects are new for both of us.  The
> sysadmin aspects are not new for me.  I expect there to be several
> versions of this, each one moving more functions into the FPGA.  The
> first one may use the hard memory controllers on the FPGA.
> Miniaturizing power consumption or enclosure size are not goals.

Sounds very interesting. Please keep us posted. :)

> Brian

Rob