Add support of CH390H both in esp_eth and its examples (IDFGH-12259)

[SergeyKharenko]

CH390H is the first ethernet controller integrated with both MAC and PHY designed by NanjingQinhengMicroelectronics CO LTD (abbreviated as WCH). It could perfectly replace DM9051. Besides, the peripheral circuit of CH390H is much more simple than that of DM9051. What's more, CH390H is integrated with a hardware-defined globally unique MAC address. Therefore that simplifies the configuration of the chip.

However, this chip is released around 2023 Q2. WCH only provides sample code on the CH32V series platform. As far as I know, there is no existing example that successfully migrated this chip on ESP-IDF. In this case, my work is meaningful.

My work can mainly be divided into the following steps：

1. Refer to the code in the ESP-IDF about DM9051
2. Adjust for the hardware design of the CH390H (for example, vendor id check)
3. Optimize the strategy of the driver. For example, combine xxx_get_recv_byte_count and emac_xxx_receive. I don't think repetitively reading the length of the data is an efficient strategy.
4. Add support of CH390H in Kconfig, so that it can be chosen in several examples provided by EDP-IDF.
5. Performance benchmark using iperf created by Show Example Projects in Visual Studio Code. The result is shown in the below table. Both transmit and receive increase LINEARLY as the SPI frequency increases. From this result, it can be concluded that the current performance bottleneck is mainly in the SPI frequency rather than the driver layer (CH390H can run SPI at a frequency up to 50MHz).

SPI Frequency (MHz)	UDP Transmit (Mbps)	TCP Receive (Mbps)
1	0.88	0.86
4	3.4	3.11
8	6.38	5.85
16	11.29	9.81
20	13.3	11.34
26	16.3	13.96
40	20.96	17.3

Before this PR, I also consulted WCH about the copyright, for the reason that I have used the register definition of this chip which directly comes from their example project. They just told me I am free to develop and share these codes.

PS:
Here is the introduction to this ethernet controller in detail(translated from its official website):
CH390 is an industrial-grade Ethernet controller IC with 10/100M Ethernet Media Transport Layer (MAC) and Physical Layer Transceiver (PHY), supporting CAT3, 4, 5 and CAT5, and 6 connections for 10BASE-TX and 100BASE-TX, supporting HP Auto-MDIX, low power design, and IEEE 802.3u compliant. The CH390 has a built-in 16K byte SRAM, and supports 3.3V or 2.5V parallel interface and SPI serial interface.

[CLAassistant]

All committers have signed the CLA.

[github-actions]

	Messages
📖	This PR seems to be quite large (total lines of code: 1329), you might consider splitting it into smaller PRs

👋 Hello SergeyKharenko, we appreciate your contribution to this project!

---

📘 Please review the project's Contributions Guide for key guidelines on code, documentation, testing, and more.

---

🖊️ Please also make sure you have read and signed the Contributor License Agreement for this project.

---

Click to see more instructions ...

This automated output is generated by the PR linter DangerJS, which checks if your Pull Request meets the project's requirements and helps you fix potential issues.

DangerJS is triggered with each push event to a Pull Request and modify the contents of this comment.

Please consider the following:
- Danger mainly focuses on the PR structure and formatting and can't understand the meaning behind your code or changes.
- Danger is not a substitute for human code reviews; it's still important to request a code review from your colleagues.
- Addressing info messages (📖) is strongly recommended; they're less critical but valuable.
- To manually retry these Danger checks, please navigate to the Actions tab and re-run last Danger workflow.

Review and merge process you can expect ...

We do welcome contributions in the form of bug reports, feature requests and pull requests via this public GitHub repository.

This GitHub project is public mirror of our internal git repository

1. An internal issue has been created for the PR, we assign it to the relevant engineer.
2. They review the PR and either approve it or ask you for changes or clarifications.
3. Once the GitHub PR is approved, we synchronize it into our internal git repository.
4. In the internal git repository we do the final review, collect approvals from core owners and make sure all the automated tests are passing.
- At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
5. If the change is approved and passes the tests it is merged into the default branch.
5. On next sync from the internal git repository merged change will appear in this public GitHub repository.

Generated by 🚫 dangerJS against fb7531c

[kostaond]

@SergeyKharenko nice job! Thank you for the PR. Community surely appreciate adding support of CH390! We only need to internally discuss if to add support directly to ESP-IDF or to maintain it at https://github.com/espressif/esp-eth-drivers. I let you know.

[SergeyKharenko]

@SergeyKharenko nice job! Thank you for the PR. Community surely appreciate adding support of CH390! We only need to internally discuss if to add support directly to ESP-IDF or to maintain it at https://github.com/espressif/esp-eth-drivers. I let you know.

No problem, I'll stay tuned! It is certainly a good idea to separate the network driver from the mainline.

[SergeyKharenko]

Due to my lack of experience with PRs, I mistakenly submitted the master branch directly to the PR, which directly caused the pre-commit to fail. New session has been submitted by the new branch. Here is the new session #13309

[leeebo]

@SergeyKharenko Thanks for your contribution, follow this topic I'd like to share few "painful" debugging process about CH390H.

I happen to have both DM9051 and CH390H chips, and also tested CH390H based on the DM9051 code, but I ran into a lot of hidden problems:

1. for CH390H, the PHY OUI is not Inconsistent with the manual (ok, easy to fix)
2. for CH390H, the x_memory_peek function does not work normally (read CH390_MRCMDX1 register), the second byte (header->status) always set BIT0 to 1 (FOE bit: RX Memory Overflow ERROR), But this is not possible for the first package. (It took me days to debug!!) (I saw you just remove the x_memory_peek using x_memory_read instead, good workaround)
3. for CH390H, the PHY should be powered on again after mac software reset. (It took me several retries to find it...)
4. ...

CH390H just announces it can replace DM9051, and provide document looks same as DM9051 (But they are not really same as my expected, and no docs mention the differences). The only thing you can do is guess and experiment, I am not sure what other problems users will encounter when using registers outside the CH390 official's demo example.

Personal opinion 🤔:
It is recommended to use IDF component manager with personal namespace to provide Initial support.

[leeebo]

And the "official" blog indicate that CH390H have a TX RX probabilistic offset error problem. We also need to provide workaround if add support.

[kostaond]

@SergeyKharenko we discussed internally and we decided that the CH390 should be distributed as separate component via Component registry. Could you please open PR at https://github.com/espressif/esp-eth-drivers

@leeebo thanks for additional insight! It would be great if you helped us to review the PR once opened at https://github.com/espressif/esp-eth-drivers. It would be much appreciated.

[SergeyKharenko]

And the "official" blog indicate that CH390H have a TX RX probabilistic offset error problem. We also need to provide workaround if add support.

What a coincidence to meet you here! I have read you blog. It provides me with very valuable experience!🥰🥰🥰

[SergeyKharenko]

@kostaond I have committed the PR in esp_eth_drivers as you wish. It is marked as beta.

I have to acknowledge these bugs mentioned by @leeebo . However, at least during my benchmark using iperf(over 10 min), no error log was reported(corresponding to RX TX offset error will case error log). I think the locking mechanism for the SPI and DMA transmission protects the chip from interruption when ESP r/w its SRAM.

[leeebo]

@SergeyKharenko Thanks, will help review your PR

[kostaond]

Duplicates espressif/esp-eth-drivers#23