Hi Mark, On 6/25/21 8:53 AM, Mark Cave-Ayland wrote: > Here is the next set of patches from my attempts to boot MacOS under QEMU's > Q800 machine related to the Sonic network adapter. > > Patches 1 and 2 sort out checkpatch and convert from DPRINTF macros to > trace-events. > > The discussion for the v1 patchset concluded that the dp8393x device does > NOT have its own NVRAM (there is no mention of it on the datasheet) and so > patches 3 to 5 move the generation of the PROM to the q800 and jazz boards > separately to allow the formats to diverge. > > Patch 6 adds an implementation of bitrev8 to bitops.h in preparation for > changing the q800 PROM storage format, whilst patch 7 updates the MAC address > storage and checksum for the q800 machine to match the format expected by the > MacOS toolbox ROM. > > Patch 8 ensures that the CPU loads/stores are correctly converted to 16-bit > accesses for the network card and patch 9 fixes a bug when selecting the > index specified for CAM entries. > > Finally since the MIPS magnum machine exists for both big-endian (mips64) and > little-endian (mips64el) configurations, patch 10 sets the dp8393x big_endian > property accordingly using a similar technique already used for the MIPS malta > machines. > > Migration notes: the changes to the dp8393x PROM are a migration break, but we > don't care about this for now since a) the q800 machine will have more > breaking migration changes as further MacOS toolbox ROM support is upstreamed > and b) the magnum machine migration is currently broken (and has been for > quite some time). > > Signed-off-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk> > > > v2: > - Move PROM generation from dp8393x to q800 and magnum machines and remove > the existing code from the device itself > - Add bitrev8 implementation to bitops.h so it can be used elsewhere in > future. Use a shift/merge technique rather than a massive table lookup > as we don't care about speed > - Add patch to set the big_endian property correctly depending upon whether > a big-endian or little-endian configuration is being used > > > Mark Cave-Ayland (10): > dp8393x: checkpatch fixes > dp8393x: convert to trace-events > hw/mips/jazz: move PROM and checksum calculation from dp8393x device > to board > hw/m68k/q800: move PROM and checksum calculation from dp8393x device > to board > dp8393x: remove onboard PROM containing MAC address and checksum > qemu/bitops.h: add bitrev8 implementation > hw/m68k/q800: fix PROM checksum and MAC address storage > dp8393x: don't force 32-bit register access > dp8393x: fix CAM descriptor entry index > hw/mips/jazz: specify correct endian for dp8393x device
Since a MIPS machine is involved, I'm queuing patches 1-7,10 (PROM cksum) to mips-next. I'm leaving 8-9 for further discussion after seeing the guest memory traces. Regards, Phil.
