On 1/11/22 12:23, Robert Święcki wrote:
Recently I tried to create a working modern disk image for Linux-SH4.
There were many problems, but I finally managed to pull it off.
If anyone needs a working Debian (unstable/experimental) + kernel
5.15.0 - here're the images/kernels/scripts
You could also create a Debian unstable environment for the sh4 architecture using debootstrap:
suse-laptop:/tmp # debootstrap --no-check-gpg --arch=sh4 --foreign unstable debian-sh4-root http://ftp.ports.debian.org/debian-ports
I: Retrieving InRelease
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
(...)
I: Extracting login...
I: Extracting logsave...
I: Extracting mawk...
I: Extracting mount...
I: Extracting ncurses-bin...
I: Extracting passwd...
I: Extracting perl-base...
I: Extracting sed...
I: Extracting sysvinit-utils...
I: Extracting tar...
I: Extracting util-linux...
I: Extracting zlib1g...
suse-laptop:/tmp #
Then run "./debootstrap/debootstrap --second-stage" on the target system.
If your qemu-user is properly set up to use binfmt (which is currently not the case on my
system), you can omit the "--foreign" option and get a ready-to-boot chroot for Debian sh4.
Recently I tried to create a working modern disk image for Linux-SH4.
There were many problems, but I finally managed to pull it off.
If anyone needs a working Debian (unstable/experimental) + kernel
5.15.0 - here're the images/kernels/scripts
Thanks, I guess I did it the hard way then (through the debian-installer) :)
BTW: some problems I noticed during installation:
- debian-installer for sh4 (probably one of the most recent ones) has
tools compiled with glibc-2.33 but the version of glibc inside (initrd
image) is glibc-2.32, so some tools like mount and part*something
refuse to run with sth like "missing symbol GLIBC_2.33"
- debian-installer comes with kernel version 5.13 or so, and the
pool-sh4 has only 5.15.*-di kernels - I used custom kernel with custom
kernel version (so it matches the -di kernel version)
- older debian-installers for sh4 won't run on r2d with 64MB RAM due
to OOOms. I added some ninja swap images to bypass that. I think newer installers have low-RAM mode, and it works better.
PS: Many years ago I was solving a CTF (Capture The Flag) challenge - https://blog.dragonsector.pl/2014/12/seccon-2014-japanese-super-micro.html
- which was using SH4 for Linux compiled in big-endian mode. I guess
someone went through troubles to compile Linux kernel in big-endian,
and then compiled some userland to big-endian too. Dunno.
Ha.. I didn't. debian's cross-sh4-gcc (I think I tried versions 11 10
8 and 6) doesn't build "working" kernels. Dunno why. It compiles, but
doesn't boot.
In the end I had to compile it myself with one of those https://toolchains.bootlin.com/releases_sh-sh4.html and use it with istaller's initrd.
Fortunately it allowed me to proceed even if the
*-di* modules couldn't be loaded. The only thing I had to do was to
trick the installer into thinking that my custom kernel is the same
kernel version as the *di* version in pool-sh4 via EXTRAVERSION in
kernel's Makefile, because the "anna" thingy stops the installation
process w/o it.
$ ./sh-sh4--glibc--stable/bin/sh4-linux-gcc --version
sh4-linux-gcc.br_real (Buildroot 2017.05) 5.4.0
[ 0.000000] Linux version 5.15.0 (jagger@jd) (sh4-buildroot-linux-gnu-gcc.br_real (Buildroot 2017.05) 5.4.0, GNU ld
(GNU Binutils) 2.27) #37 Tue Jan 11 12:58:34 CET 2022
Thanks, I guess I did it the hard way then (through the debian-installer) :)
BTW: some problems I noticed during installation:
- debian-installer for sh4 (probably one of the most recent ones) has
tools compiled with glibc-2.33 but the version of glibc inside (initrd image) is glibc-2.32, so some tools like mount and part*something
refuse to run with sth like "missing symbol GLIBC_2.33"
I will build updated debian-installer images within the next days which should
fix the problem.
- debian-installer comes with kernel version 5.13 or so, and the
pool-sh4 has only 5.15.*-di kernels - I used custom kernel with custom kernel version (so it matches the -di kernel version)
That will be fixed by an updated image build as well.
- older debian-installers for sh4 won't run on r2d with 64MB RAM due
to OOOms. I added some ninja swap images to bypass that. I think newer installers have low-RAM mode, and it works better.
I never managed to get debian-installer to boot on qemu-sh4-system, did you?
If yes, I would be very interested to learn how you managed to get the kernel to boot in qemu-sh4.
I just compiled with buildroot's newest gcc and it works as well. I'll
do some builds with debian's cross-toolchain of vmlinux and see
whether I can spot anything obvious between those two.
[ 0.000000] Linux version 5.15.0 (jagger@jd) (sh4-buildroot-linux-gnu-gcc.br_real (Buildroot toolchains.bootlin.com-2021.11-1) 10.3.0, GNU ld (GNU Binutils)
2.36.1) #38 Tue Jan 11 15:54:50 CET 2022
[ 0.000000] Linux version 5.15.0 (jagger@jd) (sh4-buildroot-linux-gnu-gcc.br_real (Buildroot 2017.05) 5.4.0, GNU ld
(GNU Binutils) 2.27) #37 Tue Jan 11 12:58:34 CET 2022
Thanks for the information.
If you can find out anything else on the kernel/GCC issue that would be much appreciated. I have been quite stuck on this issue in the past although it works on real hardware.
On 1/11/22 16:00, John Paul Adrian Glaubitz wrote:
Out of curiosity: Does a kernel built using Debian's kernel configuration for
the SH-7751 work with that toolchain?
Extracted it from the Debian package, see attached.
I tried with both sh7785lcr and with sh7751r debian configs and no
luck. So it's a config problem.
I don't know how I got to the conclusion that it's problem with cross-toolchain. Now I tried with Debian's version, and it works. Must
have gotten confused in the process.
[ 0.000000] Linux version 5.15.0 (jagger@jd) (sh4-linux-gnu-gcc
(Debian 6.3.0-18) 6.3.0 20170516, GNU ld (GNU Binutils for Debian) 2.37.50.20220106) #46 Tue Jan 11 16:19:36 CET 2022
I'm attaching my working config. I'll see whether I can bisect it or
spot anything obvious.
I tried with both sh7785lcr and with sh7751r debian configs and no
luck. So it's a config problem.
I don't know how I got to the conclusion that it's problem with cross-toolchain. Now I tried with Debian's version, and it works. Must
have gotten confused in the process.
OK, good to know.
[ 0.000000] Linux version 5.15.0 (jagger@jd) (sh4-linux-gnu-gcc
(Debian 6.3.0-18) 6.3.0 20170516, GNU ld (GNU Binutils for Debian) 2.37.50.20220106) #46 Tue Jan 11 16:19:36 CET 2022
I'm attaching my working config. I'll see whether I can bisect it or
spot anything obvious.
That would be awesome, thanks a lot!
[ 0.000000] Linux version 5.15.0 (jagger@jd) (sh4-linux-gnu-gcc (Debian 6.3.0-18) 6.3.0 20170516, GNU ld (GNU Binutils for Debian) 2.37.50.20220106) #46 Tue Jan 11 16:19:36 CET 2022
I'm attaching my working config. I'll see whether I can bisect it or
spot anything obvious.
That would be awesome, thanks a lot!
Disabling
Kernel Hacking -> Tracers
makes it boot. I'll check which option is responsible exactly.
makes it boot. I'll check which option is responsible exactly.
It seems that pretty much everything must be disabled in this menu - except
"Create a snapshot trace buffer"
in comparison to the default Debian config. All other options (enabled
by default under Debian) seem to enable "yet another options", but my
Kconfig foo is too weak to understand what's going on there.
Then run "./debootstrap/debootstrap --second-stage" on the target system.
If your qemu-user is properly set up to use binfmt (which is currently not the case on my
system), you can omit the "--foreign" option and get a ready-to-boot chroot for Debian sh4.
Thanks, I guess I did it the hard way then (through the debian-installer) :)
In the end I had to compile it myself with one of those
https://toolchains.bootlin.com/releases_sh-sh4.html and use it with
istaller's initrd.
OK, that is very interesting. We need to figure out what the problem with Debian's compiler is what causes the kernel to be non-bootable.
I have already had a discussion with QEMU upstream and we hadn't come up
with a solution yet, so your successful boot with QEMU is a very useful result.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 54:58:06 |
| Calls: | 6,650 |
| Calls today: | 2 |
| Files: | 12,200 |
| Messages: | 5,330,746 |