This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Ethernet CPDMA

Hi,

 in AM335x TRM, session 14.3.2.4.1 CCPI Buffer Descriptors, the Note mention that CPPI RAM begin at address 0x4a102000 and end at 0x4a103FFF.

but when i print the value "&(prev->hw_mode)" in u-boot, it shown 0x8ff77204, which is exceed the range of CPPI RAM as mention above.

is this normal ?

in file "board-support/u-boot-2011.09-psp04.06.00.02/driver/net/cpsw.c":

static int cpdma_submit(struct cpsw_priv *priv, struct cpdma_chan *chan,
   volatile void *buffer, int len)
{
 struct cpdma_desc *desc, *prev;
 u32 mode;

 desc = cpdma_desc_alloc(priv);
 if (!desc)
  return -ENOMEM;

 if (len < PKT_MIN)
  len = PKT_MIN;

 mode = CPDMA_DESC_OWNER | CPDMA_DESC_SOP | CPDMA_DESC_EOP;

 desc_write(desc, hw_next,   0);
 desc_write(desc, hw_buffer, buffer);
 desc_write(desc, hw_len,    len);
 desc_write(desc, hw_mode,   mode | len);
 desc_write(desc, sw_buffer, buffer);
 desc_write(desc, sw_len,    len);

 if (!chan->head) {
  /* simple case - first packet enqueued */
  chan->head = desc;
  chan->tail = desc;
  chan_write(chan, hdp, desc);
  goto done;
 }

 /* not the first packet - enqueue at the tail */
 prev = chan->tail;
 desc_write(prev, hw_next, desc);
 chan->tail = desc;

 /* next check if EOQ has been triggered already */
printf("Checking address [0x%08x] value is [0x%08x]\n",&(prev->hw_mode),desc_read(prev, hw_mode)); -----------------added by me
 if (desc_read(prev, hw_mode) & CPDMA_DESC_EOQ)
  chan_write(chan, hdp, desc);

done:
 if (chan->rxfree)
  chan_write(chan, rxfree, 1);
 return 0;
}

When i enter the "dhcp" command in U-Boot:

U-boot#dhcp

Checking address [0x8ff77204] value is [0xe00005ee]                            
Checking address [0x8ff7721c] value is [0xe00005ee]                            
Checking address [0x8ff77234] value is [0xe00005ee]                            
BOOTP broadcast 1                                                              
BOOTP broadcast 2                                                              
BOOTP broadcast 3                                                              
BOOTP broadcast 4

Thanks & Regards

Keldy

  • Hi,

    U-boot is not using dedicated CPPI DRAM. Buffer descriptors are allocated as normal ram inside cpsw_register()

    struct cpsw_priv {
    ...
    struct cpdma_desc descs[NUM_DESCS];
    ...
    This driver is originally written for older CPSW implementations without CPPI RAM. I guess using CPPI_RAM is faster but not so important for u-boot operation
    Damjan
  • Hi,

    For your infomation, i'm using micrel PHY KSZ9021RL and my ethernet having a problem now, cannot acquire IP when i type "dhcp" in the u-boot. 

    U-boot#dhcp                           
    BOOTP broadcast 1                                                              
    BOOTP broadcast 2                                                              
    BOOTP broadcast 3                                                              
    BOOTP broadcast 4

    Is that mean this error has nothing to do with the CPDMA ?

    Thanks & Regards

    Keldy

  • Keldy said:
    ,

    ...cannot acquire IP when i type "dhcp" in the u-boot. 

    U-boot#dhcp                           
    BOOTP broadcast 1                                                              
    BOOTP broadcast 2                                                              
    BOOTP broadcast 3                                                              
    BOOTP broadcast 4

    I have this same problem on a evm board v5.05. Although, once Linux boots, the board gets an IP Address.

    Was this resolved?

  • This problem was due to having a 1Gbps link. When I hooked up to a 100Mbps switch, all was well. There's a processor errata that states the processor gets confused when the PHY doesn't report a connection speed. (http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360&fileType=pdf): Advisory 1.0.7.

    This is supposed to get fixed in the next revision of silicon.