Re: [PATCH 0/5] dp8393x: fixes for MacOS toolbox ROM

[Finn Thain]

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?