Nabble - OpenCores - RISC

simulating the ORPSOC

2009-11-17T01:14:03Z

Hello I try to simulate the ORPSOC.I have installed the Icarus simulator. In the subdirectory sim i run the command make simulate and i have an error : Pas de régle pour fabriquer la cible simulate. Have you an idea about this problem? Thanks .

patching or1ksim 0.3.0 in an1

2009-11-12T01:09:02Z

hi :
I was trying to pach the or1ksim.0.3.0 as in the an1, but i got some errors. i noticed that the patch embecosm-or32-or1ksim-0.2.0-lib-patch.bz2 is for or1ksim-0.2.0, but mine is or1ksim.0.3.0, anyone know how to solve this problem, thx a lot.

error in compiling demo_or32_sw

2009-11-06T08:52:59Z

hello I want to compile a simple application on the openrisc. The open rsc toolchain has been build. I dowwnload the simple application of Hello world from http://opencores.org/openrisc,downloads . when i extract the demo_or32_sw.zip and i pick to this directory ( demo_or32_sw) and i run the command " make all" i obtain this message : ~/Documents/demo_or32_sw$ make all --- Assembling BootReset.S --- or32-elf-gcc -g -c -Wunknown-pragmas -mhard-mul -msoft-div -msoft-float -o BootReset.o BootReset.S make: or32-elf-gcc : commande introuvable make: *** [BootReset.o] Erreur 127 please can you help me.

simulate the open risc

2009-11-05T06:09:23Z

Hello I work on a Ubunto machine. I installed the tool chain and the simaulator of the openrisc , and all it's fine. Now i downloaded the open risc processor and smply i want to simulate the processor with the hello word program. How can i procede. Thanks.

building and installing binutils

2009-11-04T15:03:44Z

hello i started using openrisc. To installe the simulator and the toolchain , i referred to this document http://www.embecosm.com/appnotes/ean2/embecosm-or1k-setup-ean2-issue-3.html I create the directory opt and then the subdirectory or32. I download the binutils to opt/or32 and i followed the guide.But when i build the binutils , i didn't find a bin directory which contain the indicated command :or32-uclinux-addr2line ,or32-uclinux-ar, or32-uclinux-as..... I want to note that when i run the ../binutils-2.16.1/configure --target=or32-uclinux --prefix=/opt/or32 the chek of or32-uclinux-addr2line ,or32-uclinux-ar, or32-uclinux-as.....is not found. I will be greatful for help

Re: Minimal configuration for Spartan-3E Starter Kit board

2009-06-18T15:29:42Z

Hi

thanks for your great project .

i have the same board spartan-3E 500 ;and when i doawnload the bitsream withe usb cable ;i have Read’ and ‘Expected’ values only sometimes different like this with jtag parallel cable III:

[root@localhost jtag]# ./jp1 xpc3 9999
Connected to parallel port at 378
Dropping root privileges.
Read npc = 00000004 ppc = 00000000 r1 = 00000000
Expected npc = 4000000c ppc = 40000024 r1 = 00000005
Read npc = 00000000 ppc = 00000004 r1 = 00000000
Expected npc = 4000000c ppc = 40000024 r1 = 00000008
Read npc = 00000010 ppc = 0000000c r1 = 00000001
Expected npc = 40000024 ppc = 40000020 r1 = 0000000b
Read npc = 00000000 ppc = 00000000 r1 = 00000000
Expected npc = 40000020 ppc = 4000001c r1 = 00000018
Read npc = 00000010 ppc = 00000014 r1 = 00000001
Expected npc = 4000001c ppc = 40000018 r1 = 00000031
Read npc = 0000001c ppc = 00000018 r1 = 00000001
Expected npc = 40000020 ppc = 4000001c r1 = 00000032
Read npc = 00000000 ppc = 00000000 r1 = 00000000
Expected npc = 40000010 ppc = 4000000c r1 = 00000063
Read npc = 00000018 ppc = 00000000 r1 = 00000000
Expected npc = 40000024 ppc = 40000020 r1 = 00000065
Read npc = 00000020 ppc = 00000024 r1 = 00000001
Expected npc = 4000000c ppc = 40000024 r1 = 000000c9
result = 5eaddb85
Dropping root privileges.
JTAG Proxy server started on port 9999
Press CTRL+c to exit.

[root@localhost jtag]# ./jp1 xpc3 9999
Connected to parallel port at 378
Dropping root privileges.
Read npc = 0000000c ppc = 00000008 r1 = 00000001
Expected npc = 4000000c ppc = 40000024 r1 = 00000005
Read npc = 0000000c ppc = 00000008 r1 = 00000001
Expected npc = 4000000c ppc = 40000024 r1 = 00000008
Read npc = 00000000 ppc = 00000000 r1 = 00000000
Expected npc = 40000024 ppc = 40000020 r1 = 0000000b
Read npc = 00000000 ppc = 00000000 r1 = 00000000
Expected npc = 40000020 ppc = 4000001c r1 = 00000018
Read npc = 00000000 ppc = 00000000 r1 = 00000000
Expected npc = 4000001c ppc = 40000018 r1 = 00000031
Read npc = 00000000 ppc = 00000000 r1 = 00000000
Expected npc = 40000020 ppc = 4000001c r1 = 00000032
Read npc = 00000020 ppc = 00000020 r1 = 0021ca23
Expected npc = 40000010 ppc = 4000000c r1 = 00000063
Read npc = 00000000 ppc = 00000000 r1 = 00000000
Expected npc = 40000024 ppc = 40000020 r1 = 00000065
Read npc = 00000024 ppc = 00000024 r1 = 0021ca23
Expected npc = 4000000c ppc = 40000024 r1 = 000000c9
result = 5ef16fa1
Dropping root privileges.
JTAG Proxy server started on port 9999
Press CTRL+c to exit.

////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////

and in gdb i receve this

[root@localhost hello-uart]# or32-uclinux-gdb hello.or32
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=or32-uclinux"...
(gdb) target jtag jtag://localhost:9999
Remote or1k debugging using jtag://localhost:9999
0x0 in ?? ()
(gdb) load
Loading section .vectors, size 0x128 lma 0x0
Loading section .text, size 0x348 lma 0x2000
Loading section .data, size 0x4 lma 0x2348
Loading section .rodata, size 0x1c lma 0x234c
Start address 0x2000 , load size 1168
Transfer rate: 467 bits/sec, 233 bytes/write.
(gdb) set $pc=0x100
(gdb) continue
Continuing.
warning: Invalid exception occured.

Program received signal ?, Unknown signal.
0x0 in ?? ()
(gdb)

thanks.lol

Serge Vakulenko wrote:

Hello,

I developed a minimal configuration of OR1K for Spartan-3E Starter Kit
board. Hello-uart is running fine. You can download the sources and
BIT image from here: http://vak.ru/pub/fpga/s3esk-openrisc.tgz

The configuration contains OpenRISC 1200 and a limited set of
OpenCores peripherals: UART16550, debug interface, and 16 kbytes of
internal FPGA block RAM.

Data/instruction caches, MMU and are disabled (lack of BlockRAMs).
Multiply-Accumulate instruction is also disabled (it takes 6% of slices).
The clock is decreased to 5MHz. Probably I was too pessimistic here...

To recompile the system from sources, you need Xilinx ISE Webpack
Linux version to be installed. Just run:

make

and all the synthesis passes will be executed in order (xst, ngdbuild,
map, par, trce, bitgen) resulting in "or1k-mini.bit" file.

Device utilization summary:
Selected Device : 3s500efg320-4

Number of Slices: 2734 out of 4656 58%
Number of Slice Flip Flops: 1725 out of 9312 18%
Number of 4 input LUTs: 5113 out of 9312 54%
Number used as logic: 5081
Number used as RAMs: 32
Number of IOs: 9
Number of bonded IOBs: 9 out of 232 3%
Number of BRAMs: 14 out of 20 70%
Number of MULT18X18SIOs: 3 out of 20 15%
Number of GCLKs: 3 out of 24 12%
___
Regards,
Serge Vakulenko
_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

ORP_SOC in Spartan-3E500

2009-06-18T14:53:04Z

Hi

i am etudiant ;so i have some problem with my projet orp_soc (or1200 ;debug;uart;onchip_ram)
i want just runing the message "hello world" in terminalle (redhat 9)

i have Spartan-3E500 .

so in first i used the document "openrisc-tutorial-Xilinx softawre and hardware"

i enable : `define OR1200_XILINX_RAMB16
i enable : `define OR1200_RFRAM_GENERIC

i used corgene for generate onchip_ram (8 - 4096)

i download the bitsream in the board ( ise 9.2i) usb cable.

but when i type ./jp1 xpc3 9999 => Read’ and ‘Expected’ values are sometimes different

