[ECOS] XIP some kernel parts

[ECOS] XIP some kernel parts

[Sergei Gavrikov]

Hi Folks,

Did anybody try to XIP (exucute in a place) in the _different_ places the
parts of eCos kernel itself? I keep in a mind GCC attribute __section__.

May be it is a stupid idea, but, I thought that would help me to reduce
the ISR/DSR latencies on my target. The different places are: 1) fast
CPU SRAM and 2) slow external RAM. It's pity, but, I cannot put whole
eCos kernel into SRAM (16K). Did anybody try the same (to run a kernel
is divided on the chunks (critical/not critical))?

Why I ask about? I can successfully handle the ISRs every 125 uS using
ROM startup, but, I cannot do the same when application is running in
the external RAM (RAM or ROMRAM startup). And I thought about fast and
unused SRAM for the eCos RTC ISR  handler, handler for pending DSRs,
etc. i.e. to wrap some parts of the kernel with some attribute, e.g.

#define __xipsram noinline __attribute__ ((__section__ (".sram")))

If anybody did try it. Which the routines you tweaked?  Thanks in
advance for any critic and comments.

Sergei

P.S.

I would glad hear a talk about the "idea" itself, before anybody will
pronounce "FIQ", "VSR" :-) I dislike an assembler.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: XIP some kernel parts

[Sergei Gavrikov]

On Sat, Jul 11, 2009 at 07:40:00PM +0300, Sergei Gavrikov wrote:
> Why I ask about? I can successfully handle the ISRs every 125 uS using
> ROM startup, but, I cannot do the same when application is running in
> the external RAM (RAM or ROMRAM startup). And I thought about fast and
> unused SRAM for the eCos RTC ISR  handler, handler for pending DSRs,
> etc. i.e. to wrap some parts of the kernel with some attribute, e.g.

More info on issue. I get for my target

*Dhrystones* for *ROM* startup

Microseconds for one run through Dhrystone:    25.5 
Dhrystones per Second:                         39215.7 
VAX MIPS rating =     22.320 

*Dhrystones* for *ROMRAM* startup

Microseconds for one run through Dhrystone:    48.5 
Dhrystones per Second:                         20607.9 
VAX MIPS rating =     11.729 

Okay. You can see that run in external RAM take twice as many time.

The below is the most interesing for me. I could expect that runnig eCos
kernel timing test I will get for ROMRAM startup something multiplied on
2 against the values are getting for ROM startup. But, I get a few
timing faults (look the below, please).

*Kernel timing* for *ROM* startup

Reading the hardware clock takes 12 'ticks' overhead
... this value will be factored out of all other measurements
Clock interrupt took    7.55 microseconds (445 raw clock ticks)

     Ave     Min     Max     Var  Ave  Min  Function
  ======  ======  ======  ====== ========== ========
    2.69    2.68    3.70    0.02   99%  99% Thread switch
   54.49   54.49   54.49    0.00  100% 100% Tick & fire counters [>1 together]

    1.39    1.37    1.63    0.00            Clock/interrupt latency
    2.49    2.15    4.10    0.00            Clock DSR latency

*Kernel timing* for *ROMRAM* startup

Reading the hardware clock takes 20 'ticks' overhead
... this value will be factored out of all other measurements
Clock interrupt took   11.49 microseconds (677 raw clock ticks)

     Ave     Min     Max     Var  Ave  Min  Function
  ======  ======  ======  ====== ========== ========
    4.54    4.53    6.07    0.02   99%  99% Thread switch
  315.98   81.30 7591.15  454.70   96%  96% Tick & fire counters [>1 together]
                 ^^^^^^^

    2.10    2.07    2.37    0.00            Clock/interrupt latency
    3.93    3.32   75.29    0.00            Clock DSR latency
                   ^^^^^


Why I get these terrible 'Max' faults? What is a reason can be? Can
anybody commment this?

Thank you,

Sergei

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss