Update Zynq Ultrascale port for V4.x and Clean up

[StefanBalt]

Description

This pull request introduces the V4.x port for the Xilinx Ultrascale, which basically merges the previous implementation, the Zynq7000 port and the suggestion by @pete-pjb here #1172

Key Changes:

• V4.x Port: A combination of previous work, the Zynq7000 port, and the proposal in by @pete-pjb here #1172
• Interrupt Mapping: A new header file, x_emac_map.h, has been introduced to handle interrupt IDs. Since there is no canonical definition for EMAC interrupt IDs, the header maps interrupt IDs based on the EMAC base address.
• LLMNR Update: The LLMNR implementation now leverages the multicast MAC hash table rather than using a dedicated MAC entry.
• Removal of Zynq7000 (GEM V2) Code: Zynq7000-related code has been removed, as the ports for the Zynq7000 and Ultrascale are quite distinct. Keeping the Zynq7000 code IMHO no longer adds value and was redundant.
• Micrel PHY support is also from the .zip provided by @pete-pjb. However, this has not been tested and may require further validation.

I will provide inline comments on specific sections where I'm uncertain or need feedback.

Test Steps

I could only test a single interface with IPv4 so far. Junbo Frames and LLMNR also work fine. I plan to test multiple interfaces on a Kria board I have at my hand soon.

Checklist:

• [ ] I have tested my changes. No regression in existing tests.
• [ ] I have modified and/or added unit-tests to cover the code changes in this Pull Request.

Related Issue

#1172

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[htibosch]

Every Ethernet peripheral, or most of them, has two ways of setting a MAC-address:

• Up to four standard MAC-addresses. Need 100% match
• A hash table with like 64 entries. Each entry is actually a bit.

Hash: when you add a MAC address whose calculated hash value is 12, then bit 12 in the hash table will get set.

( no news for most of you ).

Emil Popov and me came up with this idea:

• First add primary MAC-addresses, i.e. the hardware addresses of the endpoint.
• Secondly, add the MAC-addresses of the multicast addresses used (e.g. mDNS, LLMNR).

The first 4 (GMACSA_NUMBER) addresses will go to the table in the peripheral. All subsequent addresses will be hashed.

MAC-addresses can be unhashed too: there will be 64 usage counters. When the counter reaches zero again, the hash value will be cleared. You find an implementation in DriverSAM. Maybe we should put it in Common, so all drivers can use it.

For the Ultrascale port, I am thinking of using the same method.

[StefanBalt]

Ah youre'right the Zynq7000 port uses XEMACPS_NWCFG_MCASTHASHEN_MASK directly instead of using the API function. I added the discussed multicast fixes to the Zynq7000 port.

I noticed the promiscuous mode in the Zynq7000 port which is somewhat questionable as a default:

    /* As 'MCASTHASHEN' doesn't seem to work, use the promiscuous mode so that IPv6 multicast packets are received. */
    /* Allow promiscuous mode. */
    ulValue |= XEMACPS_NWCFG_COPYALLEN_MASK;

But I cannot test it.

By enabling and playing with mDNS?

I meant I do not have a Zynq7000 at hand. I did test mDNS now for the Ultrascale.

I do like the idea of sharing the MAC related code in Common, however I do not have the time to do it at the moment.

My testing is complete for now here is what I did and what I think should still be tested:

• [x] IPv4 including LLMNR, mDNS, Jumbo Frames
• [x] Two endpoints (Virtual interfaces) on the same physical interface
• [ ] IPv6
• [ ] More than one physical interface
• [ ] Zynq7000 changes

[tony-josi-aws]

@StefanBalt

Thanks for taking time to contribute to FreeRTOS+TCP.

Can you help in fixing the CI checks:

1. To fix the spell checks these words [those listed in the logs Run spellings check] needs to be added to this file.
2. To fix the formatting please apply this patch.

Please let us know if you have questions or want us to take care of the CI.

[tony-josi-aws]

@StefanBalt Since the multicast PR needs more time to be merged, can you please help in fixing the following proposals from @htibosch so that we can go ahead with merging the branch:

• LLMNR
• MDNS

Please feel free to let us know if you prefer us to make the suggested changes. Thank you.

[StefanBalt]

Sure, I will push a fix (probably today).

[StefanBalt]

I don't have the time to test it, I hope you did.

As mentioned earlier, I tested some of the features but not all (i.e. IPv6, DHCP and more than one physical interface missing).