All of lore.kernel.org
 help / color / mirror / Atom feed
* [PULL 00/14] aspeed queue
@ 2021-09-13 16:12 Cédric Le Goater
  2021-09-13 16:12 ` [PULL 01/14] hw: arm: aspeed: Enable eth0 interface for aspeed-ast2600-evb Cédric Le Goater
                   ` (14 more replies)
  0 siblings, 15 replies; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-13 16:12 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Andrew Jeffery, Cédric Le Goater, qemu-arm, Joel Stanley,
	qemu-devel

The following changes since commit eae587e8e3694b1aceab23239493fb4c7e1a80f5:

  Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2021-09-13' into staging (2021-09-13 11:00:30 +0100)

are available in the Git repository at:

  https://github.com/legoater/qemu/ tags/pull-aspeed-20210913

for you to fetch changes up to d7add12e20fa8982f5932ff4dca317c5d2dfe7d9:

  hw/arm/aspeed: Add Fuji machine type (2021-09-13 15:19:20 +0200)

----------------------------------------------------------------
Aspeed patches :

* MAC enablement fixes (Guenter)
* Watchdog  and pca9552 fixes (Andrew)
* GPIO fixes (Joel)
* AST2600A3 SoC and DPS310 models (Joel)
* New Fuji BMC machine (Peter)

----------------------------------------------------------------
Andrew Jeffery (3):
      watchdog: aspeed: Sanitize control register values
      watchdog: aspeed: Fix sequential control writes
      misc/pca9552: Fix LED status register indexing in pca955x_get_led()

Guenter Roeck (2):
      hw: arm: aspeed: Enable eth0 interface for aspeed-ast2600-evb
      hw: arm: aspeed: Enable mac0/1 instead of mac1/2 for g220a

Joel Stanley (6):
      hw: aspeed_gpio: Simplify 1.8V defines
      hw: aspeed_gpio: Clarify GPIO controller name
      arm/aspeed: rainier: Add i2c eeproms and muxes
      aspeed: Emulate the AST2600A3
      hw/misc: Add Infineon DPS310 sensor model
      arm/aspeed: Add DPS310 to Witherspoon and Rainier

Peter Delevoryas (3):
      hw/arm/aspeed: Initialize AST2600 UART clock selection registers
      hw/arm/aspeed: Allow machine to set UART default
      hw/arm/aspeed: Add Fuji machine type

 include/hw/arm/aspeed.h          |   1 +
 include/hw/arm/aspeed_soc.h      |   1 +
 include/hw/misc/aspeed_scu.h     |   2 +
 include/hw/watchdog/wdt_aspeed.h |   1 +
 hw/arm/aspeed.c                  | 175 ++++++++++++++++++++++++++++--
 hw/arm/aspeed_ast2600.c          |  14 +--
 hw/arm/aspeed_soc.c              |   8 +-
 hw/gpio/aspeed_gpio.c            |  97 +++++++++--------
 hw/misc/aspeed_scu.c             |  40 +++++--
 hw/misc/pca9552.c                |   2 +-
 hw/sensor/dps310.c               | 225 +++++++++++++++++++++++++++++++++++++++
 hw/watchdog/wdt_aspeed.c         |  26 ++++-
 hw/arm/Kconfig                   |   1 +
 hw/sensor/Kconfig                |   4 +
 hw/sensor/meson.build            |   1 +
 15 files changed, 522 insertions(+), 76 deletions(-)
 create mode 100644 hw/sensor/dps310.c


^ permalink raw reply	[flat|nested] 41+ messages in thread

* [PULL 01/14] hw: arm: aspeed: Enable eth0 interface for aspeed-ast2600-evb
  2021-09-13 16:12 [PULL 00/14] aspeed queue Cédric Le Goater
@ 2021-09-13 16:12 ` Cédric Le Goater
  2021-09-13 16:12 ` [PULL 02/14] hw: arm: aspeed: Enable mac0/1 instead of mac1/2 for g220a Cédric Le Goater
                   ` (13 subsequent siblings)
  14 siblings, 0 replies; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-13 16:12 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Andrew Jeffery, qemu-devel, qemu-arm, Cédric Le Goater,
	Guenter Roeck, Joel Stanley

From: Guenter Roeck <linux@roeck-us.net>

Commit 7582591ae7 ("aspeed: Support AST2600A1 silicon revision") switched
the silicon revision for AST2600 to revision A1. On revision A1, the first
Ethernet interface is operational. Enable it.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20210808200457.889955-1-linux@roeck-us.net>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
 hw/arm/aspeed.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 9d43e26c51bb..ecf0c9cfacb8 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -959,7 +959,8 @@ static void aspeed_machine_ast2600_evb_class_init(ObjectClass *oc, void *data)
     amc->fmc_model = "w25q512jv";
     amc->spi_model = "mx66u51235f";
     amc->num_cs    = 1;
-    amc->macs_mask  = ASPEED_MAC1_ON | ASPEED_MAC2_ON | ASPEED_MAC3_ON;
+    amc->macs_mask = ASPEED_MAC0_ON | ASPEED_MAC1_ON | ASPEED_MAC2_ON |
+                     ASPEED_MAC3_ON;
     amc->i2c_init  = ast2600_evb_i2c_init;
     mc->default_ram_size = 1 * GiB;
     mc->default_cpus = mc->min_cpus = mc->max_cpus =
-- 
2.31.1



^ permalink raw reply	[flat|nested] 41+ messages in thread

* [PULL 02/14] hw: arm: aspeed: Enable mac0/1 instead of mac1/2 for g220a
  2021-09-13 16:12 [PULL 00/14] aspeed queue Cédric Le Goater
  2021-09-13 16:12 ` [PULL 01/14] hw: arm: aspeed: Enable eth0 interface for aspeed-ast2600-evb Cédric Le Goater
@ 2021-09-13 16:12 ` Cédric Le Goater
  2021-09-13 16:12 ` [PULL 03/14] watchdog: aspeed: Sanitize control register values Cédric Le Goater
                   ` (12 subsequent siblings)
  14 siblings, 0 replies; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-13 16:12 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Andrew Jeffery, qemu-devel, qemu-arm, Cédric Le Goater,
	Guenter Roeck, Joel Stanley

From: Guenter Roeck <linux@roeck-us.net>

According to its dts file in the Linux kernel, we need mac0 and mac1 enabled
instead of mac1 and mac2. Also, g220a is based on aspeed-g5 (ast2500) which
doesn't even have the third interface.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20210810035742.550391-1-linux@roeck-us.net>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
 hw/arm/aspeed.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index ecf0c9cfacb8..20e3a7716006 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -997,7 +997,7 @@ static void aspeed_machine_g220a_class_init(ObjectClass *oc, void *data)
     amc->fmc_model = "n25q512a";
     amc->spi_model = "mx25l25635e";
     amc->num_cs    = 2;
-    amc->macs_mask  = ASPEED_MAC1_ON | ASPEED_MAC2_ON;
+    amc->macs_mask  = ASPEED_MAC0_ON | ASPEED_MAC1_ON;
     amc->i2c_init  = g220a_bmc_i2c_init;
     mc->default_ram_size = 1024 * MiB;
     mc->default_cpus = mc->min_cpus = mc->max_cpus =
-- 
2.31.1



^ permalink raw reply	[flat|nested] 41+ messages in thread

* [PULL 03/14] watchdog: aspeed: Sanitize control register values
  2021-09-13 16:12 [PULL 00/14] aspeed queue Cédric Le Goater
  2021-09-13 16:12 ` [PULL 01/14] hw: arm: aspeed: Enable eth0 interface for aspeed-ast2600-evb Cédric Le Goater
  2021-09-13 16:12 ` [PULL 02/14] hw: arm: aspeed: Enable mac0/1 instead of mac1/2 for g220a Cédric Le Goater
@ 2021-09-13 16:12 ` Cédric Le Goater
  2021-09-13 16:12 ` [PULL 04/14] watchdog: aspeed: Fix sequential control writes Cédric Le Goater
                   ` (11 subsequent siblings)
  14 siblings, 0 replies; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-13 16:12 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Andrew Jeffery, Cédric Le Goater, qemu-arm, Joel Stanley,
	qemu-devel

From: Andrew Jeffery <andrew@aj.id.au>

While some of the critical fields remain the same, there is variation in
the definition of the control register across the SoC generations.
Reserved regions are adjusted, while in other cases the mutability or
behaviour of fields change.

Introduce a callback to sanitize the value on writes to ensure model
behaviour reflects the hardware.

Fixes: 854123bf8d4b ("wdt: Add Aspeed watchdog device model")
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20210709053107.1829304-2-andrew@aj.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
 include/hw/watchdog/wdt_aspeed.h |  1 +
 hw/watchdog/wdt_aspeed.c         | 24 ++++++++++++++++++++++--
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/include/hw/watchdog/wdt_aspeed.h b/include/hw/watchdog/wdt_aspeed.h
index 80b03661e303..f945cd6c5833 100644
--- a/include/hw/watchdog/wdt_aspeed.h
+++ b/include/hw/watchdog/wdt_aspeed.h
@@ -44,6 +44,7 @@ struct AspeedWDTClass {
     uint32_t reset_ctrl_reg;
     void (*reset_pulse)(AspeedWDTState *s, uint32_t property);
     void (*wdt_reload)(AspeedWDTState *s);
+    uint64_t (*sanitize_ctrl)(uint64_t data);
 };
 
 #endif /* WDT_ASPEED_H */
diff --git a/hw/watchdog/wdt_aspeed.c b/hw/watchdog/wdt_aspeed.c
index 6352ba1b0e5b..faa3d35fdf21 100644
--- a/hw/watchdog/wdt_aspeed.c
+++ b/hw/watchdog/wdt_aspeed.c
@@ -118,13 +118,27 @@ static void aspeed_wdt_reload_1mhz(AspeedWDTState *s)
     }
 }
 
