Discussion:
[ORLinux] Linux on DE0-Nano
Geert Uytterhoeven
2013-11-05 14:15:07 UTC
Permalink
Hi,

I'm trying to play a bit with Linux on OpenRISC using a DE0-Nano board.
Basically I followed the instructions on http://kevinmehall.net/openrisc/guide/.
That works fine (most of the time).

Then I wanted to try a newer kernel. Unfortunately I seem to have stability
issues when starting the kernel, where it crashes before anything is output
on the serial port.
The latest version I managed to run is openrisc-3.11.
The one on master (v3.12-rc1) doesn't boot. I tried to bisect it, but
I got stuck
due to the stability issues.

Success rate is quite good with the v3.4 kernel, but bad with later kernels:

(gdb) jump *0x100
Continuing at 0x100.
^C
Program received signal SIGINT, Interrupt.
0xc000432c in die ()
(gdb) bt
#0 0xc000432c in die ()
#1 0x00000000 in ?? ()
(gdb)

After wiring up _early_uart_init() and _emergency_print() inside printk(),
I get this:

KERNEL: Unaligned Access 0x000000ff
CPU #: 0
PC: 0028c174 SR: 00008279 SP: c0270000
GPR00: 00000000 GPR01: c0270000 GPR02: 00000000 GPR03: 00000000
GPR04: 00000000 GPR05: 00000a81 GPR06: 00001281 GPR07: ffffffff
GPR08: 00000000 GPR09: 0028c0ec GPR10: c026e000 GPR11: 00000000
GPR12: 00000000 GPR13: 00000000 GPR14: 00000010 GPR15: 00000000
GPR16: 00000400 GPR17: 00000000 GPR18: 00000000 GPR19: 00000000
GPR20: 00000000 GPR21: 00000000 GPR22: 00000000 GPR23: 00000000
GPR24: 00002650 GPR25: 000000ff GPR26: 00000050 GPR27: 00000000
GPR28: 00000060 GPR29: 00000000 GPR30: 00008279 GPR31: 0026e000
RES: 00000000 oGPR11: ffffffff
Process swapper (pid: 0, stackpage=c027c2ac)

Stack: Stack dump [0xc026fef4]:
sp + 00: 0xc0270000
sp + 04: 0x00000000
sp + 08: 0x00000000
sp + 12: 0x00000000
sp + 16: 0x00000a81
sp + 20: 0x00001281
sp + 24: 0xffffffff
sp + 28: 0x00000000
sp + 32: 0x0028c0ec
sp + 36: 0xc026e000
sp + 40: 0x00000000
sp + 44: 0x00000000
sp + 48: 0x00000000
sp + 52: 0x00000010
sp + 56: 0x00000000
sp + 60: 0x00000400
sp + 64: 0x00000000
sp + 68: 0x00000000
sp + 72: 0x00000000
sp + 76: 0x00000000
sp + 80: 0x00000000
sp + 84: 0x00000000
sp + 88: 0x00000000
sp + 92: 0x00002650
sp + 96: 0x000000ff
sp + 100: 0x00000050
sp + 104: 0x00000000
sp + 108: 0x00000060
sp + 112: 0x00000000
sp + 116: 0x00008279
sp + 120: 0x0026e000
sp + 124: 0x0028c174
sp + 128: 0xffffffff
sp + 132: 0x00000000
sp + 136: 0x00000000
sp + 140: 0x00000000
sp + 144: 0x00000000
sp + 148: 0x00000000
sp + 152: 0x00000000
sp + 156: 0x00000000
sp + 160: 0x00000000
sp + 164: 0x00000000
sp + 168: 0x00000000
sp + 172: 0x00000000
sp + 176: 0x00000000
sp + 180: 0x00000000
sp + 184: 0x00000000
sp + 188: 0x00000000
sp + 192: 0x00000000
sp + 196: 0x00000000
sp + 200: 0x00000000
sp + 204: 0x00000000
sp + 208: 0x00000000
sp + 212: 0x00000000
sp + 216: 0x00000000
sp + 220: 0x00000000
sp + 224: 0x00000000
sp + 228: 0x00000000
sp + 232: 0x00000000
sp + 236: 0x00000000
sp + 240: 0x00000000
sp + 244: 0x00000000
sp + 248: 0x00000000
sp + 252: 0x00000000
sp + 256: 0x00000000
sp + 260: 0x00000000
sp + 264: 0x00000000

=======================

Code: Bad PC value.

