target/arm: Allow users to set the number of VFP registers

Cortex A7 CPUs with an FPU implementing VFPv4 without NEON support
have 16 64-bit FPU registers and not 32 registers. Let users set the
num

target/arm: Allow users to set the number of VFP registers

Cortex A7 CPUs with an FPU implementing VFPv4 without NEON support
have 16 64-bit FPU registers and not 32 registers. Let users set the
number of VFP registers with a CPU property.

The primary use case of this property is for the Cortex A7 of the
Aspeed AST2600 SoC.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

target/arm: Allow users to set the number of VFP registers

Cortex A7 CPUs with an FPU implementing VFPv4 without NEON support
have 16 64-bit FPU registers and not 32 registers. Let users set the
num

target/arm: Allow users to set the number of VFP registers

Cortex A7 CPUs with an FPU implementing VFPv4 without NEON support
have 16 64-bit FPU registers and not 32 registers. Let users set the
number of VFP registers with a CPU property.

The primary use case of this property is for the Cortex A7 of the
Aspeed AST2600 SoC.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

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 addr

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>

show more ...

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 addr

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>

show more ...

hw/watchdog/wdt_aspeed: Rename MMIO region size as 'iosize'

Avoid confusing two different things:
- the WDT I/O region size ('iosize')
- at which offset the SoC map the WDT ('offset')
While it is of

hw/watchdog/wdt_aspeed: Rename MMIO region size as 'iosize'

Avoid confusing two different things:
- the WDT I/O region size ('iosize')
- at which offset the SoC map the WDT ('offset')
While it is often the same, we can map smaller region sizes
at larger offsets.

Here we are interested in the I/O region size, so rename as
'iosize'.

