Message

Reply | Reply all

Date Prev | Date Next | Thread Prev | Thread Next Date Index | Thread Index

From: Jeremy Bennett<jeremy.bennett@e...>
Date: Thu Jul 24 09:55:42 CEST 2008
Subject: [openrisc] What tag version of the RTL should I use that matches the or1k-sim?
Hi Flavio,

I've run the program and single stepped it. It executes correctly for
me. I ran interactively with the command:

or32-uclinux-sim -i -f sim.cfg vmlinux

Here is the executed.log file:

r3 =00000001 00000100 l.ori r3,r0,0x1
r3 =00000001 00000104 l.mtspr r0,r3,0x11
r3 =f0000000 00000108 l.movhi r3,0xf000
r3 =f0000118 r3 =f0000118 0000010c l.ori r3,r3,0x118
r3 =f0000118 00000110 l.jr r3
00000114 l.nop 0
f0000118 l.jal 0x83d
f000011c l.nop 0
r3 =93000000 f000220c l.movhi r3,0x9300

Here are a few of the step instructions:

(sim) t
0000010c: a8630118 l.ori r3,r3,0x118 (executed) [cycle 40, #4]
00000110: 44001800 l.jr r3 (next insn)
GPR00: 00000000 GPR01: 00000000 GPR02: 00000000 GPR03: f0000118
GPR04: 00000000 GPR05: 00000000 GPR06: 00000000 GPR07: 00000000
GPR08: 00000000 GPR09: 00000000 GPR10: 00000000 GPR11: 00000000
GPR12: 00000000 GPR13: 00000000 GPR14: 00000000 GPR15: 00000000
GPR16: 00000000 GPR17: 00000000 GPR18: 00000000 GPR19: 00000000
GPR20: 00000000 GPR21: 00000000 GPR22: 00000000 GPR23: 00000000
GPR24: 00000000 GPR25: 00000000 GPR26: 00000000 GPR27: 00000000
GPR28: 00000000 GPR29: 00000000 GPR30: 00000000 GPR31: 00000000
flag: 0
(sim) t
00000110: 44001800 l.jr r3 (executed) [cycle 50, #5]
00000114: 15000000 l.nop 0 (next insn) (delay insn)
GPR00: 00000000 GPR01: 00000000 GPR02: 00000000 GPR03: f0000118
GPR04: 00000000 GPR05: 00000000 GPR06: 00000000 GPR07: 00000000
GPR08: 00000000 GPR09: 00000000 GPR10: 00000000 GPR11: 00000000
GPR12: 00000000 GPR13: 00000000 GPR14: 00000000 GPR15: 00000000
GPR16: 00000000 GPR17: 00000000 GPR18: 00000000 GPR19: 00000000
GPR20: 00000000 GPR21: 00000000 GPR22: 00000000 GPR23: 00000000
GPR24: 00000000 GPR25: 00000000 GPR26: 00000000 GPR27: 00000000
GPR28: 00000000 GPR29: 00000000 GPR30: 00000000 GPR31: 00000000
flag: 0
(sim) t
00000114: 15000000 l.nop 0 (executed) [cycle 60, #6]
f0000118: 0400083d l.jal 0x83d (next insn)
GPR00: 00000000 GPR01: 00000000 GPR02: 00000000 GPR03: f0000118
GPR04: 00000000 GPR05: 00000000 GPR06: 00000000 GPR07: 00000000
GPR08: 00000000 GPR09: 00000000 GPR10: 00000000 GPR11: 00000000
GPR12: 00000000 GPR13: 00000000 GPR14: 00000000 GPR15: 00000000
GPR16: 00000000 GPR17: 00000000 GPR18: 00000000 GPR19: 00000000
GPR20: 00000000 GPR21: 00000000 GPR22: 00000000 GPR23: 00000000
GPR24: 00000000 GPR25: 00000000 GPR26: 00000000 GPR27: 00000000
GPR28: 00000000 GPR29: 00000000 GPR30: 00000000 GPR31: 00000000
flag: 0
(sim) t
f0000118: 0400083d l.jal 0x83d (executed) [cycle 70, #7]
f000011c: 15000000 l.nop 0 (next insn) (delay insn)
GPR00: 00000000 GPR01: 00000000 GPR02: 00000000 GPR03: f0000118
GPR04: 00000000 GPR05: 00000000 GPR06: 00000000 GPR07: 00000000
GPR08: 00000000 GPR09: f0000120 GPR10: 00000000 GPR11: 00000000
GPR12: 00000000 GPR13: 00000000 GPR14: 00000000 GPR15: 00000000
GPR16: 00000000 GPR17: 00000000 GPR18: 00000000 GPR19: 00000000
GPR20: 00000000 GPR21: 00000000 GPR22: 00000000 GPR23: 00000000
GPR24: 00000000 GPR25: 00000000 GPR26: 00000000 GPR27: 00000000
GPR28: 00000000 GPR29: 00000000 GPR30: 00000000 GPR31: 00000000
flag: 0

I notice you have the Ethernet configured - my application note builds
Linux without this configured and disables the Ethernet entry in the
config file. This is a material difference to the configuration in my
application note.

I then ran using your command (i.e. not interactively) and Linux booted
fine for me. On my machine (a low end Core 2 Duo) it took about 1 minute
to get from the "Ok, booting the kernel." to the UART being initialized
so other output could appear. Here's the output from the telnet session
connected to port 10084:

-------

[sim-jpb-0001.c) (gcc version 4.2.2) #1 Wed
Jul 16 17:34:42 PDT 2008
Detecting Processor units:
Signed 0x391
Setting up paging and PTEs.
write protecting ro sections (0xc0002000 - 0xc024e000)
Setting up identical mapping (0x80000000 - 0x90000000)
Setting up identical mapping (0x92000000 - 0x92002000)
Setting up identical mapping (0xb8070000 - 0xb8072000)
Setting up identical mapping (0x97000000 - 0x97002000)
Setting up identical mapping (0x99000000 - 0x9a000000)
Setting up identical mapping (0x93000000 - 0x93002000)
Setting up identical mapping (0xa6000000 - 0xa6100000)
Setting up identical mapping (0x1e50000 - 0x1fa0000)
dtlb_miss_handler c00040c8 itlb_miss_handler c00041a8 Built 1 zonelists. Total pages: 3953 Kernel command line: root=/dev/ram console=ttyS0 PID hash table entries: 128 (order: 7, 512 bytes) start_kernel(): bug: interrupts were enabled early Console: colour dummy device 80x25 Dentry cache hash table entries: 4096 (order: 1, 16384 bytes) Inode-cache hash table entries: 2048 (order: 0, 8192 bytes) Memory: 26568k/31744k available (2213k kernel code, 5176k reserved, 252k data, 112k init, 0k highmem) Mount-cache hash table entries: 1024 checking if image is initramfs...it isn't (bad gzip magic numbers); looks like an initrd Freeing initrd memory: 2048k freed NET: Registered protocol family 16 NET: Registered protocol family 2 IP route cache hash table entries: 256 (order: -3, 1024 bytes) TCP established hash table entries: 1024 (order: -1, 4096 bytes) TCP bind hash table entries: 512 (order: -2, 2048 bytes) TCP: Hash tables configured (established 1024 bind 512) TCP reno registered eth0: Open Ethernet Core Version 1.0 rcu-torture:--- Start of test: nreaders=2 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval = 5 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 2048 (order 0, 8192 bytes) Installing knfsd (copyright (C) 1996 sim-jpb-0001.c). 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 RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize loop: loaded (max 8 devices) TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 RAMDISK: ext2 filesystem found at block 0 RAMDISK: Loading 2048KiB [1 disk] into ram disk... done. VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 112k freed init started: BusyBox v1.7.5 (2008-04-26 13:18:58 EDT) starting pid 22, tty '': '/etc/init.d/rcS' Please press Enter to activate this console. ----- There is then a problem with the UART. Here's what happens: ----- starting pid 24, tty '': '/bin/sh' BusyBox v1.7.5 (2008-04-26 13:18:58 EDT) built-in shell (ash) Enter 'help' for a list of built-in commands. /bin/sh: can't access tty; job control turned off # # stty -echo serial8250: too much work for irq2 serial8250: too much work for irq2 serial8250: too much work for irq2 serial8250: too much work for irq2 serial8250: too much work for irq2 serial8250: too much work for irq2 serial8250: too much work for irq2 serial8250: too much work for irq2 serial8250: too much work for irq2 serial8250: too much work for irq2 ----- I believe this is due to two bugs in the Linux kernel UART setup and microsecond timers. The serial driver gets flooded with interrupts. Both are fixed in the Embecosm patch. Do you have this patch applied? Interestingly I don't get the problem if I use an xterm rather than telnet for the UART connection (modified sim.cfg attached). ----- Please press Enter to activate this console. starting pid 24, tty '': '/bin/sh' BusyBox v1.7.5 (2008-04-26 13:18:58 EDT) built-in shell (ash) Enter 'help' for a list of built-in commands. /bin/sh: can't access tty; job control turned off # ls ls bin etc linuxrc root tmp var dev home proc sbin usr # stty -echo stty -echo # ls /proc 1 2 bus iomem self 10 24 cmdline ioports slabinfo 11 27 cpuinfo kcore stat 12 3 crypto kmsg sys 13 4 devices loadavg sysrq-trigger 14 5 diskstats locks sysvipc 15 6 driver meminfo tty 16 7 execdomains misc uptime 17 8 filesystems mounts version 18 9 fs net vmstat 19 buddyinfo interrupts partitions zoneinfo # ----- I don't know why the "/bin/sh: can't access tty; job control turned off" message appears. I hope this is useful. Jeremy - Tel: +44 (1202) 416955 Cell: +44 (7970) 676050 SkypeID: jeremybennett Email: sim-jpb-0001.c Web: www.embecosm.com -----Original Message----- From: Flavio M. De Paula <sim-jpb-0001.c> To: sim-jpb-0001.c, List about OpenRISC project <sim-jpb-0001.c> Subject: Re: [openrisc] What tag version of the RTL should I use that matches the or1k-sim? Date: Mon, 21 Jul 2008 20:31:06 -0700 (PDT) Hi Jeremy, I assumed you're original architect/developer of or1ksim. OK, in this case I will also share whatever I find. You can download the linux image and the sim.cfg file used from: www.cs.ubc.ca/~depaulfm/or1ksim_files.tar.bz2 Please, let me know if you have any issue accessing them. The command I used was pretty straight forward: or32-uclinux-sim -f sim.cfg vmlinux > Your description of FLASH is correct - there is no address translation > on load. However I've never used logging, so I don't know if it works. > Can you single step the simulator, so you can see the successive > changes? That will show immediately if the PC is changing to 0xf0000118. I think the cpu is outputting 0xf0000118. As far as I understand now, or1ksim is really tied to the 'mc' module (memory controller). Unless, there is another config option that I need to set up and that I'm not aware of. If I disable 'mc' nothing happens -- the executed.log outputs fetched addresses 0x100 and 0x104 in an endless loop fashion. I've even tried simple code to test this argument. Please, let me know if this is really true or just some misunderstanding in my part. > I'm not aware of any default initialization of either MMU. Linux boot up > has code which sets it up for Linux, so I guess that is what you will > need to do. Rich Daddio suggested me to take a look at the *.ld files. That's the place where we can set up the final addresses for the relocatable code. But I'm a little bit concerned that it won't matter given that it seems or1ksim needs 'mc' always enabled. I'll see how far I can go... > I've fixed some bugs and written up what I did, so others can learn from > it. I'm very happy to share what I've learned about Or1ksim, but there's > still a great deal about it which I do not know. Let me know if you want me to try something for you. Thanks for all the help. -------------- next part -------------- A non-text attachment was scrubbed... Name: sim-jpb.cfg Type: text/x-csrc Size: 20238 bytes Desc: not available Url : sim-jpb-0001.c