On Thu, 24 Jun 2021, Mark Cave-Ayland wrote: > Thanks for the link and the detailed testing information. I've been > trying to understand why you had to set the MAC address in the ARC > firmware so I had a bit of an experiment here. > > The reason that you need to do this is because of the NVRAM > configuration in your command line, in particular -global > ds1225y.size=8200. What this does is extend the NVRAM over the top of > the dp8393x-prom area where QEMU places the NIC MAC address and checksum > on startup, so the NVRAM captures the MAC address reads/writes instead. > The net effect of this is that the empty NVRAM initially reads all zeros > and why an initial setup is required to set the MAC address. > > This can be seen quite clearly in the "info mtree" output: > > 0000000080009000-000000008000b007 (prio 0, i/o): nvram > 000000008000b000-000000008000bfff (prio 0, rom): dp8393x-prom > > However if you completely drop -global ds1225y.size=8200 from your > command line then the NVRAM doesn't overrun into the dp8393x-prom area, > and the ARC firmware picks up the MAC address from QEMU correctly: > > 0000000080009000-000000008000afff (prio 0, i/o): nvram > 000000008000b000-000000008000bfff (prio 0, rom): dp8393x-prom > > I've also looked over the entire SONIC datasheet to see if the PROM > format is documented, and according to that there is no non-volatile > storage available on the chip itself.
Yes, that's my understanding also. The relevant National Semicondutor Application Notes seem to include a separate PROM. And if you closely examine the Linux macsonic.c driver, you'll see that the PowerBook 5x0 models get a random MAC address because no-one (outside of Apple) knows where the real MAC address is stored. > Testing shows that the checksum algorithm currently used for the dp8393x > device generates the same result as that generated by the ARC firmware, > which is known to be different than that used by the Q800 machine. > > From this I conclude that the PROM is provided by the board and not the > chipset, and therefore each machine should construct its own PROM > accordingly. I'll send a v2 patchset shortly with these changes which > shall also include the proposed endian patch. > If you potentially have both a ds1225y NVRAM and a dp8393x PROM (for the magnum machine) how do you avoid ending up with conflicting state? Would the two storage devices have to be mutually exclusive?