Status of 'cris' architecture support in Linux kernel
From: Guenter Roeck
Date: Sun Aug 31 2014 - 13:50:47 EST
The idea was to create a crisv32 kernel and initramfs to work with qemu
for the ongoing Linux kernel test project.
After spending a number of days (and nights) on it, the results don't look
My overall conclusion is that 'cris' architecture support in the Linux kernel
is in bad shape, does not work anymore, and would require substantial effort
to get it into working state.
Anyway, below are my individual findings. If there is an ongoing effort to
improve cris support in the upstream kernel, specifically support for crisv32,
please let me know. I'll be happy to test the resulting kernels.
make ARCH=cris INSTALL_HDR_PATH=/tmp headers_install
No such file or directory
make: *** No rule to make target `arch/cris/include/uapi/asm/arch-v10/Kbuild'. Stop.
Trying to enable architecture specific drivers:
Enabling ETRAX_I2C or ETRAX_STREAMCOPROC results in compile errors.
The errors date back as far as 2.6.27 and are thus not the result
of later API changes. I did not attempt to enable any other functionality.
qemu: Attempts to load images in qemu fail.
qemu-system-cris -serial stdio -kernel vmlinux -monitor none \
-nographic -append "console=ttyS0,115200,N,8 rdinit=/sbin/init" \
This command yields no output; using arch/cris/boot/Image has the same result.
With arch/cris/boot/zImage, the result is:
invalid compressed format (err=1)
-- System halted
Research shows that there is a working image and root file system at the
qemu web site. Further research shows that this image includes code which
was never merged upstream. The missing code includes (at least) early console
support as well as support for the crisv32 serial interface.
After some digging, I found at least some of the code in out-of-tree sources.
After adding early console support, there is console output, but the image
crashes with the following log message.
NET: Registered protocol family 16
Switched to clocksource crisv32_rotime
Unable to handle kernel NULL pointer dereferenceOops: 0000
ERP: c001029e SRP: c00108ce CCS: 00028008 USP: 00000000 MOF: 00000000
r0: c0230660 r1: c1ff3e7c r2: 00000014 r3: 00000001
r4: c1ff3e88 r5: c1ffffff r6: c0102b94 r7: 00000000
r8: c1ff3e58 r9: c1ff3e80 r10: c1ff3e7c r11: c0230660
r12: 00000001 r13: 80000200 oR10: c1ff3e7c acr: 00000018
Data MMU Cause: 00000100
Instruction MMU Cause: 00000000
Process swapper (pid: 1, stackpage=c1ff1c40)
Stack from c1ff3cbc:
c0004a44 c01e84e6 c1ff3e20 c1ff3e28 00000000 c1ffffff c1ff3cf8 c000589c
00000018 00000000 c1ff3dd4 00000000 00000000 00000000 c1ff3e88 c1ff3d04
c0004b6e c0293bb0 c1ff3dcc c0005220 00000000 c0230660 c1ff3e7c 00000014
Call Trace: [<c0004a44>] [<c01e84e6>] [<c000589c>] [<c0004b6e>] [<c0005220>] [<c0102b94>] [<c00fb92c>]
[<c002922c>] [<c00fbd58>] [<c00fb858>] [<c00fbc02>] [<c002922c>] [<c0008896>] [<c0102b94>] [<c00108ce>]
[<c001029e>] [<c0010250>] [<c00be2d6>] [<c00203f4>] [<c00108ce>] [<c00ff4d8>] [<c00b81b4>] [<c00be3b0>]
[<c00ff4d8>] [<c0004236>] [<c00041bc>] [<c00205ae>] [<c00ff4d8>] [<c00203f4>] [<c01e6f22>] [<c01e6f36>]
Code: 04 29 0f 00 43 36 68 30 18 21 14 22 (62) 2a c0 22 32 30 b0 05 0c 21 6f fa
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
I did not attempt to bisect the problem.
I got an earlier kernel, 2.6.27, to proceed further, though I did not attempt
to load initramfs (the kernel had a missing symbol when I tried to enable
I was able to find the serial driver for crisv32 in an out-of-kernel tree
and port it to 2.6.27 to the point where it loads. I did not attempt to do
this with the current upstream kernel, as it crashed before it gets to
the point of trying to load the driver.
The crisv32 serial driver (or at least the version I found) is far from
acceptable for upstream integration and would require major cleanup or even
rewrite effort if it was to be merged upstream. The version I found is from
a 2.6.26 kernel, while the kernel version at the qemu web site (binary only)
is 2.6.33, so the driver I worked with is not the latest version and may
have been improved later. However, the result was not published, or I was
unable to find it.
Creating a toolchain from upstream sources required a number of patches.
- Fix the basic headers_install problem mentioned above
- Export ptrace.h
- Some post-processing after installing the headers; specifically,
create a couple of symlinks in the headers directory
usr/include/arch-v10/arch -> usr/include/arch [for crisv10]
usr/include/arch-v32/arch -> usr/include/arch [for crisv32]
- binutils 2.24
- uclibc 0.9.33.2
- gcc 4.7.4
Requires a backport from upstream gcc to compile.
Later versions of gcc (4.8.3, 4.9.1) fail with internal compiler errors
even after patching.
Toolchain was built successfully with buildroot (after adding cris support to
it) with above patches / changes.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/