Re: [ECOS] hal vsr question

[Grant Edwards <grante at visi dot com>]

I'm still working on running eCos with ROM at address 0.

One solution is attaching a small boot program that executes
before eCos does -- this boot program re-arranges the memory
map so that RAM is at 0.  This works, but it's just a
short-term fix. I need a long-term solution where eCos runs
with ROM at address 0.

I've moved the vsr table from 0x20 to the location used by the
ROM code.  I've fixed vectors.S to initialize the vsr table
properly. I've changed the SET/GET_VSR macros.  I've verified
that interrupts are in fact vectoring through the vsr table in
RAM.

But still some of the kernel tests fail:

      clockcnv         hangs
      kflag1           resets
      kmbox1           hangs when testing timed functions
      kmemfix1         resets
      memfix1          locks up hardware completely
      memvar2          resets
      mutex3           runs for a couple seconds, then resets
      stress_threads   hangs
      sync2            hangs
      tm_basic         exits without printing results

All of the other kernel tests pass.

There's obviously some assumptions about memory layout hidden
somewhere where I haven't found them.  Any ideas on where that
might be?


I've investigated two of the above cases a bit further. 

kmbox1  everything passes until it gets to the call to
        cyg_mbox_timed_get(), which generates an undefined
        instruction interrupt.

        If I step through that call wigh gdb, it does not hit
        the undefined instruction, but completes (and fails)
        the test -- presumably due to the fact that the timer
        keeps running while gdb has the exeucution stopepd.

kflag1  Everything passes until it tests flag_timed_wait(),
        which then eventually generates an undefined
        isntruction interrupt.

So, one of the problems seems to be related to timing out while
waiting for an event?

-- 
Grant Edwards
grante@visi.com