On 1/17/23 14:26, Geert Uytterhoeven wrote: > Hi Rob, > > On Tue, Jan 17, 2023 at 8:01 PM Rob Landley <rob@xxxxxxxxxxx> 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:
linux-fullconfig.gz
Description: application/gzip
# 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