Die:#: 00ff
CPU #: 0
PC: 0028c174 SR: 00008279 SP: c0270000
GPR00: 00000000 GPR01: c0270000 GPR02: 00000000 GPR03: 00000000
GPR04: 00000000 GPR05: 00000a81 GPR06: 00001281 GPR07: ffffffff
GPR08: 00000000 GPR09: 0028c0ec GPR10: c026e000 GPR11: 00000000
GPR12: 00000000 GPR13: 00000000 GPR14: 00000010 GPR15: 00000000
GPR16: 00000400 GPR17: 00000000 GPR18: 00000000 GPR19: 00000000
GPR20: 00000000 GPR21: 00000000 GPR22: 00000000 GPR23: 00000000
GPR24: 00002650 GPR25: 000000ff GPR26: 00000050 GPR27: 00000000
GPR28: 00000060 GPR29: 00000000 GPR30: 00008279 GPR31: 0026e000
RES: 00000000 oGPR11: ffffffff
Process swapper (pid: 0, stackpage=c027c2ac)

Stack: Stack dump [0xc026fef4]:
sp + 00: 0xc0270000
sp + 04: 0x00000000
sp + 08: 0x00000000
sp + 12: 0x00000000
sp + 16: 0x00000a81
sp + 20: 0x00001281
sp + 24: 0xffffffff
sp + 28: 0x00000000
sp + 32: 0x0028c0ec
sp + 36: 0xc026e000
sp + 40: 0x00000000
sp + 44: 0x00000000
sp + 48: 0x00000000
sp + 52: 0x00000010
sp + 56: 0x00000000
sp + 60: 0x00000400
sp + 64: 0x00000000
sp + 68: 0x00000000
sp + 72: 0x00000000
sp + 76: 0x00000000
sp + 80: 0x00000000
sp + 84: 0x00000000
sp + 88: 0x00000000
sp + 92: 0x00002650
sp + 96: 0x000000ff
sp + 100: 0x00000050
sp + 104: 0x00000000
sp + 108: 0x00000060
sp + 112: 0x00000000
sp + 116: 0x00008279
sp + 120: 0x0026e000
sp + 124: 0x0028c174
sp + 128: 0xffffffff
sp + 132: 0x00000000
sp + 136: 0x00000000
sp + 140: 0x00000000
sp + 144: 0x00000000
sp + 148: 0x00000000
sp + 152: 0x00000000
sp + 156: 0x00000000
sp + 160: 0x00000000
sp + 164: 0x00000000
sp + 168: 0x00000000
sp + 172: 0x00000000
sp + 176: 0x00000000
sp + 180: 0x00000000
sp + 184: 0x00000000
sp + 188: 0x00000000
sp + 192: 0x00000000
sp + 196: 0x00000000
sp + 200: 0x00000000
sp + 204: 0x00000000
sp + 208: 0x00000000
sp + 212: 0x00000000
sp + 216: 0x00000000
sp + 220: 0x00000000
sp + 224: 0x00000000
sp + 228: 0x00000000
sp + 232: 0x00000000
sp + 236: 0x00000000
sp + 240: 0x00000000
sp + 244: 0x00000000
sp + 248: 0x00000000
sp + 252: 0x00000000
sp + 256: 0x00000000
sp + 260: 0x00000000
sp + 264: 0x00000000

=======================

Code: Bad PC value.


UNHANDLED_EXCEPTION: entering infinite loop

PC is 0x0028c174:

c028c11c <enable_mmu>:
c028c11c: b7 c0 00 11 l.mfspr r30,r0,0x11
c028c120: 1b 80 00 00 l.movhi r28,0x0
c028c124: ab 9c 00 60 l.ori r28,r28,0x60
c028c128: e3 de e0 04 l.or r30,r30,r28
c028c12c: c0 00 f0 11 l.mtspr r0,r30,0x11
c028c130: 15 00 00 00 l.nop 0x0
c028c134: 15 00 00 00 l.nop 0x0
c028c138: 15 00 00 00 l.nop 0x0
c028c13c: 15 00 00 00 l.nop 0x0
c028c140: 15 00 00 00 l.nop 0x0
c028c144: 15 00 00 00 l.nop 0x0
c028c148: 15 00 00 00 l.nop 0x0
c028c14c: 15 00 00 00 l.nop 0x0
c028c150: 15 00 00 00 l.nop 0x0
c028c154: 15 00 00 00 l.nop 0x0
c028c158: 15 00 00 00 l.nop 0x0
c028c15c: 15 00 00 00 l.nop 0x0
c028c160: 15 00 00 00 l.nop 0x0
c028c164: 15 00 00 00 l.nop 0x0
c028c168: 15 00 00 00 l.nop 0x0
c028c16c: 15 00 00 00 l.nop 0x0
c028c170: 15 00 00 05 l.nop 0x5
--> c028c174: 84 79 00 00 l.lwz r3,0x0(r25)
c028c178: 18 80 d0 0d l.movhi r4,0xd00d
c028c17c: a8 84 fe ed l.ori r4,r4,0xfeed
c028c180: e4 03 20 00 l.sfeq r3,r4
c028c184: 10 00 00 03 l.bf c028c190 <_fdt_found>
c028c188: 15 00 00 00 l.nop 0x0
c028c18c: e3 20 00 04 l.or r25,r0,r0

