AM6422: SDK8.6 icssg1 freertos modfiy mac addr

Hi,

For Layer2 application, you would need to use "ICSSG_HOSTPORT_IOCTL_SET_MACADDR" IOCTL to set the new MAC address, and you should also update your own application's checks with the new mac address.

For LwIP applications, you should update the netif->hwaddr field along with the above mentioned IOCTL to update the MAC address.

In case of switch implementation, you should use "ICSSG_MACPORT_IOCTL_SET_MACADDR" IOCTL per mac port and netif to achieve the same.

Please let us know if you have further queries.

Thanks and regards,
Teja.

Hello，

    We initially had the Ethernet running normally with the default IP address. Then we called the MAC‑address modification function (as mentioned below), and after that the system entered an error state. The attached screenshot shows the location where the error occurred; at that point the len field of the pbuf was measured as 42.

int32_t ICSSG_setMacAddress(uint8_t macAddr[ENET_MAC_ADDR_LEN])
{
int i;
int32_t status = ENET_SOK;
uint32_t coreId = EnetSoc_getCoreId();
EnetApp_AppEnetInfo* pEnetInstInfo = &gEnetAppParams[0];
EnetApp_getEnetInstInfo(CONFIG_ENET_ICSS0, &pEnetInstInfo->enetType, &pEnetInstInfo->instId);

Enet_Handle hEnet = Enet_getHandle(pEnetInstInfo->enetType, pEnetInstInfo->instId);
/* Add port MAC entry in case of ICSSG dual MAC */

Enet_IoctlPrms prms;
IcssgMacPort_SetMacAddressInArgs inArgs;

memset(&inArgs, 0, sizeof(inArgs));
EnetUtils_copyMacAddr(&inArgs.macAddr[0U], &macAddr[0U]);
inArgs.macPort = Lwip2Enet_findMacPortFromEnet(ENET_ICSSG_DUALMAC, pEnetInstInfo->instId);

ENET_IOCTL_SET_IN_ARGS(&prms, &inArgs);
ENET_IOCTL(hEnet, coreId, ICSSG_MACPORT_IOCTL_SET_MACADDR, &prms, status);

if(NULL != g_pNetif[0])
{
for(i=0; i<6; i++)
g_pNetif[0]->hwaddr[i] = macAddr[i];
}

if (status != ENET_SOK)
{
EnetAppUtils_print("failed ICSSG_MACPADDR Write: %d\r\n",status);
}
EnetAppUtils_assert(status == ENET_SOK);
}

Hi,

When changing the MAC address, the IP address needs to be re negotiated, and the lwip stack needs to stop transmitting packets when the netif->hwaddr is being updated. I have not tested changing the MAC address on the fly during transmissions.

To stop the transmissions, you can set the netif state to down using the API "netif_set_down"

Please let us know if you face issues further after following these steps. We will try to recreate the issue locally, and help resolving the issue.

Thanks and regards,
Teja.

Hello,

    We called netif_set_down before changing the MAC address, but we still encounter this issue, with the same symptom.

Hello，

    We have also observed that when using the ICSSG1 Ethernet, in lwip2enet.c, the function Lwip2Enet_prepRxPktQ monitors the value of Enet_MacPort rxPortNum = pCurrDmaPacket->rxPortNum; and finds that it takes 0xff, whereas the actual port is 0. Later, the code stores netif = rx->mapPortToNetif[rxPortNum]; – but the maximum size of this array is only 2. This results in a buffer overflow.

Hi,

I will try to reproduce this on our side, and I will update you on the results.

Wendy said:

Enet_MacPort rxPortNum = pCurrDmaPacket->rxPortNum; and finds that it takes 0xff, whereas the actual port is 0.

This shouldn't be possible, since the firmware will be filling the rxportnum field per packet, and will be routed to the hostport. Can you please verify that you are indeed using the correct version of the ICSSG firmware?

Thanks and regards,
Teja.

Hello，

    How can I check the firmware version you mentioned? We are simply using the default example program from SDK 8.6 – enet_lwip_icssg_am64x-evm_r5fss0-0_freertos_ti-arm-clang – with no modifications. During simulation, we confirmed that the value is indeed 0xff.

    Also, regarding the runtime MAC address change we discussed earlier, we still haven't been able to implement it and would appreciate your support on that.

Hi,

Is the value 0xFF from the start of the application itself? Or is it changing after the MAC address change is done? In the out of box application, I was able to confirm that the application actually receives the correct port number.

Regards,
Teja.

Hello，

    We are using the example MAC address and haven't modified it yet.

Hi,

I will check this behaviour and will get back to you by EoD.

Regards,
Teja.

Hi,

I am able to verify that with the 08.06.00.45 version MCU+ SDK, we do not have issues with out of box example for enet_lwip_icssg example. Can you please try this on your end with a fresh install of the SDK again?

I am able to confirm that the packet reception is working fine, along with the rxPortNum being reported correctly.

Regards,
Teja.

Hello，

   Okay, let's try again using the newly installed example. We have not made any progress so far on modifying the MAC address during runtime, and we would appreciate your support on this part.

Hi,

Let us know when you have the results. We can continue the discussion once we have more data.

BR,
Teja.

Hello，

    We now need to know about another issue, which is the method for modifying the MAC online.

Hi,

Since there seems to be some misalignments with your baseline compared to standard SDK, I would suggest you to try with a new and fresh install without any changes to the installer baseline. If you are facing issues with it, then we can take a look regarding what is happening.

Regards,
Teja.

Hello，

    We are using the unmodified base example of SDK 8.6, and the behavior is the same as previously reported. Since we are using the DP83869, the detected PHY is shown as Generic, as shown in the figure below. In the Lwip2Enet_prepRxPktQ function, the value of rxPortNum is 0xff. However, when we use the SDK 11.2 example, we find that it can identify the PHY as 83869, and the port value is also correct. Since we cannot use SDK 11 for now, we are considering whether there are any methods or workarounds for SDK 8.6 that can solve this problem.

SDK8.6

SDK11.2