lkml.org 
[lkml]   [2014]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Status of 'cris' architecture support in Linux kernel
On Mon, Sep 15, 2014 at 04:52:03PM +0200, Jesper Nilsson wrote:
> Hi Guenter,
>
> Sorry for not answering earlier, like some have said in
> the thread followups, I have been on parental leave for quite some time.
>
> On Sun, Aug 31, 2014 at 10:50:10AM -0700, Guenter Roeck wrote:
> > The idea was to create a crisv32 kernel and initramfs to work with qemu
> > for the ongoing Linux kernel test project.
>
> A very ambitious goal. :-)
>
> > After spending a number of days (and nights) on it, the results don't look
> > very encouraging.
> >
> > 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.
>
> Your conclusion is not completely off, but it could be better than it looks. :-)
>
> I'll try to explain the state of the CRIS port as it currently stands:
>
> (Background: CRIS port supports 3 different SoC:s, where the CRISv10 is
> older and subsequently less used. The other two are ETRAX FS and ARTPEC-3,
> which in principle share the same CPU-core (CRISv32) but contain some changes to
> the peripheral hardware IPs)
>
> CRISv10 is only supported by me as a hobby project, AXIS does not have any
> current shipping units with this SoC, thus support for this is waning fast.
> QEMU support is not available for this SoC.
> Additionally, newer gcc assumes TLS support, which CRISv10 does not have,
> and older gcc:s yields an ICE (internal compiler error) on newer kernels.
>
> Units with ETRAX FS is no longer actively upgraded by AXIS with newer kernels,
> and I have a problem testing anything other than the AXIS 88 developer board
> (Last relase of the SDK was a couple of years ago with the 2.6.32 kernel IIRC)
> which is not up to date, but at least have a lot in common with ARTPEC-3 and
> so is not so hard to support.
>
> ARTPEC-3 support is not complete as some drivers are not included in upstream
> (ethernet and serial are the most notable ones) but is actually in best shape,
> we have 3.16 booting on real hardware in house.
>
> I'll add the missing drivers and current patches we have locally to a
> git tree on git-hub, I'll get back to you on that.
>
Would be great.

> It is also the ARTPEC-3 SoC that is implemented in QEMU unless I'm mistaken.
>
The only machine supported in qemu is axis-88.

qemu-system-cris -M ?
Supported machines are:
none empty machine
axis-dev88 AXIS devboard 88 (default)

Does that include or imply ARTPEC-3 ?

> > 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.
>
> Thank you for your work, I'll try to add some more information in the hope
> that this will at least help people google for more information.
>
> Feel free to send me an email if you want to pick this up again.
>
Definitely. Being able to build a kernel is great, but it is just as important
to ensure that it is actually working. Otherwise any effort on the architecture
would be just a waste of time.

> > Thanks,
> > Guenter
>
> > ---------------------
> >
> > Individual findings:
> >
> > headers_install
> >
> > make ARCH=cris INSTALL_HDR_PATH=/tmp headers_install
> >
> > results in:
> >
> > ./scripts/Makefile.headersinst:14: arch/cris/include/uapi/asm/arch-v10/Kbuild:
> > No such file or directory
> > make[2]: *** No rule to make target `arch/cris/include/uapi/asm/arch-v10/Kbuild'. Stop.
>
> Yes, known error, I believe that Sam Ravnborg's patch will correct this.
>
Is that patch available in public ? Sam's response seems to suggest that he
sent it to Michael (Mikael ?) who wanted to handle it, but I don't find a
matching patch in public archives.

> On a tangential note, my automatic (minimal) builds does not do
> make install, so I haven't seen this error. :-P
>
Mine not either ;-). I only found it because I tried to build an initramfs
which needs installed headers.

> > -----------
> >
> > 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.
>
> Thanks, I don't have these included in my automatic builds,
> and I note that the cryptocop.c which is gated with ETRAX_STREAMCOPROC
> has a large number of changes in our internal tree as compared to upstream.
>
> > -----------
> >
> > qemu: Attempts to load images in qemu fail.
> >
> > Command line:
> >
> > qemu-system-cris -serial stdio -kernel vmlinux -monitor none \
> > -nographic -append "console=ttyS0,115200,N,8 rdinit=/sbin/init" \
> > -initrd busybox-cris.img
> >
> > This command yields no output; using arch/cris/boot/Image has the same result.
> >
> > With arch/cris/boot/zImage, the result is:
> >
> > Uncompressing Linux...
>
> ... which at least indicates that the uncompress code is running...
>
> >
> >
> > invalid compressed format (err=1)
> >
> > -- System halted
>
> ... but I believe that the image might need to be massaged a bit
> further to be able to boot in QEMU, however it's been some time since
> I last did this. I'll have to get back to you on this.
>
> > ---
> >
> > 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.
>
> Confirmed, the serial driver isn't upstream.
>
:-(

> > 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
> > CPU: 0
> > 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
> > sp: c1ff3dd4
> > 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>]
> > [<c000547e>]
> > 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
> >
> > Manual backtrace:
> >
> > c0004a44 show_stack
> > c01e84e6 printk
> > c000589c show_registers
> > c0004b6e die_if_kernel
> > c0005220 get_mmu_context
> > c0102b94 strcmp
> > c00fb92c idr_get_empty_slot
> > c002922c __init_waitqueue_head
> > c00fbd58 ida_get_new_above
> > c00fb858 ida_pre_get
> > c00fbc02 ida_get_new_above
> > c002922c __init_waitqueue_head
> > c0008896 d_mmu_refill
> > c0102b94 strcmp
> > c00108ce walk_system_ram_range
> > c001029e find_next_iomem_res
> > c0010250 find_next_iomem_res
> > c00be2d6 kclist_add_private
> > c00203f4 parse_args
> > c00108ce walk_system_ram_range
> > c00ff4d8 strcpy
> > c00b81b4 proc_register
> > c00be3b0 kcore_update_ram
> > c00ff4d8 strcpy
> > c0004236 do_one_initcall
> > c00041bc do_one_initcall
> > c00205ae parse_args
> > c00ff4d8 strcpy
> > c00203f4 parse_args
> > c01e6f22 kernel_init
> > c01e6f36 kernel_init
>
> No clue on this though...
>
> > ----------------
> > 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
> > initramfs support).
> >
> > 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.
>
> Unfortunately, the code quality was the original problem why it
> wasn't upstreamed at the same time as the rest of the port,
> and it still hasn't changed in any markable respect. :-(
>
Is your latest kernel (if possible one running with qemu) available anywhere) ?
It would be very useful to be able to access a kernel source which runs with
qemu to have at least a baseline for comparison, even if not everything in it
is in the upstream kernel.

> > -----------------
> >
> > Toolchain
> >
> > Creating a toolchain from upstream sources required a number of patches.
> >
> > Linux headers:
> > - 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]
> >
> > gcc:
> > - 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.
>
> I'm using gcc 4.7.2, but of course, that is a locally built
> version that might have patches not upstream
> (although I doubt it knowing the gcc CRIS maintainer :-)
>
I got 4.9.1 to work (or let's say build) as well after applying another patch
from upstream gcc. Of course that does not help much if I don't get to a point
where I can actually run it.

Guenter


\
 
 \ /
  Last update: 2014-09-15 22:21    [W:0.246 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site