Reviewed-by: Peter Delevoryas <peter@pjd.dev>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
[ clg: Introduced temporary wdt_offset variable ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

ast2600: Drop NEON from the CPU features

Currently, the CPU features exposed to the AST2600 QEMU machines are :

half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
vfpd32 lpae evtstrm

ast2600: Drop NEON from the CPU features

Currently, the CPU features exposed to the AST2600 QEMU machines are :

half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
vfpd32 lpae evtstrm

But, the features of the Cortex A7 CPU on the Aspeed AST2600 A3 SoC
are :

half thumb fastmult vfp edsp vfpv3 vfpv3d16 tls vfpv4 idiva idivt
lpae evtstrm

Drop NEON support in the Aspeed AST2600 SoC.

Reviewed-by: Joel Stanley <joel@jms.id.au>
Message-Id: <20220928164719.655586-3-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

ast2600: Drop NEON from the CPU features

Currently, the CPU features exposed to the AST2600 QEMU machines are :

half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
vfpd32 lpae evtstrm

ast2600: Drop NEON from the CPU features

Currently, the CPU features exposed to the AST2600 QEMU machines are :

half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
vfpd32 lpae evtstrm

But, the features of the Cortex A7 CPU on the Aspeed AST2600 A3 SoC
are :

half thumb fastmult vfp edsp vfpv3 vfpv3d16 tls vfpv4 idiva idivt
lpae evtstrm

Drop NEON support in the Aspeed AST2600 SoC.

Reviewed-by: Joel Stanley <joel@jms.id.au>
Message-Id: <20220928164719.655586-3-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

ast2600: Drop NEON from the CPU features

Currently, the CPU features exposed to the AST2600 QEMU machines are :

half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
vfpd32 lpae evtstrm

ast2600: Drop NEON from the CPU features

Currently, the CPU features exposed to the AST2600 QEMU machines are :

half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
vfpd32 lpae evtstrm

But, the features of the Cortex A7 CPU on the Aspeed AST2600 A3 SoC
are :

half thumb fastmult vfp edsp vfpv3 vfpv3d16 tls vfpv4 idiva idivt
lpae evtstrm

Drop NEON support in the Aspeed AST2600 SoC.

Reviewed-by: Joel Stanley <joel@jms.id.au>
Message-Id: <20220928164719.655586-3-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

ast2600: Drop NEON from the CPU features

Currently, the CPU features exposed to the AST2600 QEMU machines are :

half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
vfpd32 lpae evtstrm

ast2600: Drop NEON from the CPU features

Currently, the CPU features exposed to the AST2600 QEMU machines are :

half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
vfpd32 lpae evtstrm

But, the features of the Cortex A7 CPU on the Aspeed AST2600 A3 SoC
are :

half thumb fastmult vfp edsp vfpv3 vfpv3d16 tls vfpv4 idiva idivt
lpae evtstrm

Drop NEON support in the Aspeed AST2600 SoC.

Reviewed-by: Joel Stanley <joel@jms.id.au>
Message-Id: <20220928164719.655586-3-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

ast2600: Drop NEON from the CPU features

Currently, the CPU features exposed to the AST2600 QEMU machines are :

half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
vfpd32 lpae evtstrm

ast2600: Drop NEON from the CPU features

Currently, the CPU features exposed to the AST2600 QEMU machines are :

half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
vfpd32 lpae evtstrm

But, the features of the Cortex A7 CPU on the Aspeed AST2600 A3 SoC
are :

half thumb fastmult vfp edsp vfpv3 vfpv3d16 tls vfpv4 idiva idivt
lpae evtstrm

Drop NEON support in the Aspeed AST2600 SoC.

Reviewed-by: Joel Stanley <joel@jms.id.au>
Message-Id: <20220928164719.655586-3-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

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 the

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: 6827ff20b2975 ("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>

show more ...

aspeed: Create SRAM name from first CPU index

To support multiple SoC's running simultaneously, we need a unique name for
each RAM region. DRAM is created by the machine, but SRAM is created by the

aspeed: Create SRAM name from first CPU index

To support multiple SoC's running simultaneously, we need a unique name for
each RAM region. DRAM is created by the machine, but SRAM is created by the
SoC, since in hardware it is part of the SoC's internals.

We need a way to uniquely identify each SRAM region though, for VM
migration. Since each of the SoC's CPU's has an index which identifies it
uniquely from other CPU's in the machine, we can use the index of any of the
CPU's in the SoC to uniquely identify differentiate the SRAM name from other
SoC SRAM's. In this change, I just elected to use the index of the first CPU
in each SoC.

Signed-off-by: Peter Delevoryas <peter@pjd.dev>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220705191400.41632-3-peter@pjd.dev>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

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 the

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: 6827ff20b2975 ("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>

show more ...

aspeed: Create SRAM name from first CPU index

To support multiple SoC's running simultaneously, we need a unique name for
each RAM region. DRAM is created by the machine, but SRAM is created by the

aspeed: Create SRAM name from first CPU index

To support multiple SoC's running simultaneously, we need a unique name for
each RAM region. DRAM is created by the machine, but SRAM is created by the
SoC, since in hardware it is part of the SoC's internals.

We need a way to uniquely identify each SRAM region though, for VM
migration. Since each of the SoC's CPU's has an index which identifies it
uniquely from other CPU's in the machine, we can use the index of any of the
CPU's in the SoC to uniquely identify differentiate the SRAM name from other
SoC SRAM's. In this change, I just elected to use the index of the first CPU
in each SoC.

Signed-off-by: Peter Delevoryas <peter@pjd.dev>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220705191400.41632-3-peter@pjd.dev>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

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 the

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: 6827ff20b2975 ("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>

show more ...

aspeed: Create SRAM name from first CPU index

To support multiple SoC's running simultaneously, we need a unique name for
each RAM region. DRAM is created by the machine, but SRAM is created by the

aspeed: Create SRAM name from first CPU index

To support multiple SoC's running simultaneously, we need a unique name for
each RAM region. DRAM is created by the machine, but SRAM is created by the
SoC, since in hardware it is part of the SoC's internals.

We need a way to uniquely identify each SRAM region though, for VM
migration. Since each of the SoC's CPU's has an index which identifies it
uniquely from other CPU's in the machine, we can use the index of any of the
CPU's in the SoC to uniquely identify differentiate the SRAM name from other
SoC SRAM's. In this change, I just elected to use the index of the first CPU
in each SoC.

Signed-off-by: Peter Delevoryas <peter@pjd.dev>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220705191400.41632-3-peter@pjd.dev>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

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

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>

show more ...

aspeed: Remove use of qemu_get_cpu

Signed-off-by: Peter Delevoryas <pdel@fb.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220624003701.1363500-6-pdel@fb.com>
Signed-off-by: Cédric

aspeed: Remove use of qemu_get_cpu

Signed-off-by: Peter Delevoryas <pdel@fb.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220624003701.1363500-6-pdel@fb.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

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-o

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>

show more ...

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 memo

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>

show more ...

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-

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>

show more ...

aspeed: Set CPU memory property explicitly

Signed-off-by: Peter Delevoryas <pdel@fb.com>
Message-Id: <20220624003701.1363500-2-pdel@fb.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

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 ad1a9782186d
("aspeed: add a RAM

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 ad1a9782186d
("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 ebe31c0a8ef7
("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>

show more ...

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-of

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>

show more ...

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@ka

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>

show more ...