Re: Help!

["Mark Chambers" <markc@mail.com>]

> Yes, the 'HPI' - are connected to a T.I. DSP, 6416 type.
>
> About the HPI problem progress.
> now we have the following resolve method:
>
> 1, If we use a temp variable to store the read out data, then store the
data to SDRAM, it is OK, there is no hop.
>      tmpReadRst = READ_UL_HPI_REG(UL_HPIDA_ADDR);
>     *p_cur = tmpReadRst;
>      p_cur++;
>
> 2, If we donot modify the source codes, but we use the optimization O3 to
compile the source codes, it is OK.
> *p_cur = READ_UL_HPI_REG(UL_HPIDA_ADDR);
> p_cur++;
>
> 3, If we add a sync instruction to the source  codes, it is OK.
> *p_cur = READ_UL_HPI_REG(UL_HPIDA_ADDR);
>             __asm__("  eieio; sync");
> p_cur++;
>
> 4, If we modify the BSP, update the memory operation option,
> from :
> PHYS_MEM_DESC sysPhysMemDesc [] =
> {
> ...
>     /*all the other small chip*/
>     {
>     (void *) 0x50000000,
>     (void *) 0x50000000,
>     0x08000000,
>     VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE |
VM_STATE_MASK_CACHEABLE,
>     VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT
>     },
> ...
> to:
> PHYS_MEM_DESC sysPhysMemDesc [] =
> {
> ...
>     /*all the other small chip*/
>     {
>     (void *) 0x50000000,
>     (void *) 0x50000000,
>     0x08000000,
>     VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE
| VM_STATE_MASK_GUARDED,
>     VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT
| VM_STATE_GUARDED
>     },
> ...
>
> We added the option VM_STATE_VM_MASK_GUARDED and VM_STATE_GUARDED,
> still use the old source codes:
> *p_cur = READ_UL_HPI_REG(UL_HPIDA_ADDR);
> p_cur++;
>
> Now We find there is no hop. It is OK
>
>
> 5, If we use the memory which is allocated by function cacheDmaMalloc(),
> the hop still exist, but the number of  hop is little than when we use
malloc().
>
> Do you tell me the reason??
>

sysPhysMemDesc? This is VxWorks, not linux, right?  Well, the same general
points can be made, but this list is not the right one for VxWorks issues.

1) Even though the 8260 is cache-coherent you should make sure the MMU is
set up so the HPI space is non-cached.
2) In C code make sure the HPI space is declared as 'volatile' so the
compiler doesn't optimize out references to the address.
3) Remember that the HPI interface on the DSP is DMA driven and goes through
a FIFO, so that writes to DSP memory have a delay before they actually
appear in DSP memory.  And don't forget to look at cache issues on the DSP
side.  Your problem may actually be on the DSP side and your various fixes
are just introducing enough delay for things to complete on the DSP side.

Good luck,
Mark Chambers