Commit Graph

72 Commits

Author SHA1 Message Date
Ninad Palsule
3fd941f3f1 hw/arm: Hook up FSI module in AST2600
This patchset introduces IBM's Flexible Service Interface(FSI).

Time for some fun with inter-processor buses. FSI allows a service
processor access to the internal buses of a host POWER processor to
perform configuration or debugging.

FSI has long existed in POWER processes and so comes with some baggage,
including how it has been integrated into the ASPEED SoC.

Working backwards from the POWER processor, the fundamental pieces of
interest for the implementation are:

1. The Common FRU Access Macro (CFAM), an address space containing
   various "engines" that drive accesses on buses internal and external
   to the POWER chip. Examples include the SBEFIFO and I2C masters. The
   engines hang off of an internal Local Bus (LBUS) which is described
   by the CFAM configuration block.

2. The FSI slave: The slave is the terminal point of the FSI bus for
   FSI symbols addressed to it. Slaves can be cascaded off of one
   another. The slave's configuration registers appear in address space
   of the CFAM to which it is attached.

3. The FSI master: A controller in the platform service processor (e.g.
   BMC) driving CFAM engine accesses into the POWER chip. At the
   hardware level FSI is a bit-based protocol supporting synchronous and
   DMA-driven accesses of engines in a CFAM.

4. The On-Chip Peripheral Bus (OPB): A low-speed bus typically found in
   POWER processors. This now makes an appearance in the ASPEED SoC due
   to tight integration of the FSI master IP with the OPB, mainly the
   existence of an MMIO-mapping of the CFAM address straight onto a
   sub-region of the OPB address space.

5. An APB-to-OPB bridge enabling access to the OPB from the ARM core in
   the AST2600. Hardware limitations prevent the OPB from being directly
   mapped into APB, so all accesses are indirect through the bridge.

The implementation appears as following in the qemu device tree:

    (qemu) info qtree
    bus: main-system-bus
      type System
      ...
      dev: aspeed.apb2opb, id ""
        gpio-out "sysbus-irq" 1
        mmio 000000001e79b000/0000000000001000
        bus: opb.1
          type opb
          dev: fsi.master, id ""
            bus: fsi.bus.1
              type fsi.bus
              dev: cfam.config, id ""
              dev: cfam, id ""
                bus: fsi.lbus.1
                  type lbus
                  dev: scratchpad, id ""
                    address = 0 (0x0)
        bus: opb.0
          type opb
          dev: fsi.master, id ""
            bus: fsi.bus.0
              type fsi.bus
              dev: cfam.config, id ""
              dev: cfam, id ""
                bus: fsi.lbus.0
                  type lbus
                  dev: scratchpad, id ""
                    address = 0 (0x0)

The LBUS is modelled to maintain the qdev bus hierarchy and to take
advantage of the object model to automatically generate the CFAM
configuration block. The configuration block presents engines in the
order they are attached to the CFAM's LBUS. Engine implementations
should subclass the LBusDevice and set the 'config' member of
LBusDeviceClass to match the engine's type.

CFAM designs offer a lot of flexibility, for instance it is possible for
a CFAM to be simultaneously driven from multiple FSI links. The modeling
is not so complete; it's assumed that each CFAM is attached to a single
FSI slave (as a consequence the CFAM subclasses the FSI slave).

As for FSI, its symbols and wire-protocol are not modelled at all. This
is not necessary to get FSI off the ground thanks to the mapping of the
CFAM address space onto the OPB address space - the models follow this
directly and map the CFAM memory region into the OPB's memory region.
Future work includes supporting more advanced accesses that drive the
FSI master directly rather than indirectly via the CFAM mapping, which
will require implementing the FSI state machine and methods for each of
the FSI symbols on the slave. Further down the track we can also look at
supporting the bitbanged SoftFSI drivers in Linux by extending the FSI
slave model to resolve sequences of GPIO IRQs into FSI symbols, and
calling the associated symbol method on the slave to map the access onto
the CFAM.