[root@localhost jtag]# ./jp1 xpc3 9999
Connected to parallel port at 378
Dropping root privileges.
Read npc = 00000004 ppc = 00000000 r1 = 00000000
Expected npc = 4000000c ppc = 40000024 r1 = 00000005
Read npc = 00000000 ppc = 00000004 r1 = 00000000
Expected npc = 4000000c ppc = 40000024 r1 = 00000008
Read npc = 00000004 ppc = 00000000 r1 = 00000000
Expected npc = 40000024 ppc = 40000020 r1 = 0000000b
Read npc = 00000000 ppc = 00000004 r1 = 00000000
Expected npc = 40000020 ppc = 4000001c r1 = 00000018
Read npc = 00000020 ppc = 00000024 r1 = 00000000
Expected npc = 4000001c ppc = 40000018 r1 = 00000031
Read npc = 00000018 ppc = 0000001c r1 = 00000000
Expected npc = 40000020 ppc = 4000001c r1 = 00000032
Read npc = 00000018 ppc = 00000018 r1 = 00000000
Expected npc = 40000010 ppc = 4000000c r1 = 00000063
Read npc = 00000018 ppc = 00000018 r1 = 00000000
Expected npc = 40000024 ppc = 40000020 r1 = 00000065
Read npc = 00000020 ppc = 00000024 r1 = 00000000
Expected npc = 4000000c ppc = 40000024 r1 = 000000c9

so where is the problem?

i try the programe of s3esk-openrisc (Serge Vakulenko) and i have the same problem.

do you help me please.

Re: : make verilate error (EAN6/ESP5 ORPSoC with Verilator)

2009-03-13T23:12:00Z

