On Sun, Sep 07, 2014 at 11:44:28AM -0700, Guenter Roeck wrote: > 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. > > Here is where I am: > > - 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 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 time 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 have 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 way into OpenRISC isn't always straight forward :( If the newer toolchain doesn't solve the problems, please ping us back. Stefan _______________________________________________ Linux mailing list Linux@lists.openrisc.net http://lists.openrisc.net/listinfo/linux