Oops...

My kernel config is defconfig with the following enabled:
CONFIG_INITRAMFS_SOURCE="arch/openrisc/support/initramfs
arch/openrisc/support/initramfs.devnodes"
CONFIG_INITRAMFS_ROOT_UID=0
CONFIG_INITRAMFS_ROOT_GID=0
CONFIG_OPENRISC_BUILTIN_DTB="de0_nano"
CONFIG_LOCALVERSION_AUTO=y

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Jonas Bonn
2013-11-05 15:01:21 UTC
Permalink
Hi Geert,
Post by Geert Uytterhoeven
Hi,
I'm trying to play a bit with Linux on OpenRISC using a DE0-Nano board.
Basically I followed the instructions on http://kevinmehall.net/openrisc/guide/.
That works fine (most of the time).
Great to have you looking into this stuff! Some more experienced "Linux
eyes" on this code is very much welcome.
Post by Geert Uytterhoeven
c028c11c: b7 c0 00 11 l.mfspr r30,r0,0x11
c028c120: 1b 80 00 00 l.movhi r28,0x0
c028c124: ab 9c 00 60 l.ori r28,r28,0x60
c028c128: e3 de e0 04 l.or r30,r30,r28
c028c12c: c0 00 f0 11 l.mtspr r0,r30,0x11
c028c130: 15 00 00 00 l.nop 0x0
c028c134: 15 00 00 00 l.nop 0x0
c028c138: 15 00 00 00 l.nop 0x0
c028c13c: 15 00 00 00 l.nop 0x0
c028c140: 15 00 00 00 l.nop 0x0
c028c144: 15 00 00 00 l.nop 0x0
c028c148: 15 00 00 00 l.nop 0x0
c028c14c: 15 00 00 00 l.nop 0x0
c028c150: 15 00 00 00 l.nop 0x0
c028c154: 15 00 00 00 l.nop 0x0
c028c158: 15 00 00 00 l.nop 0x0
c028c15c: 15 00 00 00 l.nop 0x0
c028c160: 15 00 00 00 l.nop 0x0
c028c164: 15 00 00 00 l.nop 0x0
c028c168: 15 00 00 00 l.nop 0x0
c028c16c: 15 00 00 00 l.nop 0x0
c028c170: 15 00 00 05 l.nop 0x5
--> c028c174: 84 79 00 00 l.lwz r3,0x0(r25)
See commit dec830189e1e192a80f574243a2dc31bdc1c4fc5. r25 is supposed to
contain a pointer to the FDT at this point... since you're using a
built-in DTB this value will presumably be garbage and there's no sanity
checking on the value.

r3 (see patch) should really contain a "no FDT" value when the kernel is
launched but I don't see that that's being done.

Stefan... any thoughts on this? I take it you never use a built-in
kernel? What does u-boot do if there's no FDT to pass to the kernel?

