Problem running IXP1200 VERA apps
Hi, Thanks to some help from this group, I managed to build the IXP1200 applications for Vera. I also built and ran the Hello World test program. Now I have a problem running the IPmm and PktGen applications. When I invoke 'sgo ipmm.srec', the output on the board's serial port stops abruptly. Here is the output. =============================== Jumping to: 0xC1002000 bss_start = 0xC10121A8 bss_end = 0xC1012A40 (length) = 0x00000898 Sbrk_heap_ptr_ = 0xC1013000 Sbrk_heap_end_ = 0xC1CF8000 (length) = 0x00CE5000 (13204 Kbytes) Enabling MMU MMU enabled Calling sram_init() Calling scratch_init() Calling PCI_mapout_init() PCI_mapout_init: PCI_dram_siz = 0x02000000 PCI_mapout_init: PCI_dram_bar = 0xF6000000 Calling my_main() Starting uEngines and control program. --- Control_SystemStart --- Contr ========================== This happens irrespective of if I build the microcode with or without VRP. The LED displays 0x25. The same happens with the application PktGen. What have I done wrong here? Thanks, Magesh
Quoting Magesh Kannan
When I invoke 'sgo ipmm.srec', the output on the board's serial port stops abruptly. Here is the output.
Calling my_main() Starting uEngines and control program.
--- Control_SystemStart --- Contr ==========================
This happens irrespective of if I build the microcode with or without VRP. The LED displays 0x25. The same happens with the application PktGen. What have I done wrong here?
I don't think that you have done anything wrong. Everything sounds like it's starting up fine until it stops. (The 0x25 in the LEDS is normal, if I remember correctly.) This sounds like the program exiting early, either because of an error (like a segmentation fault), or something else. How is the board crashing? Is it just stopping, or is it resetting? How about putting a line like while (getc() != '\n'); to find out where in the program the board is crashing. Zuki (PS, I'm out of the office today, but I'll try to keep responding.)
Hi,
When I invoke 'sgo ipmm.srec', the output on the board's serial port stops abruptly. Here is the output.
Calling my_main() Starting uEngines and control program.
--- Control_SystemStart --- Contr ==========================
This happens irrespective of if I build the microcode with or without VRP. The LED displays 0x25. The same happens with the application PktGen. What have I done wrong here?
I don't think that you have done anything wrong. Everything sounds like it's starting up fine until it stops. (The 0x25 in the LEDS is normal, if I remember correctly.) This sounds like the program exiting early, either because of an error (like a segmentation fault), or something else. How is the board crashing? Is it just stopping, or is it resetting?
How about putting a line like
while (getc() != '\n');
to find out where in the program the board is crashing.
I added these while loops before and after the following two statements in IXP1200_Apps/IPmm/main.c Control_SystemStart(0, 0); Control_BootUEs(&rcv_uCode, &xmt_uCode); The board seemed to hang immediately after returning from Control_SystemStart and before calling Control_BootUEs. I added a couple of led() function calls between these two statements. The LEDs displayed the code that I had put in, but the very next statement (a while loop) would hang. Then I realized that the board had a flash image built on a machine with RH 6.2 and Linux 2.2.19, though the board was now installed in a PC with RH 7.1 and Linux 2.4.5 (I had to move the board to a new PC but forgot to update the flash). Can this be a reason for the board hanging? Anyway, I decided to update the flash with one built on the same machine in which the board is now installed. Here is where I am stuck now. If I invoke the flash utility from Flash/linux-386/bin/flash, I get the error 'Operation not permitted' (Vera and Vera_flash drivers are installed). The following output is printed on the board's serial port ===== Compile Timestamp: 12:51:23 on Sep 27 2002 Command Line (argc = 3): ixp1200/sa/bin/flash.srec 0 0x0B1AE000 mode = 0x00000000 (0) kbba = 0x0B1AE000 (186310656) parse_opts passed Uncaught exception Assertion failed raised at flash.c:61 aborting... minimon mode. Type ^C to exit minimon, ^X to discard line, ^R reset ===== The assertion failure in flash.c is because the kbba value is NOT less than 128 M (128*1024*1024) How do I get around this problem and update the flash? Thanks for your help, Magesh
Hello All, Has anybody tried to program the timer in IXP1200? I currently have VxWorks running on it. I am trying to use Timer 4 for my application, but control is not reaching my ISR. I believe I have done everything as mentioned in the programmer's guide. I have enabled the IXP1200_IRQSTATUS, but it still doesnt work. Can anybody tell me what step I could be missing. Thanks, Sandeep.
Hi Sandeep, This is an OS-independent answer to your question. I am not familiar enough with VxWorks to know which timers or interrupts it claims for itself. Such conflicts could very well be the cause of your problem. Here's a sketch of what you need to do to use the timers: (1) decide if you want to use FIQ or IRQ interrupts. (2) load the address of your ISR at the correct vector location. (3) Make sure you have an IRQ stack set up (4) Choose a timer (e.g., Timer 1) (5) Load the initial value into the timer *((volatile u32 *) 0x42000300) = 0xFFFFFFFF; (6) Enable the timer to generate IRQ interrupts *((volatile u32 *) 0x42000188) = 0x00000010; (7) Enable interrupts in the StrongARM core asm volatile("mrs %0, cpsr" : "=r" (cpsr)); cpsr &= ~0x80; asm volatile("msr cpsr, %0" : : "r" (cpsr)); Anyway, this is the basic idea. Scott On Fri, Sep 27, 2002 at 07:41:55PM -0700, Sandeep P wrote:
Hello All, Has anybody tried to program the timer in IXP1200? I currently have VxWorks running on it. I am trying to use Timer 4 for my application, but control is not reaching my ISR. I believe I have done everything as mentioned in the programmer's guide. I have enabled the IXP1200_IRQSTATUS, but it still doesnt work. Can anybody tell me what step I could be missing.
Thanks, Sandeep.
Hi Sandeep, This is an OS-independent answer to your question. I am not familiar enough with VxWorks to know which timers or interrupts it claims for itself. Such conflicts could very well be the cause of your problem. Here's a sketch of what you need to do to use the timers: (1) decide if you want to use FIQ or IRQ interrupts. (2) load the address of your ISR at the correct vector location. (3) Make sure you have an IRQ stack set up (4) Choose a timer (e.g., Timer 1) (5) Load the initial value into the timer *((volatile u32 *) 0x42000300) = 0xFFFFFFFF; (6) Enable the timer to generate IRQ interrupts *((volatile u32 *) 0x42000188) = 0x00000010; (7) Enable interrupts in the StrongARM core asm volatile("mrs %0, cpsr" : "=r" (cpsr)); cpsr &= ~0x80; asm volatile("msr cpsr, %0" : : "r" (cpsr)); (8) Start the timer *((volatile u32 *) 0x42000308) = 0x000000C0; Anyway, this is the basic idea. Scott On Fri, Sep 27, 2002 at 07:41:55PM -0700, Sandeep P wrote:
Hello All, Has anybody tried to program the timer in IXP1200? I currently have VxWorks running on it. I am trying to use Timer 4 for my application, but control is not reaching my ISR. I believe I have done everything as mentioned in the programmer's guide. I have enabled the IXP1200_IRQSTATUS, but it still doesnt work. Can anybody tell me what step I could be missing.
Thanks, Sandeep.
On Fri, 27 Sep 2002, Magesh Kannan wrote:
I added these while loops before and after the following two statements in IXP1200_Apps/IPmm/main.c
Control_SystemStart(0, 0); Control_BootUEs(&rcv_uCode, &xmt_uCode);
The board seemed to hang immediately after returning from Control_SystemStart and before calling Control_BootUEs. I added a couple of led() function calls between these two statements. The LEDs displayed the code that I had put in, but the very next statement (a while loop) would hang.
Magesh, This sounds like a crash in an interrupt handler. The two 0's sent to Control_SystemStart are actually function pointers the first called when quit is invoked, the second function should be called every second. I don't understand why the board is crashing (it works find here, but maybe if you put a function pointer (the function should return 1) in the second parameter you will see if that function is called. I hope this helps. Zuki -- Yitzchak Gottlieb zuki@CS.Princeton.EDU
Hi,
I added these while loops before and after the following two statements in IXP1200_Apps/IPmm/main.c
Control_SystemStart(0, 0); Control_BootUEs(&rcv_uCode, &xmt_uCode);
The board seemed to hang immediately after returning from Control_SystemStart and before calling Control_BootUEs. I added a couple of led() function calls between these two statements. The LEDs displayed the code that I had put in, but the very next statement (a while loop) would hang.
Magesh,
This sounds like a crash in an interrupt handler. The two 0's sent to Control_SystemStart are actually function pointers the first called when quit is invoked, the second function should be called every second. I don't understand why the board is crashing (it works find here, but maybe if you put a function pointer (the function should return 1) in the second parameter you will see if that function is called. I hope this helps.
Thanks for the info. The problem disappeared after I updated the flash with an image built on a RH 7.1 machine. Magesh
Hi, Does anyone know why and how to solve this error when I compile the micro C code? error: QIL verify failed after qcg_expand_intrinsics Thank you very much. -- Li Zhao Dept. of Computer Science Univ. of California, Riverside Tel:1-909-787-2001
participants (6)
-
Li Zhao -
Magesh Kannan -
Sandeep P -
Scott C. Karlin -
Yitzchak M. Gottlieb -
zuki＠CS.Princeton.EDU