[PATCH v3 0/8] Add IBM Huygens BMC machine for AST2700

Mikail Sadic <[email protected]>
Newsgroups org.nongnu.qemu-arm,org.nongnu.qemu-devel
Message-ID <[email protected]>
This series adds initial support for the IBM Huygens BMC, the baseboard
management controller of an IBM POWER12 server platform, based on the
ASPEED AST2700 A2 SoC.

It introduces a CFAM-S FSI responder model, wires the AST2700 FSI
controllers to their APB-to-OPB bridges, fixes an aspeed I2C DMA
block-read corner case, adds a TI UCD90320 PMBus power-sequencer model,
adds an AST2700 UFS host controller on top of the generic sysbus UFS
device, and finally adds the huygens-bmc machine that ties these together
to boot OpenBMC from FMC flash and a UFS root filesystem.

Dependency: this series applies on top of Jeuk Kim's UFS restructure,
which is on-list but not yet merged:

  https://lore.kernel.org/qemu-devel/[email protected]/

The base-commit trailer below therefore names a local commit that is
v11.1.0-rc3 (3e3ccab106) plus those two patches. Patches 6 and 7 need
it, patches 1-5 and 8 do not.

Patch summary:

  1. fsi/cfam: a common CFAM model holding the slot, config table,
     responder and local bus, with the existing cfam as its first
     derivative. No functional change to the existing cfam.
  2. fsi/cfam: the CFAM-S as a second derivative - its own config table,
     the slave-ID alias window, and a v1 mailbox engine added to lbus.c
     alongside the scratchpad.
  3. arm/aspeed: wire the two AST2700 FSI controllers to their APB-to-OPB
     bridges.
  4. i2c/aspeed: fix DMA-receive first-byte handling so SMBus block reads
     (I2C_M_RECV_LEN) report the correct length.
  5. hw/sensor: TI UCD90320 24-rail PMBus power sequencer.
  6. ufs: a configurable logical-block-size on ufs-lu, and an unmapped LUN
     answering INQUIRY as "not connected". The ufs PCI device keeps its
     current property set and geometry.
  7. ufs/aspeed: the AST2700 UFS host controller as a subclass of
     TYPE_SYSBUS_UFS, adding only the UFSHCI version.
  8. arm/aspeed: the huygens-bmc machine.

Changes since v2:

* UFS: rebased onto Jeuk Kim's restructure, as requested. The v2 core
  refactor (v2 patch 6) is dropped entirely, Jeuk's patch 1 supersedes it.
  hw/ufs/aspeed_ufs.c is now a subclass of TYPE_SYSBUS_UFS whose only
  AST2700-specific behavior is pinning the controller version register
  to 2.0, chained after the parent realize. MMIO, IRQ, DMA address space,
  properties, migration state and unrealize all come from the generic
  sysbus device, and the Aspeed type adds no instance fields.

  The two behaviors Huygens needs that the restructure does not provide
  are now their own patch (6), placed ahead of the Aspeed patch: the
  ufs-lu logical-block-size property (default unchanged, so the PCI
  device is unaffected) and the unmapped-LUN INQUIRY reporting "not
  connected" rather than failing the request. logical-block-size now also
  rejects non-powers-of-two, values outside 512..UFS_BLOCK_SIZE, and a
  drive shorter than one block, which would previously have realized a
  zero-block unit.

  The Aspeed SoC Kconfig now selects UFS_SYSBUS. It previously relied on
  UFS_PCI being enabled via "imply PCI_DEVICES".

* CFAM: dropped the State suffix from the instance struct names (Miles).
  FSICFAMCommonState becomes FSICFAMCommon; FSICFAMState, which predates
  this series, becomes FSICFAM to match rather than leaving the two
  spellings side by side in one header; FSICFAMSState becomes FSICFAMS.
  The FSI prefix is kept. The class structs keep their suffix, as is
  usual for QOM. Also fixed patch 1 to check the realize_engines() return
  value.

* Machine: reworded the commit message (Miles). No code change.

* Rebased onto v11.1.0-rc3.

Not addressed in this series:

* CFAM extended addressing (Miles): the mode where a single CFAM has 8MB
  rather than four cascaded CFAMs sharing that space. This changes the
  addressing model of the existing FSI/CFAM code rather than anything this
  series introduces, so it's left it as follow-up work. It does bear on
  patch 2 though: the CFAM-S there aliases one 2MiB slot across the 8MiB
  window to fold the slave-ID views together, and if extended addressing
  is modelled properly that window is probably the wrong shape or should
  not exist at all. I am happy to take direction on whether to do that
  first.

Testing done:

* Whole series builds, and each of the 8 patches builds standalone.
* make check passes.
* huygens-bmc boots OpenBMC to the login prompt and multi-user target
  from FMC flash + UFS storage (internal images).
* PCI UFS qtests pass (13/13), unchanged by patch 6.
* aspeed_fsi-test passes (4/4), unchanged by the CFAM patches.
* huygens-bmc, ast2700-evb and ast2600-evb all construct successfully.
* On huygens-bmc, the UFS version register reads 0x00000200, and the
  ufs-lu created by the board reports a 512-byte block size and passes it
  to its backing scsi-hd. The PCI ufs device with no property set still
  reports 4096.

Changes since v1 (unchanged from the v2 posting, for reference):

* Split the original 5 commits into 8. The aspeed I2C DMA fix, the FSI
  controller wiring, the CFAM common base class, and the UFS
  core-vs-frontend split are now separate patches (each buildable on its
  own).

