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

[Mark Cave-Ayland]

On 18/06/2021 07:22, Finn Thain wrote:

> I was able to test this patch series successfully, using both
> "qemu-system-mipsel -M magnum" and "qemu-system-m68k -M q800". With the
> latter emulator I used a Linux/m68k guest and with the former I used both
> Linux/mips and NetBSD/arc guests.
>
> Basic dp8393x functionality worked fine. I don't know how the m68k guest
> obtained its MAC address setting, but the macsonic driver banner message
> agrees with what's on the wire, at least.
>
> The mips guest has ARC firmware which allowed the MAC address to be
> programmed manually:
>
>   JAZZ Setup Program Version 0.17            Friday, 6-18-2021   5:06:02 AM
>   Copyright (c) 1991, 1992  Microsoft Corporation
>
>       The current Ethernet station address is: 900090001122
>       Enter the new station address:  900090123456
>       The value written to NVRAM is: 9000901234560042
>   Press any key to continue...
>
> I'm guessing that the "0042" is the checksum?
>
> BTW, the patch in the message quoted above does not seem to affect my
> results. (This host is little-endian...) I don't know how to test
> that one. For the others:
> Tested-by: Finn Thain <fthain@linux-m68k.org>

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


ATB,

Mark.