Re: Call for nommu LTP maintainer [was: Re: [PATCH 00/36] Remove UCLINUX from LTP]

From: Greg Ungerer
Date: Wed Jan 10 2024 - 09:46:50 EST



On 10/1/24 15:47, Rob Landley wrote:
On 1/9/24 17:17, Greg Ungerer wrote:
On 10/1/24 06:24, Rob Landley wrote:
I'm a bit weird in that I try to get CURRENT stuff to work on nommu, and a lot
of people have been happy to consume my work, but getting any of them to post
directly to linux-kernel is like pulling teeth.

I regularly test nommu configurations (as in every kernel rc and release) on m68k
and at least every release on other architectures like arm(*) and recently on
riscv as well.

Sigh, I should start caring about riscv. I added or1k support, I should do
riscv. (Except I did or1k because I found it in actual hardware, the Orange Pi
3b's power controller is an or1k asic so I needed an or1k toolchain to build
some of u-boot's firmware or else the board couldn't reboot, and there was a
qemu-system-or1k already, which turned into adding it to mkroot via a long
https://lore.kernel.org/openrisc/ZX1xbs_AGdgLgcx7@antec/ thread with its
developers. Alas I still can't get qemu to exit (I.E. virtually reboot or power
off), apparently I need to reinstall my laptop to have a new enough version of
python 3 to build a newer qemu with. It's on the todo list...)

I still have a hard time considering riscv anything other than open source's
version of Itanium. Promises of ubiquity, but even a 28 nanometer mask is still
6 figures before you run any wafers and your mask build process is sucking in
all the black box libraries the fab can sell you, so what does "open" really get
you here? Cortex-m got cheap when the superh patents expired so Arm didn't have
to pay royalties to hitachi (renesas?) for the thumb instruction set anymore,
and they belt those suckers en masse amortizing the up-front costs over ENORMOUS
volume.

And yes, j-core was trying to fix the closed source library and toolchain issues
back when I was still working with them. Among other things fishing
Google/skywater's openlane toolchain build out of their magic docker and
reproducing it under a vanilla debootstrap, ala
https://github.com/j-core/openlane-vhdl-build (As with most corporate
clusterfscks, once you dig far enough it turns out you can throw over 90% of it
out...)

But these days I'm trying to get toybox to 1.0...

(*) somewhat annoyingly needing a minor patch to run the versatile qemu platform
I like to test with. But hey, that is on me :-)

I would very much like to add more nommu targets to mkroot, can I get your
build/config info offline? (I tried fishing configs out of buildroot a couple
years ago, but after the THIRD one where the secret was "use very old versions
of packages, the current stuff is broken"... And the problems were things like
"the conversion to device tree deleted a huge chunk of this infrastructure", not
simple fixes.)

Maybe getting a little off-topic here, but I'll just send links here.
Who knows it might be useful to others.

Recently I have been experimenting with minimal builds, this is a bunch of
scripts, configs and a couple of patches I currently have:

https://github.com/gregungerer/simple-linux

Mostly the kernel builds use the architecture defconfigs, but for armnommu
versatile it was easier to use a dedicated config and patch:

https://github.com/gregungerer/simple-linux/blob/master/configs/linux-6.6-armnommu-versatile.config
https://github.com/gregungerer/simple-linux/blob/master/patches/linux-6.6-armnommu-versatile.patch

Anyway the scripting uses the newest package versions of everything
(binutils, gcc, linux, uClibc, busybox).

Regards
Greg