edb7312 and SkyeEye followup - SUCCESS

Karel Gardas kgardas at objectsecurity.com
Thu Dec 22 21:53:01 UTC 2005


I've tried my own old build of RTEMS-4.7 (from around September I guess) 
demos (hello world) with your skyeye config file and I can confirm that 
skyeye really aborts. Anyway, I have arm-elf-insight installed so I 
decided to give a try to skyeye debug capability and run skyeye in debug 
mode and connect insight to it. I've set breakpoint on 
BSP_rtems_irq_mngt_init just to see that skyeye will abort really on 
*INTMR3 = 0.

Well, what was my surprise to see that I've gone ok thorough this code and 
continued into deep RTEMS internals? The second surprise was that when 
I've given up debugging and just push it to `continue' expecting skyeye 
aborting somewhere else, it in fact executed whole hello world demo well! 
So instead of patching RTEMS I do have simple workaround for skyeye bug: 
run it in debug mode and set breakpoint on the function above...


PS: I've also tested skyeye-20051204.tar.bz2, but this was even less 
stable, since debugging wasn't working well at all...

PPS: I've tested this way those apps:
- where loopback interestingly didn't work and is this output from 
ticker.exe expected?
TA1  - rtems_clock_get - 09:00:00   12/31/1988
TA2  - rtems_clock_get - 09:00:00   12/31/1988
TA3  - rtems_clock_get - 09:00:00   12/31/1988
TA1  - rtems_clock_get - 09:00:05   12/31/1988
TA1  - rtems_clock_get - 09:00:10   12/31/1988
TA2  - rtems_clock_get - 09:00:10   12/31/1988
TA1  - rtems_clock_get - 09:00:15   12/31/1988
TA3  - rtems_clock_get - 09:00:15   12/31/1988
TA1  - rtems_clock_get - 09:00:20   12/31/1988
TA2  - rtems_clock_get - 09:00:20   12/31/1988
TA1  - rtems_clock_get - 09:00:25   12/31/1988
TA3  - rtems_clock_get - 09:00:30   12/31/1988
TA1  - rtems_clock_get - 09:00:30   12/31/1988
TA2  - rtems_clock_get - 09:00:30   12/31/1988

On Wed, 14 Dec 2005, Jay Monkman wrote:

> I finally got a chance to try out skyeye. I did get the ticker test to run.
> Of course, the delays between the printf()s are wrong, but they seem
> proportional - 10 second delay appears to be twice a 5 second delay.
> I tried this with my tree. I'm checking out the latest in CVS, and I'll give
> that a try, tomorrow. I would expect it to also work.
> The problem with running the ticker test was that RAM was at the wrong place.
> Joel, you sent me a patch that moved SDRAM from 0x00000000 to 0xc0000000. That
> wreaks havoc with the interrupts, and interrupts is what the ticker test tests.
> (Say that fast five times!)
> I kept the SDRAM and 0x00000000, and updated the config file, and Voila! it worked.
> The only change I had to make to the RTEMS source was to comment out where
> INTMR3 is cleared.
> I've attached my config file and the patch I needed.
> Tomorrow, after I've finished updating to the latest in CVS, I'll try that, too.

Karel Gardas                  kgardas at objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

More information about the users mailing list