why there is NOT support for FADS board ?

why there is NOT support for FADS board ?

[Rolf Liu]

Hi, all,
I can see supports for MBX, RPXLITE, RPXCLASSIC, etc.
but why not FADS support in linux ppc ?
BRs
Rolf Liu


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: why there is NOT support for FADS board ?

[Wolfgang Denk]

In message <033b01c09a52$e88f11e0$bf0102c8@sc.mcel.mot.com> you wrote:
>
> I can see supports for MBX, RPXLITE, RPXCLASSIC, etc.
> but why not FADS support in linux ppc ?

Speaking just for myself: I always like to work in environments where
the chance of hardware  problems  is  minimal.  I'm  making  mistakes
enough  myself,  so  I  don't  need  unreliable hardware as a compli-
cation. From what I've seen so far, I don't think the FADS  board  is
the  most  reliable  piece  of hardware around. It may have been even
worse, with improvements lately. I don't really know -  and  I  don't
care any more. I've been burned once, that's enough.

I guess others feel similar.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Man is the best computer we can put aboard a spacecraft ...  and  the
only one that can be mass produced with unskilled labor.
                                                 -- Wernher von Braun

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: why there is NOT support for FADS board ?

[Dan Malek]

Rolf Liu wrote:
>
> Hi, all,
> I can see supports for MBX, RPXLITE, RPXCLASSIC, etc.
> but why not FADS support in linux ppc ?

Because the FADS board is a pain in the ass to support.  I had some
of it in the kernel years ago, then didn't have access to any hardware
so I couldn't support it.

I have recently done the port again and you can find the initial
work on MontaVista server, in Area51.  It is in the pipeline to get
back into baseline kernel.  The MontaVista kernel is for the 860,
and I have recevied patches for the 823, so both will be there.

Maybe you would like to support it :-)?


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

dynamic modification exception handler

[kerler]

Hi all,

I am developing a module (called M in the following).

When I insmod M into a running kernel, M replace the binary code at "void
SingleStepException(struct pt_regs *regs)" with a series of codes (called
PATCH_CODE in the following). So when a single-step exception occurs, the
exception will be handled by the PATCH_CODE.

When a user-level single-step exception occur, PATCH_CODE will restore the
original binary code of SingleStepException(), restore the registers' values
when PATCH_CODE is called, then rfi (use rfi is for not using LR
register.MSR is also be restored.) to SingleStepException() to continue.
(NOTE: all the registers' values when SingleStepException() is called in
this way are the same as the registers' values when SingleStepException() is
not be replaced with PATCH_CODE.)

Now, the problem is:
After PATCH_CODE restore original SingleStepException() code and rfi to it,
I found that the code executed is still the codes of PATCH_CODE, not the
restored original SingleStepException's codes.

I have tried the following two methods to invalidate the instruction cache
after the binary codes was modified, but both have no use. But, after
PATCH_CODE has restored the original codes of SingleStepException in the
first time user-lever single-step exception, the restored original codes of
SingleStepException will be executed when the second time user-level
single-step exception occurs.

SingleStepException() is called by transfer_to_handler() in
arch/ppc/kernel/head.S and will return to int_return() in head.S. MMU is
enabled by transfer_to_handler before SingleStepException() is called.

Why the instruction cache is not invalidated after the following two methods
are used? And why the restored codes can be executed when the 2nd time
user-level single-step exception occurs?

------------method 1---------
void mdb_flush_cache (const unsigned int start, const unsigned int len)
{
    unsigned int i;
    for ( i = start ; i <= len + start ; i += 0x20 )
    {
        __asm__ __volatile__ ("dcbf 0,%0;icbi 0,%0"::"r"((void*)i));
    }
    __asm__ __volatile("eieio;isync;");
}
-----------method 1----------

-----------method 2----------
static inline void store_inst(void *p)
{
    asm volatile ("dcbst 0,%0; sync; icbi 0,%0; isync" : : "r" (p));
}
void mdb_flush_cache (const unsigned int start, const unsigned int len)
{
    unsigned int i;
    for ( i = start ; i <= len + start ; i ++ )
    {
        store_inst((void*)start);
    }
}
------------end of method 2------

thanks,
kerler

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dynamic modification exception handler

[David Edelsohn]

	The suggested sequence for 604 and 604-derived processors is:

     dcbst (or dcbf)          ;# flush data block to memory
     sync                     ;# ensure flush made it to memory
     icbi                     ;# invalidate block from icache
     sync                     ;# wait for icbi to be globally performed
     isync                    ;# refetch instructions

	The dcbst must be performed before the icbi, because otherwise the
processor instruction prefetch mechanism could refetch the (stale) block
from memory before the dcbst/dcbf has actually been written back to
memory.  The sync between them is required for the same reason, because
icbi could be performed locally before the dcbst has sent the block to
memory.

	The dcbst/sync/icbi sequence can be batched up to amortize the
cost of the sync operations, but it should be written so all the dcbst's
are performed, then a sync, then all the icbi's:

     mr        r5, r3
     mtctr     blocks
