[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Mark Cave-Ayland
Subject: Re: [PATCH 0/5] dp8393x: fixes for MacOS toolbox ROM
Date: Thu, 24 Jun 2021 15:42:14 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]