+static uint64_t aspeed_2400_sanitize_ctrl(uint64_t data)
+{
+    return data & 0xffff;
+}
+
+static uint64_t aspeed_2500_sanitize_ctrl(uint64_t data)
+{
+    return (data & ~(0xfUL << 8)) | WDT_CTRL_1MHZ_CLK;
+}
+
+static uint64_t aspeed_2600_sanitize_ctrl(uint64_t data)
+{
+    return data & ~(0x7UL << 7);
+}
 
 static void aspeed_wdt_write(void *opaque, hwaddr offset, uint64_t data,
                              unsigned size)
 {
     AspeedWDTState *s = ASPEED_WDT(opaque);
     AspeedWDTClass *awc = ASPEED_WDT_GET_CLASS(s);
-    bool enable = data & WDT_CTRL_ENABLE;
+    bool enable;
 
     offset >>= 2;
 
@@ -144,6 +158,8 @@ static void aspeed_wdt_write(void *opaque, hwaddr offset, uint64_t data,
         }
         break;
     case WDT_CTRL:
+        data = awc->sanitize_ctrl(data);
+        enable = data & WDT_CTRL_ENABLE;
         if (enable && !aspeed_wdt_is_enabled(s)) {
             s->regs[WDT_CTRL] = data;
             awc->wdt_reload(s);
@@ -207,11 +223,12 @@ static const MemoryRegionOps aspeed_wdt_ops = {
 static void aspeed_wdt_reset(DeviceState *dev)
 {
     AspeedWDTState *s = ASPEED_WDT(dev);
+    AspeedWDTClass *awc = ASPEED_WDT_GET_CLASS(s);
 
     s->regs[WDT_STATUS] = 0x3EF1480;
     s->regs[WDT_RELOAD_VALUE] = 0x03EF1480;
     s->regs[WDT_RESTART] = 0;
-    s->regs[WDT_CTRL] = 0;
+    s->regs[WDT_CTRL] = awc->sanitize_ctrl(0);
     s->regs[WDT_RESET_WIDTH] = 0xFF;
 
     timer_del(s->timer);
@@ -293,6 +310,7 @@ static void aspeed_2400_wdt_class_init(ObjectClass *klass, void *data)
     awc->ext_pulse_width_mask = 0xff;
     awc->reset_ctrl_reg = SCU_RESET_CONTROL1;
     awc->wdt_reload = aspeed_wdt_reload;
+    awc->sanitize_ctrl = aspeed_2400_sanitize_ctrl;
 }
 
 static const TypeInfo aspeed_2400_wdt_info = {
@@ -328,6 +346,7 @@ static void aspeed_2500_wdt_class_init(ObjectClass *klass, void *data)
     awc->reset_ctrl_reg = SCU_RESET_CONTROL1;
     awc->reset_pulse = aspeed_2500_wdt_reset_pulse;
     awc->wdt_reload = aspeed_wdt_reload_1mhz;
+    awc->sanitize_ctrl = aspeed_2500_sanitize_ctrl;
 }
 
 static const TypeInfo aspeed_2500_wdt_info = {
@@ -348,6 +367,7 @@ static void aspeed_2600_wdt_class_init(ObjectClass *klass, void *data)
     awc->reset_ctrl_reg = AST2600_SCU_RESET_CONTROL1;
     awc->reset_pulse = aspeed_2500_wdt_reset_pulse;
     awc->wdt_reload = aspeed_wdt_reload_1mhz;
+    awc->sanitize_ctrl = aspeed_2600_sanitize_ctrl;
 }
 
 static const TypeInfo aspeed_2600_wdt_info = {
-- 
2.31.1



^ permalink raw reply	[flat|nested] 41+ messages in thread

* [PULL 04/14] watchdog: aspeed: Fix sequential control writes
  2021-09-13 16:12 [PULL 00/14] aspeed queue Cédric Le Goater
                   ` (2 preceding siblings ...)
  2021-09-13 16:12 ` [PULL 03/14] watchdog: aspeed: Sanitize control register values Cédric Le Goater
@ 2021-09-13 16:12 ` Cédric Le Goater
  2021-09-13 16:12 ` [PULL 05/14] hw: aspeed_gpio: Simplify 1.8V defines Cédric Le Goater
                   ` (10 subsequent siblings)
  14 siblings, 0 replies; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-13 16:12 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Andrew Jeffery, Cédric Le Goater, qemu-arm, Joel Stanley,
	qemu-devel

From: Andrew Jeffery <andrew@aj.id.au>

The logic in the handling for the control register required toggling the
enable state for writes to stick. Rework the condition chain to allow
sequential writes that do not update the enable state.

Fixes: 854123bf8d4b ("wdt: Add Aspeed watchdog device model")
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20210709053107.1829304-3-andrew@aj.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
 hw/watchdog/wdt_aspeed.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/watchdog/wdt_aspeed.c b/hw/watchdog/wdt_aspeed.c
index faa3d35fdf21..69c37af9a6e9 100644
--- a/hw/watchdog/wdt_aspeed.c
+++ b/hw/watchdog/wdt_aspeed.c
@@ -166,6 +166,8 @@ static void aspeed_wdt_write(void *opaque, hwaddr offset, uint64_t data,
         } else if (!enable && aspeed_wdt_is_enabled(s)) {
             s->regs[WDT_CTRL] = data;
             timer_del(s->timer);
+        } else {
+            s->regs[WDT_CTRL] = data;
         }
         break;
     case WDT_RESET_WIDTH:
-- 
2.31.1



^ permalink raw reply	[flat|nested] 41+ messages in thread

* [PULL 05/14] hw: aspeed_gpio: Simplify 1.8V defines
  2021-09-13 16:12 [PULL 00/14] aspeed queue Cédric Le Goater
                   ` (3 preceding siblings ...)
  2021-09-13 16:12 ` [PULL 04/14] watchdog: aspeed: Fix sequential control writes Cédric Le Goater
@ 2021-09-13 16:12 ` Cédric Le Goater
  2021-09-13 16:12 ` [PULL 06/14] hw: aspeed_gpio: Clarify GPIO controller name Cédric Le Goater
                   ` (9 subsequent siblings)
  14 siblings, 0 replies; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-13 16:12 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Andrew Jeffery, qemu-devel, Philippe Mathieu-Daudé,
	qemu-arm, Joel Stanley, Rashmica Gupta, Cédric Le Goater

From: Joel Stanley <joel@jms.id.au>

There's no need to define the registers relative to the 0x800 offset
where the controller is mapped, as the device is instantiated as it's
own model at the correct memory address.

Simplify the defines and remove the offset to save future confusion.

Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Rashmica Gupta <rashmica.g@gmail.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20210713065854.134634-3-joel@jms.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
 hw/gpio/aspeed_gpio.c | 73 +++++++++++++++++++++----------------------
 1 file changed, 36 insertions(+), 37 deletions(-)

diff --git a/hw/gpio/aspeed_gpio.c b/hw/gpio/aspeed_gpio.c
index b3dec4448009..dc721aec5da7 100644
--- a/hw/gpio/aspeed_gpio.c
+++ b/hw/gpio/aspeed_gpio.c
@@ -169,44 +169,43 @@
 
 /* AST2600 only - 1.8V gpios */
 /*
- * The AST2600 has same 3.6V gpios as the AST2400 (memory offsets 0x0-0x198)
- * and additional 1.8V gpios (memory offsets 0x800-0x9D4).
+ * The AST2600 two copies of the GPIO controller: the same 3.6V gpios as the
+ * AST2400 (memory offsets 0x0-0x198) and a second controller with 1.8V gpios
+ * (memory offsets 0x800-0x9D4).
  */
-#define GPIO_1_8V_REG_OFFSET          0x800
-#define GPIO_1_8V_ABCD_DATA_VALUE     ((0x800 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_ABCD_DIRECTION      ((0x804 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_ABCD_INT_ENABLE     ((0x808 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_ABCD_INT_SENS_0     ((0x80C - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_ABCD_INT_SENS_1     ((0x810 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_ABCD_INT_SENS_2     ((0x814 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_ABCD_INT_STATUS     ((0x818 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_ABCD_RESET_TOLERANT ((0x81C - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_E_DATA_VALUE        ((0x820 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_E_DIRECTION         ((0x824 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_E_INT_ENABLE        ((0x828 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_E_INT_SENS_0        ((0x82C - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_E_INT_SENS_1        ((0x830 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_E_INT_SENS_2        ((0x834 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_E_INT_STATUS        ((0x838 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_E_RESET_TOLERANT    ((0x83C - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_ABCD_DEBOUNCE_1     ((0x840 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_ABCD_DEBOUNCE_2     ((0x844 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_E_DEBOUNCE_1        ((0x848 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_E_DEBOUNCE_2        ((0x84C - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_DEBOUNCE_TIME_1     ((0x850 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_DEBOUNCE_TIME_2     ((0x854 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_DEBOUNCE_TIME_3     ((0x858 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_ABCD_COMMAND_SRC_0  ((0x860 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_ABCD_COMMAND_SRC_1  ((0x864 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_E_COMMAND_SRC_0     ((0x868 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_E_COMMAND_SRC_1     ((0x86C - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_ABCD_DATA_READ      ((0x8C0 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_E_DATA_READ         ((0x8C4 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_ABCD_INPUT_MASK     ((0x9D0 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_E_INPUT_MASK        ((0x9D4 - GPIO_1_8V_REG_OFFSET) >> 2)
-#define GPIO_1_8V_MEM_SIZE            0x9D8
-#define GPIO_1_8V_REG_ARRAY_SIZE      ((GPIO_1_8V_MEM_SIZE - \
-                                      GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_ABCD_DATA_VALUE     (0x000 >> 2)
+#define GPIO_1_8V_ABCD_DIRECTION      (0x004 >> 2)
+#define GPIO_1_8V_ABCD_INT_ENABLE     (0x008 >> 2)
+#define GPIO_1_8V_ABCD_INT_SENS_0     (0x00C >> 2)
+#define GPIO_1_8V_ABCD_INT_SENS_1     (0x010 >> 2)
+#define GPIO_1_8V_ABCD_INT_SENS_2     (0x014 >> 2)
+#define GPIO_1_8V_ABCD_INT_STATUS     (0x018 >> 2)
+#define GPIO_1_8V_ABCD_RESET_TOLERANT (0x01C >> 2)
+#define GPIO_1_8V_E_DATA_VALUE        (0x020 >> 2)
+#define GPIO_1_8V_E_DIRECTION         (0x024 >> 2)
+#define GPIO_1_8V_E_INT_ENABLE        (0x028 >> 2)
+#define GPIO_1_8V_E_INT_SENS_0        (0x02C >> 2)
+#define GPIO_1_8V_E_INT_SENS_1        (0x030 >> 2)
+#define GPIO_1_8V_E_INT_SENS_2        (0x034 >> 2)
+#define GPIO_1_8V_E_INT_STATUS        (0x038 >> 2)
+#define GPIO_1_8V_E_RESET_TOLERANT    (0x03C >> 2)
+#define GPIO_1_8V_ABCD_DEBOUNCE_1     (0x040 >> 2)
+#define GPIO_1_8V_ABCD_DEBOUNCE_2     (0x044 >> 2)
+#define GPIO_1_8V_E_DEBOUNCE_1        (0x048 >> 2)
+#define GPIO_1_8V_E_DEBOUNCE_2        (0x04C >> 2)
+#define GPIO_1_8V_DEBOUNCE_TIME_1     (0x050 >> 2)
+#define GPIO_1_8V_DEBOUNCE_TIME_2     (0x054 >> 2)
+#define GPIO_1_8V_DEBOUNCE_TIME_3     (0x058 >> 2)
+#define GPIO_1_8V_ABCD_COMMAND_SRC_0  (0x060 >> 2)
+#define GPIO_1_8V_ABCD_COMMAND_SRC_1  (0x064 >> 2)
+#define GPIO_1_8V_E_COMMAND_SRC_0     (0x068 >> 2)
+#define GPIO_1_8V_E_COMMAND_SRC_1     (0x06C >> 2)
+#define GPIO_1_8V_ABCD_DATA_READ      (0x0C0 >> 2)
+#define GPIO_1_8V_E_DATA_READ         (0x0C4 >> 2)
+#define GPIO_1_8V_ABCD_INPUT_MASK     (0x1D0 >> 2)
+#define GPIO_1_8V_E_INPUT_MASK        (0x1D4 >> 2)
+#define GPIO_1_8V_MEM_SIZE            0x1D8
+#define GPIO_1_8V_REG_ARRAY_SIZE      (GPIO_1_8V_MEM_SIZE >> 2)
 
 static int aspeed_evaluate_irq(GPIOSets *regs, int gpio_prev_high, int gpio)
 {
-- 
2.31.1



^ permalink raw reply	[flat|nested] 41+ messages in thread

* [PULL 06/14] hw: aspeed_gpio: Clarify GPIO controller name
  2021-09-13 16:12 [PULL 00/14] aspeed queue Cédric Le Goater
                   ` (4 preceding siblings ...)
  2021-09-13 16:12 ` [PULL 05/14] hw: aspeed_gpio: Simplify 1.8V defines Cédric Le Goater
@ 2021-09-13 16:12 ` Cédric Le Goater
  2021-09-13 16:12 ` [PULL 07/14] misc/pca9552: Fix LED status register indexing in pca955x_get_led() Cédric Le Goater
                   ` (8 subsequent siblings)
  14 siblings, 0 replies; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-13 16:12 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Andrew Jeffery, qemu-devel, qemu-arm, Joel Stanley,
	Rashmica Gupta, Cédric Le Goater

From: Joel Stanley <joel@jms.id.au>

There are two GPIO controllers in the ast2600; one is 3.3V and the other
is 1.8V.

Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Rashmica Gupta <rashmica.g@gmail.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20210713065854.134634-4-joel@jms.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
 hw/gpio/aspeed_gpio.c | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/hw/gpio/aspeed_gpio.c b/hw/gpio/aspeed_gpio.c
index dc721aec5da7..dfa6d6cb40a9 100644
--- a/hw/gpio/aspeed_gpio.c
+++ b/hw/gpio/aspeed_gpio.c
@@ -164,12 +164,12 @@
 #define GPIO_YZAAAB_DIRECTION      (0x1E4 >> 2)
 #define GPIO_AC_DATA_VALUE         (0x1E8 >> 2)
 #define GPIO_AC_DIRECTION          (0x1EC >> 2)
-#define GPIO_3_6V_MEM_SIZE         0x1F0
-#define GPIO_3_6V_REG_ARRAY_SIZE   (GPIO_3_6V_MEM_SIZE >> 2)
+#define GPIO_3_3V_MEM_SIZE         0x1F0
+#define GPIO_3_3V_REG_ARRAY_SIZE   (GPIO_3_3V_MEM_SIZE >> 2)
 
 /* AST2600 only - 1.8V gpios */
 /*
- * The AST2600 two copies of the GPIO controller: the same 3.6V gpios as the
+ * The AST2600 two copies of the GPIO controller: the same 3.3V gpios as the
  * AST2400 (memory offsets 0x0-0x198) and a second controller with 1.8V gpios
  * (memory offsets 0x800-0x9D4).
  */
@@ -380,7 +380,7 @@ static uint32_t update_value_control_source(GPIOSets *regs, uint32_t old_value,
     return new_value;
 }
 
-static const AspeedGPIOReg aspeed_3_6v_gpios[GPIO_3_6V_REG_ARRAY_SIZE] = {
+static const AspeedGPIOReg aspeed_3_3v_gpios[GPIO_3_3V_REG_ARRAY_SIZE] = {
     /* Set ABCD */
     [GPIO_ABCD_DATA_VALUE] =     { 0, gpio_reg_data_value },
     [GPIO_ABCD_DIRECTION] =      { 0, gpio_reg_direction },
@@ -800,7 +800,7 @@ static const GPIOSetProperties ast2500_set_props[] = {
     [7] = {0x000000ff,  0x000000ff,  {"AC"} },
 };
 
-static GPIOSetProperties ast2600_3_6v_set_props[] = {
+static GPIOSetProperties ast2600_3_3v_set_props[] = {
     [0] = {0xffffffff,  0xffffffff,  {"A", "B", "C", "D"} },
     [1] = {0xffffffff,  0xffffffff,  {"E", "F", "G", "H"} },
     [2] = {0xffffffff,  0xffffffff,  {"I", "J", "K", "L"} },
@@ -927,7 +927,7 @@ static void aspeed_gpio_ast2400_class_init(ObjectClass *klass, void *data)
     agc->nr_gpio_pins = 216;
     agc->nr_gpio_sets = 7;
     agc->gap = 196;
-    agc->reg_table = aspeed_3_6v_gpios;
+    agc->reg_table = aspeed_3_3v_gpios;
 }
 
 static void aspeed_gpio_2500_class_init(ObjectClass *klass, void *data)
@@ -938,17 +938,17 @@ static void aspeed_gpio_2500_class_init(ObjectClass *klass, void *data)
     agc->nr_gpio_pins = 228;
     agc->nr_gpio_sets = 8;
     agc->gap = 220;
-    agc->reg_table = aspeed_3_6v_gpios;
+    agc->reg_table = aspeed_3_3v_gpios;
 }
 
-static void aspeed_gpio_ast2600_3_6v_class_init(ObjectClass *klass, void *data)
+static void aspeed_gpio_ast2600_3_3v_class_init(ObjectClass *klass, void *data)
 {
     AspeedGPIOClass *agc = ASPEED_GPIO_CLASS(klass);
 
-    agc->props = ast2600_3_6v_set_props;
+    agc->props = ast2600_3_3v_set_props;
     agc->nr_gpio_pins = 208;
     agc->nr_gpio_sets = 7;
-    agc->reg_table = aspeed_3_6v_gpios;
+    agc->reg_table = aspeed_3_3v_gpios;
 }
 
 static void aspeed_gpio_ast2600_1_8v_class_init(ObjectClass *klass, void *data)
@@ -984,10 +984,10 @@ static const TypeInfo aspeed_gpio_ast2500_info = {
     .instance_init  = aspeed_gpio_init,
 };
 
-static const TypeInfo aspeed_gpio_ast2600_3_6v_info = {
+static const TypeInfo aspeed_gpio_ast2600_3_3v_info = {
     .name           = TYPE_ASPEED_GPIO "-ast2600",
     .parent         = TYPE_ASPEED_GPIO,
-    .class_init     = aspeed_gpio_ast2600_3_6v_class_init,
+    .class_init     = aspeed_gpio_ast2600_3_3v_class_init,
     .instance_init  = aspeed_gpio_init,
 };
 
@@ -1003,7 +1003,7 @@ static void aspeed_gpio_register_types(void)
     type_register_static(&aspeed_gpio_info);
     type_register_static(&aspeed_gpio_ast2400_info);
     type_register_static(&aspeed_gpio_ast2500_info);
-    type_register_static(&aspeed_gpio_ast2600_3_6v_info);
+    type_register_static(&aspeed_gpio_ast2600_3_3v_info);
     type_register_static(&aspeed_gpio_ast2600_1_8v_info);
 }
 
-- 
2.31.1



^ permalink raw reply	[flat|nested] 41+ messages in thread

* [PULL 07/14] misc/pca9552: Fix LED status register indexing in pca955x_get_led()
  2021-09-13 16:12 [PULL 00/14] aspeed queue Cédric Le Goater
                   ` (5 preceding siblings ...)
  2021-09-13 16:12 ` [PULL 06/14] hw: aspeed_gpio: Clarify GPIO controller name Cédric Le Goater
@ 2021-09-13 16:12 ` Cédric Le Goater
  2021-09-13 16:12 ` [PULL 08/14] arm/aspeed: rainier: Add i2c eeproms and muxes Cédric Le Goater
                   ` (7 subsequent siblings)
  14 siblings, 0 replies; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-13 16:12 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Andrew Jeffery, Cédric Le Goater, qemu-arm, Joel Stanley,
	qemu-devel

From: Andrew Jeffery <andrew@aj.id.au>

There was a bit of a thinko in the state calculation where every odd pin
in was reported in e.g. "pwm0" mode rather than "off". This was the
result of an incorrect bit shift for the 2-bit field representing each
LED state.

Fixes: a90d8f84674d ("misc/pca9552: Add qom set and get")
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20210723043624.348158-1-andrew@aj.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
 hw/misc/pca9552.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/misc/pca9552.c b/hw/misc/pca9552.c
index b7686e27d7fa..fff19e369a39 100644
--- a/hw/misc/pca9552.c
+++ b/hw/misc/pca9552.c
@@ -272,7 +272,7 @@ static void pca955x_get_led(Object *obj, Visitor *v, const char *name,
      * reading the INPUTx reg
      */
     reg = PCA9552_LS0 + led / 4;
-    state = (pca955x_read(s, reg) >> (led % 8)) & 0x3;
+    state = (pca955x_read(s, reg) >> ((led % 4) * 2)) & 0x3;
     visit_type_str(v, name, (char **)&led_state[state], errp);
 }
 
-- 
2.31.1



^ permalink raw reply	[flat|nested] 41+ messages in thread

* [PULL 08/14] arm/aspeed: rainier: Add i2c eeproms and muxes
  2021-09-13 16:12 [PULL 00/14] aspeed queue Cédric Le Goater
                   ` (6 preceding siblings ...)
  2021-09-13 16:12 ` [PULL 07/14] misc/pca9552: Fix LED status register indexing in pca955x_get_led() Cédric Le Goater
@ 2021-09-13 16:12 ` Cédric Le Goater
  2021-09-13 16:12 ` [PULL 09/14] aspeed: Emulate the AST2600A3 Cédric Le Goater
                   ` (6 subsequent siblings)
  14 siblings, 0 replies; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-13 16:12 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Andrew Jeffery, Cédric Le Goater, qemu-arm, Joel Stanley,
	qemu-devel

From: Joel Stanley <joel@jms.id.au>

These are the devices documented by the Rainier device tree. With this
we can see the guest discovering the multiplexers and probing the eeprom
devices:

 i2c i2c-2: Added multiplexed i2c bus 16
 i2c i2c-2: Added multiplexed i2c bus 17
 i2c i2c-2: Added multiplexed i2c bus 18
 i2c i2c-2: Added multiplexed i2c bus 19
 i2c-mux-gpio i2cmux: 4 port mux on 1e78a180.i2c-bus adapter
 at24 20-0050: 8192 byte 24c64 EEPROM, writable, 1 bytes/write
 i2c i2c-4: Added multiplexed i2c bus 20
 at24 21-0051: 8192 byte 24c64 EEPROM, writable, 1 bytes/write
 i2c i2c-4: Added multiplexed i2c bus 21
 at24 22-0052: 8192 byte 24c64 EEPROM, writable, 1 bytes/write

Signed-off-by: Joel Stanley <joel@jms.id.au>
[ clg: Introduced aspeed_eeprom_init ]
Message-Id: <20210629142336.750058-2-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
 hw/arm/aspeed.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 20e3a7716006..952fb2012a53 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -674,9 +674,21 @@ static void g220a_bmc_i2c_init(AspeedMachineState *bmc)
                           eeprom_buf);
 }
 
+static void aspeed_eeprom_init(I2CBus *bus, uint8_t addr, uint32_t rsize)
+{
+    I2CSlave *i2c_dev = i2c_slave_new("at24c-eeprom", addr);
+    DeviceState *dev = DEVICE(i2c_dev);
+
+    qdev_prop_set_uint32(dev, "rom-size", rsize);
+    i2c_slave_realize_and_unref(i2c_dev, bus, &error_abort);
+}
+
 static void rainier_bmc_i2c_init(AspeedMachineState *bmc)
 {
     AspeedSoCState *soc = &bmc->soc;
+    I2CSlave *i2c_mux;
+
+    aspeed_eeprom_init(aspeed_i2c_get_bus(&soc->i2c, 0), 0x51, 32 * KiB);
 
     /* The rainier expects a TMP275 but a TMP105 is compatible */
     i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 4), TYPE_TMP105,
@@ -685,11 +697,20 @@ static void rainier_bmc_i2c_init(AspeedMachineState *bmc)
                      0x49);
     i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 4), TYPE_TMP105,
                      0x4a);
+    i2c_mux = i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 4),
+                                      "pca9546", 0x70);
+    aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 0), 0x50, 64 * KiB);
+    aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 1), 0x51, 64 * KiB);
+    aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 2), 0x52, 64 * KiB);
 
     i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 5), TYPE_TMP105,
                      0x48);
     i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 5), TYPE_TMP105,
                      0x49);
+    i2c_mux = i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 5),
+                                      "pca9546", 0x70);
+    aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 0), 0x50, 64 * KiB);
+    aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 1), 0x51, 64 * KiB);
 
     i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 6), TYPE_TMP105,
                      0x48);
@@ -697,6 +718,12 @@ static void rainier_bmc_i2c_init(AspeedMachineState *bmc)
                      0x4a);
     i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 6), TYPE_TMP105,
                      0x4b);
+    i2c_mux = i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 6),
+                                      "pca9546", 0x70);
+    aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 0), 0x50, 64 * KiB);
+    aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 1), 0x51, 64 * KiB);
+    aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 2), 0x50, 64 * KiB);
+    aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 3), 0x51, 64 * KiB);
 
     /* Bus 7: TODO dps310@76 */
     /* Bus 7: TODO max31785@52 */
@@ -704,11 +731,15 @@ static void rainier_bmc_i2c_init(AspeedMachineState *bmc)
     /* Bus 7: TODO si7021-a20@20 */
     i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 7), TYPE_TMP105,
                      0x48);
+    aspeed_eeprom_init(aspeed_i2c_get_bus(&soc->i2c, 7), 0x50, 64 * KiB);
+    aspeed_eeprom_init(aspeed_i2c_get_bus(&soc->i2c, 7), 0x51, 64 * KiB);
 
     i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 8), TYPE_TMP105,
                      0x48);
     i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 8), TYPE_TMP105,
                      0x4a);
+    aspeed_eeprom_init(aspeed_i2c_get_bus(&soc->i2c, 8), 0x50, 64 * KiB);
+    aspeed_eeprom_init(aspeed_i2c_get_bus(&soc->i2c, 8), 0x51, 64 * KiB);
     i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 8), "pca9552", 0x61);
     /* Bus 8: ucd90320@11 */
     /* Bus 8: ucd90320@b */
@@ -716,14 +747,27 @@ static void rainier_bmc_i2c_init(AspeedMachineState *bmc)
 
     i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 9), "tmp423", 0x4c);
     i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 9), "tmp423", 0x4d);
+    aspeed_eeprom_init(aspeed_i2c_get_bus(&soc->i2c, 9), 0x50, 128 * KiB);
 
     i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 10), "tmp423", 0x4c);
     i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 10), "tmp423", 0x4d);
+    aspeed_eeprom_init(aspeed_i2c_get_bus(&soc->i2c, 10), 0x50, 128 * KiB);
 
     i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 11), TYPE_TMP105,
                      0x48);
     i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 11), TYPE_TMP105,
                      0x49);
+    i2c_mux = i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 11),
+                                      "pca9546", 0x70);
+    aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 0), 0x50, 64 * KiB);
+    aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 1), 0x51, 64 * KiB);
+
+
+    aspeed_eeprom_init(aspeed_i2c_get_bus(&soc->i2c, 13), 0x50, 64 * KiB);
+
+    aspeed_eeprom_init(aspeed_i2c_get_bus(&soc->i2c, 14), 0x50, 64 * KiB);
+
+    aspeed_eeprom_init(aspeed_i2c_get_bus(&soc->i2c, 15), 0x50, 64 * KiB);
 }
 
 static bool aspeed_get_mmio_exec(Object *obj, Error **errp)
-- 
2.31.1



^ permalink raw reply	[flat|nested] 41+ messages in thread

* [PULL 09/14] aspeed: Emulate the AST2600A3
  2021-09-13 16:12 [PULL 00/14] aspeed queue Cédric Le Goater
                   ` (7 preceding siblings ...)
  2021-09-13 16:12 ` [PULL 08/14] arm/aspeed: rainier: Add i2c eeproms and muxes Cédric Le Goater
@ 2021-09-13 16:12 ` Cédric Le Goater
  2021-09-13 16:13 ` [PULL 10/14] hw/misc: Add Infineon DPS310 sensor model Cédric Le Goater
                   ` (5 subsequent siblings)
  14 siblings, 0 replies; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-13 16:12 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Andrew Jeffery, Cédric Le Goater, qemu-arm, Joel Stanley,
	qemu-devel

From: Joel Stanley <joel@jms.id.au>

This is the latest revision of the ASPEED 2600 SoC. As there is no
need to model multiple revisions of the same SoC for the moment,
update the SCU AST2600 to model the A3 revision instead of the A1 and
adapt the AST2600 SoC and machines.

Reset values are taken from v8 of the datasheet.

Signed-off-by: Joel Stanley <joel@jms.id.au>
[ clg: - Introduced an Aspeed "ast2600-a3" SoC class
       - Commit log update ]
Message-Id: <20210629142336.750058-3-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
 include/hw/misc/aspeed_scu.h |  2 ++
 hw/arm/aspeed.c              |  6 +++---
 hw/arm/aspeed_ast2600.c      |  6 +++---
 hw/misc/aspeed_scu.c         | 36 +++++++++++++++++++++++++++++-------
 4 files changed, 37 insertions(+), 13 deletions(-)

diff --git a/include/hw/misc/aspeed_scu.h b/include/hw/misc/aspeed_scu.h
index d49bfb02fbdb..c14aff2bcbb5 100644
--- a/include/hw/misc/aspeed_scu.h
+++ b/include/hw/misc/aspeed_scu.h
@@ -43,6 +43,8 @@ struct AspeedSCUState {
 #define AST2500_A1_SILICON_REV   0x04010303U
 #define AST2600_A0_SILICON_REV   0x05000303U
 #define AST2600_A1_SILICON_REV   0x05010303U
+#define AST2600_A2_SILICON_REV   0x05020303U
+#define AST2600_A3_SILICON_REV   0x05030303U
 
 #define ASPEED_IS_AST2500(si_rev)     ((((si_rev) >> 24) & 0xff) == 0x04)
 
diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 952fb2012a53..97964c7e0c53 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -997,7 +997,7 @@ static void aspeed_machine_ast2600_evb_class_init(ObjectClass *oc, void *data)
     AspeedMachineClass *amc = ASPEED_MACHINE_CLASS(oc);
 
     mc->desc       = "Aspeed AST2600 EVB (Cortex-A7)";
-    amc->soc_name  = "ast2600-a1";
+    amc->soc_name  = "ast2600-a3";
     amc->hw_strap1 = AST2600_EVB_HW_STRAP1;
     amc->hw_strap2 = AST2600_EVB_HW_STRAP2;
     amc->fmc_model = "w25q512jv";
@@ -1017,7 +1017,7 @@ static void aspeed_machine_tacoma_class_init(ObjectClass *oc, void *data)
     AspeedMachineClass *amc = ASPEED_MACHINE_CLASS(oc);
 
     mc->desc       = "OpenPOWER Tacoma BMC (Cortex-A7)";
-    amc->soc_name  = "ast2600-a1";
+    amc->soc_name  = "ast2600-a3";
     amc->hw_strap1 = TACOMA_BMC_HW_STRAP1;
     amc->hw_strap2 = TACOMA_BMC_HW_STRAP2;
     amc->fmc_model = "mx66l1g45g";
@@ -1054,7 +1054,7 @@ static void aspeed_machine_rainier_class_init(ObjectClass *oc, void *data)
     AspeedMachineClass *amc = ASPEED_MACHINE_CLASS(oc);
 
     mc->desc       = "IBM Rainier BMC (Cortex-A7)";
-    amc->soc_name  = "ast2600-a1";
+    amc->soc_name  = "ast2600-a3";
     amc->hw_strap1 = RAINIER_BMC_HW_STRAP1;
     amc->hw_strap2 = RAINIER_BMC_HW_STRAP2;
     amc->fmc_model = "mx66l1g45g";
diff --git a/hw/arm/aspeed_ast2600.c b/hw/arm/aspeed_ast2600.c
index e3013128c670..8e1993790e6f 100644
--- a/hw/arm/aspeed_ast2600.c
+++ b/hw/arm/aspeed_ast2600.c
@@ -516,9 +516,9 @@ static void aspeed_soc_ast2600_class_init(ObjectClass *oc, void *data)
 
     dc->realize      = aspeed_soc_ast2600_realize;
 
-    sc->name         = "ast2600-a1";
+    sc->name         = "ast2600-a3";
     sc->cpu_type     = ARM_CPU_TYPE_NAME("cortex-a7");
-    sc->silicon_rev  = AST2600_A1_SILICON_REV;
+    sc->silicon_rev  = AST2600_A3_SILICON_REV;
     sc->sram_size    = 0x16400;
     sc->spis_num     = 2;
     sc->ehcis_num    = 2;
@@ -530,7 +530,7 @@ static void aspeed_soc_ast2600_class_init(ObjectClass *oc, void *data)
 }
 
 static const TypeInfo aspeed_soc_ast2600_type_info = {
-    .name           = "ast2600-a1",
+    .name           = "ast2600-a3",
     .parent         = TYPE_ASPEED_SOC,
     .instance_size  = sizeof(AspeedSoCState),
     .instance_init  = aspeed_soc_ast2600_init,
diff --git a/hw/misc/aspeed_scu.c b/hw/misc/aspeed_scu.c
index 40a38ebd8549..05edebedeb46 100644
--- a/hw/misc/aspeed_scu.c
+++ b/hw/misc/aspeed_scu.c
@@ -101,14 +101,24 @@
 #define AST2600_CLK_STOP_CTRL_CLR TO_REG(0x84)
 #define AST2600_CLK_STOP_CTRL2     TO_REG(0x90)
 #define AST2600_CLK_STOP_CTRL2_CLR TO_REG(0x94)
+#define AST2600_DEBUG_CTRL        TO_REG(0xC8)
+#define AST2600_DEBUG_CTRL2       TO_REG(0xD8)
 #define AST2600_SDRAM_HANDSHAKE   TO_REG(0x100)
 #define AST2600_HPLL_PARAM        TO_REG(0x200)
 #define AST2600_HPLL_EXT          TO_REG(0x204)
+#define AST2600_APLL_PARAM        TO_REG(0x210)
+#define AST2600_APLL_EXT          TO_REG(0x214)
+#define AST2600_MPLL_PARAM        TO_REG(0x220)
 #define AST2600_MPLL_EXT          TO_REG(0x224)
+#define AST2600_EPLL_PARAM        TO_REG(0x240)
 #define AST2600_EPLL_EXT          TO_REG(0x244)
+#define AST2600_DPLL_PARAM        TO_REG(0x260)
+#define AST2600_DPLL_EXT          TO_REG(0x264)
 #define AST2600_CLK_SEL           TO_REG(0x300)
 #define AST2600_CLK_SEL2          TO_REG(0x304)
-#define AST2600_CLK_SEL3          TO_REG(0x310)
+#define AST2600_CLK_SEL3          TO_REG(0x308)
+#define AST2600_CLK_SEL4          TO_REG(0x310)
+#define AST2600_CLK_SEL5          TO_REG(0x314)
 #define AST2600_HW_STRAP1         TO_REG(0x500)
 #define AST2600_HW_STRAP1_CLR     TO_REG(0x504)
 #define AST2600_HW_STRAP1_PROT    TO_REG(0x508)
@@ -433,6 +443,8 @@ static uint32_t aspeed_silicon_revs[] = {
     AST2500_A1_SILICON_REV,
     AST2600_A0_SILICON_REV,
     AST2600_A1_SILICON_REV,
+    AST2600_A2_SILICON_REV,
+    AST2600_A3_SILICON_REV,
 };
 
 bool is_supported_silicon_rev(uint32_t silicon_rev)
@@ -651,16 +663,26 @@ static const MemoryRegionOps aspeed_ast2600_scu_ops = {
     .valid.unaligned = false,
 };
 
-static const uint32_t ast2600_a1_resets[ASPEED_AST2600_SCU_NR_REGS] = {
+static const uint32_t ast2600_a3_resets[ASPEED_AST2600_SCU_NR_REGS] = {
     [AST2600_SYS_RST_CTRL]      = 0xF7C3FED8,
-    [AST2600_SYS_RST_CTRL2]     = 0xFFFFFFFC,
+    [AST2600_SYS_RST_CTRL2]     = 0x0DFFFFFC,
     [AST2600_CLK_STOP_CTRL]     = 0xFFFF7F8A,
     [AST2600_CLK_STOP_CTRL2]    = 0xFFF0FFF0,
+    [AST2600_DEBUG_CTRL]        = 0x00000FFF,
+    [AST2600_DEBUG_CTRL2]       = 0x000000FF,
     [AST2600_SDRAM_HANDSHAKE]   = 0x00000000,
-    [AST2600_HPLL_PARAM]        = 0x1000405F,
+    [AST2600_HPLL_PARAM]        = 0x1000408F,
+    [AST2600_APLL_PARAM]        = 0x1000405F,
+    [AST2600_MPLL_PARAM]        = 0x1008405F,
+    [AST2600_EPLL_PARAM]        = 0x1004077F,
+    [AST2600_DPLL_PARAM]        = 0x1078405F,
+    [AST2600_CLK_SEL]           = 0xF3940000,
+    [AST2600_CLK_SEL2]          = 0x00700000,
+    [AST2600_CLK_SEL3]          = 0x00000000,
+    [AST2600_CLK_SEL4]          = 0xF3F40000,
+    [AST2600_CLK_SEL5]          = 0x30000000,
     [AST2600_CHIP_ID0]          = 0x1234ABCD,
     [AST2600_CHIP_ID1]          = 0x88884444,
-
 };
 
 static void aspeed_ast2600_scu_reset(DeviceState *dev)
@@ -675,7 +697,7 @@ static void aspeed_ast2600_scu_reset(DeviceState *dev)
      * of actual revision. QEMU and Linux only support A1 onwards so this is
      * sufficient.
      */
-    s->regs[AST2600_SILICON_REV] = AST2600_A1_SILICON_REV;
+    s->regs[AST2600_SILICON_REV] = AST2600_A3_SILICON_REV;
     s->regs[AST2600_SILICON_REV2] = s->silicon_rev;
     s->regs[AST2600_HW_STRAP1] = s->hw_strap1;
     s->regs[AST2600_HW_STRAP2] = s->hw_strap2;
@@ -689,7 +711,7 @@ static void aspeed_2600_scu_class_init(ObjectClass *klass, void *data)
 
     dc->desc = "ASPEED 2600 System Control Unit";
     dc->reset = aspeed_ast2600_scu_reset;
-    asc->resets = ast2600_a1_resets;
+    asc->resets = ast2600_a3_resets;
     asc->calc_hpll = aspeed_2500_scu_calc_hpll; /* No change since AST2500 */
     asc->apb_divider = 4;
     asc->nr_regs = ASPEED_AST2600_SCU_NR_REGS;
-- 
2.31.1



^ permalink raw reply	[flat|nested] 41+ messages in thread

* [PULL 10/14] hw/misc: Add Infineon DPS310 sensor model
  2021-09-13 16:12 [PULL 00/14] aspeed queue Cédric Le Goater
                   ` (8 preceding siblings ...)
  2021-09-13 16:12 ` [PULL 09/14] aspeed: Emulate the AST2600A3 Cédric Le Goater
@ 2021-09-13 16:13 ` Cédric Le Goater
  2021-09-13 16:13 ` [PULL 11/14] arm/aspeed: Add DPS310 to Witherspoon and Rainier Cédric Le Goater
                   ` (4 subsequent siblings)
  14 siblings, 0 replies; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-13 16:13 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Andrew Jeffery, Cédric Le Goater, qemu-arm, Joel Stanley,
	qemu-devel

From: Joel Stanley <joel@jms.id.au>

This contains some hardcoded register values that were obtained from the
hardware after reading the temperature.

It does enough to test the Linux kernel driver. The FIFO mode, IRQs and
operation modes other than the default as used by Linux are not modelled.

Signed-off-by: Joel Stanley <joel@jms.id.au>
Message-Id: <20210616073358.750472-2-joel@jms.id.au>
[ clg: - Fixed sequential reading
       - Reworked regs_reset_state array
       - Moved model under hw/sensor/ ]
Message-Id: <20210629142336.750058-4-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
 hw/sensor/dps310.c    | 225 ++++++++++++++++++++++++++++++++++++++++++
 hw/arm/Kconfig        |   1 +
 hw/sensor/Kconfig     |   4 +
 hw/sensor/meson.build |   1 +
 4 files changed, 231 insertions(+)
 create mode 100644 hw/sensor/dps310.c

diff --git a/hw/sensor/dps310.c b/hw/sensor/dps310.c
new file mode 100644
index 000000000000..d60a18ac41bb
--- /dev/null
+++ b/hw/sensor/dps310.c
@@ -0,0 +1,225 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright 2017-2021 Joel Stanley <joel@jms.id.au>, IBM Corporation
+ *
+ * Infineon DPS310 temperature and humidity sensor
+ *
+ * https://www.infineon.com/cms/en/product/sensor/pressure-sensors/pressure-sensors-for-iot/dps310/
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/log.h"
+#include "hw/hw.h"
+#include "hw/i2c/i2c.h"
+#include "qapi/error.h"
+#include "qapi/visitor.h"
+#include "migration/vmstate.h"
+
+#define NUM_REGISTERS   0x33
+
+typedef struct DPS310State {
+    /*< private >*/
+    I2CSlave i2c;
+
+    /*< public >*/
+    uint8_t regs[NUM_REGISTERS];
+
+    uint8_t len;
+    uint8_t pointer;
+
+} DPS310State;
+
+#define TYPE_DPS310 "dps310"
+#define DPS310(obj) OBJECT_CHECK(DPS310State, (obj), TYPE_DPS310)
+
+#define DPS310_PRS_B2           0x00
+#define DPS310_PRS_B1           0x01
+#define DPS310_PRS_B0           0x02
+#define DPS310_TMP_B2           0x03
+#define DPS310_TMP_B1           0x04
+#define DPS310_TMP_B0           0x05
+#define DPS310_PRS_CFG          0x06
+#define DPS310_TMP_CFG          0x07
+#define  DPS310_TMP_RATE_BITS   (0x70)
+#define DPS310_MEAS_CFG         0x08
+#define  DPS310_MEAS_CTRL_BITS  (0x07)
+#define   DPS310_PRESSURE_EN    BIT(0)
+#define   DPS310_TEMP_EN        BIT(1)
+#define   DPS310_BACKGROUND     BIT(2)
+#define  DPS310_PRS_RDY         BIT(4)
+#define  DPS310_TMP_RDY         BIT(5)
+#define  DPS310_SENSOR_RDY      BIT(6)
+#define  DPS310_COEF_RDY        BIT(7)
+#define DPS310_CFG_REG          0x09
+#define DPS310_RESET            0x0c
+#define  DPS310_RESET_MAGIC     (BIT(0) | BIT(3))
+#define DPS310_COEF_BASE        0x10
+#define DPS310_COEF_LAST        0x21
+#define DPS310_COEF_SRC         0x28
+
+static void dps310_reset(DeviceState *dev)
+{
+    DPS310State *s = DPS310(dev);
+
+    static const uint8_t regs_reset_state[sizeof(s->regs)] = {
+        0xfe, 0x2f, 0xee, 0x02, 0x69, 0xa6, 0x00, 0x80, 0xc7, 0x00, 0x00, 0x00,
+        0x00, 0x10, 0x00, 0x00, 0x0e, 0x1e, 0xdd, 0x13, 0xca, 0x5f, 0x21, 0x52,
+        0xf9, 0xc6, 0x04, 0xd1, 0xdb, 0x47, 0x00, 0x5b, 0xfb, 0x3a, 0x00, 0x00,
+        0x20, 0x49, 0x4e, 0xa5, 0x90, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+        0x60, 0x15, 0x02
+    };
+
+    memcpy(s->regs, regs_reset_state, sizeof(s->regs));
+    s->pointer = 0;
+
+    /* TODO: assert these after some timeout ? */
+    s->regs[DPS310_MEAS_CFG] = DPS310_COEF_RDY | DPS310_SENSOR_RDY
+        | DPS310_TMP_RDY | DPS310_PRS_RDY;
+}
+
+static uint8_t dps310_read(DPS310State *s, uint8_t reg)
+{
+    if (reg >= sizeof(s->regs)) {
+        qemu_log_mask(LOG_GUEST_ERROR, "%s: register 0x%02x out of bounds\n",
+                      __func__, s->pointer);
+        return 0xFF;
+    }
+
+    switch (reg) {
+    case DPS310_PRS_B2:
+    case DPS310_PRS_B1:
+    case DPS310_PRS_B0:
+    case DPS310_TMP_B2:
+    case DPS310_TMP_B1:
+    case DPS310_TMP_B0:
+    case DPS310_PRS_CFG:
+    case DPS310_TMP_CFG:
+    case DPS310_MEAS_CFG:
+    case DPS310_CFG_REG:
+    case DPS310_COEF_BASE...DPS310_COEF_LAST:
+    case DPS310_COEF_SRC:
+    case 0x32: /* Undocumented register to indicate workaround not required */
+        return s->regs[reg];
+    default:
+        qemu_log_mask(LOG_UNIMP, "%s: register 0x%02x unimplemented\n",
+                      __func__, reg);
+        return 0xFF;
+    }
+}
+
+static void dps310_write(DPS310State *s, uint8_t reg, uint8_t data)
+{
+    if (reg >= sizeof(s->regs)) {
+        qemu_log_mask(LOG_GUEST_ERROR, "%s: register %d out of bounds\n",
+                      __func__, s->pointer);
+        return;
+    }
+
+    switch (reg) {
+    case DPS310_RESET:
+        if (data == DPS310_RESET_MAGIC) {
+            device_cold_reset(DEVICE(s));
+        }
+        break;
+    case DPS310_PRS_CFG:
+    case DPS310_TMP_CFG:
+    case DPS310_MEAS_CFG:
+    case DPS310_CFG_REG:
+        s->regs[reg] = data;
+        break;
+    default:
+        qemu_log_mask(LOG_UNIMP, "%s: register 0x%02x unimplemented\n",
+                      __func__, reg);
+        return;
+    }
+}
+
+static uint8_t dps310_rx(I2CSlave *i2c)
+{
+    DPS310State *s = DPS310(i2c);
+
+    if (s->len == 1) {
+        return dps310_read(s, s->pointer++);
+    } else {
+        return 0xFF;
+    }
+}
+
+static int dps310_tx(I2CSlave *i2c, uint8_t data)
+{
+    DPS310State *s = DPS310(i2c);
+
+    if (s->len == 0) {
+        /*
+         * first byte is the register pointer for a read or write
+         * operation
+         */
+        s->pointer = data;
+        s->len++;
+    } else if (s->len == 1) {
+        dps310_write(s, s->pointer++, data);
+    }
+
+    return 0;
+}
+
+static int dps310_event(I2CSlave *i2c, enum i2c_event event)
+{
+    DPS310State *s = DPS310(i2c);
+
+    switch (event) {
+    case I2C_START_SEND:
+        s->pointer = 0xFF;
+        s->len = 0;
+        break;
+    case I2C_START_RECV:
+        if (s->len != 1) {
+            qemu_log_mask(LOG_GUEST_ERROR, "%s: invalid recv sequence\n",
+                          __func__);
+        }
+        break;
+    default:
+        break;
+    }
+
+    return 0;
+}
+
+static const VMStateDescription vmstate_dps310 = {
+    .name = "DPS310",
+    .version_id = 0,
+    .minimum_version_id = 0,
+    .fields = (VMStateField[]) {
+        VMSTATE_UINT8(len, DPS310State),
+        VMSTATE_UINT8_ARRAY(regs, DPS310State, NUM_REGISTERS),
+        VMSTATE_UINT8(pointer, DPS310State),
+        VMSTATE_I2C_SLAVE(i2c, DPS310State),
+        VMSTATE_END_OF_LIST()
+    }
+};
+
+static void dps310_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    I2CSlaveClass *k = I2C_SLAVE_CLASS(klass);
+
+    k->event = dps310_event;
+    k->recv = dps310_rx;
+    k->send = dps310_tx;
+    dc->reset = dps310_reset;
+    dc->vmsd = &vmstate_dps310;
+}
+
+static const TypeInfo dps310_info = {
+    .name          = TYPE_DPS310,
+    .parent        = TYPE_I2C_SLAVE,
+    .instance_size = sizeof(DPS310State),
+    .class_init    = dps310_class_init,
+};
+
+static void dps310_register_types(void)
+{
+    type_register_static(&dps310_info);
+}
+
+type_init(dps310_register_types)
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 78fdd1b93503..18832abf7d13 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -428,6 +428,7 @@ config ASPEED_SOC
     select DS1338
     select FTGMAC100
     select I2C
+    select DPS310
     select PCA9552
     select SERIAL
     select SMBUS_EEPROM
diff --git a/hw/sensor/Kconfig b/hw/sensor/Kconfig
index a2b55a4fdb2e..9c8a049b0686 100644
--- a/hw/sensor/Kconfig
+++ b/hw/sensor/Kconfig
@@ -6,6 +6,10 @@ config TMP421
     bool
     depends on I2C
 
+config DPS310
+    bool
+    depends on I2C
+
 config EMC141X
     bool
     depends on I2C
diff --git a/hw/sensor/meson.build b/hw/sensor/meson.build
index 034e3e0207bc..059c4ca935b7 100644
--- a/hw/sensor/meson.build
+++ b/hw/sensor/meson.build
@@ -1,5 +1,6 @@
 softmmu_ss.add(when: 'CONFIG_TMP105', if_true: files('tmp105.c'))
 softmmu_ss.add(when: 'CONFIG_TMP421', if_true: files('tmp421.c'))
+softmmu_ss.add(when: 'CONFIG_DPS310', if_true: files('dps310.c'))
 softmmu_ss.add(when: 'CONFIG_EMC141X', if_true: files('emc141x.c'))
 softmmu_ss.add(when: 'CONFIG_ADM1272', if_true: files('adm1272.c'))
 softmmu_ss.add(when: 'CONFIG_MAX34451', if_true: files('max34451.c'))
-- 
2.31.1



^ permalink raw reply	[flat|nested] 41+ messages in thread

* [PULL 11/14] arm/aspeed: Add DPS310 to Witherspoon and Rainier
  2021-09-13 16:12 [PULL 00/14] aspeed queue Cédric Le Goater
                   ` (9 preceding siblings ...)
  2021-09-13 16:13 ` [PULL 10/14] hw/misc: Add Infineon DPS310 sensor model Cédric Le Goater
@ 2021-09-13 16:13 ` Cédric Le Goater
  2021-09-13 16:13 ` [PULL 12/14] hw/arm/aspeed: Initialize AST2600 UART clock selection registers Cédric Le Goater
                   ` (3 subsequent siblings)
  14 siblings, 0 replies; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-13 16:13 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Andrew Jeffery, Cédric Le Goater, qemu-arm, Joel Stanley,
	qemu-devel

From: Joel Stanley <joel@jms.id.au>

Witherspoon uses the DPS310 as a temperature sensor. Rainier uses it as
a temperature and humidity sensor.

Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20210629142336.750058-5-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
 hw/arm/aspeed.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 97964c7e0c53..886e5992cdf3 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -602,7 +602,6 @@ static void witherspoon_bmc_i2c_init(AspeedMachineState *bmc)
 
     /* Bus 3: TODO bmp280@77 */
     /* Bus 3: TODO max31785@52 */
-    /* Bus 3: TODO dps310@76 */
     dev = DEVICE(i2c_slave_new(TYPE_PCA9552, 0x60));
     qdev_prop_set_string(dev, "description", "pca1");
     i2c_slave_realize_and_unref(I2C_SLAVE(dev),
@@ -617,6 +616,7 @@ static void witherspoon_bmc_i2c_init(AspeedMachineState *bmc)
         qdev_connect_gpio_out(dev, pca1_leds[i].gpio_id,
                               qdev_get_gpio_in(DEVICE(led), 0));
     }
+    i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 3), "dps310", 0x76);
     i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 4), "tmp423", 0x4c);
     i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 5), "tmp423", 0x4c);
 
@@ -725,9 +725,9 @@ static void rainier_bmc_i2c_init(AspeedMachineState *bmc)
     aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 2), 0x50, 64 * KiB);
     aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 3), 0x51, 64 * KiB);
 
