- Create aspeed_eeprom.c and aspeed_eeprom.h
- Include aspeed_eeprom.c in CONFIG_ASPEED meson source files
- Include aspeed_eeprom.h in aspeed.c
- Add fby35_bmc_fruid data
- Use new at24c_eeprom_init_rom helper to initialize BMC FRUID EEPROM with data
from aspeed_eeprom.c
wget https://github.com/facebook/openbmc/releases/download/openbmc-e2294ff5d31d/fby35.mtd
qemu-system-aarch64 -machine fby35-bmc -nographic -mtdblock fby35.mtd
...
user: root
pass: 0penBmc
...
root@bmc-oob:~# fruid-util bb
FRU Information : Baseboard
--------------- : ------------------
Chassis Type : Rack Mount Chassis
Chassis Part Number : N/A
Chassis Serial Number : N/A
Board Mfg Date : Fri Jan 7 10:30:00 2022
Board Mfg : XXXXXX
Board Product : Management Board wBMC
Board Serial : XXXXXXXXXXXXX
Board Part Number : XXXXXXXXXXXXXX
Board FRU ID : 1.0
Board Custom Data 1 : XXXXXXXXX
Board Custom Data 2 : XXXXXXXXXXXXXXXXXX
Product Manufacturer : XXXXXX
Product Name : Yosemite V3.5 EVT2
Product Part Number : XXXXXXXXXXXXXX
Product Version : EVT2
Product Serial : XXXXXXXXXXXXX
Product Asset Tag : XXXXXXX
Product FRU ID : 1.0
Product Custom Data 1 : XXXXXXXXX
Product Custom Data 2 : N/A
root@bmc-oob:~# fruid-util bmc
FRU Information : BMC
--------------- : ------------------
Board Mfg Date : Mon Jan 10 21:42:00 2022
Board Mfg : XXXXXX
Board Product : BMC Storage Module
Board Serial : XXXXXXXXXXXXX
Board Part Number : XXXXXXXXXXXXXX
Board FRU ID : 1.0
Board Custom Data 1 : XXXXXXXXX
Board Custom Data 2 : XXXXXXXXXXXXXXXXXX
Product Manufacturer : XXXXXX
Product Name : Yosemite V3.5 EVT2
Product Part Number : XXXXXXXXXXXXXX
Product Version : EVT2
Product Serial : XXXXXXXXXXXXX
Product Asset Tag : XXXXXXX
Product FRU ID : 1.0
Product Custom Data 1 : XXXXXXXXX
Product Custom Data 2 : Config A
root@bmc-oob:~# fruid-util nic
FRU Information : NIC
--------------- : ------------------
Board Mfg Date : Tue Nov 2 08:51:00 2021
Board Mfg : XXXXXXXX
Board Product : Mellanox ConnectX-6 DX OCP3.0
Board Serial : XXXXXXXXXXXXXXXXXXXXXXXX
Board Part Number : XXXXXXXXXXXXXXXXXXXXX
Board FRU ID : FRU Ver 0.02
Product Manufacturer : XXXXXXXX
Product Name : Mellanox ConnectX-6 DX OCP3.0
Product Part Number : XXXXXXXXXXXXXXXXXXXXX
Product Version : A9
Product Serial : XXXXXXXXXXXXXXXXXXXXXXXX
Product Custom Data 3 : ConnectX-6 DX
Signed-off-by: Peter Delevoryas <peter@pjd.dev>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Corey Minyard <cminyard@mvista.com>
Link: https://lore.kernel.org/r/20230128060543.95582-5-peter@pjd.dev
Signed-off-by: Cédric Le Goater <clg@kaod.org>
supermicrox11-bmc is configured with ast2400-a1 SoC. This does not match
the Supermicro documentation for X11 BMCs, and it does not match the
devicetree file in the Linux kernel.
As it turns out, some Supermicro X11 motherboards use AST2400 SoCs,
while others use AST2500.
Introduce new machine type supermicrox11-spi-bmc with AST2500 SoC
to match the devicetree description in the Linux kernel. Hardware
configuration details for this machine type are guesswork and taken
from defaults as well as from the Linux kernel devicetree file.
The new machine type was tested with aspeed-bmc-supermicro-x11spi.dts
from the Linux kernel and with Linux versions 6.0.3 and 6.1-rc2.
Linux booted successfully from initrd and from both SPI interfaces.
Ethernet interfaces were confirmed to be operational.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/r/20221025165109.1226001-1-linux@roeck-us.net
[ clg: Renamed machine to 'supermicro-x11spi-bmc' ]
Message-Id: <20221025165109.1226001-1-linux@roeck-us.net>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
The M2S-FG484 SOM uses a 16 MiB SPI flash (Spansion
S25FL128SDPBHICO). Since the test asset is bigger,
truncate it to the correct size to avoid when running
the test_arm_emcraft_sf2 test:
qemu-system-arm: device requires 16777216 bytes, block backend provides 67108864 bytes
Add comment regarding the M2S-FG484 SOM hardware in
hw/arm/msf2-som.c.
Reported-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Tested-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Let's explicitly list out all accelerators that we support when trying to
determine the supported set of GIC versions. KVM was already separate, so
the only missing one is HVF which simply reuses all of TCG's emulation
code and thus has the same compatibility matrix.
Signed-off-by: Alexander Graf <agraf@csgraf.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20221223090107.98888-3-agraf@csgraf.de
[PMM: Added qtest to the list of accelerators]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Up to now, the finalize_gic_version() code open coded what is essentially
a support bitmap match between host/emulation environment and desired
target GIC type.
This open coding leads to undesirable side effects. For example, a VM with
KVM and -smp 10 will automatically choose GICv3 while the same command
line with TCG will stay on GICv2 and fail the launch.
This patch combines the TCG and KVM matching code paths by making
everything a 2 pass process. First, we determine which GIC versions the
current environment is able to support, then we go through a single
state machine to determine which target GIC mode that means for us.
After this patch, the only user noticable changes should be consolidated
error messages as well as TCG -M virt supporting -smp > 8 automatically.
Signed-off-by: Alexander Graf <agraf@csgraf.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Message-id: 20221223090107.98888-2-agraf@csgraf.de
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The 'hwaddr' type is defined in "exec/hwaddr.h" as:
hwaddr is the type of a physical address
(its size can be different from 'target_ulong').
All definitions use the 'HWADDR_' prefix, except TARGET_FMT_plx:
$ fgrep define include/exec/hwaddr.h
#define HWADDR_H
#define HWADDR_BITS 64
#define HWADDR_MAX UINT64_MAX
#define TARGET_FMT_plx "%016" PRIx64
^^^^^^
#define HWADDR_PRId PRId64
#define HWADDR_PRIi PRIi64
#define HWADDR_PRIo PRIo64
#define HWADDR_PRIu PRIu64
#define HWADDR_PRIx PRIx64
#define HWADDR_PRIX PRIX64
Since hwaddr's size can be *different* from target_ulong, it is
very confusing to read one of its format using the 'TARGET_FMT_'
prefix, normally used for the target_long / target_ulong types:
$ fgrep TARGET_FMT_ include/exec/cpu-defs.h
#define TARGET_FMT_lx "%08x"
#define TARGET_FMT_ld "%d"
#define TARGET_FMT_lu "%u"
#define TARGET_FMT_lx "%016" PRIx64
#define TARGET_FMT_ld "%" PRId64
#define TARGET_FMT_lu "%" PRIu64
Apparently this format was missed during commit a8170e5e97
("Rename target_phys_addr_t to hwaddr"), so complete it by
doing a bulk-rename with:
$ sed -i -e s/TARGET_FMT_plx/HWADDR_FMT_plx/g $(git grep -l TARGET_FMT_plx)
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20230110212947.34557-1-philmd@linaro.org>
[thuth: Fix some warnings from checkpatch.pl along the way]
Signed-off-by: Thomas Huth <thuth@redhat.com>
The typedef and definitions are generated by the OBJECT_DECLARE_TYPE
macro in "hw/arm/bcm2836.h":
20 #define TYPE_BCM283X "bcm283x"
21 OBJECT_DECLARE_TYPE(BCM283XState, BCM283XClass, BCM283X)
The script ran in commit a489d1951c ("Use OBJECT_DECLARE_TYPE when
possible") missed them because they are declared in a different
file unit. Remove them.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20230109140306.23161-10-philmd@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Upon introduction in commit b8433303fb ("Set proper device-width
for vexpress flash"), ve_pflash_cfi01_register() was calling
qdev_init_nofail() which can not fail. This call was later
converted with a script to use &error_fatal, still unable to
fail. Remove the unreachable code.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20230109115316.2235-13-philmd@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This patch implements Allwinner TWI/I2C controller emulation. Only
master-mode functionality is implemented.
The SPL boot for Cubieboard expects AXP209 PMIC on TWI0/I2C0 bus, so this is
first part enabling the TWI/I2C bus operation.
Since both Allwinner A10 and H3 use the same module, it is added for
both boards.
Docs are also updated for Cubieboard and Orangepi-PC board to indicate
I2C availability.
Signed-off-by: Strahinja Jankovic <strahinja.p.jankovic@gmail.com>
Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com>
Message-id: 20221226220303.14420-4-strahinja.p.jankovic@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
During SPL boot several DRAM Controller registers are used. Most
important registers are those related to DRAM initialization and
calibration, where SPL initiates process and waits until certain bit is
set/cleared.
This patch adds these registers, initializes reset values from user's
guide and updates state of registers as SPL expects it.
Signed-off-by: Strahinja Jankovic <strahinja.p.jankovic@gmail.com>
Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com>
Message-id: 20221226220303.14420-3-strahinja.p.jankovic@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When using Clang ("Apple clang version 14.0.0 (clang-1400.0.29.202)")
and building with -Wall we get:
hw/arm/smmu-common.c:173:33: warning: static function 'smmu_hash_remove_by_asid_iova' is used in an inline function with external linkage [-Wstatic-in-inline]
hw/arm/smmu-common.h:170:1: note: use 'static' to give inline function 'smmu_iotlb_inv_iova' internal linkage
void smmu_iotlb_inv_iova(SMMUState *s, int asid, dma_addr_t iova,
^
static
None of our code base require / use inlined functions with external
linkage. Some places use internal inlining in the hot path. These
two functions are certainly not in any hot path and don't justify
any inlining, so these are likely oversights rather than intentional.
Reported-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20221216214924.4711-3-philmd@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
We use 32bit value for linux,initrd-[start/end], when we have
loader_start > 4GB, there will be a wrong initrd_start passed
to the kernel, and the kernel will report the following warning.
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] initrd not fully accessible via the linear mapping -- please check your bootloader ...
[ 0.000000] WARNING: CPU: 0 PID: 0 at arch/arm64/mm/init.c:355 arm64_memblock_init+0x158/0x244
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Tainted: G W 6.1.0-rc3-13250-g30a0b95b1335-dirty #28
[ 0.000000] Hardware name: Horizon Sigi Virtual development board (DT)
[ 0.000000] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 0.000000] pc : arm64_memblock_init+0x158/0x244
[ 0.000000] lr : arm64_memblock_init+0x158/0x244
[ 0.000000] sp : ffff800009273df0
[ 0.000000] x29: ffff800009273df0 x28: 0000001000cc0010 x27: 0000800000000000
[ 0.000000] x26: 000000000050a3e2 x25: ffff800008b46000 x24: ffff800008b46000
[ 0.000000] x23: ffff800008a53000 x22: ffff800009420000 x21: ffff800008a53000
[ 0.000000] x20: 0000000004000000 x19: 0000000004000000 x18: 00000000ffff1020
[ 0.000000] x17: 6568632065736165 x16: 6c70202d2d20676e x15: 697070616d207261
[ 0.000000] x14: 656e696c20656874 x13: 0a2e2e2e20726564 x12: 0000000000000000
[ 0.000000] x11: 0000000000000000 x10: 00000000ffffffff x9 : 0000000000000000
[ 0.000000] x8 : 0000000000000000 x7 : 796c6c756620746f x6 : 6e20647274696e69
[ 0.000000] x5 : ffff8000093c7c47 x4 : ffff800008a2102f x3 : ffff800009273a88
[ 0.000000] x2 : 80000000fffff038 x1 : 00000000000000c0 x0 : 0000000000000056
[ 0.000000] Call trace:
[ 0.000000] arm64_memblock_init+0x158/0x244
[ 0.000000] setup_arch+0x164/0x1cc
[ 0.000000] start_kernel+0x94/0x4ac
[ 0.000000] __primary_switched+0xb4/0xbc
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000001000000000-0x0000001007ffffff]
This doesn't affect any machine types we currently support, because
for all of our machine types the RAM starts well below the 4GB
mark, but it does demonstrate that we're not currently writing
the device-tree properties quite as intended.
To fix it, we can change it to write these values to the dtb using a
type width matching #address-cells. This is the intended size for
these dtb properties, and is how u-boot, for instance, writes them,
although in practice the Linux kernel will cope with them being any
width as long as they're big enough to fit the value.
Signed-off-by: Schspa Shi <schspa@gmail.com>
Message-id: 20221129160724.75667-1-schspa@gmail.com
[PMM: tweaked commit message]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