$1:
     dcbst     r0, r5
     addi      r5, r5, 32
     bdnz      $1
     sync
     mr        r5, r3
     mtctr     blocks
$2:
     icbi      r0, r5
     addi      r5, r5, 32
     bdnz      $2

     sync
     isync


David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dynamic modification exception handler

[kerler]

Hi,

I add sync between icbi and isync. But the executed codes are still the
stale codes. Is cache coherence related with address translation of MMU?

-----------method 2----------
static inline void store_inst(void *p)
{
    asm volatile ("dcbst 0,%0; sync; icbi 0,%0; sync; isync" : : "r" (p));
}
void mdb_flush_cache (const unsigned int start, const unsigned int len)
{
    unsigned int i;
    for ( i = start ; i <= len + start ; i ++ )
    {
        store_inst((void*)start);
    }
}
------------end of method 2------

----- Original Message -----
From: David Edelsohn <dje@watson.ibm.com>
To: kerler <kerler@mailandnews.com>
Cc: <linuxppc-dev@lists.linuxppc.org>
Sent: Tuesday, February 27, 2001 2:35 AM
Subject: Re: dynamic modification exception handler


>
> The suggested sequence for 604 and 604-derived processors is:
>
>      dcbst (or dcbf)          ;# flush data block to memory
>      sync                     ;# ensure flush made it to memory
>      icbi                     ;# invalidate block from icache
>      sync                     ;# wait for icbi to be globally performed
>      isync                    ;# refetch instructions
>
> The dcbst must be performed before the icbi, because otherwise the
> processor instruction prefetch mechanism could refetch the (stale) block
> from memory before the dcbst/dcbf has actually been written back to
> memory.  The sync between them is required for the same reason, because
> icbi could be performed locally before the dcbst has sent the block to
> memory.
>
> The dcbst/sync/icbi sequence can be batched up to amortize the
> cost of the sync operations, but it should be written so all the dcbst's
> are performed, then a sync, then all the icbi's:
>
>      mr        r5, r3
>      mtctr     blocks
> $1:
>      dcbst     r0, r5
>      addi      r5, r5, 32
>      bdnz      $1
>      sync
>      mr        r5, r3
>      mtctr     blocks
> $2:
>      icbi      r0, r5
>      addi      r5, r5, 32
>      bdnz      $2
>
>      sync
>      isync
>
>
> David
>
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dynamic modification exception handler

[kerler]

Hi David,

The last codes I used is in the following.
The "i < len + start + CACHE_BLOCK_SIZE" in for-circle is for the situation
that the range of memory may not align with cache block. This is one of the
reason that my codes does not work well.

thanks very much.

#define CACHE_BLOCK_SIZE 0x20
void mdb_flush_cache (const unsigned int start, const unsigned int len)
{
    unsigned int i;
    for ( i = start ; i < len + start + CACHE_BLOCK_SIZE ; i +=
CACHE_BLOCK_SIZE )
    {
        __asm__ __volatile__ ("dcbf 0,%0"::"r"((void*)i));
    }
    __asm__ __volatile("sync");
    for ( i = start ; i < len + start + CACHE_BLOCK_SIZE ; i +=
CACHE_BLOCK_SIZE )
    {
        __asm__ __volatile__ ("icbi 0,%0"::"r"((void*)i));
    }
    __asm__ __volatile("sync;isync;");
}


----- Original Message -----
From: David Edelsohn <dje@watson.ibm.com>
To: kerler <kerler@mailandnews.com>
Cc: <linuxppc-dev@lists.linuxppc.org>
Sent: Tuesday, February 27, 2001 2:35 AM
Subject: Re: dynamic modification exception handler


> The suggested sequence for 604 and 604-derived processors is:
>
>      dcbst (or dcbf)          ;# flush data block to memory
>      sync                     ;# ensure flush made it to memory
>      icbi                     ;# invalidate block from icache
>      sync                     ;# wait for icbi to be globally performed
>      isync                    ;# refetch instructions
>
> The dcbst must be performed before the icbi, because otherwise the
> processor instruction prefetch mechanism could refetch the (stale) block
> from memory before the dcbst/dcbf has actually been written back to
> memory.  The sync between them is required for the same reason, because
> icbi could be performed locally before the dcbst has sent the block to
> memory.
>
> The dcbst/sync/icbi sequence can be batched up to amortize the
> cost of the sync operations, but it should be written so all the dcbst's
> are performed, then a sync, then all the icbi's:
>
>      mr        r5, r3
>      mtctr     blocks
> $1:
>      dcbst     r0, r5
>      addi      r5, r5, 32
>      bdnz      $1
>      sync
>      mr        r5, r3
>      mtctr     blocks
> $2:
>      icbi      r0, r5
>      addi      r5, r5, 32
>      bdnz      $2
>
>      sync
>      isync
>
>
> David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: dynamic modification exception handler

[David Edelsohn]

	Note that the cache block size is implementation-dependent and not
specified by the PowerPC architecture.  The 32-bit 6xx and derived
processors have that cache block size, but not embedded processors and not
high-end 64-bit PowerPC processors.  So just be aware that you code is not
portable.

David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/