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.
Sure.
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.
Perhaps '-global ds1225y.size=4096' could be used to test that assumption
about ARC firmware behaviour. Anyway, the default for ds1225y.size seems
to be 0x2000. And a glance at the DS1225Y datasheets agrees with that
figure. (I'm going to assume that DS1225Y is the actual part found in
Magnum machines even though MOS6522, for instance, was not used in
Quadras.)
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.
Well, I asked about conflicting state having assumed that the NVRAM in a
real Magnum was used to store the MAC address. But that's probably not the
case. There's probably some other chip involved and your PROM device seems
like a good way to model that. (Unfortunately I don't have access to a
Magnum machine so you should take what I say about that machine with a
grain of salt.)