Stefan Kristiansson
2014-09-08 08:02:48 UTC
Hi folks,
I have been trying to get openrisc images to run in qemu for some time now,
with not much success. The basic idea is to run an openrisc Linux kernel
with embedded initrd.
- Kernels compiled with the openrisc toolchain from kernel.org can be loaded
in the upstream version of qemu-system-or32.
- If there is no embedded initrd, the kernel crashes with "no working init found".
So far so good.
Yup ;)I have been trying to get openrisc images to run in qemu for some time now,
with not much success. The basic idea is to run an openrisc Linux kernel
with embedded initrd.
- Kernels compiled with the openrisc toolchain from kernel.org can be loaded
in the upstream version of qemu-system-or32.
- If there is no embedded initrd, the kernel crashes with "no working init found".
So far so good.
- I then built an initrd using busybox. I could not use the toolchain
from kernel.org, so I had to build my own.
I tried various variants. Ultimately, I was able to build a toolchain
from git://openrisc.net/jonas/toolchain. It did not build cleanly,
so I had to
- disable Werror for gcc and binutils
- disable MAKEINFO for binutils
- disable makeinfo enforcement in binutils
- declare libc_hidden_def(strverscmp) to make strverscmp public in uClibc.
- Build busybox with -D__linux__ as the toolchain doesn't define it.
There has been improvements made to the toolchains and at the same timefrom kernel.org, so I had to build my own.
I tried various variants. Ultimately, I was able to build a toolchain
from git://openrisc.net/jonas/toolchain. It did not build cleanly,
so I had to
- disable Werror for gcc and binutils
- disable MAKEINFO for binutils
- disable makeinfo enforcement in binutils
- declare libc_hidden_def(strverscmp) to make strverscmp public in uClibc.
- Build busybox with -D__linux__ as the toolchain doesn't define it.
some things have shifted places, the most recent toolchains are now
hosted on github under the openrisc organization (https://github.com/openrisc).
Instructions on how to build a uclibc based toolchain from these repositories
can be found here:
http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Linux_.28uClibc.29_toolchain_.28or1k-linux-uclibc.29
(binutils has since these instructions were written been upstreamed,
so you could replace or1k-src with a binutils-gdb snapshot,
but or1k-src should work as well).
(For instance, the old uclibc that you used didn't support archs that doesn't
have the "legacy" syscalls, so upstream openrisc kernels wouldn't work
without an additional patch. https://github.com/openrisc/uClibc-or1k doesn't
have this problem).
You can compile the kernel with this toolchain, but also building the kernel
with the old toolchain should work fine.
As an additional sidenote, some of us have started to shift away from
uclibc in favour of musl-libc, but there are a couple of patches needed
to make that work.
After embedding the toolchain into the kernel (essentially based on the
openrisc defconfig), I tried the resulting kernels all the way back to 3.1.
In 3.1 and 3.2, the kernels hang after "Freeing unused kernel memory: 1456k freed".
Hang means I don't get any further output until I kill the qemu session.
With later kernels, I get a number of warning tracebacks. Here is an example
with the latest upstream kernel (3.17-rc2).
WARNING: CPU: 0 PID: 0 at kernel/rcu/tiny.c:90 0xc00460d0()
WARNING: CPU: 0 PID: 0 at kernel/rcu/tiny.c:111 0xc0045fe0()
WARNING: CPU: 0 PID: 0 at kernel/rcu/tiny.c:148 0xc0045d80()
I haven't seen these warnings, and I have tried running 3.17-rc2, but I haveopenrisc defconfig), I tried the resulting kernels all the way back to 3.1.
In 3.1 and 3.2, the kernels hang after "Freeing unused kernel memory: 1456k freed".
Hang means I don't get any further output until I kill the qemu session.
With later kernels, I get a number of warning tracebacks. Here is an example
with the latest upstream kernel (3.17-rc2).
WARNING: CPU: 0 PID: 0 at kernel/rcu/tiny.c:90 0xc00460d0()
WARNING: CPU: 0 PID: 0 at kernel/rcu/tiny.c:111 0xc0045fe0()
WARNING: CPU: 0 PID: 0 at kernel/rcu/tiny.c:148 0xc0045d80()
some local patches applied with stuff I'm working on, so our mileage might vary.
I'll try a "clean" upstream 3.17-rc2 kernel and see if they'll appear here too.
Any idea what I might be doing wrong ? I see messages from others suggesting that
there is a way to run the openrisc kernel, I just seem to be unable to find out
what it is.
Yes, and this is a problem we are aware of, that finding the right waythere is a way to run the openrisc kernel, I just seem to be unable to find out
what it is.
into OpenRISC isn't always straight forward :(
If the newer toolchain doesn't solve the problems, please ping us back.
Stefan