lwip is a popular solution. As mentioned above it depends on whether you have a reason to write your own. And at what level. ARP and ping will be your first test to get your feet wet. With practice you can bang out a (special purpose) UDP stack (with cheats) in an afternoon. And when I say that I have done some that are slave only so some master/server sends packets to me, I cheat and dont arp I just flip the source/destinations in the header. and send a response, I even go so far as to fix the packet size. Not in any way a full stack but you can have a normal full stack host computer talk to you for some purpose. Real udp you need to arp you need to timeout your arp table entries. etc, etc. TCP is harder even receiving one connection, one packet sending one back and cleaning up so that the next connection works will take some time and thats assuming no fragmentation. There are some lighter weight protocols in between that you could look for (SCTCP for example), YMMV. Depends on how much of this is an educational task, the whole thing or just the OS parts and not necessarily the drivers. I recommend though once you get the USB up you should try to do RARP and ping yourself, not difficult, educational, and there is some level of pride in being able to ping to your code from some other place. Yyes there is a command at least in linux to re do or clear the arp table so that you can get multiple arps and not have to keep changing your ip address or mac address. After rarp and ping then look at udp and tcp and see if you really want to get into that vs integrating lwip.
As far as IP goes this is very typical. DRAM, USB, ethernet, video. IP like that which is non-trival is usually something you purchase, from companies like cadence since you are already giving them a million to a few million dollars a year to use their tools to make the chip in the first place whats another few ten thousand? And this IP generally has an NDA, so if you are a company that provides documentation to customers you still cant provide documentation for that IP. I find it difficult to provide open source software for NDA protected items as to me that is providing documentation about the IP. The good-ish side of this is that "everyone" buys the same IP from the same vendor(s). So as mentioned above you will find multiple chips from one or more vendors that use the same or similar open source drivers or their drivers and some other driver basically do the same thing even if it isnt the same source code. You dont see this at all or as much on a microcontroller one because they dont normally need these complicated interfaces, the usb is usually buried in the logic you dont have direct control, same with ethernet, and you dont normally have dram, dont have high speed phys or serdes to deal with. And that market historically you write your own baremetal code. Markets where you have operating system capable chips (not that an mcu cant run an RTOS) like full blown linux, windows, etc. The chip vendor makes a board support package has written the drivers or taken code from the IP vendor and used it directly or indirectly, whatever and the rest of us just write printf() programs on the operating system for that platform, applications. broadcom, allwinner and some others generally dont want any of their documentation out ,they have NDAs with customers. note buying a raspberry pi we are not a customer. the raspberry pi folks (Which are I think actually broadcom) are a customer and they can see the real documentation. Some allwinner customers have "accidentally" left marked documents laying around, and in recent years seems like some have had permission to re-release. Folks like ti I am happy to see have docs you can just download. But I assume you still cannot see the ddr nor usb nor phy/serdes register specs, maybe the ethernet, maybe not. I have not looked into that portion of those docs, was only interested in booting and blinking some leds and spitting characters out the uart.
Each new process can dictate new IP for a chip vendor, as well as a new foundry can dictate new ip. The dram and usb and ethernet controllers are or can be portable digital logic, but they tie into phys that are part analog and have to be designed to the process. LIkewise time passes. You might not necessarily be able to find a DDR2 controller/phy that works on a 10nm process at xyz foundry. Maybe not even DDR3 but certainly DDR4. Same goes for usb1.0, pcie gen1 only, etc, etc. Why would you build a new chip on a current process that only supports old protocols or speeds? How intimate the controller and the phy are and/or how interested you are in creating a standards compliant usb controller vs just buying one is how we get in this situation. Its an endless cycle. I am happy to see that baremetal is a thing on the pi, but it really isnt a thing on other similar platforms, dont know why it turned out this way.
Why do companies hide this info? From low level ip blocks to chips to boards? Various reasons in theory protecting something, from cloning or other "secrets". But if I have to call some regional salesperson and give up my name, address, name of first born, etc just to get a document I should have been able to download and as a reward you call me every week or show up at the office to harass me or try to get names of other employees to harass. I have personally blacklisted such companies, wont buy from them, I am certainly not interested in your product. It cant be that special. Arguably if broadcom had not put out the arm document they did, I probably wouldnt be here, would never have had a reason to buy a raspberry pi. Only in the last year or two have I bothered to look at anything allwinner for that reason. But the dram/usb/ethernet/etc IP though I expect that to be closed document even for actual chip customers who pay the big bucks to Broadcom and wouldnt personally blacklist them for that being closed source. At least now that I have been in the chip business for a while. Before knowing all of this I probably would have. Fortunately I dont buy stuff other than for homebrew hobbies at this point otherwise where I work we probably wouldnt have any products I would have blacklisted them all for one reason or another.
Back to ethernet.
Even though the RFCs say this one is superseeded by that one, find the older/oldest ones first. And/or google
tcp/ip illustrated volume 1
This should contain those basics and if I remember right tells you the RFC numbers.
Hint: The checksum for UDP and maybe TCP I think they call it a ones complement. You have to roll the carry out back in to get the right answer.
Hint: For UDP it says you can leave the checksum zero and that is valid (dont have to compute it until you are ready to swap/fix the mac address swap the ip addresses, change the payload, zero the checksum, send back out).
TCP is PITA...