Hii,
I am facing problem with make verilate .The error i am getting is ,
make verilate COMMAND_FILE=cf-baseline-5.scr VFLAGS="-Wno-lint -Wno-COMBDLY -Wno-UNOPTFLAT -language 1364-2001"
Makefile:85: warning: overriding commands for target `has'
Makefile:80: warning: ignoring old commands for target `has'
Makefile:85: warning: overriding commands for target `not'
Makefile:80: warning: ignoring old commands for target `not'
Makefile:85: warning: overriding commands for target `been'
Makefile:80: warning: ignoring old commands for target `been'
Makefile:93: warning: overriding commands for target `"VTARGET'
Makefile:85: warning: ignoring old commands for target `"VTARGET'
Makefile:93: warning: overriding commands for target `has'
Makefile:85: warning: ignoring old commands for target `has'
Makefile:93: warning: overriding commands for target `not'
Makefile:85: warning: ignoring old commands for target `not'
Makefile:93: warning: overriding commands for target `been'
Makefile:85: warning: ignoring old commands for target `been'
Makefile:121: OrpsocAccess.d: No such file or directory
Makefile:122: "VTARGET: No such file or directory
Makefile:122: has: No such file or directory
Makefile:122: not: No such file or directory
Makefile:122: been: No such file or directory
Makefile:122: set"__ALLcls.d: No such file or directory
Makefile:122: "VTARGET: No such file or directory
Makefile:122: has: No such file or directory
Makefile:122: not: No such file or directory
Makefile:122: been: No such file or directory
Makefile:122: set"__ALLsup.d: No such file or directory
Makefile:122: "VTARGET: No such file or directory
Makefile:122: has: No such file or directory
Makefile:122: not: No such file or directory
Makefile:122: been: No such file or directory
Makefile:122: set"__ver.d: No such file or directory
make: Circular "VTARGET <- "VTARGET dependency dropped.
make: Circular has <- "VTARGET dependency dropped.
make: Circular has <- has dependency dropped.
make: Circular not <- "VTARGET dependency dropped.
make: Circular not <- has dependency dropped.
make: Circular not <- not dependency dropped.
make: Circular been <- "VTARGET dependency dropped.
make: Circular been <- has dependency dropped.
make: Circular been <- not dependency dropped.
make: Circular been <- been dependency dropped.
make -f "VTARGET has not been set".mk "VTARGET has not been set"__ALL.a
make[1]: Entering directory `/home/vinitha/test/embecosm-esp5-or1k-verilator-1.0/verilator-model'
make[1]: VTARGET has not been set.mk: No such file or directory
make[1]: *** No rule to make target `VTARGET has not been set.mk'. Stop.
make[1]: Leaving directory `/home/vinitha/test/embecosm-esp5-or1k-verilator-1.0/verilator-model'
make: *** [set"__ALL.a] Error 2
[vinitha@gs15] >
please help...
It seems my systemC and verilator installation is ok.Because verilator converts sample verilog code to systemC module.
Regards
Vinitha

Re: ERR: 8-bit program load out of memory area: 01000074

2009-03-11T23:25:39Z

Hi laurentiuduca! I have the same problem with or32-uclinux-sim too,do you solved it? Could you give me an idea for solving this problem. thanks in advance! sam

laurentiuduca wrote:

Hi, I have this problem too. or32-uclinux-sim -i -f sim.cfg simpleprogsim Reading script file from 'sim.cfg'... Building automata... done, num uncovered: 0/213. Parsing operands data... done. loadcode: filename simpleprogsim startaddr=00000000 virtphy_transl=00000000 Not COFF file format ELF type: 0x0002 ELF machine: 0x005c ELF version: 0x00000001 ELF sec = 15 Section: .text, vaddr: 0x40004000, paddr: 0x40004000 offset: 0x00004000, size: 0x0000084c ERR: 8-bit program load out of memory area: 40004000 ERR: 8-bit program load out of memory area: 40004001 ERR: 8-bit program load out of memory area: 40004002 ERR: 8-bit program load out of memory area: 40004003 ERR: 8-bit program load out of memory area: 40004004 .... ram.ld MEMORY { bootram : ORIGIN = 0x40004000, LENGTH = 0x00001800 sram : ORIGIN = 0x20000000, LENGTH = 0x00100000 vectors : ORIGIN = 0x00000000, LENGTH = 0x00001000 } .... sim.cfg section memory type = unknown /* pattern = 0x00 */ nmemories = 6 device 0 name = "BOOT" ce = 0 baseaddr = 0x40000000 size = 0x00004000 delayr = 1 delayw = 2 enddevice device 1 name = "SRAM" ce = 1 baseaddr = 0x20000000 size = 0x00100000 delayr = 1 delayw = 2 enddevice device 2 name = "FLASH" ce = 2 baseaddr = 0xf0000000 size = 0x01000000 delayr = 10 delayw = -1 enddevice device 3 name = "SDRAM" ce = 3 baseaddr = 0x00000000 size = 0x04000000 delayr = 1 delayw = 2 enddevice ...

Dimitrios Orfanos wrote:

Hi, I've managed to create a gnu toolchain for OPENRISC by using the instructions in this website www.meansoffreedom.net (thanks to Rich). I wrote simple program: hello.c ------------ int main() { return 0; } --------------- I compiled it with the command or32-uclinux-gcc -static -o hello hello.cwith no problem. I took the or1ksim 0.2.0. and I did: ./configure --target=or32 (I also tried or32-uclinux) and then make all. It compiled with no problem. Later I copied the hello program in the directory of or1ksim and I gave the command: ./sim hello The result was to take messages like this ERR: 8-bit program load out of memory area: 01000074 I also attach a file with all the messages. What I want to do is to execute OPENRISC programs on my PC. I don't have any board (FPGA or with OPENRISC processor) so I want to test my programs for OPENRISC on my PC. What am I doing wrong. Do I have to do specific configuration via sim.cfg? Best Regards, DO _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

: make verilate error (EAN6/ESP5 ORPSoC with Verilator)

2009-03-11T05:23:44Z

Hii,
I am facing problem with make verilate..
I am getting an error like this.
Pleae reply..
cd sim/src && ln -s ../../local/sw/dhry/dhry-icdc-O2.hex flash.in
cd verilator-model && time -p make
make[1]: Entering directory `/home/vinitha/simulations/Or1200_1/orpsoc-models-1.0/verilator-model'
Makefile:121: OrpsocAccess.d: No such file or directory
Makefile:121: TraceSC.d: No such file or directory
Makefile:122: Vorpsoc_fpga_top__ALLcls.d: No such file or directory
Makefile:122: Vorpsoc_fpga_top__ALLsup.d: No such file or directory
Makefile:122: Vorpsoc_fpga_top__ver.d: No such file or directory
/bin/sh: cf-base-line.scr: No such file or directory
make[1]: *** [Vorpsoc_fpga_top.mk] Error 1
make[1]: Leaving directory `/home/vinitha/simulations/Or1200_1/orpsoc-models-1.0/verilator-model'
real 0.00
user 0.00
sys 0.00
make: *** [model] Error 2

Regards
Vinitha

Re: make verilate error (EAN6/ESP5 ORPSoC with Verilator)

2009-03-10T23:55:36Z

Hi,

I am also facing the same problem with make verilate..
I am getting an error like this..Not exactly what swaka had..
Pleae reply..
cd sim/src && ln -s ../../local/sw/dhry/dhry-icdc-O2.hex flash.in
cd verilator-model && time -p make
make[1]: Entering directory `/home/vinitha/simulations/Or1200_1/orpsoc-models-1.0/verilator-model'
Makefile:121: OrpsocAccess.d: No such file or directory
Makefile:121: TraceSC.d: No such file or directory
Makefile:122: Vorpsoc_fpga_top__ALLcls.d: No such file or directory
Makefile:122: Vorpsoc_fpga_top__ALLsup.d: No such file or directory
Makefile:122: Vorpsoc_fpga_top__ver.d: No such file or directory
/bin/sh: cf-base-line.scr: No such file or directory
make[1]: *** [Vorpsoc_fpga_top.mk] Error 1
make[1]: Leaving directory `/home/vinitha/simulations/Or1200_1/orpsoc-models-1.0/verilator-model'
real 0.00
user 0.00
sys 0.00
make: *** [model] Error 2

Regards
Vinitha

Re: orpmon

2009-03-08T07:41:48Z

Hi,

I think the problem is with the sim.cfg u are using. I had the same issues with or1ksim and my sample programs. Try using the sim.cfg that we get from the toolchain after compiling the vmlinux. It worked fine for me. Edit that to suite your needs.

regards,
zakhir

--- On Sat, 7/3/09, faroudja.abid <fabid@...> wrote:

From: faroudja.abid <fabid@...>
Subject: Re: [openrisc] orpmon
To: openrisc@...
Received: Saturday, 7 March, 2009, 8:47 PM

Hello,
i have the sam problem when i run simulation and i had this message :

WARNING: config.uart: Invalid parameter: enabled; ignoring.
WARNING: config.uart: Invalid parameter: enabled; ignoring.

ERROR: config.uart:invalid device number.

ERROR: config.uart:invalid device number.

could you tell me how do you resolve this problem
thanks

Ben Ayed Hatem wrote:

>
> Hello,
> I try to run orpmon , I compiled and I have orpmon-flash.or32 file
> when I run simulation by : or32-uclinux-sim orpmon-flash.or32 > log
> I have some probleme :
>
> WARNING: config.memory: Invalid parameter: nmemories; ignoring.
>
> WARNING: config.memory: Invalid parameter: device; ignoring.
>
> WARNING: config.memory: Invalid parameter: enddevice; ignoring.
>
> WARNING: config.memory: Invalid parameter: enddevice; ignoring.
>
> WARNING: config.memory: Invalid parameter: enddevice; ignoring.
>
> WARNING: config.sim: Invalid parameter: spr_log; ignoring.
>
> WARNING: config.sim: Invalid parameter: spr_log_fn; ignoring.
>
> WARNING: config.ata: Invalid parameter: dev_type0; ignoring.
>
> WARNING: config.ata: Invalid parameter: dev_file0; ignoring.
>
> WARNING: config.ata: Invalid parameter: dev_size0; ignoring.
>
> WARNING: config.ata: Invalid parameter: dev_packet0; ignoring.
>
> WARNING: config.ata: Invalid parameter: dev_type1; ignoring.
>
> WARNING: config.ata: Invalid parameter: dev_file1; ignoring.
>
> WARNING: config.ata: Invalid parameter: dev_size1; ignoring.
>
> WARNING: config.ata: Invalid parameter: dev_packet1; ignoring.
>
> WARNING: dependstats stats must be enabled to do history analisis.
> WARNING: Unable to open RX file stream.
> Cannot open Ethernet RX file "eth0.rx"
>
> and log file :
> Reading script file from 'sim.cfg'...
> Insn MMU 0KB: 1 ways, 64 sets, entry size 0 bytes
> Data MMU 0KB: 1 ways, 64 sets, entry size 0 bytes
> Verbose on, simdebug off, interactive prompt off
> Machine initialization...
> Clock cycle: 100ns
> Data cache present.
> Insn cache tag present.
> BPB simulation off.
> BTIC simulation off.
> Building automata... done, num uncovered: 0/213.
> Parsing operands data... done.
> loadcode: filename orpmon-flash.or32 startaddr=00000000
> virtphy_transl=00000000
> Not COFF file format
> ELF type: 0x0002
> ELF machine: 0x005c
> ELF version: 0x00000001
> ELF sec = 23
> Section: .reset, vaddr: 0xf0000000, paddr: 0xf0000000 offset: 0x00002000,
> size: 0x00000128
> ERR: 8-bit program load out of memory area: f0000000
> ERR: 8-bit program load out of memory area: f0000001
> ERR: 8-bit program load out of memory area: f0000002
> ERR: 8-bit program load out of memory area: f0000003
> ERR: 8-bit program load out of memory area: f0000004
> ERR: 8-bit program load out of memory area: f0000005
> ERR: 8-bit program load out of memory area: f0000006
> ERR: 8-bit program load out of memory area: f0000007
> ERR: 8-bit program load out of memory area: f0000008
> ......
>
>
> How can'I resolve this probleme
>

--
View this message in context: http://www.nabble.com/orpmon-tp17177641p22385955.html
Sent from the OpenCores - RISC mailing list archive at Nabble.com.

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

Stay connected to the people that matter most with a smarter inbox. Take a look.
_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

Re: Few questions about Xlinix FPGA boards.

2009-03-08T04:05:14Z

Hi Aleksei,

Le Saturday 07 March 2009 18:48:32 Aleksei Lukin, vous avez écrit :

> Hello, openrisc gurus!
>
> I played a little bit with or1k tools on ubuntu and with Xilinx Spartan 3E
> starter board and decided to use or1k as base of my SoC development because
> it is the best free solution available.
>
> I plan to buy newer Spattan development board to develop my SoC on. I guess
> that 200$ Spartan 3A starter kit with 700K chip will be small enough for
> development purposes and going to buy 600$ Spartan 3A embedded developer
> board with 1800K chip.

The Spartan 3A 1800K has more block RAM as well which can be useful if you
plan on playing with caches for instance. OpenRISC can be quite big if you
enable all features ;)

>
> Is anyone tried to implement SoC on those boards? What is your impression?
> How good it runs? What CPU and bus clock? Which DDR controller? and so
> on...I have too much questions for one message :)

We have been using or1k on a XC3S1200E running at 10Mhz for testings but it
could run faster. We do not have DDR on our board but SDRAM, using our own
controller.

>
> Please, point me to additional information abour or1k SoC on Xlinx boards.
>
> May be it is stupid solution and I must buy other board? I need about 250K
> for my own SoC parts and enough memory to run Linux and a bunch of
> user-space code.

You might run out of space quickly with a S3ESK, but if you disable some or1k
features you might be able to make it fit with your SoC parts as well.
--
Cordialement, Florian Fainelli

OpenPattern SARL - Lead software architect
GSM: +33.632843955
109/111 rue des Côtes
78 600 Maisons-Laffitte
France
------------------------------

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

signature.asc (204 bytes) Download Attachment

Re: Few questions about Xlinix FPGA boards.

2009-03-08T00:25:09Z

On Sat, 2009-03-07 at 19:48 +0200, Aleksei Lukin wrote:

> I played a little bit with or1k tools on ubuntu and with Xilinx
> Spartan 3E starter board and decided to use or1k as base of my SoC
> development because it is the best free solution available.
>
> I plan to buy newer Spattan development board to develop my SoC on. I
> guess that 200$ Spartan 3A starter kit with 700K chip will be small
> enough for development purposes and going to buy 600$ Spartan 3A
> embedded developer board with 1800K chip.
>
> Is anyone tried to implement SoC on those boards? What is your
> impression? How good it runs? What CPU and bus clock? Which DDR
> controller? and so on...I have too much questions for one message :)
>
> Please, point me to additional information abour or1k SoC on Xlinx
> boards.
>
> May be it is stupid solution and I must buy other board? I need about
> 250K for my own SoC parts and enough memory to run Linux and a
> bunch of user-space code.
>

Hi Alex,

Have you looked at the papers from the De Nayer Instituut of the
Hogeschool voor Wetenschap & Kunst. Links to them can be found in the
Documentation section of the OR1200 page on OpenCores:

http://www.opencores.org/projects.cgi/web/or1k/openrisc_1200

They are a little out of date, but should give you some information to
get you started.

The ORPSoC (OpenRISC Reference Platform SoC) page also has information
about various projects running the full ORPSoC on FPGA (including the
XSV800):

http://www.opencores.org/projects.cgi/web/or1k/orpsoc

Take a look at the Or1ksim (architectural simulator) configuration for
Linux. That will tell you how much space is needed for Flash, RAM and
cache.

If you manage to get OR1K running on your board, an updated paper on how
you did it would be much appreciated. We'll be happy to put it up on the
website.

HTH,

Jeremy

--
Tel: +44 (1202) 416955
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@...
Web: www.embecosm.com

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

About old version toolchain for uClinux2.0.x

2009-03-07T16:17:57Z

Hi,
I want to run uClinux2.0.x on my board,but I can't download the old version toochain, gcc 3.2.3 or gcc 3.1, or1k/uclibc, binutils 2.11.93, working uClinux2.0.x used by ATS scripts, Is there anyone kept the old verison toochain?Can you share them with me?

　
　　　　　　　　　　　　　　dxzhang@...
　　　　　　　　　　　　　　　　　2009-03-08

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

Few questions about Xlinix FPGA boards.

2009-03-07T09:48:32Z

Hello, openrisc gurus!

I played a little bit with or1k tools on ubuntu and with Xilinx Spartan 3E starter board and decided to use or1k as base of my SoC
development because it is the best free solution available.

I plan to buy newer Spattan development board to develop my SoC on. I guess that 200$ Spartan 3A starter kit with 700K chip will be small
enough for development purposes and going to buy 600$ Spartan 3A embedded developer board with 1800K chip.

Is anyone tried to implement SoC on those boards? What is your impression? How good it runs? What CPU and bus clock? Which DDR
controller? and so on...I have too much questions for one message :)

Please, point me to additional information abour or1k SoC on Xlinx boards.

May be it is stupid solution and I must buy other board? I need about 250K for my own SoC parts and enough memory to run Linux and a
bunch of user-space code.

--
SY, Alex Lukin
RIPE NIC HDL: LEXA1-RIPE
_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

Re: Toolchain news

2009-03-07T09:33:54Z

Friday 06 March 2009 19:16:55 jb@... написав:
> This is a quick post to let everyone know that a new automated
> toolchain install script, incorporating GDB 6.8, and the
> or1ksim-0.3.0rc2 has been created and should be up on OpenCores by
> Monday.

Could you please publish this script without any VmWare images?

--
SY, Alex Lukin
RIPE NIC HDL: LEXA1-RIPE
_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

Re: orpmon

2009-03-07T01:47:43Z

Hello,
i have the sam problem when i run simulation and i had this message :

WARNING: config.uart: Invalid parameter: enabled; ignoring.
WARNING: config.uart: Invalid parameter: enabled; ignoring.

ERROR: config.uart:invalid device number.

ERROR: config.uart:invalid device number.

could you tell me how do you resolve this problem
thanks

Ben Ayed Hatem wrote:

Hello,
I try to run orpmon , I compiled and I have orpmon-flash.or32 file
when I run simulation by : or32-uclinux-sim orpmon-flash.or32 > log
I have some probleme :

WARNING: config.memory: Invalid parameter: nmemories; ignoring.

WARNING: config.memory: Invalid parameter: device; ignoring.

WARNING: config.memory: Invalid parameter: enddevice; ignoring.

WARNING: config.memory: Invalid parameter: enddevice; ignoring.

WARNING: config.memory: Invalid parameter: enddevice; ignoring.

WARNING: config.sim: Invalid parameter: spr_log; ignoring.

WARNING: config.sim: Invalid parameter: spr_log_fn; ignoring.

WARNING: config.ata: Invalid parameter: dev_type0; ignoring.

WARNING: config.ata: Invalid parameter: dev_file0; ignoring.

WARNING: config.ata: Invalid parameter: dev_size0; ignoring.

WARNING: config.ata: Invalid parameter: dev_packet0; ignoring.

WARNING: config.ata: Invalid parameter: dev_type1; ignoring.

WARNING: config.ata: Invalid parameter: dev_file1; ignoring.

WARNING: config.ata: Invalid parameter: dev_size1; ignoring.

WARNING: config.ata: Invalid parameter: dev_packet1; ignoring.

WARNING: dependstats stats must be enabled to do history analisis.
WARNING: Unable to open RX file stream.
Cannot open Ethernet RX file "eth0.rx"

and log file :
Reading script file from 'sim.cfg'...
Insn MMU 0KB: 1 ways, 64 sets, entry size 0 bytes
Data MMU 0KB: 1 ways, 64 sets, entry size 0 bytes
Verbose on, simdebug off, interactive prompt off
Machine initialization...
Clock cycle: 100ns
Data cache present.
Insn cache tag present.
BPB simulation off.
BTIC simulation off.
Building automata... done, num uncovered: 0/213.
Parsing operands data... done.
loadcode: filename orpmon-flash.or32 startaddr=00000000 virtphy_transl=00000000
Not COFF file format
ELF type: 0x0002
ELF machine: 0x005c
ELF version: 0x00000001
ELF sec = 23
Section: .reset, vaddr: 0xf0000000, paddr: 0xf0000000 offset: 0x00002000, size: 0x00000128
ERR: 8-bit program load out of memory area: f0000000
ERR: 8-bit program load out of memory area: f0000001
ERR: 8-bit program load out of memory area: f0000002
ERR: 8-bit program load out of memory area: f0000003
ERR: 8-bit program load out of memory area: f0000004
ERR: 8-bit program load out of memory area: f0000005
ERR: 8-bit program load out of memory area: f0000006
ERR: 8-bit program load out of memory area: f0000007
ERR: 8-bit program load out of memory area: f0000008
......

How can'I resolve this probleme

Re: Toolchain news

2009-03-06T17:08:31Z

Hi JB,
Excellent!! And thanks.

Is this a linux-2.6.19 release? If so, would you be interested
releasing with 2.6.24 ? This way we would get the lasted from Jeremy
as well as the latest supported kernel.

Thanks,

Rich d

----- Original Message -----
From: Jeremy Bennett<jeremy.bennett@e...>
To:
Date: Fri Mar 6 23:36:32 CET 2009
Subject: [openrisc] Toolchain news

> On Fri, 2009-03-06 at 18:16 +0100, jb at orsoc.se wrote:
> > This is a quick post to let everyone know that a new automated
> > toolchain install script, incorporating GDB 6.8, and the
> > or1ksim-0.3.0rc2 has been created and should be up on
> OpenCores by
> > Monday. As well as installing the latest versions of GDB and
> or1ksim
> > it addresses the problems faced when compiling
> binutils-2.18.50 with
> > gcc-4.3.2 that I (and as Rich pointed out, others have) posted
> about,
> > plus another little niggle in the Linux kernel compile. The
> script has
> > been tested and is working under Ubuntu 8.10.
> > _______________________________________________
> > http://www.opencores.org/mailman/listinfo/openrisc
> Hi Julius,
> I guess you weren't on the mailing list in time to see that Or1ksim
> 0.3.0 is already released. I'd strongly recommend you include it
> rather
> than 0.3.0rc2. There's a bucket of bugs fixed in the 0.3.0 release.
> ATB,
> Jeremy
> --
> Tel: +44 (1202) 416955
> Cell: +44 (7970) 676050
> SkypeID: jeremybennett
> Email: jeremy.bennett at embecosm.com
> Web: www.embecosm.com
>
>

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

Re: Toolchain news

2009-03-06T14:36:32Z

On Fri, 2009-03-06 at 18:16 +0100, jb@... wrote:

> This is a quick post to let everyone know that a new automated
> toolchain install script, incorporating GDB 6.8, and the
> or1ksim-0.3.0rc2 has been created and should be up on OpenCores by
> Monday. As well as installing the latest versions of GDB and or1ksim
> it addresses the problems faced when compiling binutils-2.18.50 with
> gcc-4.3.2 that I (and as Rich pointed out, others have) posted about,
> plus another little niggle in the Linux kernel compile. The script has
> been tested and is working under Ubuntu 8.10.
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/openrisc

Hi Julius,

I guess you weren't on the mailing list in time to see that Or1ksim
0.3.0 is already released. I'd strongly recommend you include it rather
than 0.3.0rc2. There's a bucket of bugs fixed in the 0.3.0 release.

ATB,

Jeremy

--
Tel: +44 (1202) 416955
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@...
Web: www.embecosm.com

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

Re: C program interrupt handle function (AN1.pdf)

2009-03-06T11:32:17Z

On Fri, 2009-03-06 at 19:20 +0100, licinios@... wrote:
> Ok,
>
> where should i find start.s ?
>
> in the or1ksim-0.3.0rc3 dir ?
>
Hi Licinio,

It should be in the same directory as the uart_loop_intr.c. It's code
you link to your program that will run on Or1ksim. If you look at the
Makefile, you'll see how they link together.

HTH,

Jeremy

--
Tel: +44 (1202) 416955
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@...
Web: www.embecosm.com

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

Re: C program interrupt handle function (AN1.pdf)

2009-03-06T10:20:56Z

Ok,
where should i find start.s ?
in the or1ksim-0.3.0rc3 dir ?

----- Original Message -----
From: Jeremy Bennett<jeremy.bennett@e...>
To:
Date: Fri Mar 6 10:38:03 CET 2009
Subject: [openrisc] C program interrupt handle function (AN1.pdf)

> On Fri, 2009-03-06 at 03:34 +0100, licinios at gmail.com wrote:
>
> > How can i write a c program that will handle an interrupt
> coming from
> > a systemc hw module.
> > I am fresh in the sw world , but i would expect something like
> >
> > ..main executing
> > ...interrupt event would call
> >
> > void interrupt 5 (for example)
> > {
> > flag=1
> > return
> > }
> >
> > ..and then, the sw execution would return to the main..and the
> flag
> > could be used.
> >
> > I was expecting to see something like that in
> uart_loop_intr.c.
> > I am i missing something here?
> Hi Licinio,
> uart_loop_intr.c is a very simple program, that is only used to
> demonstrate that the UART is generating interrupts by inspecting
> its
> interrupt register. I don't set up an interrupt handler.
> You will need to extend the bootloader in start.s in two ways.
> First the
> reset code will need to configure the programmable interrupt
> controller.
> This doesn't have to be in assembler - it could be in C, before the
> call
> to _main. You will need to ensure it is configured to accept edge
> triggered interrupts on the relevant port.
> Secondly you will need to add an interrupt handler for the external
> interrupt exception (location 0x800).
> Documentation on how to do this is in chapter 6 (exception
> handling) and
> chapter 13 (programmable interrupt controller) of the architecture
> manual.
> If you do write a good simple example, I'll be very happy to
> include it
> in the next release of my application note.
> HTH,
> Jeremy
> --
> Tel: +44 (1202) 416955
> Cell: +44 (7970) 676050
> SkypeID: jeremybennett
> Email: jeremy.bennett at embecosm.com
> Web: www.embecosm.com
>
>

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

Re: C program interrupt handle function (AN1.pdf)

2009-03-06T09:57:30Z

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

Toolchain news

2009-03-06T09:16:55Z

This is a quick post to let everyone know that a new automated
toolchain install script, incorporating GDB 6.8, and the
or1ksim-0.3.0rc2 has been created and should be up on OpenCores by
Monday. As well as installing the latest versions of GDB and or1ksim
it addresses the problems faced when compiling binutils-2.18.50 with
gcc-4.3.2 that I (and as Rich pointed out, others have) posted about,
plus another little niggle in the Linux kernel compile. The script has
been tested and is working under Ubuntu 8.10.
_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

Re: openrisc toolchains

2009-03-06T05:58:49Z

Hi Jose,
Just to follow on to Jeremy's point. The work on the toolchain is not
quite as disparate as it might seem. The releases are usually "patched
forward" from each other's work. So, for example, the 2.18.50 binutils
patch is derived from the 2.17 patch. The same holds true with gcc,
linux, and uclibc. Since we have been quite small over the past few
years this has not been too hard to manage.

In the case of efforts like MOF and Freecores
(http://www.freecores.org/wiki/Main_Page) these derivative projects
were reflective of some of the changes happening at Opencores at the
time. For the most part these grew out of concern for the project and
its goals rather than vectors for vector's sake.

Now that ORSoC has stablized the project our plan with the toolchain
and linux at least is to migrate back into the Openrisc project, and
then and then push to get our stuff into public repositories so that
non-scalable herculean individual efforts are not required to support
and chase after the constantly moving upgrade targets.

HTH & BR,

Rich d

----- Original Message -----
From: Jeremy Bennett<jeremy.bennett@e...>
To:
Date: Thu Mar 5 10:41:46 CET 2009
Subject: [openrisc] openrisc toolchains

> On Thu, 2009-03-05 at 00:10 +0100, Jose Ignacio Villar wrote:
> > Hello,
> > Currently I can see three efforts to provide a robust
> toolchain to
> > openrisc developers:The new toolchain from orsoc and
> meansofreedom,
> > The toolchain that you can build from embecosm EAN2 and the
> one called
> > DRP by Mark Jarvin.
> >
> > After many months without an unified effort to provide a
> common set of
> > tools, I'm happy to see the "new toolchain" page on
> opencores but I
> > see that it contains old versions of Or1kSim and Linux, that
> and GDB
> > is missing. So, my questions is wether GDB 6.8 and or1KSim
> 0.3.0 from
> > Jeremy Bennet will be included or not in the manline Opencores
> > toolchain script. I think this way all Openrisc community may
> have a
> > common and well tested set of tools with the latest versions
> of every
> > package being used and tested by everyone.
> Hi Jose,
> Thanks for your contributions to this mailing list in recent days.
> They
> will help to improve the tool chain in the future. I look forward
> to
> seeing your future contributions.
> The differences you see reflect the dynamics of open source
> development
> and the priorities of individual, independent contributors.
> - Mark Jarvin's tool chain dates from August 2007
> - OpenCores script and vmware image pre-date GDB 6.8 and Or1ksim
> 0.3.0.
> - EAN2 pre-dates GCC 4.2.2 and binutils 2.18.50
> These latest versions are the cumulative work of (amongst many
> others) a
> Canadian academic, a US telecoms engineer, a Swedish fabless design
> house and a British embedded tools company. There are others as
> well,
> for example the guide to the software tool chain from the De Nayer
> Instituut in the Netherlands.
> The upside is that the latest work on each component is always
> available
> as the group specializing in it completes the work. The downside is
> that
> there is not one rigidly enforced script, as you would get with a
> commercial closed-source product.
> > Currently I was successful to generate the complete toolchain
> with the
> > automated script under ubuntu 8.10 32bits with binutils 2.18
> and gcc
> > 4.3.2, but a pair of patches were needed...
> All new contributions are much appreciated. If you'd post a link to
> where your script can be downloaded, I'll add it to the tool chain
> page
> alongside the link to EAN2 and the De Nayer Instituut.
> Best wishes, and I look forward to hearing more from you.
> Jeremy
> --
> Tel: +44 (1202) 416955
> Cell: +44 (7970) 676050
> SkypeID: jeremybennett
> Email: jeremy.bennett at embecosm.com
> Web: www.embecosm.com
>
>

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

Re: Building binutils 2.18.50 on Ubuntu 8.10 (gcc 4.3.2)

2009-03-06T04:43:01Z

Hi JB,
Yes if you peruse the list you will find others have posted about
this. Yan Morvan has posted a patch to fix the mof_ofsoc build script
and we will be incorporating this soon. Also thanks for the tip on
2.19. I am hoping to upgrade our toolchain to newer versions soon as well.

Thanks,

Rich d

----- Original Message -----
From: jb at orsoc.se<jb@o...>
To:
Date: Thu Mar 5 12:16:39 CET 2009
Subject: [openrisc] Building binutils 2.18.50 on Ubuntu 8.10 (gcc
4.3.2)

> Well, I've got the answer to my own problem here.
>
> It appears that this change in behavior of gcc-4.3.2 has been
> addressed in binutils-2.19, those two lines have been changed to
> be,
> in the case of binutils-2.19/binutils/dwarf.c:
> fputs (buff + (byte_size == 4 ? 8 : 0), stdout);
> and in binutils-2.19/gas/listing.c:
> fputs (field_name, list_file);
> fputs() saves the day from nasty string literal errors.
> ----- Original Message -----
> From: jb at orsoc.se<jb at o...>
> To:
> Date: Thu Mar 5 11:25:19 CET 2009
> Subject: [openrisc] Building binutils 2.18.50 on Ubuntu 8.10 (gcc
> 4.3.2)
> > Hi all,
> >
> > I've been testing building the toolchain on the most recent
> major
> > Ubuntu release, 8.10, and it appears that binutils breaks due
> to
> > stricter enforcement of string literals being passed to things
> like
> > printf and fprintf. For instance, out of the box, binutils
> 2.18.50
> > with the appropriate patch errors out the first of two times
> on
> > binutils-2.18.50/binutils/dwarf.c like so:
> > gcc -DHAVE_CONFIG_H -I.
> > -I/opt/or1200-toolchain/build/binutils-2.18.50/binutils -I.
> -I.
> > -I/opt/or1200-toolchain/build/binutils-2.18.50/binutils
> -I../bfd
> > -I/opt/or1200-toolchain/build/binutils-2.18.50/binutils/../bfd
> >
> -I/opt/or1200-toolchain/build/binutils-2.18.50/binutils/../include
> >
> >
>
>

-DLOCALEDIR="\"/opt/or1200-toolchain/build/tools/or32-uclinux/share/locale\""

> > -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall
> > -Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2 -c
> > /opt/or1200-toolchain/build/binutils-2.18.50/binutils/dwarf.c
> > cc1: warnings being treated as errors
> > /opt/or1200-toolchain/build/binutils-2.18.50/binutils/dwarf.c:
> In
> > function print_dwarf_vma:
> >
> /opt/or1200-toolchain/build/binutils-2.18.50/binutils/dwarf.c:189:
> > error: format not a string literal and no format arguments
> > make[4]: *** [dwarf.o] Error 1
> > It was configured from a recent version of the MOF script,
> like so:
> > $BUILD_TOP/$BINUTILS_VER/configure --target=or32-uclinux
> > --prefix=$BUILD_TOP/tools/or32-uclinux --disable-checking
> > --disable-Werror
> > So, the line it refers to in dwarf.c that it doesn't like is
> like
> > this:
> > printf (buff + (byte_size == 4 ? 8 : 0));
> > Now, I'm by no means one hundred percent that this is correct,
> but
> > I
> > presume there's a pre-made string it wants to pass to printf,
> so if
> > I
> > just put in a "%s" in there it will fix this error?
> Wary
> > that I may
> > have changed the code so that it doesn't do what was intended,
> I
> > can
> > at least make the file compile by changing the line at 189 to:
> > printf ("%s", buff + (byte_size == 4 ? 8 : 0));
> > The next issue when compiling is for the same reason, in the
> file
> > binutils-2.18.50/gas/listing.c:
> > gcc -DHAVE_CONFIG_H -I.
> > -I/opt/or1200-toolchain/build/binutils-2.18.50/gas -I. -I.
> > -I/opt/or1200-toolchain/build/binutils-2.18.50/gas -I../bfd
> > -I/opt/or1200-toolchain/build/binutils-2.18.50/gas/config
> > -I/opt/or1200-toolchain/build/binutils-2.18.50/gas/../include
> > -I/opt/or1200-toolchain/build/binutils-2.18.50/gas/..
> > -I/opt/or1200-toolchain/build/binutils-2.18.50/gas/../bfd
> >
> >
>
>

-DLOCALEDIR="\"/opt/or1200-toolchain/build/tools/or32-uclinux/share/locale\""

> > -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -g
> -O2
> > -c
> > /opt/or1200-toolchain/build/binutils-2.18.50/gas/listing.c
> > cc1: warnings being treated as errors
> > /opt/or1200-toolchain/build/binutils-2.18.50/gas/listing.c: In
> > function print_options:
> >
> /opt/or1200-toolchain/build/binutils-2.18.50/gas/listing.c:1103:
> > error: format not a string literal and no format arguments
> > make[4]: *** [listing.o] Error 1
> > The line concerned in listing.c is:
> > fprintf (list_file, field_name);
> > So I presume here we put in a format string like before, again
> wary
> > that I have not much of an idea of what this is meant to do:
> > fprintf (list_file, "%s", field_name);
> > And now binutils-2.18.50 compiles and installs.
> > GCC-4.2.2 seems to compile OK too, however the next issues
> with
> > this
> > toolchain build are to do with the linux kernel portion, but
> I'm
> > yet
> > to track down the specifics of this. I'll post more when I
> know.
> > Anyway, i'm not sure if perhaps there's a configure option I
> can
> > pass
> > (I've seen the -Wformat-nonliteral, but I guess this makes gcc
> > thrown
> > an error at any of these warnings.... which is now standard
> > behavior
> > in gcc-4.3.2 I think) or perhaps these fixes should be in the
> next
> > patch (or perhaps already are fixed in binutils-2.19). Anyone
> know > what could be done to make this work first time, every
> time? > -jb > >
>

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

Re: Re: Some MMU confusion

2009-03-06T02:03:51Z

On Thu, 2009-03-05 at 23:48 +0800, Zhanhua wrote:

> Hi Rich and Jeremy,
>
> Thanks for the respond.
> We dig into the verilog code and the simulator code a bit. Looks like
> the hardware implementation is the same as what the docs say, so looks
> like this is an simulator issue.
>
> Jeremy, I saw you just updated the simulator, but I didn't have a chance
> to look into the new code yet. Are you now taking care of the simulator
> code? If so, could you give me some hint? I think the biggest confusion
> here is the code for memory controller, is the simulator doing the
> following to decide if a chip is selected:

Hi Zhanhua,

I am looking after the simulator, but this is not an area I have
touched.

I have recently made available cycle accurate models of ORPSoC generated
from the Verilog using Verilator. I have yet to provide a version that
can run Linux (it has a slightly different memory map to ORPSoC), but
that should allow definitive checking of behavior. For details see:

http://www.embecosm.com/download/ean6.html

> 1. ANDed the BA_MASK with the CSC SEL field. The document says only 7:0
> bits in BA_MASK are used to mask with the SEL field of the CSC register
> which is also 8 bits long. But it seems that the BA_MASK and the SEL
> field is actually 10 bits long in the simulator, isn't it?

The general rule is that the Verilog implementation is definitive. It is
not unknown for the simulator and/or documentation to be out of step. If
you can provide details, and a test case in the OpenRISC tracker, then I
can try to get it fixed in the next release. Or feel free to contribute
your own fix.

> 2. Compare the result of step 1 with the input address. The doc says bit
> 28-21 of the input address will be used. If they're the same, and the
> chip is selected. As for the code I read, looks like the simulator use
> the highest 10 bits (31-22) of the input address to do this, right? And
> why is the hardware using bit 28-21 from the input address? Using the
> most significant bits may make more sense.

As noted above, Or1ksim is intended to mirror the behavior of the
Verilog.

> Rich, I don't know how to check the registers. Using gdb to do that?

Or1ksim in interactive mode allows you to inspect the registers. Or you
can use GDB as you suggest.

HTH,

Jeremy

--
Tel: +44 (1202) 416955
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@...
Web: www.embecosm.com

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

Re: C program interrupt handle function (AN1.pdf)

2009-03-06T01:38:03Z

On Fri, 2009-03-06 at 03:34 +0100, licinios@... wrote:

> How can i write a c program that will handle an interrupt coming from
> a systemc hw module.
> I am fresh in the sw world , but i would expect something like
>
> ..main executing
> ...interrupt event would call
>
> void interrupt 5 (for example)
> {
> flag=1
> return
> }
>
> ..and then, the sw execution would return to the main..and the flag
> could be used.
>
> I was expecting to see something like that in uart_loop_intr.c.
> I am i missing something here?

Hi Licinio,

uart_loop_intr.c is a very simple program, that is only used to
demonstrate that the UART is generating interrupts by inspecting its
interrupt register. I don't set up an interrupt handler.

You will need to extend the bootloader in start.s in two ways. First the
reset code will need to configure the programmable interrupt controller.
This doesn't have to be in assembler - it could be in C, before the call
to _main. You will need to ensure it is configured to accept edge
triggered interrupts on the relevant port.

Secondly you will need to add an interrupt handler for the external
interrupt exception (location 0x800).

Documentation on how to do this is in chapter 6 (exception handling) and
chapter 13 (programmable interrupt controller) of the architecture
manual.

If you do write a good simple example, I'll be very happy to include it
in the next release of my application note.

HTH,

Jeremy

--
Tel: +44 (1202) 416955
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@...
Web: www.embecosm.com

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

C program interrupt handle function (AN1.pdf)

2009-03-05T18:34:35Z

Hi Jeremy,
How can i write a c program that will handle an interrupt coming from
a systemc hw module.
I am fresh in the sw world , but i would expect something like

..main executing
...interrupt event would call

void interrupt 5 (for example)
{
flag=1
return
}

..and then, the sw execution would return to the main..and the flag
could be used.

I was expecting to see something like that in uart_loop_intr.c.
I am i missing something here?
Many Thanks
Licinio
_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

Re: Re: Some MMU confusion

2009-03-05T07:48:36Z

Hi Rich and Jeremy,

Thanks for the respond.
We dig into the verilog code and the simulator code a bit. Looks like
the hardware implementation is the same as what the docs say, so looks
like this is an simulator issue.

Jeremy, I saw you just updated the simulator, but I didn't have a chance
to look into the new code yet. Are you now taking care of the simulator
code? If so, could you give me some hint? I think the biggest confusion
here is the code for memory controller, is the simulator doing the
following to decide if a chip is selected:

1. ANDed the BA_MASK with the CSC SEL field. The document says only 7:0
bits in BA_MASK are used to mask with the SEL field of the CSC register
which is also 8 bits long. But it seems that the BA_MASK and the SEL
field is actually 10 bits long in the simulator, isn't it?
2. Compare the result of step 1 with the input address. The doc says bit
28-21 of the input address will be used. If they're the same, and the
chip is selected. As for the code I read, looks like the simulator use
the highest 10 bits (31-22) of the input address to do this, right? And
why is the hardware using bit 28-21 from the input address? Using the
most significant bits may make more sense.

Rich, I don't know how to check the registers. Using gdb to do that?

Thanks,
--Zhanhua

rich_daddio@... wrote:

> Hi Zhanhua,
> I will take a look on the weekend as I am busy with work issues this
> week. I have been thru that code before, have you checked all the real
> values in the registers? Are they what you expect?
>
> Thanks,
>
> Rich d
>
> ----- Original Message -----
> From: Jeremy Bennett<jeremy.bennett@e...>
> To:
> Date: Wed Mar 4 11:15:27 CET 2009
> Subject: [openrisc] Re: Some MMU confusion
>
>
>> On Tue, 2009-03-03 at 20:52 +0800, Zhanhua Kuang wrote:
>>
>>> I still can find a explanation of the below questions. Any one
>>>
>> can give
>>
>>> me a hand?
>>>
>> Hi Zhanhua,
>> This code was written some time ago, and I am not sure the author
>> is
>> still monitoring this mailing list. Rich D'Addio may know more
>> about
>> this code.
>> In general the definitive documentation on OpenRISC 1000 is the
>> Verilog
>> HDL. The architecture manual occasionally differs in details like
>> this.
>> I would expect the MMU code to be following what is actually
>> implemented
>> in the Verilog.
>> Whenever I have looked at the kernel, I've had to work out what is
>> happening just from code inspection. If you work out what is
>> happening,
>> then adding some documentation (possibly just as extended comments)
>> would be much appreciated.
>> If there are discrepancies between the implementation and the
>> documentation, they should be added to the tracker, so the manual
>> can be
>> updated in the future.
>> HTH,
>> Jeremy
>>
>>> On Mon, 2009-03-02 at 14:06 +0800, Zhanhua Kuang wrote:
>>>
>>>> Hi all,
>>>>
>>>> I found some codes that are not consistent with the
>>>>
>> OpenRisc 1000
>>
>>>> Architecture Manual:
>>>>
>>>>
>>>> 1. About BA_MASK value
>>>> The document says the only 7:0 bit in BA_MASK register
>>>>
>> will be used. And
>>
>>>> it's ANDed with the 23:16 bit of the CSC register. Then
>>>>
>> the result will
>>
>>>> be compare with the input address (28:21 bits?)
>>>>
>>>> But, looks like the code doesn't agree that the mask is 8
>>>>
>> bits:
>>
>>>> l.movhi r3,hi(MC_BASE_ADD)
>>>> l.ori r3,r3,lo(MC_BASE_ADD)
>>>>
>>>> l.addi r4,r3,MC_CSC(0)
>>>> l.movhi r5,hi(FLASH_BASE_ADD)
>>>> line1: l.srai r5,r5,6 /* We shift 6 bits right*/
>>>> l.ori r5,r5,0x0025
>>>> l.sw 0(r4),r5
>>>>
>>>> l.addi r4,r3,MC_TMS(0)
>>>> l.movhi r5,hi(FLASH_TMS_VAL)
>>>> l.ori r5,r5,lo(FLASH_TMS_VAL)
>>>> l.sw 0(r4),r5
>>>>
>>>> l.addi r4,r3,MC_BA_MASK
>>>> line2: l.addi r5,r0,MC_MASK_VAL /* the MC_MASK_VAL is
>>>>
>> 0x000003f0 */
>>
>>>> l.sw 0(r4),r5
>>>>
>>>> l.addi r4,r3,MC_CSR
>>>> l.movhi r5,hi(MC_CSR_VAL)
>>>> l.ori r5,r5,lo(MC_CSR_VAL)
>>>> l.sw 0(r4),r5
>>>>
>>>> line1, after the shift the most significant bit of r5 is
>>>>
>> at bit 25. And
>>
>>>> also the BA_MASK value is 0x000003f0, it should be 10
>>>>
>> bits long, then it
>>
>>>> will be actually ANDed with the 25:16bit of the CSC. So
>>>>
>> the document is
>>
>>>> not coincide with the code??
>>>> And also, since the CSC stores the most 10 significant
>>>>
>> bits of the
>>
>>>> address (not bit 28:21), why are we comparing the ANDed
>>>>
>> result of the
>>
>>>> CSC and BA_MASK with the 28:21 bits of input address??
>>>>
>>>> 2. About the Page Table Entry format.
>>>> As described in the document, the Page Table Entry format
>>>>
>> looks like:
>>
>>>> 31:10 9 8:6 5 4 3 2 1 0
>>>> PPN L PPI D A WOM WBC CI CC
>>>>
>>>> I think the following code is use to load the PTE from
>>>>
>> the PGD:
>>
>>>> d_pmd_good:
>>>> /*
>>>> * pte = *pte_offset(pmd, daddr);
>>>> */
>>>> line1: l.lwz r4,0x0(r4) // get **pmd value
>>>> line2: l.and r4,r4,r3 // & PAGE_MASK
>>>> l.srli r5,r2,0xd // >> PAGE_SHIFT, r2 == EEAR
>>>> l.andi r3,r5,0x7ff // (1UL << PAGE_SHIFT - 2) - 1
>>>> l.slli r3,r3,0x2 // to get address << 2
>>>> l.add r3,r3,r4
>>>> l.lwz r2,0x0(r3) // this is pte at last
>>>>
>>>> line1, r4 is now the value of the page table entry. We
>>>>
>> need to use it to
>>
>>>> get the address of the level 2 page table base address.
>>>>
>> But why are we
>>
>>>> applying the PAGE_MASK (most significant 19 bits are all
>>>>
>> 1) to r4? We
>>
>>>> leave out the least significant 3 bits of PPN. Are those
>>>>
>> 3 bits the CID
>>
>>>> number?
>>>>
>>>> Thanks, > > --Zhanhua > > > > >
>>>>
> __________________________________________________________________________________________________________________
>
>
>>> DISCLAIMER:"The information contained in this message and
>>>
>> the attachments (if any) may be privileged and confidential and
>> protected from disclosure. You are hereby notified that any
>> unauthorized use, dissemination, distribution or copying of this
>> communication, review, retransmission, or taking of any action
>> based upon this information, by persons or entities other than the
>> intended recipient, is strictly prohibited. If you are not the
>> intended recipient or an employee or agent responsible for
>> delivering this message, and have received this communication in
>> error, please notify us immediately by replying to the message and
>> kindly delete the original message, attachments, if any, and all
>> its copies from your computer system. Thank you for your
>> cooperation." >
>>
>>
> ________________________________________________________________________________________________________________
>
>
>>> _______________________________________________ >
>>>
>> http://www.opencores.org/mailman/listinfo/openrisc -- Tel: +44
>> (1202) 416955 Cell: +44 (7970) 676050 SkypeID: jeremybennett Email:
>> jeremy.bennett at embecosm.com Web: www.embecosm.com
>>
>>
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/openrisc
>
>

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

Re: Building binutils 2.18.50 on Ubuntu 8.10 (gcc 4.3.2)

2009-03-05T03:16:39Z

Well, I've got the answer to my own problem here.

It appears that this change in behavior of gcc-4.3.2 has been
addressed in binutils-2.19, those two lines have been changed to be,
in the case of binutils-2.19/binutils/dwarf.c:
fputs (buff + (byte_size == 4 ? 8 : 0), stdout);

and in binutils-2.19/gas/listing.c:
fputs (field_name, list_file);

fputs() saves the day from nasty string literal errors.

----- Original Message -----
From: jb at orsoc.se<jb@o...>
To:
Date: Thu Mar 5 11:25:19 CET 2009
Subject: [openrisc] Building binutils 2.18.50 on Ubuntu 8.10 (gcc
4.3.2)

> Hi all,
>
> I've been testing building the toolchain on the most recent major
> Ubuntu release, 8.10, and it appears that binutils breaks due to
> stricter enforcement of string literals being passed to things like
> printf and fprintf. For instance, out of the box, binutils 2.18.50
> with the appropriate patch errors out the first of two times on
> binutils-2.18.50/binutils/dwarf.c like so:
> gcc -DHAVE_CONFIG_H -I.
> -I/opt/or1200-toolchain/build/binutils-2.18.50/binutils -I. -I.
> -I/opt/or1200-toolchain/build/binutils-2.18.50/binutils -I../bfd
> -I/opt/or1200-toolchain/build/binutils-2.18.50/binutils/../bfd
> -I/opt/or1200-toolchain/build/binutils-2.18.50/binutils/../include
>
>

-DLOCALEDIR="\"/opt/or1200-toolchain/build/tools/or32-uclinux/share/locale\""

> -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall
> -Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2 -c
> /opt/or1200-toolchain/build/binutils-2.18.50/binutils/dwarf.c
> cc1: warnings being treated as errors
> /opt/or1200-toolchain/build/binutils-2.18.50/binutils/dwarf.c: In
> function print_dwarf_vma:
> /opt/or1200-toolchain/build/binutils-2.18.50/binutils/dwarf.c:189:
> error: format not a string literal and no format arguments
> make[4]: *** [dwarf.o] Error 1
> It was configured from a recent version of the MOF script, like so:
> $BUILD_TOP/$BINUTILS_VER/configure --target=or32-uclinux
> --prefix=$BUILD_TOP/tools/or32-uclinux --disable-checking
> --disable-Werror
> So, the line it refers to in dwarf.c that it doesn't like is like
> this:
> printf (buff + (byte_size == 4 ? 8 : 0));
> Now, I'm by no means one hundred percent that this is correct, but
> I
> presume there's a pre-made string it wants to pass to printf, so if
> I
> just put in a "%s" in there it will fix this error? Wary
> that I may
> have changed the code so that it doesn't do what was intended, I
> can
> at least make the file compile by changing the line at 189 to:
> printf ("%s", buff + (byte_size == 4 ? 8 : 0));
> The next issue when compiling is for the same reason, in the file
> binutils-2.18.50/gas/listing.c:
> gcc -DHAVE_CONFIG_H -I.
> -I/opt/or1200-toolchain/build/binutils-2.18.50/gas -I. -I.
> -I/opt/or1200-toolchain/build/binutils-2.18.50/gas -I../bfd
> -I/opt/or1200-toolchain/build/binutils-2.18.50/gas/config
> -I/opt/or1200-toolchain/build/binutils-2.18.50/gas/../include
> -I/opt/or1200-toolchain/build/binutils-2.18.50/gas/..
> -I/opt/or1200-toolchain/build/binutils-2.18.50/gas/../bfd
>
>

-DLOCALEDIR="\"/opt/or1200-toolchain/build/tools/or32-uclinux/share/locale\""

> -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2
> -c
> /opt/or1200-toolchain/build/binutils-2.18.50/gas/listing.c
> cc1: warnings being treated as errors
> /opt/or1200-toolchain/build/binutils-2.18.50/gas/listing.c: In
> function print_options:
> /opt/or1200-toolchain/build/binutils-2.18.50/gas/listing.c:1103:
> error: format not a string literal and no format arguments
> make[4]: *** [listing.o] Error 1
> The line concerned in listing.c is:
> fprintf (list_file, field_name);
> So I presume here we put in a format string like before, again wary
> that I have not much of an idea of what this is meant to do:
> fprintf (list_file, "%s", field_name);
> And now binutils-2.18.50 compiles and installs.
> GCC-4.2.2 seems to compile OK too, however the next issues with
> this
> toolchain build are to do with the linux kernel portion, but I'm
> yet
> to track down the specifics of this. I'll post more when I know.
> Anyway, i'm not sure if perhaps there's a configure option I can
> pass
> (I've seen the -Wformat-nonliteral, but I guess this makes gcc
> thrown
> an error at any of these warnings.... which is now standard
> behavior
> in gcc-4.3.2 I think) or perhaps these fixes should be in the next
> patch (or perhaps already are fixed in binutils-2.19). Anyone know
> what could be done to make this work first time, every time?
> -jb
>
>

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

Building binutils 2.18.50 on Ubuntu 8.10 (gcc 4.3.2)

2009-03-05T02:25:19Z

Hi all,

I've been testing building the toolchain on the most recent major
Ubuntu release, 8.10, and it appears that binutils breaks due to
stricter enforcement of string literals being passed to things like
printf and fprintf. For instance, out of the box, binutils 2.18.50
with the appropriate patch errors out the first of two times on
binutils-2.18.50/binutils/dwarf.c like so:

gcc -DHAVE_CONFIG_H -I.
-I/opt/or1200-toolchain/build/binutils-2.18.50/binutils -I. -I.
-I/opt/or1200-toolchain/build/binutils-2.18.50/binutils -I../bfd
-I/opt/or1200-toolchain/build/binutils-2.18.50/binutils/../bfd
-I/opt/or1200-toolchain/build/binutils-2.18.50/binutils/../include
-DLOCALEDIR="\"/opt/or1200-toolchain/build/tools/or32-uclinux/share/locale\""
-Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2 -c
/opt/or1200-toolchain/build/binutils-2.18.50/binutils/dwarf.c
cc1: warnings being treated as errors
/opt/or1200-toolchain/build/binutils-2.18.50/binutils/dwarf.c: In
function print_dwarf_vma:
/opt/or1200-toolchain/build/binutils-2.18.50/binutils/dwarf.c:189:
error: format not a string literal and no format arguments
make[4]: *** [dwarf.o] Error 1

It was configured from a recent version of the MOF script, like so:
$BUILD_TOP/$BINUTILS_VER/configure --target=or32-uclinux
--prefix=$BUILD_TOP/tools/or32-uclinux --disable-checking --disable-Werror

So, the line it refers to in dwarf.c that it doesn't like is like this:
printf (buff + (byte_size == 4 ? 8 : 0));

Now, I'm by no means one hundred percent that this is correct, but I
presume there's a pre-made string it wants to pass to printf, so if I
just put in a "%s" in there it will fix this error? Wary that I may
have changed the code so that it doesn't do what was intended, I can
at least make the file compile by changing the line at 189 to:
printf ("%s", buff + (byte_size == 4 ? 8 : 0));

The next issue when compiling is for the same reason, in the file
binutils-2.18.50/gas/listing.c:

gcc -DHAVE_CONFIG_H -I.
-I/opt/or1200-toolchain/build/binutils-2.18.50/gas -I. -I.
-I/opt/or1200-toolchain/build/binutils-2.18.50/gas -I../bfd
-I/opt/or1200-toolchain/build/binutils-2.18.50/gas/config
-I/opt/or1200-toolchain/build/binutils-2.18.50/gas/../include
-I/opt/or1200-toolchain/build/binutils-2.18.50/gas/..
-I/opt/or1200-toolchain/build/binutils-2.18.50/gas/../bfd
-DLOCALEDIR="\"/opt/or1200-toolchain/build/tools/or32-uclinux/share/locale\""
-W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2 -c
/opt/or1200-toolchain/build/binutils-2.18.50/gas/listing.c
cc1: warnings being treated as errors
/opt/or1200-toolchain/build/binutils-2.18.50/gas/listing.c: In
function print_options:
/opt/or1200-toolchain/build/binutils-2.18.50/gas/listing.c:1103:
error: format not a string literal and no format arguments
make[4]: *** [listing.o] Error 1

The line concerned in listing.c is:

fprintf (list_file, field_name);

So I presume here we put in a format string like before, again wary
that I have not much of an idea of what this is meant to do:
fprintf (list_file, "%s", field_name);

And now binutils-2.18.50 compiles and installs.

GCC-4.2.2 seems to compile OK too, however the next issues with this
toolchain build are to do with the linux kernel portion, but I'm yet
to track down the specifics of this. I'll post more when I know.

Anyway, i'm not sure if perhaps there's a configure option I can pass
(I've seen the -Wformat-nonliteral, but I guess this makes gcc thrown
an error at any of these warnings.... which is now standard behavior
in gcc-4.3.2 I think) or perhaps these fixes should be in the next
patch (or perhaps already are fixed in binutils-2.19). Anyone know
what could be done to make this work first time, every time?

-jb
_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

Re: openrisc toolchains

2009-03-05T01:41:46Z

On Thu, 2009-03-05 at 00:10 +0100, Jose Ignacio Villar wrote:

> Hello,
> Currently I can see three efforts to provide a robust toolchain to
> openrisc developers:The new toolchain from orsoc and meansofreedom,
> The toolchain that you can build from embecosm EAN2 and the one called
> DRP by Mark Jarvin.
>
> After many months without an unified effort to provide a common set of
> tools, I'm happy to see the "new toolchain" page on opencores but I
> see that it contains old versions of Or1kSim and Linux, that and GDB
> is missing. So, my questions is wether GDB 6.8 and or1KSim 0.3.0 from
> Jeremy Bennet will be included or not in the manline Opencores
> toolchain script. I think this way all Openrisc community may have a
> common and well tested set of tools with the latest versions of every
> package being used and tested by everyone.

Hi Jose,

Thanks for your contributions to this mailing list in recent days. They
will help to improve the tool chain in the future. I look forward to
seeing your future contributions.

The differences you see reflect the dynamics of open source development
and the priorities of individual, independent contributors.
- Mark Jarvin's tool chain dates from August 2007
- OpenCores script and vmware image pre-date GDB 6.8 and Or1ksim 0.3.0.
- EAN2 pre-dates GCC 4.2.2 and binutils 2.18.50

These latest versions are the cumulative work of (amongst many others) a
Canadian academic, a US telecoms engineer, a Swedish fabless design
house and a British embedded tools company. There are others as well,
for example the guide to the software tool chain from the De Nayer
Instituut in the Netherlands.

The upside is that the latest work on each component is always available
as the group specializing in it completes the work. The downside is that
there is not one rigidly enforced script, as you would get with a
commercial closed-source product.

> Currently I was successful to generate the complete toolchain with the
> automated script under ubuntu 8.10 32bits with binutils 2.18 and gcc
> 4.3.2, but a pair of patches were needed...

All new contributions are much appreciated. If you'd post a link to
where your script can be downloaded, I'll add it to the tool chain page
alongside the link to EAN2 and the De Nayer Instituut.

Best wishes, and I look forward to hearing more from you.

Jeremy

--
Tel: +44 (1202) 416955
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@...
Web: www.embecosm.com

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

openrisc toolchains

2009-03-04T15:10:58Z

Hello,
Currently I can see three efforts to provide a robust toolchain to openrisc developers:The new toolchain from orsoc and meansofreedom, The toolchain that you can build from embecosm EAN2 and the one called DRP by Mark Jarvin.

After many months without an unified effort to provide a common set of tools, I'm happy to see the "new toolchain" page on opencores but I see that it contains old versions of Or1kSim and Linux, that and GDB is missing. So, my questions is wether GDB 6.8 and or1KSim 0.3.0 from Jeremy Bennet will be included or not in the manline Opencores toolchain script. I think this way all Openrisc community may have a common and well tested set of tools with the latest versions of every package being used and tested by everyone.

Currently I was successful to generate the complete toolchain with the automated script under ubuntu 8.10 32bits with binutils 2.18 and gcc 4.3.2, but a pair of patches were needed...

Here is a table with versions of every package of the three toolchains.

	DRP	Orsoc	Embecosm
Binutils	2.17	2.18.50	2.16.1
GCC	4.2.1	4.2.2	3.4.4
GDB	5.3	NA	6.8
ucLibC	0.9.28	0.9.29	0.9.28
Newlib	1.15.0	NA	NA
Linux	2.6.19	2.6.19	2.6.23
BusyBox	NA	1.7.5	NA
ucLinux	2.0.38	NA	NA
Or1KSim	0.2.0	0.2.0	0.3.0

Jose.

--
José Ignacio Villar <jose@...>
Departamento de Tecnología Electrónica
Escuela Técnica Superior de Ingeniería Informática
Universidad de Sevilla
Avda. Reina Mercedes, s/n
41012 - Sevilla (Spain)

Tlf: 954 55 61 60
Fax: 954 55 27 64

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

Re: Regarding the hardware of OR1200 related to cache

2009-03-04T10:01:43Z

Hello,
I think it's a good idea to remove cab signals. Many of as have had to investigate its meaning and origin now that it is not being mentioned in Wishbone Specs anymore.
It will help to avoid confusion in the future.

Jose.

--
José Ignacio Villar <jose@...>
Departamento de Tecnología Electrónica
Escuela Técnica Superior de Ingeniería Informática
Universidad de Sevilla
Avda. Reina Mercedes, s/n
41012 - Sevilla (Spain)

Tlf: 954 55 61 60
Fax: 954 55 27 64

On Wed, Mar 4, 2009 at 8:12 AM, Richard Herveille <richard@...> wrote:

If other people agree then I suggest you remove the CAB signal and replace it with the appropriate CTI and BTE signals.

CAB is obsolete and really should be removed from any cores (including the or1200) that still use it.

Richard

From: openrisc-bounces@... [mailto:openrisc-bounces@...] On Behalf Of Pradip Harindran
Sent: 03 March 2009 12:55

To: List about OpenRISC project

Subject: Re: [openrisc] Regarding the hardware of OR1200 related to cache

Thank you for the info. We have gone through the wishbone documentation and we could find a good amount of info on the signals. But i couldnt find anything on the cab signal anywhere. It would be helpful if you could provide some more info on it as we have to work on the cache module.

Thanking you,
Pradip

On Fri, Feb 20, 2009 at 11:13 PM, Richard Herveille <richard@...> wrote:

CAB is way obsolete :) It momentarily saw light inbetween RevB2 and RevB3.
It mean Continuous Address Burst. It is superseded by CTI and BTE.
Somebody should really change this in the OpenRISC.
CAB can only operate on linear address ranges, whereas CTI/BTE allows for
interleaved (as used by the cache controller) address schemes.

Richard

-----Original Message-----
From: openrisc-bounces@... [mailto:openrisc-bounces@...]

On Behalf Of Jeremy Bennett
Sent: 20 February 2009 16:12
To: List about OpenRISC project
Subject: RE: [openrisc] Regarding the hardware of OR1200 related to cache

On Fri, 2009-02-20 at 08:47 +0100, Richard Herveille wrote:
> These are wishone signals.
>
> Download the wishbone spec from opencores.

Hi Richard,

In the OpenRISC code, the CAB signal is used, but I believe this was
dropped from Wishbone even before version 1 of the standard. Can you
tell us what this signal was for. Just curiosity for understanding the
code.

Thanks,

Jeremy

--
Tel: +44 (1202) 416955
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@...
Web: www.embecosm.com

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc