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

[Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>]

On 25/06/2021 05:36, Finn Thain wrote:

> 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.

Agreed. This means that the revised patchset should now be doing the right thing here.

FWIW I felt that it had changed too much in its latest form to include your original 
Tested-by tag due to the extra PROM changes, so I'd be grateful if you could give it 
a quick test.

>> 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?

The ds1225y NVRAM is located between 0x80009000-0x8000afff and running the nvram file 
through hexdump shows only the first 0x1000 bytes contain any data, so any other 
changes made to NVRAM via the ARC firmware setup will be preserved.

The existing default behaviour (without -global ds1225y.size=8200) is that only the 
last few bytes at 0x8000b000 are mapped to the dp8393x PROM, and this area is marked 
read-only to ensure that the MAC address obtained by the guest OS always matches the 
one provided by the QEMU configuration.


ATB,

Mark.