-    /* Bus 7: TODO dps310@76 */
     /* Bus 7: TODO max31785@52 */
     i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 7), "pca9552", 0x61);
+    i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 7), "dps310", 0x76);
     /* Bus 7: TODO si7021-a20@20 */
     i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 7), TYPE_TMP105,
                      0x48);
-- 
2.31.1



^ permalink raw reply	[flat|nested] 41+ messages in thread

* [PULL 12/14] hw/arm/aspeed: Initialize AST2600 UART clock selection registers
  2021-09-13 16:12 [PULL 00/14] aspeed queue Cédric Le Goater
                   ` (10 preceding siblings ...)
  2021-09-13 16:13 ` [PULL 11/14] arm/aspeed: Add DPS310 to Witherspoon and Rainier Cédric Le Goater
@ 2021-09-13 16:13 ` Cédric Le Goater
  2021-09-13 16:13 ` [PULL 13/14] hw/arm/aspeed: Allow machine to set UART default Cédric Le Goater
                   ` (2 subsequent siblings)
  14 siblings, 0 replies; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-13 16:13 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Andrew Jeffery, qemu-devel, qemu-arm, Cédric Le Goater,
	Peter Delevoryas, Joel Stanley

From: Peter Delevoryas <pdel@fb.com>

UART5 is typically used as the default debug UART on the AST2600, but
UART1 is also designed to be a debug UART. All the AST2600 UART's have
semi-configurable clock rates through registers in the System Control
Unit (SCU), but only UART5 works out of the box with zero-initialized
values. The rest of the UART's expect a few of the registers to be
initialized to non-zero values, or else the clock rate calculation will
yield zero or undefined (due to a divide-by-zero).

For reference, the U-Boot clock rate driver here shows the calculation:

    https://github.com/facebook/openbmc-uboot/blob/15f7e0dc01d8/drivers/clk/aspeed/clk_ast2600.c#L357

To summarize, UART5 allows selection from 4 rates: 24 MHz, 192 MHz, 24 /
13 MHz, and 192 / 13 MHz. The other UART's allow selecting either the
"low" rate (UARTCLK) or the "high" rate (HUARTCLK). UARTCLK and HUARTCLK
are configurable themselves:

    UARTCLK = UXCLK * R / (N * 2)
    HUARTCLK = HUXCLK * HR / (HN * 2)

UXCLK and HUXCLK are also configurable, and depend on the APLL and/or
HPLL clock rates, which also derive from complicated calculations. Long
story short, there's lots of multiplication and division from
configurable registers, and most of these registers are zero-initialized
in QEMU, which at best is unexpected and at worst causes this clock rate
driver to hang from divide-by-zero's. This can also be difficult to
diagnose, because it may cause U-Boot to hang before serial console
initialization completes, requiring intervention from gdb.

This change just initializes all of these registers with default values
from the datasheet.

To test this, I used Facebook's AST2600 OpenBMC image for "fuji", with
the following diff applied (because fuji uses UART1 for console output,
not UART5).

  @@ -323,8 +323,8 @@ static void aspeed_soc_ast2600_realize(DeviceState *dev, Error **errp)
       }

      /* UART - attach an 8250 to the IO space as our UART5 */
  -    serial_mm_init(get_system_memory(), sc->memmap[ASPEED_DEV_UART5], 2,
  -                   aspeed_soc_get_irq(s, ASPEED_DEV_UART5),
  +    serial_mm_init(get_system_memory(), sc->memmap[ASPEED_DEV_UART1], 2,
  +                   aspeed_soc_get_irq(s, ASPEED_DEV_UART1),
                    38400, serial_hd(0), DEVICE_LITTLE_ENDIAN);

       /* I2C */

Without these clock rate registers being initialized, U-Boot hangs in
the clock rate driver from a divide-by-zero, because the UART1 clock
rate register reads return zero, and there's no console output. After
initializing them with default values, fuji boots successfully.

Signed-off-by: Peter Delevoryas <pdel@fb.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
[ clg: Removed _PARAM suffix ]
Message-Id: <20210906134023.3711031-2-pdel@fb.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
 hw/misc/aspeed_scu.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/hw/misc/aspeed_scu.c b/hw/misc/aspeed_scu.c
index 05edebedeb46..d06e179a6e65 100644
--- a/hw/misc/aspeed_scu.c
+++ b/hw/misc/aspeed_scu.c
@@ -119,6 +119,8 @@
 #define AST2600_CLK_SEL3          TO_REG(0x308)
 #define AST2600_CLK_SEL4          TO_REG(0x310)
 #define AST2600_CLK_SEL5          TO_REG(0x314)
+#define AST2600_UARTCLK           TO_REG(0x338)
+#define AST2600_HUARTCLK          TO_REG(0x33C)
 #define AST2600_HW_STRAP1         TO_REG(0x500)
 #define AST2600_HW_STRAP1_CLR     TO_REG(0x504)
 #define AST2600_HW_STRAP1_PROT    TO_REG(0x508)
@@ -681,6 +683,8 @@ static const uint32_t ast2600_a3_resets[ASPEED_AST2600_SCU_NR_REGS] = {
     [AST2600_CLK_SEL3]          = 0x00000000,
     [AST2600_CLK_SEL4]          = 0xF3F40000,
     [AST2600_CLK_SEL5]          = 0x30000000,
+    [AST2600_UARTCLK]           = 0x00014506,
+    [AST2600_HUARTCLK]          = 0x000145C0,
     [AST2600_CHIP_ID0]          = 0x1234ABCD,
     [AST2600_CHIP_ID1]          = 0x88884444,
 };
-- 
2.31.1



^ permalink raw reply	[flat|nested] 41+ messages in thread

* [PULL 13/14] hw/arm/aspeed: Allow machine to set UART default
  2021-09-13 16:12 [PULL 00/14] aspeed queue Cédric Le Goater
                   ` (11 preceding siblings ...)
  2021-09-13 16:13 ` [PULL 12/14] hw/arm/aspeed: Initialize AST2600 UART clock selection registers Cédric Le Goater
@ 2021-09-13 16:13 ` Cédric Le Goater
  2021-09-13 16:13 ` [PULL 14/14] hw/arm/aspeed: Add Fuji machine type Cédric Le Goater
  2021-09-14 10:51 ` [PULL 00/14] aspeed queue Peter Maydell
  14 siblings, 0 replies; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-13 16:13 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Andrew Jeffery, qemu-devel, qemu-arm, Cédric Le Goater,
	Peter Delevoryas, Joel Stanley

