Message-ID: <20140915145203.GK4659@axis.com>
Date:	Mon, 15 Sep 2014 16:52:03 +0200
From:	Jesper Nilsson <jesper.nilsson@...s.com>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	linux-kernel@...r.kernel.org, linux-cris-kernel@...s.com,
	Jesper Nilsson <jespern@...s.com>,
	Mikael Starvik <starvik@...s.com>,
	Grant Likely <grant.likely@...aro.org>,
	"Edgar E. Iglesias" <edgar.iglesias@...il.com>
Subject: Re: Status of 'cris' architecture support in Linux kernel

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.

It is also the ARTPEC-3 SoC that is implemented in QEMU unless I'm mistaken.

> 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.

> 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.

On a tangential note, my automatic (minimal) builds does not do
make install, so I haven't seen this error. :-P

> -----------
> 
> 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. :-(

> -----------------
> 
> 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 :-)

> Toolchain was built successfully with buildroot (after adding cris support to
> it) with above patches / changes.

Thanks again,

/^JN - Jesper Nilsson
-- 
               Jesper Nilsson -- jesper.nilsson@...s.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists