OPENCORES.ORG

On Sun, 2008-08-17 at 16:37 +0200, rich_daddio at yahoo.com wrote:

Hi Jeremy,
That's not good... Could you send me your linux .config. 

The "job control" message should not be a problem, IIRCC this is due
to a missing entry on the ramdisk which I will try and fix next
release. This message and the double prompt have been with us for a
long time. 

Right now, all I really have time for is to get the releases out. I am
having some userland problems with 2.6.24 currently so I will try and
iron out some of the userside issues with the next release include
double prompt and "job control".

The crash concerns me so if you could send me the .config ASAP I would
appreciate it. I will try and look at it this weekend (along with 6.8
--I know I know!!)  :) Have a great weekend.

Thanks & BR,

Rich d

----- Original Message ----- 
From: Jeremy Bennett<jeremy.bennett@e...> 
To: 
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 at yahoo.com 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 at monad.swb.de). 
> 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 at embecosm.com Web: www.embecosm.com 
> 