lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aef3568c-7894-49c9-a7aa-b3c58b822b91@linux-m68k.org>
Date: Thu, 11 Jan 2024 00:46:35 +1000
From: Greg Ungerer <gerg@...ux-m68k.org>
To: Rob Landley <rob@...dley.net>, Petr Vorel <pvorel@...e.cz>
Cc: Cyril Hrubis <chrubis@...e.cz>, Geert Uytterhoeven
 <geert@...ux-m68k.org>, ltp@...ts.linux.it, Li Wang <liwang@...hat.com>,
 Andrea Cervesato <andrea.cervesato@...e.com>,
 Jonathan Corbet <corbet@....net>, Randy Dunlap <rdunlap@...radead.org>,
 John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
 Christophe Lyon <christophe.lyon@...aro.org>,
 linux-m68k@...ts.linux-m68k.org, linux-kernel@...r.kernel.org,
 Linux ARM <linux-arm-kernel@...ts.infradead.org>,
 linux-riscv <linux-riscv@...ts.infradead.org>,
 Linux-sh list <linux-sh@...r.kernel.org>,
 automated-testing@...ts.yoctoproject.org, buildroot@...ldroot.org,
 Niklas Cassel <niklas.cassel@....com>
Subject: Re: Call for nommu LTP maintainer [was: Re: [PATCH 00/36] Remove
 UCLINUX from LTP]


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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