Re: remove arch/sh

[Rob Landley <rob@landley.net>]

[-- Attachment #1: Type: text/plain, Size: 7466 bytes --]



On 1/17/23 14:26, Geert Uytterhoeven wrote:
> Hi Rob,
> 
> On Tue, Jan 17, 2023 at 8:01 PM Rob Landley <rob@landley.net> wrote:
>> On 1/16/23 01:13, Christoph Hellwig wrote:
>> > On Fri, Jan 13, 2023 at 09:09:52AM +0100, John Paul Adrian Glaubitz wrote:
>> >> I'm still maintaining and using this port in Debian.
>> >>
>> >> It's a bit disappointing that people keep hammering on it. It works fine for me.
>> >
>> > What platforms do you (or your users) use it on?
>>
>> 3 j-core boards, two sh4 boards (the sh7760 one I patched the kernel of), and an
>> sh4 emulator.
>>
>> I have multiple j-core systems (sh2 compatible with extensions, nommu, 3
>> different kinds of boards running it here). There's an existing mmu version of
>> j-core that's sh3 flavored but they want to redo it so it hasn't been publicly
>> released yet, I have yet to get that to run Linux because the mmu code would
>> need adapting, but the most recent customer projects were on the existing nommu
>> SOC, as was last year's ASIC work via sky130.
> 
> J4 still vaporware?

The 'existing mmu version' is the theoretical basis for J4 (the move from J3 to
J4 is tiny from an instruction set perspective, it was more about internal chip
architecture, primarily multi-issue with tomasulo). It exists, but we haven't
had a product that uses it and the engineer who was tasked to work on it got
reassigned during the pandemic.

The real problem is the existing implementation is a branch off of an older SOC
version so repotting it to the current tree (which among other things builds
under a different VHDL toolchain) is some work. The "conflict requiring actual
staring at" isn't the MMU, it's the instruction cancellation logic that backs
out half-finished instructions when the MMU complains partway through an
instruction that's multiple steps of microcode, so we have to back _out_ what
it's already done so it can be cleanly restarted after handling the fault.
That's got merge conflicts all over the place with the current stuff...

Not actually _hard_, but not something we've sat down and done. We spent those
cycles last year working on an ASIC implementation through Google's Sky130
OpenLane/OpenRoad stuff (see https://github.com/j-core/openlane-vhdl-build for
our in-house toolchain build for that; Google passes around a magic docker that
most people use, we trimmed off most of the dependencies and build it in a clean
debootstrap). And that was trying to make an ASIC out of the small simple
version, because Google's entire asic/skywater partnership was... fraught?

We also tried to get the previous generation of ASIC tools to work before giving
up and trying to get what Google was working on to work:

  https://landley.net/notes-2022.html#26-01-2022
  https://landley.net/notes-2022.html#28-01-2022

We targeted "known working SOC that we've been using a long time" to try to make
a physical silicon chip out of (and the first version isn't even the J2 2xSMP
SOC with all the cache and peripherals, it was a derivative of the ICE40 port
that's single processor running straight from SRAM with no DRAM controller), on
the theory we can always do a more complicated one later an what we were really
trying to establish here is that Google's ASIC development tools and process
could be made to work. (Which is kind of a heavy lift, they burned two shuttles
full of mostly dead chips that we know of before admitting "those timing
annotations we were talking about actually DO need to go all the way through"...
Jeff has the URLs to the bug reports in OpenLane/Road's github...)

(Sorry, one of OpenLane/OpenRoad is the DARPA project out of Sandia National
Laboratory, and the other is Google doing a large extremely complicated thing
analogous to the AOSP build on top of Darpa's work using a lot different
programming languages and FOREST of build and runtime package dependencies, and
I can never remember which is which. The Google thing is the one distributed in
a docker because it's considered impossible to build rom source by everybody
except us, because we're funny that way. And added VHDL support instead of just
Verilog so needed to rebuild from source anyway to do that.)

>> My physical sh4 boards are a Johnson Controls N40 (sh7760 chipset) and the
>> little blue one is... sh4a I think? (It can run the same userspace, I haven't
>> replaced that board's kernel since I got it, I think it's the type Glaubitz is
>> using? It's mostly in case he had an issue I couldn't reproduce on different
>> hardware, or if I spill something on my N40.)
>>
>> I also have a physical sh2 board on the shelf which I haven't touched in years
>> (used to comparison test during j2 development, and then the j2 boards replaced it).
>>
>> I'm lazy and mostly test each new sh4 build under qemu -M r2d because it's
>> really convenient: neither of my physical boards boot from SD card so replacing
>> the kernel requires reflashing soldered in flash. (They'll net mount userspace
>> but I haven't gotten either bootloader to net-boot a kernel.)
> 
> On my landisk (with boots from CompactFLASH), I boot the original 2.6.22
> kernel, and use kexec to boot-test each and every renesas-drivers
> release.  Note that this requires both the original 2.6.22 kernel
> and matching kexec-tools.

I make it a point to run _current_ kernels in all my mkroot systems, including
sh4. What I shipped was 6.1 is:

# cat /proc/version
Linux version 6.1.0 (landley@driftwood) (sh4-linux-musl-cc (GCC) 9.4.0, GNU ld
(GNU Binutils) 2.33.1) #1 Tue Jan 10 16:32:07 CST 2023

At the JCI contract where I got the N40 I forward ported the kernel version to a
release that was I think 2 back from the current release because there was a
race condition in the flash support I didn't have time to track down? (Only
showed up under sustained load so the test case took hours to run, and we had a
ship schedule...)

I've been meaning to get together with somebody to get the blue board updated,
but I've been busy with other things...


> Apparently both upstreamed kernel and
> kexec-tools support for SH are different, and incompatible with each
> other, so you cannot kexec from a contemporary kernel.

Sure you can. Using toybox's insmod and modprobe, anyway. (That's the target I
tested those on... :)

Haven't messed with signing or compression or anything yet, my insmod is just
doing syscall(SYS_finit_module) and then falling back to SYS_init_module if that
fails and either fd was 0 or errno was ENOSYS. (Don't ask me why
SYS_finit_module doesn't work on stdin...)

https://github.com/landley/toybox/blob/master/toys/other/insmod.c#L31

https://landley.net/toybox/downloads/binaries/0.8.9/toybox-sh4

> I tried working my way up from 2.6.22, but gave up around 2.6.29.
> Probably I should do this with r2d and qemu instead ;-)

I have current running there. I've had current running there for years. Config
attached...

> Both r2d and landisk are SH7751.

Cool. Shouldn't be hard to get landisk running current then.

> Probably SH7722/'23'24 (e.g. Migo-R and Ecovec boards) are also
> worth keeping.  Most on-SoC blocks have drivers with DT support,
> as they are shared with ARM.  So the hardest part is clock and
> interrupt-controller support.

J-core is using device tree already. Shouldn't be hard to do a device tree for
the qemu version, and then for landisk.

> Unfortunately I no longer have access to the (remote) Migo-R.

There's more stuff in Japan, but that's a Jeff question...

Rob

[-- Attachment #2: linux-fullconfig.gz --]
[-- Type: application/gzip, Size: 11830 bytes --]

[-- Attachment #3: linux-miniconfig --]
[-- Type: text/plain, Size: 1342 bytes --]

# make ARCH=sh allnoconfig KCONFIG_ALLCONFIG=linux-miniconfig
# make ARCH=sh -j $(nproc)
# boot arch/sh/boot/zImage


# architecture 0
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_RD_GZIP=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT2=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_UTF8=y
CONFIG_MISC_FILESYSTEMS=y
CONFIG_SQUASHFS=y
CONFIG_SQUASHFS_XATTR=y
CONFIG_SQUASHFS_ZLIB=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IPV6=y
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
CONFIG_NETCONSOLE=y
CONFIG_ETHERNET=y
CONFIG_COMPAT_32BIT_TIME=y
CONFIG_EARLY_PRINTK=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y

# architecture specific
CONFIG_CPU_SUBTYPE_SH7751R=y
CONFIG_MMU=y
CONFIG_VSYSCALL=y
CONFIG_SH_FPU=y
CONFIG_SH_RTS7751R2D=y
CONFIG_RTS7751R2D_PLUS=y
CONFIG_SERIAL_SH_SCI=y
CONFIG_SERIAL_SH_SCI_CONSOLE=y
CONFIG_PCI=y
CONFIG_NET_VENDOR_REALTEK=y
CONFIG_8139CP=y
CONFIG_PCI=y
CONFIG_BLK_DEV_SD=y
CONFIG_ATA=y
CONFIG_ATA_SFF=y
CONFIG_ATA_BMDMA=y
CONFIG_PATA_PLATFORM=y
CONFIG_BINFMT_ELF_FDPIC=y
CONFIG_BINFMT_FLAT=y

# architecture specific
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y

CONFIG_FSCACHE=m
CONFIG_CACHEFILES=m

CONFIG_MEMORY_START=0x0c000000