From: Rob Landley <rob@landley.net>
To: chase rayfield <cusbrar1@gmail.com>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Sam Ravnborg <sam@ravnborg.org>, Arnd Bergmann <arnd@arndb.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
Sparc kernel list <sparclinux@vger.kernel.org>,
Linux-sh list <linux-sh@vger.kernel.org>
Subject: Re: Old platforms: bring out your dead
Date: Mon, 11 Jan 2021 18:26:38 -0600 [thread overview]
Message-ID: <1f6e936c-4947-4952-fae2-c05d03e0cd2c@landley.net> (raw)
In-Reply-To: <CACwypyNS+fVoPVspSr36v8YjFbkrnYb+amcYRqVmA2kD2uD1Wg@mail.gmail.com>
On 1/11/21 8:55 AM, chase rayfield wrote:
> On Mon, Jan 11, 2021 at 3:09 AM John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
>
>>
>> I'm not sure I understand the reasoning for doing this. The SPARC architecture
>> isn't going to see any new hardware developments in the future after Oracle
>> let go of most of the SPARC developers. So it's not that we need to make room
>> for new hardware.
>>
> My take is that there *would* be more interest in Sparc sun4m / Sun4d
> from enthusiasts at the very least if it was possible to actually boot
> the bloat hog that is Linux these days in a fully usable configuration
> that probably means some modifications to SILO and Linux required.
You can trim current linux down a bit, it's just non-obvious how. Unfortunately
there's an "expert" menu and CONFIG_EMBEDDED and if you touch anything there's
suddenly a hundred extra options in your config with no explanation of what they do.
At least 50% of what you want is probably disabling the printk strings that
aren't visible at your default verbosity level, but alas you must open pandora's
box to access those options...
> The problem is as I understand it, SILO only sets up a 16Mb mapping
> (either due to having to assume 4MB minimum dram stick size or due to
> mapping limitations not sure, most of these machines have at least
> 16MB in slot one...these days though that wasn't the case for sun4c),
> loads Linux into it and says good Luck. This isn't enough for a modern
> kernel with any hardware support built in. So you might for instance
> get a kernel to fit but only if you dropped all of networking support
> etc... I'm guessing the fix for this would be to modify silo to map a
> larger amount in a way that Linux expects so it can remap it as it
> likes, or just have SILO map the full memory as Linux would. Anyway
> that is THE main demotivation for these architectures.... otherwise
> they have plenty of ram and performance to do basic router/server
> tasks sans SSL.
A lot of people with hardware like this haven't stopped using it, they've just
stopped fighting with kernel upgrades. (Common issue in the embedded world. Not
really a fun thing for security, but )
> This has been the status quo for since the last of the 2.6 series of
> kernels which it was still possible to just barely squeeze a usable
> kernel out of... If someone wanted to take a few hours and fix this
> issue, and keep these architectures around I'd be happy to "buy them a
> round of pizza", though I recognize that many people that work on this
> already have nice jobs, and just don't have time.
My https://github.com/landley/toybox/blob/master/scripts/mkroot.sh ~250 line
bash script generates the simplest kernel configs for a bunch of platforms to
boot qemu to a shell prompt, but you then have to open the "expert" menu and
_disable_ stuff in order to get the size down from there.
> Also Sparc would probably be a good project for someone to extend/test
Sparc has a runtime relocation I've never understood but did manage to break
once, resulting in a long thread to fix:
http://lists.landley.net/pipermail/aboriginal-landley.net/2011-December/001964.html
Between that and the weird save half the stack register thing with function
calls on some sort of "wheel"... there's a _reason_ I haven't been able to talk
Rich into adding support for it to musl.
> Andi Keen's Linux LTO patch set so we could reduce the kernel binary
> size that way also even if sun4 architectures are dropped, it would
> still be useful for embedded sparc. Also there is a port of Temlib to
> the Mister hardware now, 3 cores roughly equivalent to a mid 90s
> machine, at least 128MB ram is possible ( more if a way to map the ARM
> system memory also 1GB is available there, it would have higher
> latency though).
>
> It is perfectly viable to build Sparc v7 or v8 32bit binaries in a
> chroot on a fast machine also, and I would recommend this if you wish
> to retain sanity rather than attempting cross compiler voodoo, unless
> that is your thing.
It is, sadly, my thing. The above 250 line bash script builds:
aarch64 armv7l i686 mips powerpc s390x x86_64
armv4l armv7m m68k mips64 powerpc64 sh2eb
armv5l i486 microblaze mipsel powerpc64le sh4
That's toybox booting to a shell prompt and a linux kernel configured for qemu
for each target. Adding new targets looks something like:
elif [ "$TARGET" == m68k ]; then
QEMU="m68k -M q800" KARCH=m68k KARGS=ttyS0 VMLINUX=vmlinux
KCONF=MMU,M68040,M68KFPU_EMU,MAC,SCSI_MAC_ESP,MACINTOSH_DRIVERS,ADB,ADB_MACII,NET_CORE,MACSONIC,SERIAL_PMACZILOG,SERIAL_PMACZILOG_TTYS,SERIAL_PMACZILOG_CONSOLE
elif [ "$TARGET" = s390x ]; then
QEMU="s390x" KARCH=s390 VMLINUX=arch/s390/boot/bzImage
KCONF=MARCH_Z900,PACK_STACK,NET_CORE,VIRTIO_NET,VIRTIO_BLK,SCLP_TTY,SCLP_CONSOLE,SCLP_VT220_TTY,SCLP_VT220_CONSOLE,S390_GUEST
(Well, modulo thunderbird being unable to an indent a line that goes off the
right edge of the screen. The mozilla foundation somehow managed to spend half a
billion dollars in 2019 but it wasn't on thunderbird, I can tell you that.)
Anyway, I wrote a couple FAQ entries trying to explain the worst of it:
https://landley.net/toybox/faq.html#cross
https://landley.net/toybox/faq.html#mkroot
> Anyways it could be that people that want this get around to fixing
> SILO eventually and just sit on this last kernel version... *shrugs*
They're never sitting on the _last_ kernel version. They're generally way back
from there. Been true forever off of x86 (and now arm):
https://lore.kernel.org/lkml/201002211025.11588.rob@landley.net/T/
> Chase
Rob
next prev parent reply other threads:[~2021-01-12 0:40 UTC|newest]
Thread overview: 122+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-08 22:55 Old platforms: bring out your dead Arnd Bergmann
2021-01-08 23:32 ` Steven Rostedt
2021-01-09 22:04 ` Arnd Bergmann
2021-01-08 23:44 ` Thomas Bogendoerfer
2021-01-09 0:16 ` Linus Walleij
2021-01-09 17:32 ` Florian Fainelli
2021-01-09 21:59 ` Arnd Bergmann
2021-01-09 5:56 ` Willy Tarreau
2021-01-09 21:52 ` Arnd Bergmann
2021-01-10 6:21 ` Willy Tarreau
2021-01-10 10:44 ` Russell King - ARM Linux admin
2021-01-11 9:50 ` David Laight
2021-01-13 10:27 ` Andy Shevchenko
2021-01-13 12:02 ` Linus Walleij
2021-01-13 12:17 ` Andy Shevchenko
2021-01-13 12:21 ` Andy Shevchenko
2021-01-15 0:03 ` Bernd Petrovitsch
2021-01-15 0:24 ` William Breathitt Gray
2021-01-15 8:59 ` David Laight
2021-01-13 12:30 ` William Breathitt Gray
2021-01-13 12:56 ` William Breathitt Gray
2021-01-13 13:44 ` Arnd Bergmann
2021-02-04 21:01 ` Pavel Machek
2021-02-05 9:13 ` David Laight
2021-02-05 9:29 ` Pavel Machek
2021-01-09 17:34 ` Florian Fainelli
2021-01-09 21:18 ` Arnd Bergmann
2021-01-09 17:43 ` Russell King - ARM Linux admin
2021-01-09 21:34 ` Arnd Bergmann
2021-01-11 20:09 ` Russell King - ARM Linux admin
2021-01-09 20:19 ` Baruch Siach
2021-01-09 21:19 ` Arnd Bergmann
[not found] ` <67171E13-6786-4B44-A8C2-3302963B055F@gmail.com>
2021-01-09 22:20 ` Arnd Bergmann
2021-01-10 18:12 ` Fabian Vogt
2021-01-10 19:20 ` Arnd Bergmann
2021-01-10 21:33 ` Linus Walleij
2021-01-11 0:33 ` Russell King - ARM Linux admin
2021-01-11 12:32 ` Arnd Bergmann
2021-01-11 12:36 ` Russell King - ARM Linux admin
2021-01-09 23:12 ` Andrew Lunn
2021-01-10 8:45 ` Arnd Bergmann
2021-01-10 16:46 ` Andrew Lunn
2021-01-10 17:27 ` Arnd Bergmann
2021-01-10 19:51 ` Andrew Lunn
2021-01-10 15:51 ` Neil Armstrong
2021-01-10 15:56 ` Arnd Bergmann
2021-01-10 17:35 ` John Paul Adrian Glaubitz
2021-01-10 21:46 ` Sam Ravnborg
2021-01-11 8:05 ` John Paul Adrian Glaubitz
2021-01-11 14:55 ` chase rayfield
2021-01-12 0:26 ` Rob Landley [this message]
2021-01-12 0:50 ` chase rayfield
2021-01-12 14:37 ` John Paul Adrian Glaubitz
2021-01-11 18:09 ` Rob Landley
2021-01-11 15:04 ` Gerhard Pircher
2021-01-12 14:44 ` John Paul Adrian Glaubitz
2021-01-12 22:46 ` Linus Walleij
2021-01-13 8:09 ` Rob Landley
2021-01-13 8:21 ` Geert Uytterhoeven
2021-01-13 13:25 ` Rob Landley
2021-01-13 12:02 ` Andy Shevchenko
2021-01-13 8:15 ` Geert Uytterhoeven
2021-01-13 10:39 ` Arnd Bergmann
2021-01-14 3:54 ` New platforms: bring out your dead, was " Finn Thain
2021-01-14 9:41 ` John Paul Adrian Glaubitz
2021-01-14 9:48 ` Geert Uytterhoeven
2021-01-14 21:21 ` Arnd Bergmann
2021-01-14 22:54 ` Undesirable code, was Re: Old platforms etc Finn Thain
2021-01-14 23:09 ` Old platforms: bring out your dead Max Filippov
2021-01-15 8:31 ` Arnd Bergmann
2021-01-13 0:12 ` Old platforms never die, was " Finn Thain
2021-01-16 6:54 ` Rob Landley
2021-01-16 23:22 ` Finn Thain
2021-01-13 11:47 ` Andy Shevchenko
2021-01-11 1:39 ` Daniel Palmer
2021-01-11 9:15 ` John Paul Adrian Glaubitz
2021-01-11 9:20 ` Geert Uytterhoeven
2021-01-11 9:26 ` John Paul Adrian Glaubitz
2021-01-11 9:36 ` Geert Uytterhoeven
2021-01-11 9:50 ` Greg Ungerer
2021-01-11 9:42 ` Daniel Palmer
2021-01-11 10:13 ` Arnd Bergmann
2021-01-11 8:19 ` Geert Uytterhoeven
2021-01-11 8:59 ` Arnd Bergmann
2021-01-11 9:16 ` Geert Uytterhoeven
2021-01-11 10:28 ` Geert Uytterhoeven
2021-01-11 10:37 ` Arnd Bergmann
2021-01-11 9:40 ` Thomas Bogendoerfer
2021-01-11 10:34 ` Arnd Bergmann
2021-01-11 8:40 ` efm32 is dead [Was: Old platforms: bring out your dead] Uwe Kleine-König
2021-01-11 11:10 ` Old platforms: bring out your dead Viresh Kumar
2021-01-11 19:59 ` Arnd Bergmann
2021-01-11 21:15 ` Mattias Wallin
2021-01-11 21:47 ` Arnd Bergmann
2021-01-11 13:13 ` Marc Gonzalez
2021-01-11 17:29 ` Måns Rullgård
2021-01-11 21:50 ` Arnd Bergmann
2021-01-12 8:23 ` Marc Gonzalez
2021-01-11 14:22 ` Mark Salter
2021-01-11 15:00 ` Arnd Bergmann
2021-01-11 14:44 ` Alexander Shiyan
2021-01-11 14:58 ` Arnd Bergmann
2021-01-11 16:23 ` Sylvain Lemieux
2021-01-11 22:17 ` Alexandre Belloni
2021-01-11 19:58 ` Thomas Petazzoni
2021-01-11 20:10 ` Arnd Bergmann
2021-01-11 20:25 ` Song Bao Hua (Barry Song)
2021-01-12 8:41 ` Marc Gonzalez
2021-01-13 10:30 ` Andy Shevchenko
2021-01-13 11:02 ` Arnd Bergmann
2021-01-13 16:14 ` [v2] " Arnd Bergmann
2021-01-13 19:00 ` Krzysztof Hałasa
2021-01-14 8:51 ` Arnd Bergmann
2021-01-15 7:08 ` Wei Xu
2021-01-15 9:26 ` Arnd Bergmann
2021-01-15 11:09 ` Leizhen (ThunderTown)
2021-01-15 12:04 ` Arnd Bergmann
2021-01-18 10:46 ` Wei Xu
2021-01-13 22:27 ` Richard Z
2021-02-05 13:37 ` Alexander Lobakin
2021-10-23 17:44 ` Maciej W. Rozycki
2021-01-12 2:05 tedheadster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1f6e936c-4947-4952-fae2-c05d03e0cd2c@landley.net \
--to=rob@landley.net \
--cc=arnd@arndb.de \
--cc=cusbrar1@gmail.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-sh@vger.kernel.org \
--cc=sam@ravnborg.org \
--cc=sparclinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).