hw/m68k/q800.c | 21 ++- hw/mips/jazz.c | 32 ++++- hw/net/dp8393x.c | 313 +++++++++++++++++++----------------------- hw/net/trace-events | 17 +++ include/qemu/bitops.h | 22 +++ 5 files changed, 231 insertions(+), 174 deletions(-)
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-ayland@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
hw/m68k/q800.c | 21 ++-
hw/mips/jazz.c | 32 ++++-
hw/net/dp8393x.c | 313 +++++++++++++++++++-----------------------
hw/net/trace-events | 17 +++
include/qemu/bitops.h | 22 +++
5 files changed, 231 insertions(+), 174 deletions(-)
--
2.20.1
On Fri, 25 Jun 2021, 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-ayland@ilande.co.uk> > Tested-by: Finn Thain <fthain@linux-m68k.org> My testing was much the same as last time: 'qemu-system-mips64el -M magnum' with Linux/mips and NetBSD/arc, and 'qemu-system-m68k -M q800' with Linux/m68k. In each case I checked the MAC address against the '-nic' option. The host is little-endian. I have not tested 'qemu-system-mips64 -M magnum'. It appears MIPS RISC/os is needed for that but I don't have it. > > 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 > > hw/m68k/q800.c | 21 ++- > hw/mips/jazz.c | 32 ++++- > hw/net/dp8393x.c | 313 +++++++++++++++++++----------------------- > hw/net/trace-events | 17 +++ > include/qemu/bitops.h | 22 +++ > 5 files changed, 231 insertions(+), 174 deletions(-) > >
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-ayland@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.
On 02/07/2021 14:03, Philippe Mathieu-Daudé wrote: > 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-ayland@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. Thanks for picking these up - I've been AFK for the past week :) What was the issue with patch 9 "dp8393x: fix CAM descriptor entry index"? That patch ensures that the CAM index is read from the descriptor, and not taken from the for() loop i.e. it is unrelated to register access size. See section 4.1.1 "The Load CAM Command" in the DP83932C datasheet for more information. ATB, Mark.
On 7/3/21 8:32 AM, Mark Cave-Ayland wrote: > On 02/07/2021 14:03, Philippe Mathieu-Daudé wrote: > What was the issue with patch 9 "dp8393x: fix CAM descriptor entry > index"? That patch ensures that the CAM index is read from the > descriptor, and not taken from the for() loop i.e. it is unrelated to > register access size. No issue, simply nobody reviewed it and I was not confident enough. > See section 4.1.1 "The Load CAM Command" in the > DP83932C datasheet for more information. I'll have a look. The patch could go via Jason's tree or Trivial then.
© 2016 - 2024 Red Hat, Inc.