Testing:
    Tested by reading cfam config address 0 on rainier machine type.

    root@p10bmc:~# pdbg -a getcfam 0x0
    p0: 0x0 = 0xc0022d15

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Ninad Palsule <ninad@linux.ibm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2024-02-01 08:33:18 +01:00
Philippe Mathieu-Daudé
dc13909ed0 hw/arm/aspeed: Check for CPU types in machine_run_board_init()
Aspeed SoCs use a single CPU type (set as AspeedSoCClass::cpu_type).
Convert it to a NULL-terminated array (of a single non-NULL element).

Set MachineClass::valid_cpu_types[] to use the common machine code
to provide hints when the requested CPU is invalid (see commit
e702cbc19e ("machine: Improve is_cpu_type_supported()").

Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2024-02-01 08:13:30 +01:00
Philippe Mathieu-Daudé
d815649c51 hw/arm/aspeed: Introduce aspeed_soc_cpu_type() helper
In order to alter AspeedSoCClass::cpu_type in the next
commit, introduce the aspeed_soc_cpu_type() helper to
retrieve the per-SoC CPU type from AspeedSoCClass.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2024-02-01 08:13:30 +01:00
Philippe Mathieu-Daudé
dd41ce7a6f hw/arm/aspeed: Move AspeedSoCState::cpu/vic to Aspeed2400SoCState
The ARM array and VIC peripheral are only used by the
2400 series, remove them from the common AspeedSoCState.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-10-25 09:52:44 +02:00
Philippe Mathieu-Daudé
c17fc02571 hw/arm/aspeed: Move AspeedSoCState::a7mpcore to Aspeed2600SoCState
The v7-A cluster is specific to the Aspeed 2600 series,
remove it from the common AspeedSoCState.

The ARM cores belong to the MP cluster, but the array
is currently used by TYPE_ASPEED2600_SOC. We'll clean
that soon, but for now keep it in Aspeed2600SoCState.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-10-25 09:52:44 +02:00
Philippe Mathieu-Daudé
a0c2103070 hw/arm/aspeed: Move AspeedSoCState::armv7m to Aspeed10x0SoCState
The v7-M core is specific to the Aspeed 10x0 series,
remove it from the common AspeedSoCState.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-10-25 09:52:44 +02:00
Philippe Mathieu-Daudé
1a94fae4c1 hw/arm/aspeed: Introduce TYPE_ASPEED2400_SOC
TYPE_ASPEED2400_SOC inherits from TYPE_ASPEED_SOC.
In few commits we'll add more fields, but to keep
review process simple, don't add any yet.

TYPE_ASPEED_SOC is common to various Aspeed SoCs,
define it in aspeed_soc_common.c.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-10-25 09:52:44 +02:00
Philippe Mathieu-Daudé
4fc5e8065b hw/arm/aspeed: Introduce TYPE_ASPEED2600_SOC
TYPE_ASPEED2600_SOC inherits from TYPE_ASPEED_SOC.
In few commits we'll add more fields, but to keep
review process simple, don't add any yet.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-10-25 09:52:44 +02:00
Philippe Mathieu-Daudé
df4ab0764d hw/arm/aspeed: Introduce TYPE_ASPEED10X0_SOC
TYPE_ASPEED10X0_SOC inherits from TYPE_ASPEED_SOC.
In few commits we'll add more fields, but to keep
review process simple, don't add any yet.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-10-25 09:52:44 +02:00
Cédric Le Goater
5aa281d757 aspeed: Introduce a spi_boot region under the SoC
The default boot address of the Aspeed SoCs is 0x0. For this reason,
the FMC flash device contents are remapped by HW on the first 256MB of
the address space. In QEMU, this is currently done in the machine init
with the setup of a region alias.

Move this code to the SoC and introduce an extra container to prepare
ground for the boot ROM region which will overlap the FMC flash
remapping.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-03-02 13:57:50 +01:00
Philippe Mathieu-Daudé
6ba3dc2516 hw/arm/aspeed_ast10x0: Map the secure SRAM
Some SRAM appears to be used by the Secure Boot unit and
crypto accelerators. Name it 'secure sram'.

Note, the SRAM base address was already present but unused
(the 'SBC' index is used for the MMIO peripheral).

Interestingly using CFLAGS=-Winitializer-overrides reports:

  ../hw/arm/aspeed_ast10x0.c:32:30: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
    [ASPEED_DEV_SBC]       = 0x7E6F2000,
                             ^~~~~~~~~~
  ../hw/arm/aspeed_ast10x0.c:24:30: note: previous initialization is here
    [ASPEED_DEV_SBC]       = 0x79000000,
                             ^~~~~~~~~~
This fixes with Zephyr:

  uart:~$ rsa test
  rsa test vector[0]:
  [00:00:26.156,000] <err> os: ***** BUS FAULT *****
  [00:00:26.157,000] <err> os:   Precise data bus error
  [00:00:26.157,000] <err> os:   BFAR Address: 0x79000000
  [00:00:26.158,000] <err> os: r0/a1:  0x79000000  r1/a2:  0x00000000  r2/a3:  0x00001800
  [00:00:26.158,000] <err> os: r3/a4:  0x79001800 r12/ip:  0x00000800 r14/lr:  0x0001098d
  [00:00:26.158,000] <err> os:  xpsr:  0x81000000
  [00:00:26.158,000] <err> os: Faulting instruction address (r15/pc): 0x0001e1bc
  [00:00:26.158,000] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
  [00:00:26.158,000] <err> os: Current thread: 0x38248 (shell_uart)
  [00:00:26.165,000] <err> os: Halting system

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Peter Delevoryas <peter@pjd.dev>
[ clg: Fixed size of Secure Boot Controller Memory ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-02-07 09:02:05 +01:00
Philippe Mathieu-Daudé
72006c619f hw/arm/aspeed_ast10x0: Add various unimplemented peripherals
Based on booting Zephyr demo from [1] running QEMU with
'-d unimp' and checking missing devices in [2].

[1] https://github.com/AspeedTech-BMC/zephyr/releases/tag/v00.01.07
[2] https://github.com/AspeedTech-BMC/zephyr/blob/v00.01.08/dts/arm/aspeed/ast10x0.dtsi

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Peter Delevoryas <peter@pjd.dev>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-02-07 09:02:05 +01:00
Peter Delevoryas
1099ad10b0 aspeed: Make aspeed_board_init_flashes public
Signed-off-by: Peter Delevoryas <peter@pjd.dev>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220705191400.41632-5-peter@pjd.dev>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-07-14 16:24:38 +02:00
Peter Delevoryas
d2b3eaefb4 aspeed: Refactor UART init for multi-SoC machines
This change moves the code that connects the SoC UART's to serial_hd's
to the machine.

It makes each UART a proper child member of the SoC, and then allows the
machine to selectively initialize the chardev for each UART with a
serial_hd.

This should preserve backwards compatibility, but also allow multi-SoC
boards to completely change the wiring of serial devices from the
command line to specific SoC UART's.

This also removes the uart-default property from the SoC, since the SoC
doesn't need to know what UART is the "default" on the machine anymore.

I tested this using the images and commands from the previous
refactoring, and another test image for the ast1030:

    wget https://github.com/facebook/openbmc/releases/download/v2021.49.0/fuji.mtd
    wget https://github.com/facebook/openbmc/releases/download/v2021.49.0/wedge100.mtd
    wget https://github.com/peterdelevoryas/OpenBIC/releases/download/oby35-cl-2022.13.01/Y35BCL.elf

Fuji uses UART1:

    qemu-system-arm -machine fuji-bmc \
        -drive file=fuji.mtd,format=raw,if=mtd \
        -nographic

ast2600-evb uses uart-default=UART5:

    qemu-system-arm -machine ast2600-evb \
        -drive file=fuji.mtd,format=raw,if=mtd \
        -serial null -serial mon:stdio -display none

Wedge100 uses UART3:

    qemu-system-arm -machine palmetto-bmc \
        -drive file=wedge100.mtd,format=raw,if=mtd \
        -serial null -serial null -serial null \
        -serial mon:stdio -display none

AST1030 EVB uses UART5:

    qemu-system-arm -machine ast1030-evb \
        -kernel Y35BCL.elf -nographic

Fixes: 6827ff20b2 ("hw: aspeed: Init all UART's with serial devices")
Signed-off-by: Peter Delevoryas <peter@pjd.dev>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220705191400.41632-4-peter@pjd.dev>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-07-14 16:24:38 +02:00
Peter Delevoryas
55c57023b7 hw/misc/aspeed: Add PECI controller
This introduces a really basic PECI controller that responses to
commands by always setting the response code to success and then raising
an interrupt to indicate the command is done. This helps avoid getting
hit with constant errors if the driver continuously attempts to send a
command and keeps timing out.

The AST2400 and AST2500 only included registers up to 0x5C, not 0xFC.
They supported PECI 1.1, 2.0, and 3.0. The AST2600 and AST1030 support
PECI 4.0, which includes more read/write buffer registers from 0x80 to
0xFC to support 64-byte mode.

This patch doesn't attempt to handle that, or to create a different
version of the controller for the different generations, since it's only
implementing functionality that is common to all generations.

The basic sequence of events is that the firmware will read and write to
various registers and then trigger a command by setting the FIRE bit in
the command register (similar to the I2C controller).

Then the firmware waits for an interrupt from the PECI controller,
expecting the interrupt status register to be filled in with info on
what happened. If the command was transmitted and received successfully,
then response codes from the host CPU will be found in the data buffer
registers.

Signed-off-by: Peter Delevoryas <pdel@fb.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220630045133.32251-12-me@pjd.dev>
[ clg: s/sysbus_mmio_map/aspeed_mmio_map/ ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-06-30 09:21:14 +02:00
Peter Delevoryas
80beb08567 aspeed: Map unimplemented devices in SoC memory
Signed-off-by: Peter Delevoryas <pdel@fb.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220624003701.1363500-5-pdel@fb.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-06-30 09:21:13 +02:00
Peter Delevoryas
5bfcbda70d aspeed: Remove usage of sysbus_mmio_map
sysbus_mmio_map maps devices into "get_system_memory()".

With the new SoC memory attribute, we want to make sure that each device is
mapped into the SoC memory.

In single SoC machines, the SoC memory is the same as "get_system_memory()",
but in multi SoC machines it will be different.

Signed-off-by: Peter Delevoryas <pdel@fb.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220624003701.1363500-4-pdel@fb.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-06-30 09:21:13 +02:00
Peter Delevoryas
4dd9d55416 aspeed: Add memory property to Aspeed SoC
Multi-SoC machines can use this property to specify a memory container
for each SoC. Single SoC machines will just specify get_system_memory().

Signed-off-by: Peter Delevoryas <pdel@fb.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220624003701.1363500-3-pdel@fb.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-06-30 09:21:13 +02:00
Cédric Le Goater
346160cbf2 aspeed: Set the dram container at the SoC level
Currently, the Aspeed machines allocate a ram container region in
which the machine ram region is mapped. See commit ad1a978218
("aspeed: add a RAM memory region container"). An extra region is
mapped after ram in the ram container to catch invalid access done by
FW. That's how FW determines the size of ram. See commit ebe31c0a8e
("aspeed: add a max_ram_size property to the memory controller").

Let's move all the logic under the SoC where it should be. It will
also ease the work on multi SoC support.

Reviewed-by: Peter Delevoryas <pdel@fb.com>
Message-Id: <20220623202123.3972977-1-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-06-30 09:21:13 +02:00
Peter Delevoryas
470253b6d0 hw: aspeed: Introduce common UART init function
Signed-off-by: Peter Delevoryas <pdel@fb.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220516062328.298336-5-pdel@fb.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-05-25 10:31:33 +02:00
Peter Delevoryas
c5e1bdb9e2 hw: aspeed: Add uarts_num SoC attribute
AST2400 and AST2500 have 5 UART's, while the AST2600 and AST1030 have 13.

Signed-off-by: Peter Delevoryas <pdel@fb.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220516062328.298336-3-pdel@fb.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-05-25 10:31:33 +02:00
Peter Delevoryas
ab5e86053d hw: aspeed: Add missing UART's
This adds the missing UART memory and IRQ mappings for the AST2400, AST2500,
AST2600, and AST1030.

This also includes the new UART interfaces added in the AST2600 and AST1030
from UART6 to UART13. The addresses and interrupt numbers for these two
later chips are identical.

Signed-off-by: Peter Delevoryas <pdel@fb.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220516062328.298336-2-pdel@fb.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-05-25 10:31:33 +02:00
Cédric Le Goater
699db71520 aspeed: Introduce a get_irq AspeedSoCClass method
and make routine aspeed_soc_get_irq() common to all SoCs. This will be
useful to share code.

Cc: Jamin Lin <jamin_lin@aspeedtech.com>
Cc: Peter Delevoryas <pdel@fb.com>
Reviewed-by: Peter Delevoryas <pdel@fb.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220516055620.2380197-1-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-05-25 10:31:33 +02:00
Steven Lee
356b230ed1 aspeed/soc : Add AST1030 support
The embedded core of AST1030 SoC is ARM Coretex M4.
It is hard to be integrated in the common Aspeed Soc framework.
We introduce a new ast1030 class with instance_init and realize
handlers.

Signed-off-by: Troy Lee <troy_lee@aspeedtech.com>
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Signed-off-by: Steven Lee <steven_lee@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
[ clg: rename aspeed_ast10xx.c to aspeed_ast10x0.c to match zephyr ]
Message-Id: <20220401083850.15266-8-jamin_lin@aspeedtech.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-05-02 17:03:03 +02:00
Joel Stanley
fe31a2ecf0 aspeed: Add eMMC Boot Controller stub
Guest code (u-boot) pokes at this on boot. No functionality is required
for guest code to work correctly, but it helps to document the region
being read from.

Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220318092211.723938-1-joel@jms.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-05-02 17:03:02 +02:00
Joel Stanley
e1acf581c9 ast2600: Add Secure Boot Controller model
Just a stub that indicates the system has booted in secure boot mode.
Used for testing the driver:

 https://lore.kernel.org/all/20211019080608.283324-1-joel@jms.id.au/

Signed-off-by: Joel Stanley <joel@jms.id.au>
[ clg: - Fixed typo
       - Adjusted Copyright dates ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-02-26 18:40:51 +01:00
Troy Lee
3222165dcb hw/arm/aspeed: Add the i3c device to the AST2600 SoC
Add the new i3c device to the AST2600 SoC.

Signed-off-by: Troy Lee <troy_lee@aspeedtech.com>
Reviewed-by: Graeme Gregory <quic_ggregory@quicinc.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Tested-by: Graeme Gregory <quic_ggregory@quicinc.com>
Message-id: 20220111084546.4145785-3-troy_lee@aspeedtech.com
[PMM: tidied commit message]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-20 16:04:57 +00:00
Troy Lee
d9e9cd59df Add dummy Aspeed AST2600 Display Port MCU (DPMCU)
AST2600 Display Port MCU introduces 0x18000000~0x1803FFFF as it's memory
and io address. If guest machine try to access DPMCU memory, it will
cause a fatal error.

Signed-off-by: Troy Lee <troy_lee@aspeedtech.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-id: 20211210083034.726610-1-troy_lee@aspeedtech.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-07 17:07:57 +00:00
Andrew Jeffery
199fd6230c hw/arm: Integrate ADC model into Aspeed SoC
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Peter Delevoryas <pdel@fb.com>
Message-Id: <20211005052604.1674891-3-pdel@fb.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-10-12 08:20:08 +02:00
Peter Delevoryas
5d63d0c76c hw/arm/aspeed: Allow machine to set UART default
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>
2021-09-20 08:50:59 +02:00
Joel Stanley
a3888d757a aspeed: Integrate HACE
Add the hash and crypto engine model to the Aspeed socs.

Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Message-Id: <20210409000253.1475587-3-joel@jms.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-05-01 10:03:51 +02:00
Andrew Jeffery
c59f781e3b hw/misc: Model KCS devices in the Aspeed LPC controller
Keyboard-Controller-Style devices for IPMI purposes are exposed via LPC
IO cycles from the BMC to the host.

Expose support on the BMC side by implementing the usual MMIO
behaviours, and expose the ability to inspect the KCS registers in
"host" style by accessing QOM properties associated with each register.

The model caters to the IRQ style of both the AST2600 and the earlier
SoCs (AST2400 and AST2500). The AST2600 allocates an IRQ for each LPC
sub-device, while there is a single IRQ shared across all subdevices on
the AST2400 and AST2500.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20210302014317.915120-6-andrew@aj.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-03-09 12:01:28 +01:00
Cédric Le Goater
2ecf17264d hw/misc: Add a basic Aspeed LPC controller model
This is a very minimal framework to access registers which are used to
configure the AHB memory mapping of the flash chips on the LPC HC
Firmware address space.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Message-Id: <20210302014317.915120-5-andrew@aj.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-03-09 12:01:28 +01:00
Eduardo Habkost
a489d1951c Use OBJECT_DECLARE_TYPE when possible
This converts existing DECLARE_OBJ_CHECKERS usage to
OBJECT_DECLARE_TYPE when possible.

 $ ./scripts/codeconverter/converter.py -i \
   --pattern=AddObjectDeclareType $(git grep -l '' -- '*.[ch]')

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Acked-by: Paul Durrant <paul@xen.org>
Message-Id: <20200916182519.415636-5-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-09-18 14:12:32 -04:00
Eduardo Habkost
8110fa1d94 Use DECLARE_*CHECKER* macros
Generated using:

 $ ./scripts/codeconverter/converter.py -i \
   --pattern=TypeCheckMacro $(git grep -l '' -- '*.[ch]')

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Message-Id: <20200831210740.126168-12-ehabkost@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Message-Id: <20200831210740.126168-13-ehabkost@redhat.com>
Message-Id: <20200831210740.126168-14-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-09-09 09:27:09 -04:00
Eduardo Habkost
db1015e92e Move QOM typedefs and add missing includes
Some typedefs and macros are defined after the type check macros.
This makes it difficult to automatically replace their
definitions with OBJECT_DECLARE_TYPE.

Patch generated using:

 $ ./scripts/codeconverter/converter.py -i \
   --pattern=QOMStructTypedefSplit $(git grep -l '' -- '*.[ch]')

which will split "typdef struct { ... } TypedefName"
declarations.

Followed by:

 $ ./scripts/codeconverter/converter.py -i --pattern=MoveSymbols \
    $(git grep -l '' -- '*.[ch]')

which will:
- move the typedefs and #defines above the type check macros
- add missing #include "qom/object.h" lines if necessary

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Message-Id: <20200831210740.126168-9-ehabkost@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Message-Id: <20200831210740.126168-10-ehabkost@redhat.com>
Message-Id: <20200831210740.126168-11-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-09-09 09:26:43 -04:00
Eduardo Habkost
347df6f876 aspeed_soc: Rename memmap/irqmap enum constants
Some of the enum constant names conflict with the QOM type check
macros:

ASPEED_GPIO
ASPEED_I2C
ASPEED_RTC
ASPEED_SCU
ASPEED_SDHCI
ASPEED_SDMC
ASPEED_VIC
ASPEED_WDT
ASPEED_XDMA

This needs to be addressed to allow us to transform the QOM type
check macros into functions generated by OBJECT_DECLARE_TYPE().

Rename all the constants to ASPEED_DEV_*, to avoid conflicts.

Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Tested-By: Roman Bolshakov <r.bolshakov@yadro.com>
Message-Id: <20200825192110.3528606-7-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-08-27 14:04:54 -04:00
Cédric Le Goater
b7f1a0cb76 arm/aspeed: Compute the number of CPUs from the SoC definition
Commit ece09beec4 ("aspeed: introduce a configurable number of CPU
per machine") was a convient change during bringup but the Aspeed SoCs
have a fixed number of CPUs : one for the AST2400 and AST2500, and two
for the AST2600.

When the number of CPUs configured with -smp is less than the SoC's
fixed number, the "unconfigured" CPUs are left unrealized. This can
happen for machines ast2600-evb and tacoma-bmc, where the SoC's fixed
number is 2. To get virtual hardware that matches the physical
hardware, you have to pass -smp cpus=2 (or its sugared form -smp 2).

We normally reject -smp cpus=N when N exceeds the machine's limit.
Except we ignore cpus=2 (and only cpus=2) with a warning for machines
ast2500-evb, palmetto-bmc, romulus-bmc, sonorapass-bmc, swift-bmc, and
witherspoon-bmc.

Remove the "num-cpu" property from the SoC state and use the fixed
number of CPUs defined in the SoC class instead. Compute the default,
min, max number of CPUs of the machine directly from the SoC class
definition.

Machines ast2600-evb and tacoma-bmc now always get their second CPU as
they should. Visible in "info qom-tree"; here's the change for
ast2600-evb:

     /machine (ast2600-evb-machine)
       /peripheral (container)
       /peripheral-anon (container)
       /soc (ast2600-a1)
         /a7mpcore (a15mpcore_priv)
           /a15mp-priv-container[0] (qemu:memory-region)
           /gic (arm_gic)
             /gic_cpu[0] (qemu:memory-region)
             /gic_cpu[1] (qemu:memory-region)
    +        /gic_cpu[2] (qemu:memory-region)
             /gic_dist[0] (qemu:memory-region)
             /gic_vcpu[0] (qemu:memory-region)
             /gic_viface[0] (qemu:memory-region)
             /gic_viface[1] (qemu:memory-region)
    +        /gic_viface[2] (qemu:memory-region)
             /unnamed-gpio-in[0] (irq)
             [...]
    +        /unnamed-gpio-in[160] (irq)
             [same for 161 to 190...]
    +        /unnamed-gpio-in[191] (irq)

Also visible in "info qtree"; here's the change for ast2600-evb:

     bus: main-system-bus
       type System
       dev: a15mpcore_priv, id ""
         gpio-in "" 128
    -    gpio-out "sysbus-irq" 5
    -    num-cpu = 1 (0x1)
    +    gpio-out "sysbus-irq" 10
    +    num-cpu = 2 (0x2)
         num-irq = 160 (0xa0)
         mmio 0000000040460000/0000000000008000
       dev: arm_gic, id ""
    -    gpio-in "" 160
    -    num-cpu = 1 (0x1)
    +    gpio-in "" 192
    +    num-cpu = 2 (0x2)
         num-irq = 160 (0xa0)
         revision = 2 (0x2)
         has-security-extensions = true
         has-virtualization-extensions = true
         num-priority-bits = 8 (0x8)
         mmio ffffffffffffffff/0000000000001000
         mmio ffffffffffffffff/0000000000002000
         mmio ffffffffffffffff/0000000000001000
         mmio ffffffffffffffff/0000000000002000
         mmio ffffffffffffffff/0000000000000100
    +    mmio ffffffffffffffff/0000000000000100
    +    mmio ffffffffffffffff/0000000000000200
         mmio ffffffffffffffff/0000000000000200

The other machines now reject -smp cpus=2 just like -smp cpus=3 and up.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
[Commit message expanded]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20200609122339.937862-5-armbru@redhat.com>
2020-06-15 21:36:09 +02:00
Guenter Roeck
bfdd34f1ca hw/arm: ast2400/ast2500: Wire up EHCI controllers
Initialize EHCI controllers on AST2400 and AST2500 using the existing
TYPE_PLATFORM_EHCI. After this change, booting ast2500-evb into Linux
successfully instantiates a USB interface.

ehci-platform 1e6a3000.usb: EHCI Host Controller
ehci-platform 1e6a3000.usb: new USB bus registered, assigned bus number 1
ehci-platform 1e6a3000.usb: irq 21, io mem 0x1e6a3000
ehci-platform 1e6a3000.usb: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.05
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20200206183437.3979-1-linux@roeck-us.net
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13 14:14:55 +00:00
Andrew Jeffery
a29e3e1270 hw/arm: ast2600: Wire up the eMMC controller
Initialise another SDHCI model instance for the AST2600's eMMC
controller and use the SDHCI's num_slots value introduced previously to
determine whether we should create an SD card instance for the new slot.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-id: 20200114103433.30534-3-clg@kaod.org
[ clg : - removed ternary operator from sdhci_attach_drive()
        - renamed SDHCI objects with a '-controller' prefix ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-30 16:02:02 +00:00
Cédric Le Goater
95b56e173e aspeed: Add a DRAM memory region at the SoC level
Currently, we link the DRAM memory region to the FMC model (for DMAs)
through a property alias at the SoC level. The I2C model will need a
similar region for DMA support, add a DRAM region property at the SoC
level for both model to use.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Tested-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-id: 20191119141211.25716-4-clg@kaod.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-12-16 10:46:34 +00:00
Philippe Mathieu-Daudé
ea5dcf4e1d hw: Move Aspeed RTC from hw/timer/ to hw/rtc/ subdirectory
Move RTC devices under the hw/rtc/ subdirectory.

Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20191003230404.19384-12-philmd@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2019-10-24 20:31:44 +02:00
Joel Stanley
514bcf6fdd aspeed/soc: Add ASPEED Video stub
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-id: 20190925143248.10000-24-clg@kaod.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-15 18:09:05 +01:00
Cédric Le Goater
289251b033 aspeed: add support for the Aspeed MII controller of the AST2600
The AST2600 SoC has an extra controller to set the PHY registers.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Message-id: 20190925143248.10000-23-clg@kaod.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-15 18:09:05 +01:00
Joel Stanley
d300db0277 aspeed: Parameterise number of MACs
To support the ast2600's four MACs allow SoCs to specify the number
they have, and create that many.

Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-id: 20190925143248.10000-22-clg@kaod.org
[clg: - included a check on sc->macs_num when realizing the macs
      - included interrupt definitions for the AST2600 ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-15 18:09:05 +01:00
Cédric Le Goater
f25c0ae107 aspeed/soc: Add AST2600 support
Initial definitions for a simple machine using an AST2600 SoC (Cortex
CPU).

The Cortex CPU and its interrupt controller are too complex to handle
in the common Aspeed SoC framework. We introduce a new Aspeed SoC
class with instance_init and realize handlers to handle the differences
with the AST2400 and the AST2500 SoCs. This will add extra work to
keep in sync both models with future extensions but it makes the code
clearer.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Message-id: 20190925143248.10000-19-clg@kaod.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-15 18:09:05 +01:00
Cédric Le Goater
54ecafb7f9 aspeed: Introduce an object class per SoC
It prepares ground for the AST2600.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Message-id: 20190925143248.10000-18-clg@kaod.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-15 18:09:04 +01:00
Joel Stanley
6b2b2a703c hw: wdt_aspeed: Add AST2600 support
The AST2600 has four watchdogs, and they each have a 0x40 of registers.

When running as part of an ast2600 system we must check a different
offset for the system reset control register in the SCU.

Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-id: 20190925143248.10000-12-clg@kaod.org
[clg: - reworked model integration into new object class ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-15 18:09:04 +01:00
Eddie James
2bea128c3d hw/sd/aspeed_sdhci: New device
The Aspeed SOCs have two SD/MMC controllers. Add a device that
encapsulates both of these controllers and models the Aspeed-specific
registers and behavior.

Tested by reading from mmcblk0 in Linux:
qemu-system-arm -machine romulus-bmc -nographic \
 -drive file=flash-romulus,format=raw,if=mtd \
 -device sd-card,drive=sd0 -drive file=_tmp/kernel,format=raw,if=sd,id=sd0

Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-id: 20190925143248.10000-3-clg@kaod.org
[clg: - changed the controller MMIO window size to 0x1000
      - moved the MMIO mapping of the SDHCI slots at the SoC level
      - merged code to add SD drives on the SD buses at the machine level ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-15 18:09:04 +01:00
Cédric Le Goater
811a5b1d6c aspeed: Use consistent typenames
Improve the naming of the different controller models to ease their
generation when initializing the SoC. The rename of the SMC types is
breaking migration compatibility.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-id: 20190904070506.1052-5-clg@kaod.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-09-13 16:05:01 +01:00