* UFS: reworked per review (Jeuk Kim). Instead of a second, standalone
  UFS implementation, the common core was separated from the PCI glue so
  the AST2700 controller could be a thin sysbus frontend on top of it.
  (Superseded in v3 - see above.)

* CFAM-S: reworked per review (Ninad). It now shares a common base class
  with the cfam rather than being a parallel implementation: patch 1 adds
  an abstract cfam-common whose realize is driven by an FSICFAMCommonClass
  (config table, responder and local-bus offsets, and an engines hook),
  and both cfam and cfam-s derive from it. They are siblings rather than
  parent and child, since a CFAM-S is another kind of CFAM and not a
  specialisation of the P9 one. Patch 2 adds cfam-s supplying only its own
  config table, its mailbox engine and the slave-ID alias window; the v1
  mailbox is a local bus engine so it sits in lbus.c next to the
  scratchpad. Duplicated code has been cleaned. Two behavior changes
  follow from sharing the common config ops, both noted in patch 2: cfam-s
  now honors the SID_BREAK sequence, and config-table access is word-only
  for both types. Also made generic, all specific references dropped.

  Patch 1 is intended to be a no-op for the existing cfam, and was
  checked that way: aspeed_fsi-test passes, the four P9 config words read
  back identically over the OPB, and "info mtree" for ast2600-evb is
  unchanged. The Rainier boot test was also run and verified.

* i2c/aspeed: the DMA block-read fix is now its own patch, with a commit
  message explaining the I2C_M_RECV_LEN + DMA interaction (Cédric).

* UCD90320: the device-id/monitor-config/mfr-status responses are now
  device reset state rather than file-scope constants, with matching
  VMState (Cédric).

* Docs: the huygens-bmc and aspeed-ufs boot examples now use -blockdev
  instead of -drive (Cédric).

* Machine: commit message expanded (POWER12 BMC on AST2700 A2), the VPD
  buffer uses g_autofree, the docs describe the flash-vs-UFS split, and
  the networking example was simplified.

* New device files use DEFINE_TYPES() with inlined TypeInfo (Jamin Lin).

* Dropped the v1 functional test for now: depends on non-public Huygens
  images. It will be resent once images go public.

Note: checkpatch reports a couple of MAINTAINERS/SPDX warnings for the
new files; they are covered by existing wildcard entries in the ASPEED
and FSI sections.

Thank you again for all of the feedback.

Mikail Sadic (8):
  fsi/cfam: Add common CFAM base class
  fsi/cfam: Add CFAM-S model
  arm/aspeed: Wire AST2700 FSI controllers to APB-to-OPB bridges
  i2c/aspeed: Fix DMA receive first-byte handling for block reads
  hw/sensor: Add UCD90320 model
  ufs: Make the logical block size configurable and answer absent LUNs
  ufs/aspeed: Add AST2700 UFS host controller
  arm/aspeed: Add AST2700 Huygens machine

 MAINTAINERS                     |   3 +
 docs/specs/aspeed-ufs.rst       |  46 ++++++
 docs/specs/fsi.rst              |  15 ++
 docs/specs/index.rst            |   2 +
 docs/specs/ucd90320.rst         |  36 +++++
 docs/system/arm/aspeed.rst      |  50 ++++++-
 hw/ufs/ufs.h                    |   3 +
 include/hw/arm/aspeed.h         |   1 +
 include/hw/arm/aspeed_soc.h     |   3 +
 include/hw/fsi/cfam-s.h         |  40 ++++++
 include/hw/fsi/cfam.h           |  68 ++++++++-
 include/hw/fsi/fsi-master.h     |   4 +-
 include/hw/fsi/lbus.h           |  11 ++
 include/hw/ufs/aspeed_ufs.h     |  15 ++
 hw/arm/aspeed.c                 |  25 ++++
 hw/arm/aspeed_ast27x0.c         |  31 ++++
 hw/arm/aspeed_ast27x0_huygens.c | 241 ++++++++++++++++++++++++++++++++
 hw/fsi/cfam-s.c                 |  91 ++++++++++++
 hw/fsi/cfam.c                   | 125 ++++++++++-------
 hw/fsi/fsi-master.c             |   9 +-
 hw/fsi/lbus.c                   |  69 +++++++++
 hw/i2c/aspeed_i2c.c             |   7 +
 hw/sensor/ucd90320.c            | 169 ++++++++++++++++++++++
 hw/ufs/aspeed_ufs.c             |  67 +++++++++
 hw/ufs/lu.c                     |  67 ++++++++-
 hw/ufs/ufs.c                    |   2 +-
 hw/arm/Kconfig                  |   2 +
 hw/arm/meson.build              |   1 +
 hw/fsi/meson.build              |   2 +-
 hw/fsi/trace-events             |   2 +
 hw/sensor/Kconfig               |   4 +
 hw/sensor/meson.build           |   1 +
 hw/ufs/meson.build              |   1 +
 33 files changed, 1149 insertions(+), 64 deletions(-)
 create mode 100644 docs/specs/aspeed-ufs.rst
 create mode 100644 docs/specs/ucd90320.rst
 create mode 100644 include/hw/fsi/cfam-s.h
 create mode 100644 include/hw/ufs/aspeed_ufs.h
 create mode 100644 hw/arm/aspeed_ast27x0_huygens.c
 create mode 100644 hw/fsi/cfam-s.c
 create mode 100644 hw/sensor/ucd90320.c
 create mode 100644 hw/ufs/aspeed_ufs.c

base-commit: 8c9baa57b781ae86330ba036415a768da12d9b28

-- 
2.53.0
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.