From: Peter Delevoryas <pdel@fb.com>

When you run QEMU with an Aspeed machine and a single serial device
using stdio like this:

    qemu -machine ast2600-evb -drive ... -serial stdio

The guest OS can read and write to the UART5 registers at 0x1E784000 and
it will receive from stdin and write to stdout. The Aspeed SoC's have a
lot more UART's though (AST2500 has 5, AST2600 has 13) and depending on
the board design, may be using any of them as the serial console. (See
"stdout-path" in a DTS to check which one is chosen).

Most boards, including all of those currently defined in
hw/arm/aspeed.c, just use UART5, but some use UART1. This change adds
some flexibility for different boards without requiring users to change
their command-line invocation of QEMU.

I tested this doesn't break existing code by booting an AST2500 OpenBMC
image and an AST2600 OpenBMC image, each using UART5 as the console.

Then I tested switching the default to UART1 and booting an AST2600
OpenBMC image that uses UART1, and that worked too.

Signed-off-by: Peter Delevoryas <pdel@fb.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20210901153615.2746885-2-pdel@fb.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
 include/hw/arm/aspeed.h     | 1 +
 include/hw/arm/aspeed_soc.h | 1 +
 hw/arm/aspeed.c             | 3 +++
 hw/arm/aspeed_ast2600.c     | 8 ++++----
 hw/arm/aspeed_soc.c         | 8 +++++---
 5 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/include/hw/arm/aspeed.h b/include/hw/arm/aspeed.h
index c9747b15fc5f..cbeacb214ca4 100644
--- a/include/hw/arm/aspeed.h
+++ b/include/hw/arm/aspeed.h
@@ -38,6 +38,7 @@ struct AspeedMachineClass {
     uint32_t num_cs;
     uint32_t macs_mask;
     void (*i2c_init)(AspeedMachineState *bmc);
+    uint32_t uart_default;
 };
 
 
diff --git a/include/hw/arm/aspeed_soc.h b/include/hw/arm/aspeed_soc.h
index d9161d26d645..87d76c92598b 100644
--- a/include/hw/arm/aspeed_soc.h
+++ b/include/hw/arm/aspeed_soc.h
@@ -65,6 +65,7 @@ struct AspeedSoCState {
     AspeedSDHCIState sdhci;
     AspeedSDHCIState emmc;
     AspeedLPCState lpc;
+    uint32_t uart_default;
 };
 
 #define TYPE_ASPEED_SOC "aspeed-soc"
diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 886e5992cdf3..7a9459340cf4 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -350,6 +350,8 @@ static void aspeed_machine_init(MachineState *machine)
         object_property_set_int(OBJECT(&bmc->soc), "hw-prot-key",
                                 ASPEED_SCU_PROT_KEY, &error_abort);
     }
+    qdev_prop_set_uint32(DEVICE(&bmc->soc), "uart-default",
+                         amc->uart_default);
     qdev_realize(DEVICE(&bmc->soc), NULL, &error_abort);
 
     memory_region_add_subregion(get_system_memory(),
@@ -848,6 +850,7 @@ static void aspeed_machine_class_init(ObjectClass *oc, void *data)
     mc->no_parallel = 1;
     mc->default_ram_id = "ram";
     amc->macs_mask = ASPEED_MAC0_ON;
+    amc->uart_default = ASPEED_DEV_UART5;
 
     aspeed_machine_class_props_init(oc);
 }
diff --git a/hw/arm/aspeed_ast2600.c b/hw/arm/aspeed_ast2600.c
index 8e1993790e6f..9d70e8e060c6 100644
--- a/hw/arm/aspeed_ast2600.c
+++ b/hw/arm/aspeed_ast2600.c
@@ -322,10 +322,10 @@ static void aspeed_soc_ast2600_realize(DeviceState *dev, Error **errp)
         sysbus_connect_irq(SYS_BUS_DEVICE(&s->timerctrl), i, irq);
     }
 
-    /* UART - attach an 8250 to the IO space as our UART5 */
-    serial_mm_init(get_system_memory(), sc->memmap[ASPEED_DEV_UART5], 2,
-                   aspeed_soc_get_irq(s, ASPEED_DEV_UART5),
-                   38400, serial_hd(0), DEVICE_LITTLE_ENDIAN);
+    /* UART - attach an 8250 to the IO space as our UART */
+    serial_mm_init(get_system_memory(), sc->memmap[s->uart_default], 2,
+                   aspeed_soc_get_irq(s, s->uart_default), 38400,
+                   serial_hd(0), DEVICE_LITTLE_ENDIAN);
 
     /* I2C */
     object_property_set_link(OBJECT(&s->i2c), "dram", OBJECT(s->dram_mr),
diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
index 3ad6c56fa9a9..ed84502e238a 100644
--- a/hw/arm/aspeed_soc.c
+++ b/hw/arm/aspeed_soc.c
@@ -287,9 +287,9 @@ static void aspeed_soc_realize(DeviceState *dev, Error **errp)
         sysbus_connect_irq(SYS_BUS_DEVICE(&s->timerctrl), i, irq);
     }
 
