1) You have done your own version of MbedTLS. This is a massive piece of code, taking up some 250k of my total FLASH usage of 500k. How many years did you spend on that? I realise the crypto suite algorithms are available as open source, but still it is a lot of code.
2) Your illustration of the config for the DMA and the RMII MAC config link (which IIRC is basically a 64 bit "USART") is amazingly simple and I wonder how much more code there is behind that. My project uses the ST Cube IDE (ex Cube MX, AFAIK) code which needed a huge amount of work to make it run properly. I had to dig into the RMII MAC config link to implement a MAC power-down feature and it took ages to find out the details.
3) You mention that some devs have problems with DMA not having access to some memory regions. In the 32F4 it is only the CCM RAM which DMA cannot access. Is that what you had in mind?
It's not just me, we have a team of several developers working on it.
1. TLS took us quite some time. The initial effort was done in 2015-2016, at that time mbedTLS was still polarSSL, commercial and not yet bought by ARM. So there was no free, good quality TLS library out there. Well there was axTLS by Cameron Rich, but it did not support couple of things at the time, like mutial TLS, so we decided to write our own TLS stack. And we did, and it worked well with AWS IoT which was just released, it was 2016 if I am not mistaken. Our TLS was RSA only. Then ARM bought polarSSL, rebranded as mbedTLS, and made free. So there was no reason for us keeping our own stack, so we have sunset the project.
Later on we found out that a lot of our customers had issues with mbedTLS, especially on slow micros with little RAM, like F4x9. mbedTLS is very well written and capable, but it needs some expertise with tuning - and that's the issue. So we took our old project, threw away RSA and added EC (Elliptic Curve) which is more modern, smaller and faster, and made it very small and fast by default, no tuning required. It eats about 50k flash or so, and several kylobytes RAM per live connection, the precise number depends on various factors. That took quite an effort too, but it was worth it. Some customers with no hope of running TLS on their micros, managed to run it successfully with our built-in TLS.
2. There MAC -> PHY interaction in terms of code is tiny. On a software side, talking to PHY is "register" based. PHY registers are 16-bits, you either read or write to them. To read a PHY register, you write to MAC's MACMDIOAR register the PHY's address and register number you want to read, and then wait on MACMDIOAR register. While you wait, the MAC communicates with PHY over the MDIO pin. When PHY responds with the result, MAC writes it to the MACMDIODR register and signals readiness in MACMDIOAR. The writing is done similarly. The whole code for H7 is 12 lines, F4/F7 are very similar:
https://github.com/cesanta/mongoose/blob/e0740fc2ca3024eaa2f80fa73dd141c9827f86db/src/drivers/stm32h.c#L59-L73All PHY logic - like intialisation, getting link status is handled in
https://github.com/cesanta/mongoose/blob/master/src/drivers/phy.c which is 150 lines of code and handles all supported PHYs.
3. Yes. For example on H723, the "default" RAM region which usually starts at 0x20000000 is in D1 domain, and Ethernet controller is in D2 domain, so Ethernet won't work without linker script magic. Other controllers, like H5x3, have a simpler RAM layout and that linker script yada yada is not needed. I believe the same goes for F4xx, where the "default" RAM region IS accessible by the Ethernet DMA.