When I worked at qcom it took 2 devs 3 managers and 2 directors to get another group to let us fix a single race condition in their code. Once I got a copy of the code I started handing off tons of memory overwrites and underruns back for them to fix and another 10 or so race conditions. Their initial stance was 'there is nothing wrong with the code it is your code that is broken'. That was internal in the same vertical. It would be awful to work as an external group with that lib. Other stacks I got to look into were in similar shape. Some groups if you got their code you knew it was going to be solid and you would learn a thing or two. Others groups you were kind of surprised it compiled.
Unless you're buying hundreds of thousands of chips, you don't even get the "opportunity" to work with them. They won't sell you chips directly or return emails reliably.
If you're working at one of the big companies (e.g. Microsoft), they'll give you access to the documentation and source code that should be open for everyone, but even then you're going to spend time reverse engineering your own documentation because trying to get details from them is a months long process of no one being willing to say yes. It's painful. Best to stay away unless you have no other alternatives.
As a small company with relatively low volumes (10,000s) , the only way to work with them is via an OEM who has an existing relationship with a distributor (not with the actual semiconductor company). That means you won't own your PCB design, at least for most OEMs, because they don't make money on the NRE (non recurring expense) so need you to use them for manufacturing to make back their investment.
For larger volumes, ~100,000 you get to talk to a distributor yourself and design your own pcb. You still won't get to talk to anyone at BigSemiCo, but you will get access to datasheets and (probably) drivers. You will have to sign an NDA.
For their largest customers, they go all out. The customer gets significant input into the design roadmap years in advance. They can get cost-reduced versions of existing parts that leave off blocks they aren't using. reference board designs and example software are provided (to the extent that low-margin, enormous volume customers sometimes just change the html logo and ship). If the product needs integrating, Field Engineers will be flown out to assist.
There are some levels between these last two, where they will talk to you but not invest as much.
Take the above numbers with a pinch of salt; it's been a while since I was in that industry
I don't know what's it like to work with their chips, but I worked at one of them designing chips. There is often a block designed by someone 10 years ago but left the company, it has bugs, but nobody dares to touch it and fix it because "we knyiw ots bugs" and nobody really knows what's happening under the hood. So someone writes a wrapper for the next gen, to add new features. This person soon leaves the company.. rinse and repeat. I've seen wrapper of a wrapper of a wrapper on 10th gen of a product in 5nm process of a product line started its life when 90nm was state of the art. Most of the the bugs accumulated over the years were still there. They won't fix it as long as a big customer doesn't complain about it.
This is why I used a VSC PHY. After they bought Microsemi (and Vitesse as a division of Microsemi) it looked like the only viable option to get a QSGMII PHY since all the other players were much worse.
When I first started the project in 2012-13, Vitesse was just as NDA-happy and I ruled them out. The original roadmap called for a 24-port switch with 24 individual TI DP83867 SGMII PHYs on three 8-port line cards.
BTW looking at the 8051 patch bytes, they look like 8051 code to me. 0x02 is the ljmp opcode, so this is a jump table: 0x02, 0x40, 0x58, 0x02, 0x40, 0x4e, 0x02, 0x44, 0x00, 0x02, 0x42, 0x2b, 0x02, 0x41, 0x82
I poked at a vsc73xx-based switch in the past and wrote my own test firmware, but had problems with packet loss since I didn't do all the necessary phy initializations I guess, in case this might be of interest:
https://github.com/ranma/openvsc73xx/blob/master/example/pay...
Also on the device I had the EEPROM was tiny and the code is loaded from EEPROM into RAM, you were pretty much stuck with 8051 assembly that had to fit into the 8KiB of onchip RAM :)
Those addresses all make sense, as 0x4000 - 4fff appears to be where the 8051 has its RAM mapped (all of the peek/poke addresses used for accessing serdes fields are on the high end)
