1/1

|
ecos-3.0 interrupt handling on OR1200.
by avamsi on Jul 21, 2012 |
avamsi
Posts: 54 Joined: Apr 16, 2012 Last seen: Jul 30, 2014 |
||
|
Hi,
ISRs were not triggered when I tried to port ecos-3.0 on OR1200 HW. Did any one come across this sort of issue. Please confirm if the present ecos-3.0 port handles the interrupts well during multi-threading. thanks, Avamsi |
|||
|
RE: ecos-3.0 interrupt handling on OR1200.
by skrzyp on Jul 29, 2012 |
skrzyp
Posts: 28 Joined: Jun 9, 2011 Last seen: Jan 25, 2013 |
||
|
Hello
I haven't noticed any problems with interrupts during multi-threading. Could you please give me more details, so that maybe I could reproduce the problem? Piotr |
|||
|
RE: ecos-3.0 interrupt handling on OR1200.
by avamsi on Aug 14, 2012 |
avamsi
Posts: 54 Joined: Apr 16, 2012 Last seen: Jul 30, 2014 |
||
|
Thank you for the reply,
Is the present ecos port available on Openrisc svn stable or not. Actually when I tried to run the simple multi thread example code with adding some function calls, it is giving bus errors. I am not accessing any illegal memory location and sure that hardware is stable. Thanks, A.vamsi |
|||
|
RE: ecos-3.0 interrupt handling on OR1200.
by skrzyp on Aug 21, 2012 |
skrzyp
Posts: 28 Joined: Jun 9, 2011 Last seen: Jan 25, 2013 |
||
|
Hello
The code published on opencores repository is the most up to date and well tested code. I have been testing multitasking / context switching and I didn't have any problems with that. Are you sure you set in ecc file the right amount of ram memory attached to processor? This is often the case when processor enters bus error state. Did you try to run this program in or1ksim? How long do you have to wait until bus error occurs? Is it easy to reproduce the error? Please let me know if there is a chance for me to reproduce the error so that I can take a look what is wrong. Best regards Piotr |
|||
|
RE: ecos-3.0 interrupt handling on OR1200.
by avamsi on Aug 22, 2012 |
avamsi
Posts: 54 Joined: Apr 16, 2012 Last seen: Jul 30, 2014 |
||
|
Hi Piotr,
Here is the problem that I came across.Actually for the hardware configuration, I modified the target.ld file like below format. Rest of the file is same.
{
vector : ORIGIN = 0x00000000, LENGTH = 0x00002000
ram : ORIGIN = 0x40000000, LENGTH = 0x1000000
rom : ORIGIN = 0xF0000000, LENGTH = 0x00040000
}
.vectors 0x00000100 : { . = .; KEEP(*(.vectors)) } > vector ,
rest all same.
part of the program:
void cyg_user_start(void)
{
uart_init();
printk("Entering user_start\n");
cyg_mutex_init(&cliblock);
cyg_thread_create(4, simple_program, (cyg_addrword_t) 0,
"Thread A", (void *) stack[0], 4096,
&simple_threadA, &thread_s[0]);
cyg_thread_create(4, simple_program, (cyg_addrword_t) 1,
"Thread B", (void *) stack[1], 4096,
&simple_threadB, &thread_s[1]);
printk("thread created\n");
cyg_thread_resume(simple_threadA);
cyg_thread_resume(simple_threadB);
}
When I checked the disassemble file, all the section are properly mapped, means all the sections are mapped to existing memory space. I tried to run the above program, printk function is user defined function for sending the strings to uart. It executed and printed both the printk fuctions. When it entered the cyg_thread_resume(), it gave the below error.
Program received signal SIGILL, Illegal instruction.
Cyg_Scheduler::thread_entry (this=, thread=0x11110000)
at /home/avamsi/OpenRISC/ecos-3.0/install/include/cyg/kernel/smp.hxx:451
451 return sched_lock;
(gdb) info registers
gpr0 0x0 0
gpr1 0x4001e024 0x4001e024
gpr2 0x4001f038 0x4001f038
gpr3 0x8001 32769
gpr4 0x11110000 286326784
gpr5 0x1111000a 286326794
gpr6 0x4001f038 1073868856
gpr7 0x40010000 1073807360
gpr8 0x11110010 286326800
gpr9 0x11110012 286326802
gpr10 0x11110014 286326804
gpr11 0x11110016 286326806
gpr12 0x11110018 286326808
gpr13 0x1111001a 286326810
gpr14 0x1111001c 286326812
gpr15 0x1111001e 286326814
gpr16 0x829208 8557064
gpr17 0xb86aa918 -1200969448
gpr18 0x8291b0 8556976
gpr19 0x829330 8557360
gpr20 0xc8c961fc -926326276
gpr21 0x829390 8557456
gpr22 0x3 3
thanks,
A.Vamsi
|
|||
|
RE: ecos-3.0 interrupt handling on OR1200.
by avamsi on Aug 22, 2012 |
avamsi
Posts: 54 Joined: Apr 16, 2012 Last seen: Jul 30, 2014 |
||
|
Hi Piotr,
Here is the problem that I came across.Actually for the hardware configuration, I modified the target.ld file like below format. Rest of the file is same. { vector : ORIGIN = 0x00000000, LENGTH = 0x00002000 ram : ORIGIN = 0x40000000, LENGTH = 0x1000000 rom : ORIGIN = 0xF0000000, LENGTH = 0x00040000 } .vectors 0x00000100 : { . = .; KEEP(*(.vectors)) } > vector , rest all same. part of the program: void cyg_user_start(void) { uart_init(); printk("Entering user_start\n"); cyg_mutex_init(&cliblock); cyg_thread_create(4, simple_program, (cyg_addrword_t) 0, "Thread A", (void *) stack[0], 4096, &simple_threadA, &thread_s[0]); cyg_thread_create(4, simple_program, (cyg_addrword_t) 1, "Thread B", (void *) stack[1], 4096, &simple_threadB, &thread_s[1]); printk("thread created\n"); cyg_thread_resume(simple_threadA); cyg_thread_resume(simple_threadB); } When I checked the disassemble file, all the section are properly mapped, means all the sections are mapped to existing memory space. I tried to run the above program, printk function is user defined function for sending the strings to uart. It executed and printed both the printk fuctions. When it entered the cyg_thread_resume(), it gave the below error. Program received signal SIGILL, Illegal instruction. Cyg_Scheduler::thread_entry (this=, thread=0x11110000) at /home/avamsi/OpenRISC/ecos-3.0/install/include/cyg/kernel/smp.hxx:451 451 return sched_lock; (gdb) info registers gpr0 0x0 0 gpr1 0x4001e024 0x4001e024 gpr2 0x4001f038 0x4001f038 gpr3 0x8001 32769 gpr4 0x11110000 286326784 gpr5 0x1111000a 286326794 gpr6 0x4001f038 1073868856 gpr7 0x40010000 1073807360 gpr8 0x11110010 286326800 gpr9 0x11110012 286326802 gpr10 0x11110014 286326804 gpr11 0x11110016 286326806 gpr12 0x11110018 286326808 gpr13 0x1111001a 286326810 gpr14 0x1111001c 286326812 gpr15 0x1111001e 286326814 gpr16 0x829208 8557064 gpr17 0xb86aa918 -1200969448 gpr18 0x8291b0 8556976 gpr19 0x829330 8557360 gpr20 0xc8c961fc -926326276 gpr21 0x829390 8557456 gpr22 0x3 3 thanks, A.Vamsi |
|||
|
RE: ecos-3.0 interrupt handling on OR1200.
by skrzyp on Aug 26, 2012 |
skrzyp
Posts: 28 Joined: Jun 9, 2011 Last seen: Jan 25, 2013 |
||
|
When ecos is executing code in cyg_user_start, the scheduler is not started yet. The scheduler is invoked after this function ends. So I assume the problem is not related to task switching procedures. Also, your output reports illegal instruction rather than bus error. Did you try to see what kind of opcode has been generated there?
Please note, that not only exception vectors are stored in the beginning of address space. This is also the place for vsr table and virtual vector table (see hal_virtual_vector_table = 0xF00; in target.ld). Nevertheless, I think that length of 2000 is enough). Could you send me your ecc file and source code by email? I will try to run this in or1ksim and see if I can reproduce the error and help you track down the problem. Best regards Piotr |
|||
|
RE: ecos-3.0 interrupt handling on OR1200.
by avamsi on Aug 29, 2012 |
avamsi
Posts: 54 Joined: Apr 16, 2012 Last seen: Jul 30, 2014 |
||
|
Hi Piotr,
Thank you for your response, I sent the zip file by email, included .ecc file and elf. Please look into it and correct me if the method I did is not the right way. thanks, A.vamsi |
|||
1/1