/Jonas
Stefan Kristiansson
2013-11-05 15:45:56 UTC
Permalink
Post by Geert Uytterhoeven
Hi,
I'm trying to play a bit with Linux on OpenRISC using a DE0-Nano board.
Basically I followed the instructions on
http://kevinmehall.net/openrisc/guide/.
That works fine (most of the time).
Those are slightly dated, but should be fine for most needs.
Post by Geert Uytterhoeven
Then I wanted to try a newer kernel. Unfortunately I seem to have stability
issues when starting the kernel, where it crashes before anything is output
on the serial port.
The latest version I managed to run is openrisc-3.11.
The one on master (v3.12-rc1) doesn't boot. I tried to bisect it, but
I got stuck
due to the stability issues.
(gdb) jump *0x100
Continuing at 0x100.
^C
Program received signal SIGINT, Interrupt.
0xc000432c in die ()
(gdb) bt
#0 0xc000432c in die ()
#1 0x00000000 in ?? ()
(gdb)
After wiring up _early_uart_init() and _emergency_print() inside printk(),
KERNEL: Unaligned Access 0x000000ff
CPU #: 0
PC: 0028c174 SR: 00008279 SP: c0270000
GPR00: 00000000 GPR01: c0270000 GPR02: 00000000 GPR03: 00000000
GPR04: 00000000 GPR05: 00000a81 GPR06: 00001281 GPR07: ffffffff
GPR08: 00000000 GPR09: 0028c0ec GPR10: c026e000 GPR11: 00000000
GPR12: 00000000 GPR13: 00000000 GPR14: 00000010 GPR15: 00000000
GPR16: 00000400 GPR17: 00000000 GPR18: 00000000 GPR19: 00000000
GPR20: 00000000 GPR21: 00000000 GPR22: 00000000 GPR23: 00000000
GPR24: 00002650 GPR25: 000000ff GPR26: 00000050 GPR27: 00000000
GPR28: 00000060 GPR29: 00000000 GPR30: 00008279 GPR31: 0026e000
RES: 00000000 oGPR11: ffffffff
Process swapper (pid: 0, stackpage=c027c2ac)
<snip>
Post by Geert Uytterhoeven
Code: Bad PC value.
UNHANDLED_EXCEPTION: entering infinite loop
c028c11c: b7 c0 00 11 l.mfspr r30,r0,0x11
c028c120: 1b 80 00 00 l.movhi r28,0x0
c028c124: ab 9c 00 60 l.ori r28,r28,0x60
c028c128: e3 de e0 04 l.or r30,r30,r28
c028c12c: c0 00 f0 11 l.mtspr r0,r30,0x11
c028c130: 15 00 00 00 l.nop 0x0
c028c134: 15 00 00 00 l.nop 0x0
c028c138: 15 00 00 00 l.nop 0x0
c028c13c: 15 00 00 00 l.nop 0x0
c028c140: 15 00 00 00 l.nop 0x0
c028c144: 15 00 00 00 l.nop 0x0
c028c148: 15 00 00 00 l.nop 0x0
c028c14c: 15 00 00 00 l.nop 0x0
c028c150: 15 00 00 00 l.nop 0x0
c028c154: 15 00 00 00 l.nop 0x0
c028c158: 15 00 00 00 l.nop 0x0
c028c15c: 15 00 00 00 l.nop 0x0
c028c160: 15 00 00 00 l.nop 0x0
c028c164: 15 00 00 00 l.nop 0x0
c028c168: 15 00 00 00 l.nop 0x0
c028c16c: 15 00 00 00 l.nop 0x0
c028c170: 15 00 00 05 l.nop 0x5
--> c028c174: 84 79 00 00 l.lwz r3,0x0(r25)
c028c178: 18 80 d0 0d l.movhi r4,0xd00d
c028c17c: a8 84 fe ed l.ori r4,r4,0xfeed
c028c180: e4 03 20 00 l.sfeq r3,r4
c028c184: 10 00 00 03 l.bf c028c190 <_fdt_found>
c028c188: 15 00 00 00 l.nop 0x0
c028c18c: e3 20 00 04 l.or r25,r0,r0
Oops...
What is happening at that point is that the pointer to the fdt is read,
it is passed to the kernel via r3 and r3 is saved into r25 as the first
instruction at _start.
So, if you're loading the kernel with gdb, you have to ensure that r3
contains a sane value (0 should be fine) before you boot.

Hope that helps.

Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openrisc.net/pipermail/linux/attachments/20131105/b63f7481/attachment.html>
Geert Uytterhoeven
2013-11-05 18:27:27 UTC
Permalink
On Tue, Nov 5, 2013 at 4:45 PM, Stefan Kristiansson
Post by Stefan Kristiansson
Post by Geert Uytterhoeven
--> c028c174: 84 79 00 00 l.lwz r3,0x0(r25)
c028c178: 18 80 d0 0d l.movhi r4,0xd00d
c028c17c: a8 84 fe ed l.ori r4,r4,0xfeed
c028c180: e4 03 20 00 l.sfeq r3,r4
c028c184: 10 00 00 03 l.bf c028c190 <_fdt_found>
c028c188: 15 00 00 00 l.nop 0x0
c028c18c: e3 20 00 04 l.or r25,r0,r0
Oops...
What is happening at that point is that the pointer to the fdt is read,
it is passed to the kernel via r3 and r3 is saved into r25 as the first
instruction at _start.
So, if you're loading the kernel with gdb, you have to ensure that r3
contains a sane value (0 should be fine) before you boot.
Hope that helps.
Yes it does!

"set $r3 = 0" in gdb does the trick.

Thanks, happily running Jonas' 3.12 now...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Loading...