-    /* UART - attach an 8250 to the IO space as our UART5 */
-    serial_mm_init(get_system_memory(), sc->memmap[ASPEED_DEV_UART5], 2,
-                   aspeed_soc_get_irq(s, ASPEED_DEV_UART5), 38400,
+    /* UART - attach an 8250 to the IO space as our UART */
+    serial_mm_init(get_system_memory(), sc->memmap[s->uart_default], 2,
+                   aspeed_soc_get_irq(s, s->uart_default), 38400,
                    serial_hd(0), DEVICE_LITTLE_ENDIAN);
 
     /* I2C */
@@ -439,6 +439,8 @@ static void aspeed_soc_realize(DeviceState *dev, Error **errp)
 static Property aspeed_soc_properties[] = {
     DEFINE_PROP_LINK("dram", AspeedSoCState, dram_mr, TYPE_MEMORY_REGION,
                      MemoryRegion *),
+    DEFINE_PROP_UINT32("uart-default", AspeedSoCState, uart_default,
+                       ASPEED_DEV_UART5),
     DEFINE_PROP_END_OF_LIST(),
 };
 
-- 
2.31.1



^ permalink raw reply	[flat|nested] 41+ messages in thread

* [PULL 14/14] hw/arm/aspeed: Add Fuji machine type
  2021-09-13 16:12 [PULL 00/14] aspeed queue Cédric Le Goater
                   ` (12 preceding siblings ...)
  2021-09-13 16:13 ` [PULL 13/14] hw/arm/aspeed: Allow machine to set UART default Cédric Le Goater
@ 2021-09-13 16:13 ` Cédric Le Goater
  2021-09-14 10:56   ` Cédric Le Goater
  2021-09-14 10:51 ` [PULL 00/14] aspeed queue Peter Maydell
  14 siblings, 1 reply; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-13 16:13 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Andrew Jeffery, qemu-devel, qemu-arm, Cédric Le Goater,
	Peter Delevoryas, Joel Stanley

From: Peter Delevoryas <pdel@fb.com>

This adds a new machine type "fuji-bmc" based on the following device tree:

https://github.com/torvalds/linux/blob/40cb6373b46/arch/arm/boot/dts/aspeed-bmc-facebook-fuji.dts

Most of the i2c devices are not there, they're added here:

https://github.com/facebook/openbmc/blob/fb2ed12002fb/meta-facebook/meta-fuji/recipes-utils/openbmc-utils/files/setup_i2c.sh

I tested this by building a Fuji image from Facebook's OpenBMC repo,
booting, and ssh'ing from host-to-guest.

Signed-off-by: Peter Delevoryas <pdel@fb.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Message-Id: <20210906133124.3674661-1-pdel@fb.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
 hw/arm/aspeed.c | 113 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 113 insertions(+)

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 7a9459340cf4..95ce4b1670ac 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -159,6 +159,10 @@ struct AspeedMachineState {
 #define RAINIER_BMC_HW_STRAP1 0x00000000
 #define RAINIER_BMC_HW_STRAP2 0x00000000
 
+/* Fuji hardware value */
+#define FUJI_BMC_HW_STRAP1    0x00000000
+#define FUJI_BMC_HW_STRAP2    0x00000000
+
 /*
  * The max ram region is for firmwares that scan the address space
  * with load/store to guess how much RAM the SoC has.
@@ -772,6 +776,91 @@ static void rainier_bmc_i2c_init(AspeedMachineState *bmc)
     aspeed_eeprom_init(aspeed_i2c_get_bus(&soc->i2c, 15), 0x50, 64 * KiB);
 }
 
+static void get_pca9548_channels(I2CBus *bus, uint8_t mux_addr,
+                                 I2CBus **channels)
+{
+    I2CSlave *mux = i2c_slave_create_simple(bus, "pca9548", mux_addr);
+    for (int i = 0; i < 8; i++) {
+        channels[i] = pca954x_i2c_get_bus(mux, i);
+    }
+}
+
+#define TYPE_LM75 TYPE_TMP105
+#define TYPE_TMP75 TYPE_TMP105
+#define TYPE_TMP422 "tmp422"
+
+static void fuji_bmc_i2c_init(AspeedMachineState *bmc)
+{
+    AspeedSoCState *soc = &bmc->soc;
+    I2CBus *i2c[144] = {};
+
+    for (int i = 0; i < 16; i++) {
+        i2c[i] = aspeed_i2c_get_bus(&soc->i2c, i);
+    }
+    I2CBus *i2c180 = i2c[2];
+    I2CBus *i2c480 = i2c[8];
+    I2CBus *i2c600 = i2c[11];
+
+    get_pca9548_channels(i2c180, 0x70, &i2c[16]);
+    get_pca9548_channels(i2c480, 0x70, &i2c[24]);
+    /* NOTE: The device tree skips [32, 40) in the alias numbering */
+    get_pca9548_channels(i2c600, 0x77, &i2c[40]);
+    get_pca9548_channels(i2c[24], 0x71, &i2c[48]);
+    get_pca9548_channels(i2c[25], 0x72, &i2c[56]);
+    get_pca9548_channels(i2c[26], 0x76, &i2c[64]);
+    get_pca9548_channels(i2c[27], 0x76, &i2c[72]);
+    for (int i = 0; i < 8; i++) {
+        get_pca9548_channels(i2c[40 + i], 0x76, &i2c[80 + i * 8]);
+    }
+
+    i2c_slave_create_simple(i2c[17], TYPE_LM75, 0x4c);
+    i2c_slave_create_simple(i2c[17], TYPE_LM75, 0x4d);
+
+    aspeed_eeprom_init(i2c[19], 0x52, 64 * KiB);
+    aspeed_eeprom_init(i2c[20], 0x50, 2 * KiB);
+    aspeed_eeprom_init(i2c[22], 0x52, 2 * KiB);
+
+    i2c_slave_create_simple(i2c[3], TYPE_LM75, 0x48);
+    i2c_slave_create_simple(i2c[3], TYPE_LM75, 0x49);
+    i2c_slave_create_simple(i2c[3], TYPE_LM75, 0x4a);
+    i2c_slave_create_simple(i2c[3], TYPE_TMP422, 0x4c);
+
+    aspeed_eeprom_init(i2c[8], 0x51, 64 * KiB);
+    i2c_slave_create_simple(i2c[8], TYPE_LM75, 0x4a);
+
+    i2c_slave_create_simple(i2c[50], TYPE_LM75, 0x4c);
+    aspeed_eeprom_init(i2c[50], 0x52, 64 * KiB);
+    i2c_slave_create_simple(i2c[51], TYPE_TMP75, 0x48);
+    i2c_slave_create_simple(i2c[52], TYPE_TMP75, 0x49);
+
+    i2c_slave_create_simple(i2c[59], TYPE_TMP75, 0x48);
+    i2c_slave_create_simple(i2c[60], TYPE_TMP75, 0x49);
+
+    aspeed_eeprom_init(i2c[65], 0x53, 64 * KiB);
+    i2c_slave_create_simple(i2c[66], TYPE_TMP75, 0x49);
+    i2c_slave_create_simple(i2c[66], TYPE_TMP75, 0x48);
+    aspeed_eeprom_init(i2c[68], 0x52, 64 * KiB);
+    aspeed_eeprom_init(i2c[69], 0x52, 64 * KiB);
+    aspeed_eeprom_init(i2c[70], 0x52, 64 * KiB);
+    aspeed_eeprom_init(i2c[71], 0x52, 64 * KiB);
+
+    aspeed_eeprom_init(i2c[73], 0x53, 64 * KiB);
+    i2c_slave_create_simple(i2c[74], TYPE_TMP75, 0x49);
+    i2c_slave_create_simple(i2c[74], TYPE_TMP75, 0x48);
+    aspeed_eeprom_init(i2c[76], 0x52, 64 * KiB);
+    aspeed_eeprom_init(i2c[77], 0x52, 64 * KiB);
+    aspeed_eeprom_init(i2c[78], 0x52, 64 * KiB);
+    aspeed_eeprom_init(i2c[79], 0x52, 64 * KiB);
+    aspeed_eeprom_init(i2c[28], 0x50, 2 * KiB);
+
+    for (int i = 0; i < 8; i++) {
+        aspeed_eeprom_init(i2c[81 + i * 8], 0x56, 64 * KiB);
+        i2c_slave_create_simple(i2c[82 + i * 8], TYPE_TMP75, 0x48);
+        i2c_slave_create_simple(i2c[83 + i * 8], TYPE_TMP75, 0x4b);
+        i2c_slave_create_simple(i2c[84 + i * 8], TYPE_TMP75, 0x4a);
+    }
+}
+
 static bool aspeed_get_mmio_exec(Object *obj, Error **errp)
 {
     return ASPEED_MACHINE(obj)->mmio_exec;
@@ -1070,6 +1159,26 @@ static void aspeed_machine_rainier_class_init(ObjectClass *oc, void *data)
         aspeed_soc_num_cpus(amc->soc_name);
 };
 
+static void aspeed_machine_fuji_class_init(ObjectClass *oc, void *data)
+{
+    MachineClass *mc = MACHINE_CLASS(oc);
+    AspeedMachineClass *amc = ASPEED_MACHINE_CLASS(oc);
+
+    mc->desc = "Facebook Fuji BMC (Cortex-A7)";
+    amc->soc_name = "ast2600-a3";
+    amc->hw_strap1 = FUJI_BMC_HW_STRAP1;
+    amc->hw_strap2 = FUJI_BMC_HW_STRAP2;
+    amc->fmc_model = "mx66l1g45g";
+    amc->spi_model = "mx66l1g45g";
+    amc->num_cs = 2;
+    amc->macs_mask = ASPEED_MAC3_ON;
+    amc->i2c_init = fuji_bmc_i2c_init;
+    amc->uart_default = ASPEED_DEV_UART1;
+    mc->default_ram_size = 2 * GiB;
+    mc->default_cpus = mc->min_cpus = mc->max_cpus =
+        aspeed_soc_num_cpus(amc->soc_name);
+};
+
 static const TypeInfo aspeed_machine_types[] = {
     {
         .name          = MACHINE_TYPE_NAME("palmetto-bmc"),
@@ -1119,6 +1228,10 @@ static const TypeInfo aspeed_machine_types[] = {
         .name          = MACHINE_TYPE_NAME("rainier-bmc"),
         .parent        = TYPE_ASPEED_MACHINE,
         .class_init    = aspeed_machine_rainier_class_init,
+    }, {
+        .name          = MACHINE_TYPE_NAME("fuji-bmc"),
+        .parent        = TYPE_ASPEED_MACHINE,
+        .class_init    = aspeed_machine_fuji_class_init,
     }, {
         .name          = TYPE_ASPEED_MACHINE,
         .parent        = TYPE_MACHINE,
-- 
2.31.1



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PULL 00/14] aspeed queue
  2021-09-13 16:12 [PULL 00/14] aspeed queue Cédric Le Goater
                   ` (13 preceding siblings ...)
  2021-09-13 16:13 ` [PULL 14/14] hw/arm/aspeed: Add Fuji machine type Cédric Le Goater
@ 2021-09-14 10:51 ` Peter Maydell
  2021-09-14 10:58   ` Cédric Le Goater
  14 siblings, 1 reply; 41+ messages in thread
From: Peter Maydell @ 2021-09-14 10:51 UTC (permalink / raw)
  To: Cédric Le Goater
  Cc: Andrew Jeffery, qemu-arm, Joel Stanley, QEMU Developers

On Mon, 13 Sept 2021 at 17:13, Cédric Le Goater <clg@kaod.org> wrote:
>
> The following changes since commit eae587e8e3694b1aceab23239493fb4c7e1a80f5:
>
>   Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2021-09-13' into staging (2021-09-13 11:00:30 +0100)
>
> are available in the Git repository at:
>
>   https://github.com/legoater/qemu/ tags/pull-aspeed-20210913
>
> for you to fetch changes up to d7add12e20fa8982f5932ff4dca317c5d2dfe7d9:
>
>   hw/arm/aspeed: Add Fuji machine type (2021-09-13 15:19:20 +0200)
>
> ----------------------------------------------------------------
> Aspeed patches :
>
> * MAC enablement fixes (Guenter)
> * Watchdog  and pca9552 fixes (Andrew)
> * GPIO fixes (Joel)
> * AST2600A3 SoC and DPS310 models (Joel)
> * New Fuji BMC machine (Peter)

Hi; this fails 'make check' on 32-bit hosts:

qemu-system-aarch64: at most 2047 MB RAM can be simulated
Broken pipe
ERROR qtest-aarch64/qom-test - too few tests run (expected 83, got 31)

I suspect the new machine type has a default of more than 2GB
of RAM, which won't work on 32 bit systems.

-- PMM


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type
  2021-09-13 16:13 ` [PULL 14/14] hw/arm/aspeed: Add Fuji machine type Cédric Le Goater
@ 2021-09-14 10:56   ` Cédric Le Goater
  2021-09-14 11:59     ` Peter Delevoryas
  0 siblings, 1 reply; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-14 10:56 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Andrew Jeffery, qemu-arm, Joel Stanley, Peter Delevoryas, qemu-devel


Hello Peter D,

> +static void aspeed_machine_fuji_class_init(ObjectClass *oc, void *data)
> +{
> +    MachineClass *mc = MACHINE_CLASS(oc);
> +    AspeedMachineClass *amc = ASPEED_MACHINE_CLASS(oc);
> +
> +    mc->desc = "Facebook Fuji BMC (Cortex-A7)";
> +    amc->soc_name = "ast2600-a3";
> +    amc->hw_strap1 = FUJI_BMC_HW_STRAP1;
> +    amc->hw_strap2 = FUJI_BMC_HW_STRAP2;
> +    amc->fmc_model = "mx66l1g45g";
> +    amc->spi_model = "mx66l1g45g";
> +    amc->num_cs = 2;
> +    amc->macs_mask = ASPEED_MAC3_ON;
> +    amc->i2c_init = fuji_bmc_i2c_init;
> +    amc->uart_default = ASPEED_DEV_UART1;
> +    mc->default_ram_size = 2 * GiB;

Is that the default of the Fuji board ? This is causing an issue in our tests :

   qemu-system-aarch64: at most 2047 MB RAM can be simulated

Could we lower it down to 1G ?

Thanks,

C.

> +    mc->default_cpus = mc->min_cpus = mc->max_cpus =
> +        aspeed_soc_num_cpus(amc->soc_name);
> +};
> +
>  static const TypeInfo aspeed_machine_types[] = {
>      {
>          .name          = MACHINE_TYPE_NAME("palmetto-bmc"),
> @@ -1119,6 +1228,10 @@ static const TypeInfo aspeed_machine_types[] = {
>          .name          = MACHINE_TYPE_NAME("rainier-bmc"),
>          .parent        = TYPE_ASPEED_MACHINE,
>          .class_init    = aspeed_machine_rainier_class_init,
> +    }, {
> +        .name          = MACHINE_TYPE_NAME("fuji-bmc"),
> +        .parent        = TYPE_ASPEED_MACHINE,
> +        .class_init    = aspeed_machine_fuji_class_init,
>      }, {
>          .name          = TYPE_ASPEED_MACHINE,
>          .parent        = TYPE_MACHINE,
> 



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PULL 00/14] aspeed queue
  2021-09-14 10:51 ` [PULL 00/14] aspeed queue Peter Maydell
@ 2021-09-14 10:58   ` Cédric Le Goater
  2021-09-14 11:38     ` Philippe Mathieu-Daudé
  0 siblings, 1 reply; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-14 10:58 UTC (permalink / raw)
  To: Peter Maydell; +Cc: Andrew Jeffery, qemu-arm, Joel Stanley, QEMU Developers

On 9/14/21 12:51 PM, Peter Maydell wrote:
> On Mon, 13 Sept 2021 at 17:13, Cédric Le Goater <clg@kaod.org> wrote:
>>
>> The following changes since commit eae587e8e3694b1aceab23239493fb4c7e1a80f5:
>>
>>   Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2021-09-13' into staging (2021-09-13 11:00:30 +0100)
>>
>> are available in the Git repository at:
>>
>>   https://github.com/legoater/qemu/ tags/pull-aspeed-20210913
>>
>> for you to fetch changes up to d7add12e20fa8982f5932ff4dca317c5d2dfe7d9:
>>
>>   hw/arm/aspeed: Add Fuji machine type (2021-09-13 15:19:20 +0200)
>>
>> ----------------------------------------------------------------
>> Aspeed patches :
>>
>> * MAC enablement fixes (Guenter)
>> * Watchdog  and pca9552 fixes (Andrew)
>> * GPIO fixes (Joel)
>> * AST2600A3 SoC and DPS310 models (Joel)
>> * New Fuji BMC machine (Peter)
> 
> Hi; this fails 'make check' on 32-bit hosts:
> 
> qemu-system-aarch64: at most 2047 MB RAM can be simulated
> Broken pipe
> ERROR qtest-aarch64/qom-test - too few tests run (expected 83, got 31)
> 
> I suspect the new machine type has a default of more than 2GB
> of RAM, which won't work on 32 bit systems.

ok. I guess we need to change the Fuji.

Thanks,

C. 



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PULL 00/14] aspeed queue
  2021-09-14 10:58   ` Cédric Le Goater
@ 2021-09-14 11:38     ` Philippe Mathieu-Daudé
  0 siblings, 0 replies; 41+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-09-14 11:38 UTC (permalink / raw)
  To: Cédric Le Goater, Peter Maydell
  Cc: Andrew Jeffery, qemu-arm, Joel Stanley, QEMU Developers

On 9/14/21 12:58 PM, Cédric Le Goater wrote:
> On 9/14/21 12:51 PM, Peter Maydell wrote:
>> On Mon, 13 Sept 2021 at 17:13, Cédric Le Goater <clg@kaod.org> wrote:
>>>
>>> The following changes since commit eae587e8e3694b1aceab23239493fb4c7e1a80f5:
>>>
>>>   Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2021-09-13' into staging (2021-09-13 11:00:30 +0100)
>>>
>>> are available in the Git repository at:
>>>
>>>   https://github.com/legoater/qemu/ tags/pull-aspeed-20210913
>>>
>>> for you to fetch changes up to d7add12e20fa8982f5932ff4dca317c5d2dfe7d9:
>>>
>>>   hw/arm/aspeed: Add Fuji machine type (2021-09-13 15:19:20 +0200)
>>>
>>> ----------------------------------------------------------------
>>> Aspeed patches :
>>>
>>> * MAC enablement fixes (Guenter)
>>> * Watchdog  and pca9552 fixes (Andrew)
>>> * GPIO fixes (Joel)
>>> * AST2600A3 SoC and DPS310 models (Joel)
>>> * New Fuji BMC machine (Peter)
>>
>> Hi; this fails 'make check' on 32-bit hosts:
>>
>> qemu-system-aarch64: at most 2047 MB RAM can be simulated
>> Broken pipe
>> ERROR qtest-aarch64/qom-test - too few tests run (expected 83, got 31)
>>
>> I suspect the new machine type has a default of more than 2GB
>> of RAM, which won't work on 32 bit systems.
> 
> ok. I guess we need to change the Fuji.

If the machine requires 2GiB, I'd rather not modify it but not
register it on 32-bit hosts. Better to avoid Frankenstein machines.
Thoughts?


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type
  2021-09-14 10:56   ` Cédric Le Goater
@ 2021-09-14 11:59     ` Peter Delevoryas
  2021-09-14 12:14       ` Joel Stanley
  0 siblings, 1 reply; 41+ messages in thread
From: Peter Delevoryas @ 2021-09-14 11:59 UTC (permalink / raw)
  To: Cédric Le Goater
  Cc: Peter Maydell, Andrew Jeffery, Joel Stanley, qemu-arm, qemu-devel


> On Sep 14, 2021, at 3:56 AM, Cédric Le Goater <clg@kaod.org> wrote:
> 
> 
> Hello Peter D,
> 
>> +static void aspeed_machine_fuji_class_init(ObjectClass *oc, void *data)
>> +{
>> +    MachineClass *mc = MACHINE_CLASS(oc);
>> +    AspeedMachineClass *amc = ASPEED_MACHINE_CLASS(oc);
>> +
>> +    mc->desc = "Facebook Fuji BMC (Cortex-A7)";
>> +    amc->soc_name = "ast2600-a3";
>> +    amc->hw_strap1 = FUJI_BMC_HW_STRAP1;
>> +    amc->hw_strap2 = FUJI_BMC_HW_STRAP2;
>> +    amc->fmc_model = "mx66l1g45g";
>> +    amc->spi_model = "mx66l1g45g";
>> +    amc->num_cs = 2;
>> +    amc->macs_mask = ASPEED_MAC3_ON;
>> +    amc->i2c_init = fuji_bmc_i2c_init;
>> +    amc->uart_default = ASPEED_DEV_UART1;
>> +    mc->default_ram_size = 2 * GiB;
> 
> Is that the default of the Fuji board ? This is causing an issue in our tests :
> 
>   qemu-system-aarch64: at most 2047 MB RAM can be simulated
> 
> Could we lower it down to 1G ?

Yikes, sorry about that. I thought it was 2G, but yeah let’s just lower it to 1G. I might be completely wrong anyways.

> 
> Thanks,
> 
> C.
> 
>> +    mc->default_cpus = mc->min_cpus = mc->max_cpus =
>> +        aspeed_soc_num_cpus(amc->soc_name);
>> +};
>> +
>> static const TypeInfo aspeed_machine_types[] = {
>>     {
>>         .name          = MACHINE_TYPE_NAME("palmetto-bmc"),
>> @@ -1119,6 +1228,10 @@ static const TypeInfo aspeed_machine_types[] = {
>>         .name          = MACHINE_TYPE_NAME("rainier-bmc"),
>>         .parent        = TYPE_ASPEED_MACHINE,
>>         .class_init    = aspeed_machine_rainier_class_init,
>> +    }, {
>> +        .name          = MACHINE_TYPE_NAME("fuji-bmc"),
>> +        .parent        = TYPE_ASPEED_MACHINE,
>> +        .class_init    = aspeed_machine_fuji_class_init,
>>     }, {
>>         .name          = TYPE_ASPEED_MACHINE,
>>         .parent        = TYPE_MACHINE,
>> 
> 

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type
  2021-09-14 11:59     ` Peter Delevoryas
@ 2021-09-14 12:14       ` Joel Stanley
  2021-09-14 12:26         ` Peter Maydell
  0 siblings, 1 reply; 41+ messages in thread
From: Joel Stanley @ 2021-09-14 12:14 UTC (permalink / raw)
  To: Peter Delevoryas
  Cc: Andrew Jeffery, Peter Maydell, qemu-arm, Cédric Le Goater,
	qemu-devel

On Tue, 14 Sept 2021 at 11:59, Peter Delevoryas <pdel@fb.com> wrote:
>
>
> > On Sep 14, 2021, at 3:56 AM, Cédric Le Goater <clg@kaod.org> wrote:
> >
> > 
> > Hello Peter D,
> >
> >> +static void aspeed_machine_fuji_class_init(ObjectClass *oc, void *data)
> >> +{
> >> +    MachineClass *mc = MACHINE_CLASS(oc);
> >> +    AspeedMachineClass *amc = ASPEED_MACHINE_CLASS(oc);
> >> +
> >> +    mc->desc = "Facebook Fuji BMC (Cortex-A7)";
> >> +    amc->soc_name = "ast2600-a3";
> >> +    amc->hw_strap1 = FUJI_BMC_HW_STRAP1;
> >> +    amc->hw_strap2 = FUJI_BMC_HW_STRAP2;
> >> +    amc->fmc_model = "mx66l1g45g";
> >> +    amc->spi_model = "mx66l1g45g";
> >> +    amc->num_cs = 2;
> >> +    amc->macs_mask = ASPEED_MAC3_ON;
> >> +    amc->i2c_init = fuji_bmc_i2c_init;
> >> +    amc->uart_default = ASPEED_DEV_UART1;
> >> +    mc->default_ram_size = 2 * GiB;
> >
> > Is that the default of the Fuji board ? This is causing an issue in our tests :
> >
> >   qemu-system-aarch64: at most 2047 MB RAM can be simulated
> >
> > Could we lower it down to 1G ?
>
> Yikes, sorry about that. I thought it was 2G, but yeah let’s just lower it to 1G. I might be completely wrong anyways.

The upstream device tree uses 2G:

https://elixir.bootlin.com/linux/v5.15-rc1/source/arch/arm/boot/dts/ast2600-facebook-netbmc-common.dtsi#L20

It's unfortunate we limit the defaults given very few (no one?) is
using this model on a machine that is 32 bit.

OTOH, modelling 1G of RAM is useful for testing, so it's no great loss.

Cheers,

Joel


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type
  2021-09-14 12:14       ` Joel Stanley
@ 2021-09-14 12:26         ` Peter Maydell
  2021-09-14 15:22           ` Richard Henderson
  0 siblings, 1 reply; 41+ messages in thread
From: Peter Maydell @ 2021-09-14 12:26 UTC (permalink / raw)
  To: Joel Stanley
  Cc: Andrew Jeffery, qemu-devel, qemu-arm, Cédric Le Goater,
	Peter Delevoryas

On Tue, 14 Sept 2021 at 13:14, Joel Stanley <joel@jms.id.au> wrote:
> The upstream device tree uses 2G:
>
> https://elixir.bootlin.com/linux/v5.15-rc1/source/arch/arm/boot/dts/ast2600-facebook-netbmc-common.dtsi#L20
>
> It's unfortunate we limit the defaults given very few (no one?) is
> using this model on a machine that is 32 bit.

This runs into a set of desires which are all reasonable
but unfortunately sometimes in conflict:

(1) boards should behave the same on all hosts (whether those
    hosts are 64 bit or 32 bit)
(2) RAM blocks should have a length that fits inside a
    signed 32-bit type on 32-bit hosts (at least I assume this
    is where the 2047MB limit is coming from; in theory this ought
    to be improveable but auditing the code for mishandling of
    RAMblock sizes to ensure we weren't accidentally stuffing
    their size into a signed 'long' somewhere would be kind
    of painful)
(3) default behaviour of a board should match the real
    hardware
(4) every board should start cleanly with no non-default
    arguments, so we can have a machine-model agnostic test
    of "does every machine we support at least init cleanly"

So far when we have run into this problem with other machine
types, the one that we have ended up discarding is (3).

There's a good argument to be made that what we should deal
with is (2) -- this probably involves making ram_addr_t
be 64-bits always, rather than "64 bits unless we're on
a 32-bit host and Xen is not compiled in", and a certain
amount of testing or audit that we don't have any places
where we stuff ram sizes into 'long' variables. But it's a lot
more work than compromising on (3) :-)

Even if we did fix (2) we'd need to compromise on (3)
sometimes still -- if a board has 4GB of RAM that's
not going to fit in 32 bits regardless. But we would be
able to let boards with 2GB have 2GB.

thanks
-- PMM


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type
  2021-09-14 12:26         ` Peter Maydell
@ 2021-09-14 15:22           ` Richard Henderson
  2021-09-15  7:42             ` Deprecate 32-bit hosts? (was: Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type) Thomas Huth
  2021-09-16 12:29             ` [PULL 14/14] hw/arm/aspeed: Add Fuji machine type Cédric Le Goater
  0 siblings, 2 replies; 41+ messages in thread
From: Richard Henderson @ 2021-09-14 15:22 UTC (permalink / raw)
  To: Peter Maydell, Joel Stanley
  Cc: Andrew Jeffery, qemu-arm, qemu-devel, Peter Delevoryas,
	Cédric Le Goater

On 9/14/21 5:26 AM, Peter Maydell wrote:
> (2) RAM blocks should have a length that fits inside a
>      signed 32-bit type on 32-bit hosts (at least I assume this
>      is where the 2047MB limit is coming from; in theory this ought
>      to be improveable but auditing the code for mishandling of
>      RAMblock sizes to ensure we weren't accidentally stuffing
>      their size into a signed 'long' somewhere would be kind
>      of painful)

Recalling that the win64 abi model is p64, i.e. 'long' is still 32-bit while pointers are 
64-bit, how close do we think we are to this being fixed already?

> Even if we did fix (2) we'd need to compromise on (3)
> sometimes still -- if a board has 4GB of RAM that's
> not going to fit in 32 bits regardless. But we would be
> able to let boards with 2GB have 2GB.

I'm not opposed to deprecating 32-bit hosts...  ;-)


r~


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Deprecate 32-bit hosts? (was: Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type)
  2021-09-14 15:22           ` Richard Henderson
@ 2021-09-15  7:42             ` Thomas Huth
  2021-09-15  7:54               ` Philippe Mathieu-Daudé
  2021-09-15  8:37               ` Daniel P. Berrangé
  2021-09-16 12:29             ` [PULL 14/14] hw/arm/aspeed: Add Fuji machine type Cédric Le Goater
  1 sibling, 2 replies; 41+ messages in thread
From: Thomas Huth @ 2021-09-15  7:42 UTC (permalink / raw)
  To: Richard Henderson, Peter Maydell, Joel Stanley
  Cc: Daniel P. Berrange, Samuel Thibault, Andrew Jeffery, qemu-devel,
	qemu-arm, Cédric Le Goater, Peter Delevoryas, Paolo Bonzini,
	Philippe Mathieu-Daudé

On 14/09/2021 17.22, Richard Henderson wrote:
> On 9/14/21 5:26 AM, Peter Maydell wrote:
>> (2) RAM blocks should have a length that fits inside a
>>      signed 32-bit type on 32-bit hosts (at least I assume this
>>      is where the 2047MB limit is coming from; in theory this ought
>>      to be improveable but auditing the code for mishandling of
>>      RAMblock sizes to ensure we weren't accidentally stuffing
>>      their size into a signed 'long' somewhere would be kind
>>      of painful)
> 
> Recalling that the win64 abi model is p64, i.e. 'long' is still 32-bit while 
> pointers are 64-bit, how close do we think we are to this being fixed already?
> 
>> Even if we did fix (2) we'd need to compromise on (3)
>> sometimes still -- if a board has 4GB of RAM that's
>> not going to fit in 32 bits regardless. But we would be
>> able to let boards with 2GB have 2GB.
> 
> I'm not opposed to deprecating 32-bit hosts...  ;-)

I think we should consider this again, indeed. Plain 32-bit CPUs are quite 
seldom these days, aren't they? And I think we urgently need to decrease the 
amount of things that we have to test and maintain in our CI and developer 
branches... So is there still a really really compelling reason to keep 
32-bit host support alive?
Could we maybe also decrease the amount of targets, i.e. merge 
qemu-system-x86_64 and qemu-system-i386, merge qemu-system-ppc64 and 
qemu-system-ppc, etc. where it makes sense (i.e. where one of the binaries 
is a superset of the other)?

  Thomas



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Deprecate 32-bit hosts? (was: Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type)
  2021-09-15  7:42             ` Deprecate 32-bit hosts? (was: Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type) Thomas Huth
@ 2021-09-15  7:54               ` Philippe Mathieu-Daudé
  2021-09-15  8:37               ` Daniel P. Berrangé
  1 sibling, 0 replies; 41+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-09-15  7:54 UTC (permalink / raw)
  To: Thomas Huth, Richard Henderson, Peter Maydell, Joel Stanley
  Cc: Daniel P. Berrange, Samuel Thibault, Andrew Jeffery, qemu-devel,
	qemu-arm, Cédric Le Goater, Peter Delevoryas, Paolo Bonzini

On 9/15/21 9:42 AM, Thomas Huth wrote:
> On 14/09/2021 17.22, Richard Henderson wrote:
>> On 9/14/21 5:26 AM, Peter Maydell wrote:
>>> (2) RAM blocks should have a length that fits inside a
>>>      signed 32-bit type on 32-bit hosts (at least I assume this
>>>      is where the 2047MB limit is coming from; in theory this ought
>>>      to be improveable but auditing the code for mishandling of
>>>      RAMblock sizes to ensure we weren't accidentally stuffing
>>>      their size into a signed 'long' somewhere would be kind
>>>      of painful)
>>
>> Recalling that the win64 abi model is p64, i.e. 'long' is still 32-bit
>> while pointers are 64-bit, how close do we think we are to this being
>> fixed already?
>>
>>> Even if we did fix (2) we'd need to compromise on (3)
>>> sometimes still -- if a board has 4GB of RAM that's
>>> not going to fit in 32 bits regardless. But we would be
>>> able to let boards with 2GB have 2GB.
>>
>> I'm not opposed to deprecating 32-bit hosts...  ;-)
> 
> I think we should consider this again, indeed. Plain 32-bit CPUs are
> quite seldom these days, aren't they? And I think we urgently need to
> decrease the amount of things that we have to test and maintain in our
> CI and developer branches... So is there still a really really
> compelling reason to keep 32-bit host support alive?
> Could we maybe also decrease the amount of targets, i.e. merge
> qemu-system-x86_64 and qemu-system-i386, merge qemu-system-ppc64 and
> qemu-system-ppc, etc. where it makes sense (i.e. where one of the
> binaries is a superset of the other)?

Not directly related, but orthogonal to this, now than Richard got his
memory API series addressing endian issues merged, I'm slowly (in my
free time) trying to unify dual-endian machines. For user-emulation
it is a bit tricker so I'll look at it once sysemu is working. This
won't reduce the testing time, but the build time.


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Deprecate 32-bit hosts? (was: Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type)
  2021-09-15  7:42             ` Deprecate 32-bit hosts? (was: Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type) Thomas Huth
  2021-09-15  7:54               ` Philippe Mathieu-Daudé
@ 2021-09-15  8:37               ` Daniel P. Berrangé
  2021-09-15  8:51                 ` Philippe Mathieu-Daudé
  1 sibling, 1 reply; 41+ messages in thread
From: Daniel P. Berrangé @ 2021-09-15  8:37 UTC (permalink / raw)
  To: Thomas Huth
  Cc: Peter Maydell, Samuel Thibault, Andrew Jeffery,
	Richard Henderson, qemu-devel, qemu-arm, Joel Stanley,
	Peter Delevoryas, Paolo Bonzini, Philippe Mathieu-Daudé,
	Cédric Le Goater

On Wed, Sep 15, 2021 at 09:42:48AM +0200, Thomas Huth wrote:
> On 14/09/2021 17.22, Richard Henderson wrote:
> > On 9/14/21 5:26 AM, Peter Maydell wrote:
> > > (2) RAM blocks should have a length that fits inside a
> > >      signed 32-bit type on 32-bit hosts (at least I assume this
> > >      is where the 2047MB limit is coming from; in theory this ought
> > >      to be improveable but auditing the code for mishandling of
> > >      RAMblock sizes to ensure we weren't accidentally stuffing
> > >      their size into a signed 'long' somewhere would be kind
> > >      of painful)
> > 
> > Recalling that the win64 abi model is p64, i.e. 'long' is still 32-bit
> > while pointers are 64-bit, how close do we think we are to this being
> > fixed already?
> > 
> > > Even if we did fix (2) we'd need to compromise on (3)
> > > sometimes still -- if a board has 4GB of RAM that's
> > > not going to fit in 32 bits regardless. But we would be
> > > able to let boards with 2GB have 2GB.
> > 
> > I'm not opposed to deprecating 32-bit hosts...  ;-)
> 
> I think we should consider this again, indeed. Plain 32-bit CPUs are quite
> seldom these days, aren't they? And I think we urgently need to decrease the
> amount of things that we have to test and maintain in our CI and developer
> branches... So is there still a really really compelling reason to keep
> 32-bit host support alive?

I think it probably depends on the architecture to some extent.

i386 is possibly getting rare enough to consider dropping, though
IIUC, KVM in the kernel still supports it.  Would feel odd to drop
it in QEMU if the kernel still thinks it is popular enough to keep
KVM support.

armv7 feels like it is relatively common as 64-bit didn't arrive
in widespread use until relatively recent times compared to x86_64.
KVM dropped armv7, but then hardware for that was never widespread,
so armv7 was always TCG dominated

Other 32-bit arches were/are always rare.

> Could we maybe also decrease the amount of targets, i.e. merge
> qemu-system-x86_64 and qemu-system-i386, merge qemu-system-ppc64 and
> qemu-system-ppc, etc. where it makes sense (i.e. where one of the binaries
> is a superset of the other)?

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Deprecate 32-bit hosts? (was: Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type)
  2021-09-15  8:37               ` Daniel P. Berrangé
@ 2021-09-15  8:51                 ` Philippe Mathieu-Daudé
  2021-09-15  9:05                   ` Daniel P. Berrangé
  0 siblings, 1 reply; 41+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-09-15  8:51 UTC (permalink / raw)
  To: Daniel P. Berrangé, Thomas Huth
  Cc: Peter Maydell, Samuel Thibault, Andrew Jeffery, Michael Tokarev,
	Richard Henderson, qemu-devel, Richard W.M. Jones, qemu-arm,
	Joel Stanley, Peter Delevoryas, Paolo Bonzini, Stefan Weil,
	Cédric Le Goater

On 9/15/21 10:37 AM, Daniel P. Berrangé wrote:
> On Wed, Sep 15, 2021 at 09:42:48AM +0200, Thomas Huth wrote:
>> On 14/09/2021 17.22, Richard Henderson wrote:
>>> On 9/14/21 5:26 AM, Peter Maydell wrote:
>>>> (2) RAM blocks should have a length that fits inside a
>>>>      signed 32-bit type on 32-bit hosts (at least I assume this
>>>>      is where the 2047MB limit is coming from; in theory this ought
>>>>      to be improveable but auditing the code for mishandling of
>>>>      RAMblock sizes to ensure we weren't accidentally stuffing
>>>>      their size into a signed 'long' somewhere would be kind
>>>>      of painful)
>>>
>>> Recalling that the win64 abi model is p64, i.e. 'long' is still 32-bit
>>> while pointers are 64-bit, how close do we think we are to this being
>>> fixed already?
>>>
>>>> Even if we did fix (2) we'd need to compromise on (3)
>>>> sometimes still -- if a board has 4GB of RAM that's
>>>> not going to fit in 32 bits regardless. But we would be
>>>> able to let boards with 2GB have 2GB.
>>>
>>> I'm not opposed to deprecating 32-bit hosts...  ;-)
>>
>> I think we should consider this again, indeed. Plain 32-bit CPUs are quite
>> seldom these days, aren't they? And I think we urgently need to decrease the
>> amount of things that we have to test and maintain in our CI and developer
>> branches... So is there still a really really compelling reason to keep
>> 32-bit host support alive?
> 
> I think it probably depends on the architecture to some extent.
> 
> i386 is possibly getting rare enough to consider dropping, though
> IIUC, KVM in the kernel still supports it.  Would feel odd to drop
> it in QEMU if the kernel still thinks it is popular enough to keep
> KVM support.
> 
> armv7 feels like it is relatively common as 64-bit didn't arrive
> in widespread use until relatively recent times compared to x86_64.
> KVM dropped armv7, but then hardware for that was never widespread,
> so armv7 was always TCG dominated
> 
> Other 32-bit arches were/are always rare.

While I could understand there are rare uses of system emulation on
32-bit hosts, I still believe user-emulation is used, but would like
to be proven to the contrary. With that in mind, I'm not sure removing
sysemu on 32-bit hosts is worthful. Maybe we should ask distribution
maintainers first, then eventually poll the community? Or start with
a deprecation warning?

>> Could we maybe also decrease the amount of targets, i.e. merge
>> qemu-system-x86_64 and qemu-system-i386, merge qemu-system-ppc64 and
>> qemu-system-ppc, etc. where it makes sense (i.e. where one of the binaries
>> is a superset of the other)?
> 
> Regards,
> Daniel
> 



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: Deprecate 32-bit hosts? (was: Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type)
  2021-09-15  8:51                 ` Philippe Mathieu-Daudé
@ 2021-09-15  9:05                   ` Daniel P. Berrangé
  0 siblings, 0 replies; 41+ messages in thread
From: Daniel P. Berrangé @ 2021-09-15  9:05 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé
  Cc: Peter Maydell, Thomas Huth, Samuel Thibault, Andrew Jeffery,
	Michael Tokarev, Richard Henderson, qemu-devel,
	Richard W.M. Jones, qemu-arm, Joel Stanley, Peter Delevoryas,
	Paolo Bonzini, Stefan Weil, Cédric Le Goater

On Wed, Sep 15, 2021 at 10:51:56AM +0200, Philippe Mathieu-Daudé wrote:
> On 9/15/21 10:37 AM, Daniel P. Berrangé wrote:
> > On Wed, Sep 15, 2021 at 09:42:48AM +0200, Thomas Huth wrote:
> >> On 14/09/2021 17.22, Richard Henderson wrote:
> >>> On 9/14/21 5:26 AM, Peter Maydell wrote:
> >>>> (2) RAM blocks should have a length that fits inside a
> >>>>      signed 32-bit type on 32-bit hosts (at least I assume this
> >>>>      is where the 2047MB limit is coming from; in theory this ought
> >>>>      to be improveable but auditing the code for mishandling of
> >>>>      RAMblock sizes to ensure we weren't accidentally stuffing
> >>>>      their size into a signed 'long' somewhere would be kind
> >>>>      of painful)
> >>>
> >>> Recalling that the win64 abi model is p64, i.e. 'long' is still 32-bit
> >>> while pointers are 64-bit, how close do we think we are to this being
> >>> fixed already?
> >>>
> >>>> Even if we did fix (2) we'd need to compromise on (3)
> >>>> sometimes still -- if a board has 4GB of RAM that's
> >>>> not going to fit in 32 bits regardless. But we would be
> >>>> able to let boards with 2GB have 2GB.
> >>>
> >>> I'm not opposed to deprecating 32-bit hosts...  ;-)
> >>
> >> I think we should consider this again, indeed. Plain 32-bit CPUs are quite
> >> seldom these days, aren't they? And I think we urgently need to decrease the
> >> amount of things that we have to test and maintain in our CI and developer
> >> branches... So is there still a really really compelling reason to keep
> >> 32-bit host support alive?
> > 
> > I think it probably depends on the architecture to some extent.
> > 
> > i386 is possibly getting rare enough to consider dropping, though
> > IIUC, KVM in the kernel still supports it.  Would feel odd to drop
> > it in QEMU if the kernel still thinks it is popular enough to keep
> > KVM support.
> > 
> > armv7 feels like it is relatively common as 64-bit didn't arrive
> > in widespread use until relatively recent times compared to x86_64.
> > KVM dropped armv7, but then hardware for that was never widespread,
> > so armv7 was always TCG dominated
> > 
> > Other 32-bit arches were/are always rare.
> 
> While I could understand there are rare uses of system emulation on
> 32-bit hosts, I still believe user-emulation is used, but would like
> to be proven to the contrary. With that in mind, I'm not sure removing
> sysemu on 32-bit hosts is worthful. Maybe we should ask distribution
> maintainers first, then eventually poll the community? Or start with
> a deprecation warning?

Well Debian still supports arm7, i686, mips officially, and several
more unofficially, so that's an easy answer from that side.

Fedora only has arm7, having dropped i686 a while ago.

I don't have insight into usage of QEMU on any platforms breakdown
though.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type
  2021-09-14 15:22           ` Richard Henderson
  2021-09-15  7:42             ` Deprecate 32-bit hosts? (was: Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type) Thomas Huth
@ 2021-09-16 12:29             ` Cédric Le Goater
  2021-09-16 13:53               ` Philippe Mathieu-Daudé
  1 sibling, 1 reply; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-16 12:29 UTC (permalink / raw)
  To: Richard Henderson, Peter Maydell, Joel Stanley
  Cc: Andrew Jeffery, qemu-arm, qemu-devel, Peter Delevoryas

On 9/14/21 17:22, Richard Henderson wrote:
> On 9/14/21 5:26 AM, Peter Maydell wrote:
>> (2) RAM blocks should have a length that fits inside a
>>      signed 32-bit type on 32-bit hosts (at least I assume this
>>      is where the 2047MB limit is coming from; in theory this ought
>>      to be improveable but auditing the code for mishandling of
>>      RAMblock sizes to ensure we weren't accidentally stuffing
>>      their size into a signed 'long' somewhere would be kind
>>      of painful)
> 
> Recalling that the win64 abi model is p64, i.e. 'long' is still 32-bit while pointers are 64-bit, how close do we think we are to this being fixed already?

I removed the check from softmmu/vl.c and "all" tests on gitlab ran
fine. But, there is still a problem indeed. When running the Fuji
machine with a flash device to boot from  :

     $ gdb --args qemu-system-arm -M fuji-bmc -drive file=./flash-fuji,format=raw,if=mtd
     Thread 1 "qemu-system-arm" received signal SIGTRAP, Trace/breakpoint trap.
     _g_log_abort (breakpoint=1) at ../../../glib/gmessages.c:554
     554	../../../glib/gmessages.c: No such file or directory.
     (gdb) bt
     #0  _g_log_abort (breakpoint=1) at ../../../glib/gmessages.c:554
     #1  0xb7ae351d in g_logv
         (log_domain=0xb7b2d00e "GLib", log_level=G_LOG_LEVEL_ERROR, format=0xb7b36730 "%s: failed to allocate %u bytes", args=0xbfffed8c "\260f\263\267") at ../../../glib/gmessages.c:1373
     #2  0xb7ae36b9 in g_log (log_domain=0xb7b2d00e "GLib", log_level=G_LOG_LEVEL_ERROR, format=0xb7b36730 "%s: failed to allocate %u bytes")
         at ../../../glib/gmessages.c:1415
     #3  0xb7ae1e6a in g_malloc0 (n_bytes=134217728) at ../../../glib/gmem.c:137
     #4  0x006af2b7 in rom_add_blob
         (name=0xd65c67 "aspeed.boot_rom", blob=0xa3fa010, len=134217728, max_len=134217728, addr=0, fw_file_name=0x0, fw_callback=0x0, callback_opaque=0x0, as=0x0, read_only=true) at ../hw/core/loader.c:1068
     #5  0x0084b714 in write_boot_rom (addr=0, errp=<optimized out>, rom_size=134217728, dinfo=0x1766570) at ../hw/arm/aspeed.c:267
     #6  aspeed_machine_init (machine=0xb67c3010) at ../hw/arm/aspeed.c:397
     #7  0x0060e6d9 in machine_run_board_init (machine=<optimized out>) at ../hw/core/machine.c:1276
     #8  0x0099be9b in qemu_init_board () at ../softmmu/vl.c:2618
     ...

The last allocation of the machine (which is the boot ramblock) fails.

However, when using the 'execute-in-place' option of the Aspeed machine
which fetches directly instructions to execute from the flash MMIO region,
the machine boots correctly. No extra allocation for the ramblock.

>> Even if we did fix (2) we'd need to compromise on (3)
>> sometimes still -- if a board has 4GB of RAM that's
>> not going to fit in 32 bits regardless. But we would be
>> able to let boards with 2GB have 2GB.
> 
> I'm not opposed to deprecating 32-bit hosts...  ;-)

Until then, I am willing to make the following compromise for the fuji  :

     mc->default_ram_size = (HOST_LONG_BITS == 32 ? 1 : 2) * GiB;

Thanks,


C.


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type
  2021-09-16 12:29             ` [PULL 14/14] hw/arm/aspeed: Add Fuji machine type Cédric Le Goater
@ 2021-09-16 13:53               ` Philippe Mathieu-Daudé
  2021-09-16 14:06                 ` Cédric Le Goater
  0 siblings, 1 reply; 41+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-09-16 13:53 UTC (permalink / raw)
  To: Cédric Le Goater, Richard Henderson, Peter Maydell, Joel Stanley
  Cc: Andrew Jeffery, qemu-arm, qemu-devel, Peter Delevoryas

On 9/16/21 2:29 PM, Cédric Le Goater wrote:
> On 9/14/21 17:22, Richard Henderson wrote:
>> On 9/14/21 5:26 AM, Peter Maydell wrote:
>>> (2) RAM blocks should have a length that fits inside a
>>>      signed 32-bit type on 32-bit hosts (at least I assume this
>>>      is where the 2047MB limit is coming from; in theory this ought
>>>      to be improveable but auditing the code for mishandling of
>>>      RAMblock sizes to ensure we weren't accidentally stuffing
>>>      their size into a signed 'long' somewhere would be kind
>>>      of painful)

>>> Even if we did fix (2) we'd need to compromise on (3)
>>> sometimes still -- if a board has 4GB of RAM that's
>>> not going to fit in 32 bits regardless. But we would be
>>> able to let boards with 2GB have 2GB.
>>
>> I'm not opposed to deprecating 32-bit hosts...  ;-)
> 
> Until then, I am willing to make the following compromise for the fuji  :
> 
>     mc->default_ram_size = (HOST_LONG_BITS == 32 ? 1 : 2) * GiB;

While I disagree with this approach, better to document it clearly
like commit 25ff112a8cc ("hw/arm/mps2-tz: Add new mps3-an524 board").


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type
  2021-09-16 13:53               ` Philippe Mathieu-Daudé
@ 2021-09-16 14:06                 ` Cédric Le Goater
  2021-09-16 14:07                   ` Peter Maydell
  0 siblings, 1 reply; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-16 14:06 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé,
	Richard Henderson, Peter Maydell, Joel Stanley
  Cc: Andrew Jeffery, qemu-arm, qemu-devel, Peter Delevoryas

On 9/16/21 15:53, Philippe Mathieu-Daudé wrote:
> On 9/16/21 2:29 PM, Cédric Le Goater wrote:
>> On 9/14/21 17:22, Richard Henderson wrote:
>>> On 9/14/21 5:26 AM, Peter Maydell wrote:
>>>> (2) RAM blocks should have a length that fits inside a
>>>>       signed 32-bit type on 32-bit hosts (at least I assume this
>>>>       is where the 2047MB limit is coming from; in theory this ought
>>>>       to be improveable but auditing the code for mishandling of
>>>>       RAMblock sizes to ensure we weren't accidentally stuffing
>>>>       their size into a signed 'long' somewhere would be kind
>>>>       of painful)
> 
>>>> Even if we did fix (2) we'd need to compromise on (3)
>>>> sometimes still -- if a board has 4GB of RAM that's
>>>> not going to fit in 32 bits regardless. But we would be
>>>> able to let boards with 2GB have 2GB.
>>>
>>> I'm not opposed to deprecating 32-bit hosts...  ;-)
>>
>> Until then, I am willing to make the following compromise for the fuji  :
>>
>>      mc->default_ram_size = (HOST_LONG_BITS == 32 ? 1 : 2) * GiB;
> 
> While I disagree with this approach, better to document it clearly
> like commit 25ff112a8cc ("hw/arm/mps2-tz: Add new mps3-an524 board").
> 

OK. The patch I had prepared was a bit more explicit :

     /* On 32-bit hosts, lower RAM to 1G because of 2047 MB limit */
     mc->default_ram_size = (HOST_LONG_BITS == 32 ? 1 : 2) * GiB;

I even have a version with a warn_report() since 32-bit hosts are
not that common these days. But let's adopt the mps3-an524 board
approach.

Thanks,

C.


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type
  2021-09-16 14:06                 ` Cédric Le Goater
@ 2021-09-16 14:07                   ` Peter Maydell
  0 siblings, 0 replies; 41+ messages in thread
From: Peter Maydell @ 2021-09-16 14:07 UTC (permalink / raw)
  To: Cédric Le Goater
  Cc: Andrew Jeffery, Richard Henderson, qemu-devel,
	Philippe Mathieu-Daudé,
	qemu-arm, Joel Stanley, Peter Delevoryas

On Thu, 16 Sept 2021 at 15:06, Cédric Le Goater <clg@kaod.org> wrote:
> OK. The patch I had prepared was a bit more explicit :
>
>      /* On 32-bit hosts, lower RAM to 1G because of 2047 MB limit */
>      mc->default_ram_size = (HOST_LONG_BITS == 32 ? 1 : 2) * GiB;
>
> I even have a version with a warn_report() since 32-bit hosts are
> not that common these days.

Using warn_report is likely to get the patch bounced because
it adds a new warning to the 'make check' output on 32-bit hosts,
unless you take special care to suppress it when running in qtest...

-- PMM


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PULL 00/14] aspeed queue
  2021-09-20  8:09 Cédric Le Goater
@ 2021-09-21 14:07 ` Peter Maydell
  0 siblings, 0 replies; 41+ messages in thread
From: Peter Maydell @ 2021-09-21 14:07 UTC (permalink / raw)
  To: Cédric Le Goater
  Cc: Andrew Jeffery, qemu-arm, Joel Stanley, QEMU Developers

On Mon, 20 Sept 2021 at 09:09, Cédric Le Goater <clg@kaod.org> wrote:
>
> The following changes since commit c99e34e537f13a431a80e3e414e5904e9dd0a116:
>
>   Merge remote-tracking branch 'remotes/vivier2/tags/linux-user-for-6.2-pull-request' into staging (2021-09-16 21:09:18 +0100)
>
> are available in the Git repository at:
>
>   https://github.com/legoater/qemu/ tags/pull-aspeed-20210920
>
> for you to fetch changes up to febbe308bf9477767ca92e8ed5f265b0001fcef9:
>
>   hw/arm/aspeed: Add Fuji machine type (2021-09-20 08:50:59 +0200)
>
> ----------------------------------------------------------------
> Aspeed patches :
>
> * MAC enablement fixes (Guenter)
> * Watchdog  and pca9552 fixes (Andrew)
> * GPIO fixes (Joel)
> * AST2600A3 SoC and DPS310 models (Joel)
> * New Fuji BMC machine (Peter)
>


Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/6.2
for any user-visible changes.

-- PMM


^ permalink raw reply	[flat|nested] 41+ messages in thread

* [PULL 00/14] aspeed queue
@ 2021-09-20  8:09 Cédric Le Goater
  2021-09-21 14:07 ` Peter Maydell
  0 siblings, 1 reply; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-20  8:09 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Andrew Jeffery, Cédric Le Goater, qemu-arm, Joel Stanley,
	qemu-devel

The following changes since commit c99e34e537f13a431a80e3e414e5904e9dd0a116:

  Merge remote-tracking branch 'remotes/vivier2/tags/linux-user-for-6.2-pull-request' into staging (2021-09-16 21:09:18 +0100)

are available in the Git repository at:

  https://github.com/legoater/qemu/ tags/pull-aspeed-20210920

for you to fetch changes up to febbe308bf9477767ca92e8ed5f265b0001fcef9:

  hw/arm/aspeed: Add Fuji machine type (2021-09-20 08:50:59 +0200)

----------------------------------------------------------------
Aspeed patches :

* MAC enablement fixes (Guenter)
* Watchdog  and pca9552 fixes (Andrew)
* GPIO fixes (Joel)
* AST2600A3 SoC and DPS310 models (Joel)
* New Fuji BMC machine (Peter)

----------------------------------------------------------------
Andrew Jeffery (3):
      watchdog: aspeed: Sanitize control register values
      watchdog: aspeed: Fix sequential control writes
      misc/pca9552: Fix LED status register indexing in pca955x_get_led()

Guenter Roeck (2):
      hw: arm: aspeed: Enable eth0 interface for aspeed-ast2600-evb
      hw: arm: aspeed: Enable mac0/1 instead of mac1/2 for g220a

Joel Stanley (6):
      hw: aspeed_gpio: Simplify 1.8V defines
      hw: aspeed_gpio: Clarify GPIO controller name
      arm/aspeed: rainier: Add i2c eeproms and muxes
      aspeed: Emulate the AST2600A3
      hw/misc: Add Infineon DPS310 sensor model
      arm/aspeed: Add DPS310 to Witherspoon and Rainier

Peter Delevoryas (3):
      hw/arm/aspeed: Initialize AST2600 UART clock selection registers
      hw/arm/aspeed: Allow machine to set UART default
      hw/arm/aspeed: Add Fuji machine type

 include/hw/arm/aspeed.h          |   1 +
 include/hw/arm/aspeed_soc.h      |   1 +
 include/hw/misc/aspeed_scu.h     |   2 +
 include/hw/watchdog/wdt_aspeed.h |   1 +
 hw/arm/aspeed.c                  | 182 +++++++++++++++++++++++++++++--
 hw/arm/aspeed_ast2600.c          |  14 +--
 hw/arm/aspeed_soc.c              |   8 +-
 hw/gpio/aspeed_gpio.c            |  97 +++++++++--------
 hw/misc/aspeed_scu.c             |  40 +++++--
 hw/misc/pca9552.c                |   2 +-
 hw/sensor/dps310.c               | 225 +++++++++++++++++++++++++++++++++++++++
 hw/watchdog/wdt_aspeed.c         |  26 ++++-
 hw/arm/Kconfig                   |   1 +
 hw/sensor/Kconfig                |   4 +
 hw/sensor/meson.build            |   1 +
 15 files changed, 529 insertions(+), 76 deletions(-)
 create mode 100644 hw/sensor/dps310.c


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PULL 00/14] aspeed queue
  2021-09-05 14:34         ` Peter Delevoryas
@ 2021-09-05 14:43           ` Cédric Le Goater
  0 siblings, 0 replies; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-05 14:43 UTC (permalink / raw)
  To: Peter Delevoryas
  Cc: Peter Maydell, Andrew Jeffery, qemu-devel,
	Philippe Mathieu-Daudé,
	qemu-arm, Joel Stanley

On 9/5/21 4:34 PM, Peter Delevoryas wrote:
> 
> 
>> On Sep 5, 2021, at 1:51 AM, Cédric Le Goater <clg@kaod.org> wrote:
>>
>> On 9/5/21 1:03 AM, Philippe Mathieu-Daudé wrote:
>>>> On 9/4/21 7:33 AM, Cédric Le Goater wrote:
>>>> On 9/3/21 10:41 PM, Philippe Mathieu-Daudé wrote:
>>>>> Hi Peter,
>>>>>
>>>>> On 9/3/21 9:40 PM, Cédric Le Goater wrote:
>>>>>> The following changes since commit 8880cc4362fde4ecdac0b2092318893118206fcf:
>>>>>>
>>>>>>  Merge remote-tracking branch 'remotes/cschoenebeck/tags/pull-9p-20210902' into staging (2021-09-03 08:27:38 +0100)
>>>>>>
>>>>>> are available in the Git repository at:
>>>>>>
>>>>>>  https://github.com/legoater/qemu/ tags/pull-aspeed-20210903
>>>>>>
>>>>>> for you to fetch changes up to 907796622b2a6b945c87641d94e254ac898b96ae:
>>>>>>
>>>>>>  hw/arm/aspeed: Add Fuji machine type (2021-09-03 18:43:16 +0200)
>>>>>>
>>>>>> ----------------------------------------------------------------
>>>>>> Aspeed patches :
>>>>>>
>>>>>> * MAC enablement fixes (Guenter)
>>>>>> * Watchdog  and pca9552 fixes (Andrew)
>>>>>> * GPIO fixes (Joel)
>>>>>> * AST2600A3 SoC and DPS310 models (Joel)
>>>>>> * New Fuji BMC machine (Peter)
>>>>>>
>>>>>> ----------------------------------------------------------------
>>>>>
>>>>>> Peter Delevoryas (3):
>>>>>>      hw/arm/aspeed: Initialize AST2600 UART clock selection registers
>>>>>>      hw/arm/aspeed: Allow machine to set UART default
>>>>>>      hw/arm/aspeed: Add Fuji machine type
>>>>>
>>>>> I have a pending question with the last patch, do you mind holding
>>>>> this PR until it is resolved with Cédric and the patch author please?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Phil.
>>>>>
>>>>
>>>> I guess we can drop the following from the commit log : 
>>>>
>>>>    git clone https://github.com/facebook/openbmc
>>>>    cd openbmc
>>>>    ./sync_yocto.sh
>>>>    source openbmc-init-build-env fuji build-fuji
>>>>    bitbake fuji-image
>>>>    dd if=/dev/zero of=/tmp/fuji.mtd bs=1M count=128
>>>>    dd if=./tmp/deploy/images/fuji/flash-fuji of=/tmp/fuji.mtd \
>>>>        bs=1k conv=notrunc
>>>>    
>>>>    git clone --branch aspeed-next https://github.com/peterdelevoryas/qemu
>>>>    cd qemu
>>>>    ./configure --target-list=arm-softmmu --disable-vnc
>>>>    make -j $(nproc)
>>>>    ./build/arm-softmmu/qemu-system-arm \
>>>>        -machine fuji-bmc \
>>>>        -drive file=/tmp/fuji.mtd,format=raw,if=mtd \
>>>>        -serial stdio \
>>>>        -nic user,hostfwd=::2222-:22
>>>>    sshpass -p 0penBmc ssh root@localhost -p 2222
>>>
>>> Sounds good. Eventually document that in docs/system/arm/aspeed.rst
>>> in a follow up patch?
>>>
>>> Regards,
>>>
>>> Phil.
>>>
>>
>>
>> Peter D, 
>>
>> Could you please resend the "hw/arm/aspeed: Add Fuji machine type"
>> patch addressing Phil's comment. I will resend a PR with the 
>> update.
>>
>> Thanks,
>>
>> C. 
>>
>>
> 
> Oh! Yes, I can do that, sorry, I wasn’t sure if it was necessary to resend or if it could be fixed inline or something. I’ll send that within the next 24 hrs, removing the selected text from the commit description.

I didn't either. 

Thanks, 

C.


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PULL 00/14] aspeed queue
  2021-09-05  8:51       ` Cédric Le Goater
@ 2021-09-05 14:34         ` Peter Delevoryas
  2021-09-05 14:43           ` Cédric Le Goater
  0 siblings, 1 reply; 41+ messages in thread
From: Peter Delevoryas @ 2021-09-05 14:34 UTC (permalink / raw)
  To: Cédric Le Goater
  Cc: Philippe Mathieu-Daudé,
	Peter Maydell, Andrew Jeffery, qemu-arm, Joel Stanley,
	qemu-devel



> On Sep 5, 2021, at 1:51 AM, Cédric Le Goater <clg@kaod.org> wrote:
> 
> On 9/5/21 1:03 AM, Philippe Mathieu-Daudé wrote:
>>> On 9/4/21 7:33 AM, Cédric Le Goater wrote:
>>> On 9/3/21 10:41 PM, Philippe Mathieu-Daudé wrote:
>>>> Hi Peter,
>>>> 
>>>> On 9/3/21 9:40 PM, Cédric Le Goater wrote:
>>>>> The following changes since commit 8880cc4362fde4ecdac0b2092318893118206fcf:
>>>>> 
>>>>>  Merge remote-tracking branch 'remotes/cschoenebeck/tags/pull-9p-20210902' into staging (2021-09-03 08:27:38 +0100)
>>>>> 
>>>>> are available in the Git repository at:
>>>>> 
>>>>>  https://github.com/legoater/qemu/ tags/pull-aspeed-20210903
>>>>> 
>>>>> for you to fetch changes up to 907796622b2a6b945c87641d94e254ac898b96ae:
>>>>> 
>>>>>  hw/arm/aspeed: Add Fuji machine type (2021-09-03 18:43:16 +0200)
>>>>> 
>>>>> ----------------------------------------------------------------
>>>>> Aspeed patches :
>>>>> 
>>>>> * MAC enablement fixes (Guenter)
>>>>> * Watchdog  and pca9552 fixes (Andrew)
>>>>> * GPIO fixes (Joel)
>>>>> * AST2600A3 SoC and DPS310 models (Joel)
>>>>> * New Fuji BMC machine (Peter)
>>>>> 
>>>>> ----------------------------------------------------------------
>>>> 
>>>>> Peter Delevoryas (3):
>>>>>      hw/arm/aspeed: Initialize AST2600 UART clock selection registers
>>>>>      hw/arm/aspeed: Allow machine to set UART default
>>>>>      hw/arm/aspeed: Add Fuji machine type
>>>> 
>>>> I have a pending question with the last patch, do you mind holding
>>>> this PR until it is resolved with Cédric and the patch author please?
>>>> 
>>>> Thanks,
>>>> 
>>>> Phil.
>>>> 
>>> 
>>> I guess we can drop the following from the commit log : 
>>> 
>>>    git clone https://github.com/facebook/openbmc
>>>    cd openbmc
>>>    ./sync_yocto.sh
>>>    source openbmc-init-build-env fuji build-fuji
>>>    bitbake fuji-image
>>>    dd if=/dev/zero of=/tmp/fuji.mtd bs=1M count=128
>>>    dd if=./tmp/deploy/images/fuji/flash-fuji of=/tmp/fuji.mtd \
>>>        bs=1k conv=notrunc
>>>    
>>>    git clone --branch aspeed-next https://github.com/peterdelevoryas/qemu
>>>    cd qemu
>>>    ./configure --target-list=arm-softmmu --disable-vnc
>>>    make -j $(nproc)
>>>    ./build/arm-softmmu/qemu-system-arm \
>>>        -machine fuji-bmc \
>>>        -drive file=/tmp/fuji.mtd,format=raw,if=mtd \
>>>        -serial stdio \
>>>        -nic user,hostfwd=::2222-:22
>>>    sshpass -p 0penBmc ssh root@localhost -p 2222
>> 
>> Sounds good. Eventually document that in docs/system/arm/aspeed.rst
>> in a follow up patch?
>> 
>> Regards,
>> 
>> Phil.
>> 
> 
> 
> Peter D, 
> 
> Could you please resend the "hw/arm/aspeed: Add Fuji machine type"
> patch addressing Phil's comment. I will resend a PR with the 
> update.
> 
> Thanks,
> 
> C. 
> 
> 

Oh! Yes, I can do that, sorry, I wasn’t sure if it was necessary to resend or if it could be fixed inline or something. I’ll send that within the next 24 hrs, removing the selected text from the commit description.

Thanks,
Peter

> 
> 
> 

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PULL 00/14] aspeed queue
  2021-09-04 23:03     ` Philippe Mathieu-Daudé
@ 2021-09-05  8:51       ` Cédric Le Goater
  2021-09-05 14:34         ` Peter Delevoryas
  0 siblings, 1 reply; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-05  8:51 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé, Peter Maydell
  Cc: Andrew Jeffery, qemu-devel, qemu-arm, Joel Stanley, Peter Delevoryas

On 9/5/21 1:03 AM, Philippe Mathieu-Daudé wrote:
> On 9/4/21 7:33 AM, Cédric Le Goater wrote:
>> On 9/3/21 10:41 PM, Philippe Mathieu-Daudé wrote:
>>> Hi Peter,
>>>
>>> On 9/3/21 9:40 PM, Cédric Le Goater wrote:
>>>> The following changes since commit 8880cc4362fde4ecdac0b2092318893118206fcf:
>>>>
>>>>   Merge remote-tracking branch 'remotes/cschoenebeck/tags/pull-9p-20210902' into staging (2021-09-03 08:27:38 +0100)
>>>>
>>>> are available in the Git repository at:
>>>>
>>>>   https://github.com/legoater/qemu/ tags/pull-aspeed-20210903
>>>>
>>>> for you to fetch changes up to 907796622b2a6b945c87641d94e254ac898b96ae:
>>>>
>>>>   hw/arm/aspeed: Add Fuji machine type (2021-09-03 18:43:16 +0200)
>>>>
>>>> ----------------------------------------------------------------
>>>> Aspeed patches :
>>>>
>>>> * MAC enablement fixes (Guenter)
>>>> * Watchdog  and pca9552 fixes (Andrew)
>>>> * GPIO fixes (Joel)
>>>> * AST2600A3 SoC and DPS310 models (Joel)
>>>> * New Fuji BMC machine (Peter)
>>>>
>>>> ----------------------------------------------------------------
>>>
>>>> Peter Delevoryas (3):
>>>>       hw/arm/aspeed: Initialize AST2600 UART clock selection registers
>>>>       hw/arm/aspeed: Allow machine to set UART default
>>>>       hw/arm/aspeed: Add Fuji machine type
>>>
>>> I have a pending question with the last patch, do you mind holding
>>> this PR until it is resolved with Cédric and the patch author please?
>>>
>>> Thanks,
>>>
>>> Phil.
>>>
>>
>> I guess we can drop the following from the commit log : 
>>
>> 	git clone https://github.com/facebook/openbmc
>> 	cd openbmc
>> 	./sync_yocto.sh
>> 	source openbmc-init-build-env fuji build-fuji
>> 	bitbake fuji-image
>> 	dd if=/dev/zero of=/tmp/fuji.mtd bs=1M count=128
>> 	dd if=./tmp/deploy/images/fuji/flash-fuji of=/tmp/fuji.mtd \
>> 	    bs=1k conv=notrunc
>> 	
>> 	git clone --branch aspeed-next https://github.com/peterdelevoryas/qemu
>> 	cd qemu
>> 	./configure --target-list=arm-softmmu --disable-vnc
>> 	make -j $(nproc)
>> 	./build/arm-softmmu/qemu-system-arm \
>> 	    -machine fuji-bmc \
>> 	    -drive file=/tmp/fuji.mtd,format=raw,if=mtd \
>> 	    -serial stdio \
>> 	    -nic user,hostfwd=::2222-:22
>> 	sshpass -p 0penBmc ssh root@localhost -p 2222
> 
> Sounds good. Eventually document that in docs/system/arm/aspeed.rst
> in a follow up patch?
> 
> Regards,
> 
> Phil.
> 


Peter D, 

Could you please resend the "hw/arm/aspeed: Add Fuji machine type"
patch addressing Phil's comment. I will resend a PR with the 
update.

Thanks,

C. 







^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PULL 00/14] aspeed queue
  2021-09-04  5:33   ` Cédric Le Goater
@ 2021-09-04 23:03     ` Philippe Mathieu-Daudé
  2021-09-05  8:51       ` Cédric Le Goater
  0 siblings, 1 reply; 41+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-09-04 23:03 UTC (permalink / raw)
  To: Cédric Le Goater, Peter Maydell
  Cc: Andrew Jeffery, qemu-devel, qemu-arm, Joel Stanley, Peter Delevoryas

On 9/4/21 7:33 AM, Cédric Le Goater wrote:
> On 9/3/21 10:41 PM, Philippe Mathieu-Daudé wrote:
>> Hi Peter,
>>
>> On 9/3/21 9:40 PM, Cédric Le Goater wrote:
>>> The following changes since commit 8880cc4362fde4ecdac0b2092318893118206fcf:
>>>
>>>   Merge remote-tracking branch 'remotes/cschoenebeck/tags/pull-9p-20210902' into staging (2021-09-03 08:27:38 +0100)
>>>
>>> are available in the Git repository at:
>>>
>>>   https://github.com/legoater/qemu/ tags/pull-aspeed-20210903
>>>
>>> for you to fetch changes up to 907796622b2a6b945c87641d94e254ac898b96ae:
>>>
>>>   hw/arm/aspeed: Add Fuji machine type (2021-09-03 18:43:16 +0200)
>>>
>>> ----------------------------------------------------------------
>>> Aspeed patches :
>>>
>>> * MAC enablement fixes (Guenter)
>>> * Watchdog  and pca9552 fixes (Andrew)
>>> * GPIO fixes (Joel)
>>> * AST2600A3 SoC and DPS310 models (Joel)
>>> * New Fuji BMC machine (Peter)
>>>
>>> ----------------------------------------------------------------
>>
>>> Peter Delevoryas (3):
>>>       hw/arm/aspeed: Initialize AST2600 UART clock selection registers
>>>       hw/arm/aspeed: Allow machine to set UART default
>>>       hw/arm/aspeed: Add Fuji machine type
>>
>> I have a pending question with the last patch, do you mind holding
>> this PR until it is resolved with Cédric and the patch author please?
>>
>> Thanks,
>>
>> Phil.
>>
> 
> I guess we can drop the following from the commit log : 
> 
> 	git clone https://github.com/facebook/openbmc
> 	cd openbmc
> 	./sync_yocto.sh
> 	source openbmc-init-build-env fuji build-fuji
> 	bitbake fuji-image
> 	dd if=/dev/zero of=/tmp/fuji.mtd bs=1M count=128
> 	dd if=./tmp/deploy/images/fuji/flash-fuji of=/tmp/fuji.mtd \
> 	    bs=1k conv=notrunc
> 	
> 	git clone --branch aspeed-next https://github.com/peterdelevoryas/qemu
> 	cd qemu
> 	./configure --target-list=arm-softmmu --disable-vnc
> 	make -j $(nproc)
> 	./build/arm-softmmu/qemu-system-arm \
> 	    -machine fuji-bmc \
> 	    -drive file=/tmp/fuji.mtd,format=raw,if=mtd \
> 	    -serial stdio \
> 	    -nic user,hostfwd=::2222-:22
> 	sshpass -p 0penBmc ssh root@localhost -p 2222

Sounds good. Eventually document that in docs/system/arm/aspeed.rst
in a follow up patch?

Regards,

Phil.


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PULL 00/14] aspeed queue
  2021-09-03 20:41 ` Philippe Mathieu-Daudé
@ 2021-09-04  5:33   ` Cédric Le Goater
  2021-09-04 23:03     ` Philippe Mathieu-Daudé
  0 siblings, 1 reply; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-04  5:33 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé, Peter Maydell
  Cc: Andrew Jeffery, qemu-arm, Joel Stanley, Peter Delevoryas, qemu-devel

On 9/3/21 10:41 PM, Philippe Mathieu-Daudé wrote:
> Hi Peter,
> 
> On 9/3/21 9:40 PM, Cédric Le Goater wrote:
>> The following changes since commit 8880cc4362fde4ecdac0b2092318893118206fcf:
>>
>>   Merge remote-tracking branch 'remotes/cschoenebeck/tags/pull-9p-20210902' into staging (2021-09-03 08:27:38 +0100)
>>
>> are available in the Git repository at:
>>
>>   https://github.com/legoater/qemu/ tags/pull-aspeed-20210903
>>
>> for you to fetch changes up to 907796622b2a6b945c87641d94e254ac898b96ae:
>>
>>   hw/arm/aspeed: Add Fuji machine type (2021-09-03 18:43:16 +0200)
>>
>> ----------------------------------------------------------------
>> Aspeed patches :
>>
>> * MAC enablement fixes (Guenter)
>> * Watchdog  and pca9552 fixes (Andrew)
>> * GPIO fixes (Joel)
>> * AST2600A3 SoC and DPS310 models (Joel)
>> * New Fuji BMC machine (Peter)
>>
>> ----------------------------------------------------------------
> 
>> Peter Delevoryas (3):
>>       hw/arm/aspeed: Initialize AST2600 UART clock selection registers
>>       hw/arm/aspeed: Allow machine to set UART default
>>       hw/arm/aspeed: Add Fuji machine type
> 
> I have a pending question with the last patch, do you mind holding
> this PR until it is resolved with Cédric and the patch author please?
> 
> Thanks,
> 
> Phil.
> 

I guess we can drop the following from the commit log : 

	git clone https://github.com/facebook/openbmc
	cd openbmc
	./sync_yocto.sh
	source openbmc-init-build-env fuji build-fuji
	bitbake fuji-image
	dd if=/dev/zero of=/tmp/fuji.mtd bs=1M count=128
	dd if=./tmp/deploy/images/fuji/flash-fuji of=/tmp/fuji.mtd \
	    bs=1k conv=notrunc
	
	git clone --branch aspeed-next https://github.com/peterdelevoryas/qemu
	cd qemu
	./configure --target-list=arm-softmmu --disable-vnc
	make -j $(nproc)
	./build/arm-softmmu/qemu-system-arm \
	    -machine fuji-bmc \
	    -drive file=/tmp/fuji.mtd,format=raw,if=mtd \
	    -serial stdio \
	    -nic user,hostfwd=::2222-:22
	sshpass -p 0penBmc ssh root@localhost -p 2222


Thanks,

C.


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PULL 00/14] aspeed queue
  2021-09-03 19:40 Cédric Le Goater
@ 2021-09-03 20:41 ` Philippe Mathieu-Daudé
  2021-09-04  5:33   ` Cédric Le Goater
  0 siblings, 1 reply; 41+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-09-03 20:41 UTC (permalink / raw)
  To: Cédric Le Goater, Peter Maydell
  Cc: Andrew Jeffery, qemu-arm, Joel Stanley, Peter Delevoryas, qemu-devel

Hi Peter,

On 9/3/21 9:40 PM, Cédric Le Goater wrote:
> The following changes since commit 8880cc4362fde4ecdac0b2092318893118206fcf:
> 
>   Merge remote-tracking branch 'remotes/cschoenebeck/tags/pull-9p-20210902' into staging (2021-09-03 08:27:38 +0100)
> 
> are available in the Git repository at:
> 
>   https://github.com/legoater/qemu/ tags/pull-aspeed-20210903
> 
> for you to fetch changes up to 907796622b2a6b945c87641d94e254ac898b96ae:
> 
>   hw/arm/aspeed: Add Fuji machine type (2021-09-03 18:43:16 +0200)
> 
> ----------------------------------------------------------------
> Aspeed patches :
> 
> * MAC enablement fixes (Guenter)
> * Watchdog  and pca9552 fixes (Andrew)
> * GPIO fixes (Joel)
> * AST2600A3 SoC and DPS310 models (Joel)
> * New Fuji BMC machine (Peter)
> 
> ----------------------------------------------------------------

> Peter Delevoryas (3):
>       hw/arm/aspeed: Initialize AST2600 UART clock selection registers
>       hw/arm/aspeed: Allow machine to set UART default
>       hw/arm/aspeed: Add Fuji machine type

I have a pending question with the last patch, do you mind holding
this PR until it is resolved with Cédric and the patch author please?

Thanks,

Phil.


^ permalink raw reply	[flat|nested] 41+ messages in thread

* [PULL 00/14] aspeed queue
@ 2021-09-03 19:40 Cédric Le Goater
  2021-09-03 20:41 ` Philippe Mathieu-Daudé
  0 siblings, 1 reply; 41+ messages in thread
From: Cédric Le Goater @ 2021-09-03 19:40 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Andrew Jeffery, Cédric Le Goater, qemu-arm, Joel Stanley,
	qemu-devel

The following changes since commit 8880cc4362fde4ecdac0b2092318893118206fcf:

  Merge remote-tracking branch 'remotes/cschoenebeck/tags/pull-9p-20210902' into staging (2021-09-03 08:27:38 +0100)

are available in the Git repository at:

  https://github.com/legoater/qemu/ tags/pull-aspeed-20210903

for you to fetch changes up to 907796622b2a6b945c87641d94e254ac898b96ae:

  hw/arm/aspeed: Add Fuji machine type (2021-09-03 18:43:16 +0200)

----------------------------------------------------------------
Aspeed patches :

* MAC enablement fixes (Guenter)
* Watchdog  and pca9552 fixes (Andrew)
* GPIO fixes (Joel)
* AST2600A3 SoC and DPS310 models (Joel)
* New Fuji BMC machine (Peter)

----------------------------------------------------------------
Andrew Jeffery (3):
      watchdog: aspeed: Sanitize control register values
      watchdog: aspeed: Fix sequential control writes
      misc/pca9552: Fix LED status register indexing in pca955x_get_led()

Guenter Roeck (2):
      hw: arm: aspeed: Enable eth0 interface for aspeed-ast2600-evb
      hw: arm: aspeed: Enable mac0/1 instead of mac1/2 for g220a

Joel Stanley (6):
      hw: aspeed_gpio: Simplify 1.8V defines
      hw: aspeed_gpio: Clarify GPIO controller name
      arm/aspeed: rainier: Add i2c eeproms and muxes
      aspeed: Emulate the AST2600A3
      hw/misc: Add Infineon DPS310 sensor model
      arm/aspeed: Add DPS310 to Witherspoon and Rainier

Peter Delevoryas (3):
      hw/arm/aspeed: Initialize AST2600 UART clock selection registers
      hw/arm/aspeed: Allow machine to set UART default
      hw/arm/aspeed: Add Fuji machine type

 include/hw/arm/aspeed.h          |   1 +
 include/hw/arm/aspeed_soc.h      |   1 +
 include/hw/misc/aspeed_scu.h     |   2 +
 include/hw/watchdog/wdt_aspeed.h |   1 +
 hw/arm/aspeed.c                  | 178 +++++++++++++++++++++++++++++--
 hw/arm/aspeed_ast2600.c          |  14 +--
 hw/arm/aspeed_soc.c              |   8 +-
 hw/gpio/aspeed_gpio.c            |  97 +++++++++--------
 hw/misc/aspeed_scu.c             |  40 +++++--
 hw/misc/pca9552.c                |   2 +-
 hw/sensor/dps310.c               | 225 +++++++++++++++++++++++++++++++++++++++
 hw/watchdog/wdt_aspeed.c         |  26 ++++-
 hw/arm/Kconfig                   |   1 +
 hw/sensor/Kconfig                |   4 +
 hw/sensor/meson.build            |   1 +
 15 files changed, 525 insertions(+), 76 deletions(-)
 create mode 100644 hw/sensor/dps310.c


^ permalink raw reply	[flat|nested] 41+ messages in thread

end of thread, other threads:[~2021-09-21 14:10 UTC | newest]

Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-13 16:12 [PULL 00/14] aspeed queue Cédric Le Goater
2021-09-13 16:12 ` [PULL 01/14] hw: arm: aspeed: Enable eth0 interface for aspeed-ast2600-evb Cédric Le Goater
2021-09-13 16:12 ` [PULL 02/14] hw: arm: aspeed: Enable mac0/1 instead of mac1/2 for g220a Cédric Le Goater
2021-09-13 16:12 ` [PULL 03/14] watchdog: aspeed: Sanitize control register values Cédric Le Goater
2021-09-13 16:12 ` [PULL 04/14] watchdog: aspeed: Fix sequential control writes Cédric Le Goater
2021-09-13 16:12 ` [PULL 05/14] hw: aspeed_gpio: Simplify 1.8V defines Cédric Le Goater
2021-09-13 16:12 ` [PULL 06/14] hw: aspeed_gpio: Clarify GPIO controller name Cédric Le Goater
2021-09-13 16:12 ` [PULL 07/14] misc/pca9552: Fix LED status register indexing in pca955x_get_led() Cédric Le Goater
2021-09-13 16:12 ` [PULL 08/14] arm/aspeed: rainier: Add i2c eeproms and muxes Cédric Le Goater
2021-09-13 16:12 ` [PULL 09/14] aspeed: Emulate the AST2600A3 Cédric Le Goater
2021-09-13 16:13 ` [PULL 10/14] hw/misc: Add Infineon DPS310 sensor model Cédric Le Goater
2021-09-13 16:13 ` [PULL 11/14] arm/aspeed: Add DPS310 to Witherspoon and Rainier Cédric Le Goater
2021-09-13 16:13 ` [PULL 12/14] hw/arm/aspeed: Initialize AST2600 UART clock selection registers Cédric Le Goater
2021-09-13 16:13 ` [PULL 13/14] hw/arm/aspeed: Allow machine to set UART default Cédric Le Goater
2021-09-13 16:13 ` [PULL 14/14] hw/arm/aspeed: Add Fuji machine type Cédric Le Goater
2021-09-14 10:56   ` Cédric Le Goater
2021-09-14 11:59     ` Peter Delevoryas
2021-09-14 12:14       ` Joel Stanley
2021-09-14 12:26         ` Peter Maydell
2021-09-14 15:22           ` Richard Henderson
2021-09-15  7:42             ` Deprecate 32-bit hosts? (was: Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type) Thomas Huth
2021-09-15  7:54               ` Philippe Mathieu-Daudé
2021-09-15  8:37               ` Daniel P. Berrangé
2021-09-15  8:51                 ` Philippe Mathieu-Daudé
2021-09-15  9:05                   ` Daniel P. Berrangé
2021-09-16 12:29             ` [PULL 14/14] hw/arm/aspeed: Add Fuji machine type Cédric Le Goater
2021-09-16 13:53               ` Philippe Mathieu-Daudé
2021-09-16 14:06                 ` Cédric Le Goater
2021-09-16 14:07                   ` Peter Maydell
2021-09-14 10:51 ` [PULL 00/14] aspeed queue Peter Maydell
2021-09-14 10:58   ` Cédric Le Goater
2021-09-14 11:38     ` Philippe Mathieu-Daudé
  -- strict thread matches above, loose matches on Subject: below --
2021-09-20  8:09 Cédric Le Goater
2021-09-21 14:07 ` Peter Maydell
2021-09-03 19:40 Cédric Le Goater
2021-09-03 20:41 ` Philippe Mathieu-Daudé
2021-09-04  5:33   ` Cédric Le Goater
2021-09-04 23:03     ` Philippe Mathieu-Daudé
2021-09-05  8:51       ` Cédric Le Goater
2021-09-05 14:34         ` Peter Delevoryas
2021-09-05 14:43           ` Cédric Le Goater

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.