|
Message
From: Jeremy Bennett<jeremy.bennett@e...>
Date: Thu Aug 21 21:04:19 CEST 2008
Subject: [openrisc] linux-2.6.23
On Sun, 2008-08-17 at 16:37 +0200, rich_daddio@y... wrote:
> Hi All,
> Patch linux_2.6.23_or32_unified_simtested.bz2 for or32 & linux-2.6.23
> is available:
>
> Get it at:
> ftp www.meansoffreedom.com
> u: download
> p: download
> cd mof_orsoc
>
> Note: Initially this was planned to be a scrub release, however due to
> the feedback from Jeremy Bennett, the scrub has been pushed to 2.6.24
> which will include the clean-up and Jeremy's ideas.
>
> As usual this was tested using the toolchain and simulator built with
> toolchain script.
> Availbable at:
> http://www.opencores.com/projects.cgi/web/or1k/gnu_toolchain_port
>
> Enjoy,
>
> Rich d
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/openrisc
Hi Rich,
This failed for me out of the box. The problem is with the Ethernet,
since if I take that out of the configuration, everything works fine.
It's just possible this is a simulator problem, although since the issue
is code corruption (see below) that does not seem likely.
Tested on Fedora 9, with GDB 6.8 and Or1ksim 0.2.0 with patches to
support GDB 6.8. Without Ethernet works standalone and through GDB
(which is much quicker now I have done some tuning).
I still get the warning about "/bin/sh: can't access tty; job control
turned off" and double # prompt when using telnet (but not xterm).
With Ethernet, the system hung as follows:
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 2048 (order 0, 8192 bytes)
Installing knfsd (copyright (C) 1996 okir@m...).
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
disabled
serial8250.0: ttyS0 at MMIO 0x90000000 (irq = 2) is a 16550A
console [ttyS0] enabled
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: module loaded
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
^C(sim) r
00009944: 00000000 l.j 0x0 (executed) [cycle 4288328388, #199466680]
00009948: c04bf9c8 l.mtspr r11,r31,0x11c8 (next insn) (delay insn)
GPR00: 00000000 GPR01: c04bf938 GPR02: 00000000 GPR03: c04bf9c8
GPR04: c04bf9c8 GPR05: 00000300 GPR06: 00000000 GPR07: 00000000
GPR08: c0008a60 GPR09: c00099ec GPR10: 00000000 GPR11: 00000000
GPR12: 00000000 GPR13: 00000017 GPR14: 00000052 GPR15: 00002000
GPR16: 0000002c GPR17: e5a1c285 GPR18: 00000300 GPR19: 67ba8ba8
GPR20: c04c81b0 GPR21: f25fb0c7 GPR22: c0278b08 GPR23: c054deac
GPR24: c054dfc8 GPR25: 9204c4df GPR26: 00000000 GPR27: d3b657f8
GPR28: 00000000 GPR29: 0a85e0b6 GPR30: c0284680 GPR31: c00098f8
flag: 0
(sim)
This is corrupted code. It is part of the data_page_fault_handler, but
the code at 0x9944 has been corrupted. The code should look like this:
0xc0009930 <_data_page_fault_handler+56>: l.sw 80(r1),r19
0xc0009934 <_data_page_fault_handler+60>: l.sw 84(r1),r20
0xc0009938 <_data_page_fault_handler+64>: l.sw 88(r1),r21
0xc000993c <_data_page_fault_handler+68>: l.sw 92(r1),r22
0xc0009940 <_data_page_fault_handler+72>: l.sw 96(r1),r23
0xc0009944 <_data_page_fault_handler+76>: l.sw 100(r1),r24
0xc0009948 <_data_page_fault_handler+80>: l.sw 104(r1),r25
0xc000994c <_data_page_fault_handler+84>: l.sw 108(r1),r26
0xc0009950 <_data_page_fault_handler+88>: l.sw 112(r1),r27
0xc0009954 <_data_page_fault_handler+92>: l.sw 116(r1),r28
0xc0009958 <_data_page_fault_handler+96>: l.sw 120(r1),r29
0xc000995c <_data_page_fault_handler+100>: l.sw 124(r1),r30
0xc0009960 <_data_page_fault_handler+104>: l.sw 136(r1),r0
0xc0009964 <_data_page_fault_handler+108>: l.addi r3,r1,0
0xc0009968 <_data_page_fault_handler+112>: l.ori r5,r0,0x300
0xc000996c <_data_page_fault_handler+116>: l.lwz r6,0(r3)
But examination in the simulator shows it looks like this:
i=9930 :: d4019850 l.sw 0x50(r1),r19
i=9934 :: d401a054 l.sw 0x54(r1),r20
i=9938 :: d401a858 l.sw 0x58(r1),r21
i=993c :: d401b05c l.sw 0x5c(r1),r22
i=9940 :: d401b860 l.sw 0x60(r1),r23
i=9944 :: 00000000 l.j 0x0
i=9948 :: c04bf9c8 l.mtspr r11,r31,0x11c8
i=994c :: d401d06c l.sw 0x6c(r1),r26
i=9950 :: 00000300 l.j 0x300
i=9954 :: 00000000 l.j 0x0
i=9958 :: 00000000 l.j 0x0
i=995c :: c0008a60 l.mtspr r0,r17,0x260
i=9960 :: c00099ec l.mtspr r0,r19,0x1ec
i=9964 :: 9c610000 l.addi r3,r1,0x0
i=9968 :: 00000000 l.j 0x0
i=996c :: 84c30000 l.lwz r6,0x0(r3)
(addresses are relocated).
Good news that there are fewer of the section mismatch warnings now.
I did get some warnings from some of the OR32 architecture components:
arch/or32/drivers/open_eth.c: In function `oeth_open':
arch/or32/drivers/open_eth.c:190: warning: passing arg 2 of
`request_irq' from incompatible pointer type
LD arch/or32/drivers/built-in.o
CC arch/or32/board/config.o
arch/or32/board/config.c:133: warning: initialization from incompatible
pointer type
LD arch/or32/board/built-in.o
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o
arch/or32/support/tools/bintoc arch/or32/support/tools/bintoc.c
arch/or32/support/tools/bintoc.c:6: warning: return type defaults to
‘int’
arch/or32/support/tools/bintoc.c: In function ‘main’:
arch/or32/support/tools/bintoc.c:13: warning: implicit declaration of
function ‘exit’
arch/or32/support/tools/bintoc.c:13: warning: incompatible implicit
declaration of built-in function ‘exit’
arch/or32/support/tools/bintoc.c:24: warning: implicit declaration of
function ‘read’
arch/or32/support/tools/bintoc.c:55: warning: incompatible implicit
declaration of built-in function ‘exit’
arch/or32/support/tools/bintoc .initrd <
arch/or32/support/initrd-fb-03.ext2 |/opt/or32/bin/or32-uclinux-as -o
arch/or32/support/initrd.o
Hope this lets you track down the problem. For simulator purposes, the
Ethernet is of little relevance. It might be best to leave it out of the
default configuration (disable in sim.cfg as well). Users can put it
back in if they have real hardware.
ATB,
Jeremy
--
Tel: +44 (1202) 416955
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@e...
Web: www.embecosm.com
|
 |
Browse
