FreeRTOS + TCP/IP on Arm Cortexa53

Kernel
62

He is a very early version of the UltraScale+ driver: xilinx_ultrascale.zip (28.9 KB)

And these are the config files that I used to test it: config_files.zip (8.9 KB)

If it doesn’t work for you, please don’t waste too much time debugging the code, just ask here on this forum.

63

I forgot to attach some modified source from FreeRTOS+TCP, here they are: FreeRTOS-Plus-TCP.zip (248.2 KB)

You will find some small changes when the code handles pointers.

Please add the following #define in your FreeRTOSIPConfig.h:

#define ipconfigBUFFER_PADDING	( 12U + ipconfigPACKET_FILLER_SIZE )

Every NetworkBufferDescriptor_t has a pucEthernetBuffer in which Ethernet packets are stored.
Normally at pucEthernetBuffer - 10, the a 32-bit pointer is stored to the owning NetworkBufferDescriptor_t.
As UltraScale+ is 64-bits, the pointer will be stored as 8 bytes in pucEthernetBuffer - 14.

64

Hello htibosh,
Thank you for the driver. I have some question to ask if you don’t mind :

  • I m using an cortex R5 32 bit arm v7 for ethernet, i m using Ram Tcm for includding binarie and execution. My buffer descriptors are located in the ddr uncached memory. I musing the freeRtoas stack TCP/IP V2.0.11.
  • i m using an ultrascale+ version 7. in the xemacps when the version are not 2 it switch to Q1 queue buffer but it seems the q1 receive_queue and Q1 transmit_queue not configured. i fixed this problem but what the difference between Q1 and Q0 and what’s the effect in the ethernet controller ?
    as I show in the picture, the statistic register show that the message are transmitted but i can’t see it throw wireshark.
    in the tx_DMA_buffer i added the offset 0xffe00000 to allow the dma to access to atcm ram memry of the R5 in both RX AND TX.
    for padding i use the 32 bit padding 8+2 it s ok pour R5 ?
    My arp frame don’t show in the wireshark flow but when i use loopback option i see the message came from tx to rx and i get data, did you have any idea about why the frame didn’t be sent on the ethernet bus ?
66

Hello Everybody,

Now i’ve got a Server running. If I send Data from my UltraScale back to my Application on my desktop i’ve got some output that say:

xCheckSizeFields: location 4

/* Check if the complete IP-header plus protocol data have been transferred: */
usLength = pxIPPacket->xIPHeader.usLength;
usLength = FreeRTOS_ntohs( usLength );
if( uxBufferLength < ( size_t ) ( ipSIZE_OF_ETH_HEADER + ( size_t ) usLength ) )
{
xLocation = 4;
break;
}

have you an Idea what that exactly mean?

Best regards, Philipp

67

I am sorry to respond so late. I had prepared a reply but forgot to finish and post it.

I m using an cortex R5 32 bit arm v7 for ethernet

As you probably know, I tested the Ultrascale+ driver on a 64-bit Cortex-A53 core.
I don’t know what you have to do to have an R5 talk with the xemacps.

My buffer descriptors are located in the ddr uncached memory.

Did you use the module uncached_memory.c for this?

i m using an ultrascale+ version 7. in the xemacps when the version are not 2 it switch
to Q1 queue buffer but it seems the q1 receive_queue and Q1 transmit_queue not configured.
i fixed this problem but what the difference between Q1 and Q0 and what’s the effect in
the ethernet controller ?

I am sorry, but I don’t know much about the memories of an Ultrascale.

@Maxim.Vechkanov, who helped me a lot when developing the driver, do you have an idea?

as I show in the picture, the statistic register show that the message are transmitted
but i can’t see it throw wireshark.

Maybe there is a problem with the PHY? Is your PHY supported? Does it get a
proper Link Status? Does it report a line speed?

in the tx_DMA_buffer i added the offset 0xffe00000 to allow the dma to access to atcm
ram memry of the R5 in both RX AND TX.

You seem to know more about the memories than I do.

for padding i use the 32 bit padding 8+2 it s ok pour R5 ?

Yes, that is OK.

The library uses a dynamic test:

if( sizeof( uintptr_t ) == 8 )

as i am not sure if __aarch64__ is defined on all compilers.

My arp frame don’t show in the wireshark flow but when i use loopback option i see the
message came from tx to rx and i get data, did you have any idea about why the frame
didn’t be sent on the ethernet bus ?

Did you also use the FreeRTOS+TCP sources as posted here above?

Have you defined:

#define ipconfigETHERNET_MINIMUM_PACKET_BYTES   ( 60 )
68

@Mulle : same question to yo: did you download and use the FreeRTOS+TCP library and driver that I posted here above?
What happens if you comment out the call to xCheckSizeFields()? Does everything work normal?
Do you have a dump of the packet that causes the “length error”?
You might see it pass-by in a Wireshark capture…