mirrors/qemu
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
master
qemu/hw/riscv/microchip_pfsoc.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

674 lines
29 KiB
C
Raw Permalink Normal View History

hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
/*
* QEMU RISC-V Board Compatible with Microchip PolarFire SoC Icicle Kit
*
* Copyright (c) 2020 Wind River Systems, Inc.
*
* Author:
* Bin Meng <bin.meng@windriver.com>
*
* Provides a board compatible with the Microchip PolarFire SoC Icicle Kit
*
* 0) CLINT (Core Level Interruptor)
* 1) PLIC (Platform Level Interrupt Controller)
* 2) eNVM (Embedded Non-Volatile Memory)
hw/riscv: microchip_pfsoc: Connect 5 MMUARTs Microchip PolarFire SoC has 5 MMUARTs, and the Icicle Kit board wires 4 of them out. Let's connect all 5 MMUARTs. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-7-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:39:01 +03:00
* 3) MMUARTs (Multi-Mode UART)
hw/riscv: microchip_pfsoc: Connect a Cadence SDHCI controller and an SD card Microchip PolarFire SoC integrates one Cadence SDHCI controller. On the Icicle Kit board, one eMMC chip and an external SD card connect to this controller depending on different configuration. As QEMU does not support eMMC yet, we just emulate the SD card configuration. To test this, the Hart Software Services (HSS) should choose the SD card configuration: $ cp boards/icicle-kit-es/def_config.sdcard .config $ make BOARD=icicle-kit-es The SD card image can be built from the Yocto BSP at: https://github.com/polarfire-soc/meta-polarfire-soc-yocto-bsp Note the generated SD card image should be resized before use: $ qemu-img resize /path/to/sdcard.img 4G Launch QEMU with the following command: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit -sd sdcard.img Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-9-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:39:03 +03:00
* 4) Cadence eMMC/SDHC controller and an SD card connected to it
hw/riscv: microchip_pfsoc: Connect a DMA controller On the Icicle Kit board, the HSS firmware utilizes the on-chip DMA controller to move the 2nd stage bootloader in the system memory. Let's connect a DMA controller to Microchip PolarFire SoC. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-11-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:39:05 +03:00
* 5) SiFive Platform DMA (Direct Memory Access Controller)
hw/riscv: microchip_pfsoc: Connect 2 Cadence GEMs Microchip PolarFire SoC integrates 2 Candence GEMs to provide IEEE 802.3 standard-compliant 10/100/1000 Mbps ethernet interface. On the Icicle Kit board, GEM0 connects to a PHY at address 8 while GEM1 connects to a PHY at address 9. The 2nd stage bootloader (U-Boot) is using GEM1 by default, so we must specify 2 '-nic' options from the command line in order to get a working ethernet. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <1598924352-89526-14-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:39:08 +03:00
* 6) GEM (Gigabit Ethernet MAC Controller)
hw/riscv: microchip_pfsoc: Connect DDR memory controller modules Connect DDR SGMII PHY module and CFG module to the PolarFire SoC. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1603863010-15807-4-git-send-email-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-10-28 08:30:03 +03:00
* 7) DMC (DDR Memory Controller)
hw/riscv: microchip_pfsoc: Connect the IOSCB module Previously IOSCB_CFG was created as an unimplemented device. With the new IOSCB model, its memory range is already covered by the IOSCB hence remove the previous unimplemented device creation in the SoC codes. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1603863010-15807-6-git-send-email-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-10-28 08:30:05 +03:00
* 8) IOSCB modules
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
*
* This board currently generates devicetree dynamically that indicates at least
* two harts and up to five harts.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
* version 2 or later, as published by the Free Software Foundation.
*
* This program is distributed in the hope it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
* more details.
*
* You should have received a copy of the GNU General Public License along with
* this program. If not, see <http://www.gnu.org/licenses/>.
*/
#include "qemu/osdep.h"
#include "qemu/error-report.h"
#include "qemu/units.h"
#include "qemu/cutils.h"
#include "qapi/error.h"
#include "hw/boards.h"
#include "hw/loader.h"
#include "hw/sysbus.h"
hw/riscv: microchip_pfsoc: Connect 5 MMUARTs Microchip PolarFire SoC has 5 MMUARTs, and the Icicle Kit board wires 4 of them out. Let's connect all 5 MMUARTs. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-7-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:39:01 +03:00
#include "chardev/char.h"
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
#include "hw/cpu/cluster.h"
#include "target/riscv/cpu.h"
#include "hw/misc/unimp.h"
#include "hw/riscv/boot.h"
#include "hw/riscv/riscv_hart.h"
#include "hw/riscv/microchip_pfsoc.h"
hw/intc: Rename sifive_clint sources to riscv_aclint sources We will be upgrading SiFive CLINT implementation into RISC-V ACLINT implementation so let's first rename the sources. Signed-off-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 20210831110603.338681-2-anup.patel@wdc.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-08-31 14:06:00 +03:00
#include "hw/intc/riscv_aclint.h"
hw/riscv: Move sifive_plic model to hw/intc This is an effort to clean up the hw/riscv directory. Ideally it should only contain the RISC-V SoC / machine codes plus generic codes. Let's move sifive_plic model to hw/intc directory. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1599129623-68957-7-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-03 13:40:17 +03:00
#include "hw/intc/sifive_plic.h"
hw/riscv: microchip_pfsoc: Support direct kernel boot At present the Microchip Icicle Kit machine only supports using '-bios' to load the HSS, and does not support '-kernel' for direct kernel booting just like other RISC-V machines do. One has to use U-Boot which is chain-loaded by HSS, to load a kernel for testing. This is not so convenient. Adding '-kernel' support together with the existing '-bios', we follow the following table to select which payload we execute: -bios | -kernel | payload ------+------------+-------- N | N | HSS Y | don't care | HSS N | Y | kernel This ensures backwards compatibility with how we used to expose '-bios' to users. When '-kernel' is used for direct boot, '-dtb' must be present to provide a valid device tree for the board, as we don't generate device tree. When direct kernel boot is used, the OpenSBI fw_dynamic BIOS image is used to boot a payload like U-Boot or OS kernel directly. Documentation is updated to describe the direct kernel boot. Note as of today there is still no PolarFire SoC support in the upstream Linux kernel hence the document does not include instructions for that. It will be updated in the future. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210430071302.1489082-8-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-04-30 10:13:02 +03:00
#include "sysemu/device_tree.h"
hw/riscv: microchip_pfsoc: Connect 5 MMUARTs Microchip PolarFire SoC has 5 MMUARTs, and the Icicle Kit board wires 4 of them out. Let's connect all 5 MMUARTs. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-7-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:39:01 +03:00
#include "sysemu/sysemu.h"
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
/*
* The BIOS image used by this machine is called Hart Software Services (HSS).
* See https://github.com/polarfire-soc/hart-software-services
*/
#define BIOS_FILENAME "hss.bin"
#define RESET_VECTOR 0x20220000
hw/riscv: clint: Avoid using hard-coded timebase frequency At present the CLINT timestamp is using a hard-coded timebase frequency value SIFIVE_CLINT_TIMEBASE_FREQ. This might not be true for all boards. Add a new 'timebase-freq' property to the CLINT device, and update various functions to accept this as a parameter. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-16-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:39:10 +03:00
/* CLINT timebase frequency */
#define CLINT_TIMEBASE_FREQ 1000000
hw/riscv: microchip_pfsoc: Connect 2 Cadence GEMs Microchip PolarFire SoC integrates 2 Candence GEMs to provide IEEE 802.3 standard-compliant 10/100/1000 Mbps ethernet interface. On the Icicle Kit board, GEM0 connects to a PHY at address 8 while GEM1 connects to a PHY at address 9. The 2nd stage bootloader (U-Boot) is using GEM1 by default, so we must specify 2 '-nic' options from the command line in order to get a working ethernet. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <1598924352-89526-14-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:39:08 +03:00
/* GEM version */
#define GEM_REVISION 0x0107010c
hw/riscv: microchip_pfsoc: Document where to look at the SoC memory maps It is not easy to find out the memory map for a specific component in the PolarFire SoC as the information is scattered in different documents. Add some comments so that people can know where to get such information from the Microchip website. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1603863010-15807-2-git-send-email-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-10-28 08:30:01 +03:00
/*
* The complete description of the whole PolarFire SoC memory map is scattered
* in different documents. There are several places to look at for memory maps:
*
* 1 Chapter 11 "MSS Memory Map", in the doc "UG0880: PolarFire SoC FPGA
* Microprocessor Subsystem (MSS) User Guide", which can be downloaded from
* https://www.microsemi.com/document-portal/doc_download/
* 1244570-ug0880-polarfire-soc-fpga-microprocessor-subsystem-mss-user-guide,
* describes the whole picture of the PolarFire SoC memory map.
*
* 2 A zip file for PolarFire soC memory map, which can be downloaded from
* https://www.microsemi.com/document-portal/doc_download/
* 1244581-polarfire-soc-register-map, contains the following 2 major parts:
* - Register Map/PF_SoC_RegMap_V1_1/pfsoc_regmap.htm
* describes the complete integrated peripherals memory map
* - Register Map/PF_SoC_RegMap_V1_1/MPFS250T/mpfs250t_ioscb_memmap_dri.htm
* describes the complete IOSCB modules memory maps
*/
hw/riscv: Drop 'struct MemmapEntry' There is already a MemMapEntry type defined in hwaddr.h. Let's drop the RISC-V defined `struct MemmapEntry` and use the existing one. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20210220144807.819-2-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-02-20 17:48:04 +03:00
static const MemMapEntry microchip_pfsoc_memmap[] = {
hw/riscv: pfsoc: add missing FICs as unimplemented The Fabric Interconnect Controllers provide interfaces between the FPGA fabric and the core complex. There are 5 FICs on PolarFire SoC, numbered 0 through 4. FIC2 is an AXI4 slave interface from the FPGA fabric and does not show up on the MSS memory map. FIC4 is dedicated to the User Crypto Processor and does not show up on the MSS memory map either. FIC 0, 1 & 3 do show up in the MSS memory map and neither FICs 0 or 1 are represented in QEMU, leading to load access violations while booting Linux for Icicle if PCIe is enabled as the root port is connected via either FIC 0 or 1. Acked-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Message-Id: <20221117225518.4102575-3-conor@kernel.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-11-18 01:55:17 +03:00
[MICROCHIP_PFSOC_RSVD0] = { 0x0, 0x100 },
[MICROCHIP_PFSOC_DEBUG] = { 0x100, 0xf00 },
[MICROCHIP_PFSOC_E51_DTIM] = { 0x1000000, 0x2000 },
[MICROCHIP_PFSOC_BUSERR_UNIT0] = { 0x1700000, 0x1000 },
[MICROCHIP_PFSOC_BUSERR_UNIT1] = { 0x1701000, 0x1000 },
[MICROCHIP_PFSOC_BUSERR_UNIT2] = { 0x1702000, 0x1000 },
[MICROCHIP_PFSOC_BUSERR_UNIT3] = { 0x1703000, 0x1000 },
[MICROCHIP_PFSOC_BUSERR_UNIT4] = { 0x1704000, 0x1000 },
[MICROCHIP_PFSOC_CLINT] = { 0x2000000, 0x10000 },
[MICROCHIP_PFSOC_L2CC] = { 0x2010000, 0x1000 },
[MICROCHIP_PFSOC_DMA] = { 0x3000000, 0x100000 },
[MICROCHIP_PFSOC_L2LIM] = { 0x8000000, 0x2000000 },
[MICROCHIP_PFSOC_PLIC] = { 0xc000000, 0x4000000 },
[MICROCHIP_PFSOC_MMUART0] = { 0x20000000, 0x1000 },
[MICROCHIP_PFSOC_WDOG0] = { 0x20001000, 0x1000 },
[MICROCHIP_PFSOC_SYSREG] = { 0x20002000, 0x2000 },
[MICROCHIP_PFSOC_AXISW] = { 0x20004000, 0x1000 },
[MICROCHIP_PFSOC_MPUCFG] = { 0x20005000, 0x1000 },
[MICROCHIP_PFSOC_FMETER] = { 0x20006000, 0x1000 },
[MICROCHIP_PFSOC_DDR_SGMII_PHY] = { 0x20007000, 0x1000 },
[MICROCHIP_PFSOC_EMMC_SD] = { 0x20008000, 0x1000 },
[MICROCHIP_PFSOC_DDR_CFG] = { 0x20080000, 0x40000 },
[MICROCHIP_PFSOC_MMUART1] = { 0x20100000, 0x1000 },
[MICROCHIP_PFSOC_MMUART2] = { 0x20102000, 0x1000 },
[MICROCHIP_PFSOC_MMUART3] = { 0x20104000, 0x1000 },
[MICROCHIP_PFSOC_MMUART4] = { 0x20106000, 0x1000 },
[MICROCHIP_PFSOC_WDOG1] = { 0x20101000, 0x1000 },
[MICROCHIP_PFSOC_WDOG2] = { 0x20103000, 0x1000 },
[MICROCHIP_PFSOC_WDOG3] = { 0x20105000, 0x1000 },
[MICROCHIP_PFSOC_WDOG4] = { 0x20106000, 0x1000 },
[MICROCHIP_PFSOC_SPI0] = { 0x20108000, 0x1000 },
[MICROCHIP_PFSOC_SPI1] = { 0x20109000, 0x1000 },
[MICROCHIP_PFSOC_I2C0] = { 0x2010a000, 0x1000 },
[MICROCHIP_PFSOC_I2C1] = { 0x2010b000, 0x1000 },
[MICROCHIP_PFSOC_CAN0] = { 0x2010c000, 0x1000 },
[MICROCHIP_PFSOC_CAN1] = { 0x2010d000, 0x1000 },
[MICROCHIP_PFSOC_GEM0] = { 0x20110000, 0x2000 },
[MICROCHIP_PFSOC_GEM1] = { 0x20112000, 0x2000 },
[MICROCHIP_PFSOC_GPIO0] = { 0x20120000, 0x1000 },
[MICROCHIP_PFSOC_GPIO1] = { 0x20121000, 0x1000 },
[MICROCHIP_PFSOC_GPIO2] = { 0x20122000, 0x1000 },
[MICROCHIP_PFSOC_RTC] = { 0x20124000, 0x1000 },
[MICROCHIP_PFSOC_ENVM_CFG] = { 0x20200000, 0x1000 },
[MICROCHIP_PFSOC_ENVM_DATA] = { 0x20220000, 0x20000 },
[MICROCHIP_PFSOC_USB] = { 0x20201000, 0x1000 },
[MICROCHIP_PFSOC_QSPI_XIP] = { 0x21000000, 0x1000000 },
[MICROCHIP_PFSOC_IOSCB] = { 0x30000000, 0x10000000 },
[MICROCHIP_PFSOC_FABRIC_FIC0] = { 0x2000000000, 0x1000000000 },
[MICROCHIP_PFSOC_FABRIC_FIC1] = { 0x3000000000, 0x1000000000 },
[MICROCHIP_PFSOC_FABRIC_FIC3] = { 0x40000000, 0x20000000 },
[MICROCHIP_PFSOC_DRAM_LO] = { 0x80000000, 0x40000000 },
[MICROCHIP_PFSOC_DRAM_LO_ALIAS] = { 0xc0000000, 0x40000000 },
[MICROCHIP_PFSOC_DRAM_HI] = { 0x1000000000, 0x0 },
[MICROCHIP_PFSOC_DRAM_HI_ALIAS] = { 0x1400000000, 0x0 },
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
};
static void microchip_pfsoc_soc_instance_init(Object *obj)
{
MachineState *ms = MACHINE(qdev_get_machine());
MicrochipPFSoCState *s = MICROCHIP_PFSOC(obj);
object_initialize_child(obj, "e-cluster", &s->e_cluster, TYPE_CPU_CLUSTER);
qdev_prop_set_uint32(DEVICE(&s->e_cluster), "cluster-id", 0);
object_initialize_child(OBJECT(&s->e_cluster), "e-cpus", &s->e_cpus,
TYPE_RISCV_HART_ARRAY);
qdev_prop_set_uint32(DEVICE(&s->e_cpus), "num-harts", 1);
qdev_prop_set_uint32(DEVICE(&s->e_cpus), "hartid-base", 0);
qdev_prop_set_string(DEVICE(&s->e_cpus), "cpu-type",
TYPE_RISCV_CPU_SIFIVE_E51);
qdev_prop_set_uint64(DEVICE(&s->e_cpus), "resetvec", RESET_VECTOR);
object_initialize_child(obj, "u-cluster", &s->u_cluster, TYPE_CPU_CLUSTER);
qdev_prop_set_uint32(DEVICE(&s->u_cluster), "cluster-id", 1);
object_initialize_child(OBJECT(&s->u_cluster), "u-cpus", &s->u_cpus,
TYPE_RISCV_HART_ARRAY);
qdev_prop_set_uint32(DEVICE(&s->u_cpus), "num-harts", ms->smp.cpus - 1);
qdev_prop_set_uint32(DEVICE(&s->u_cpus), "hartid-base", 1);
qdev_prop_set_string(DEVICE(&s->u_cpus), "cpu-type",
TYPE_RISCV_CPU_SIFIVE_U54);
qdev_prop_set_uint64(DEVICE(&s->u_cpus), "resetvec", RESET_VECTOR);
hw/riscv: microchip_pfsoc: Connect a Cadence SDHCI controller and an SD card Microchip PolarFire SoC integrates one Cadence SDHCI controller. On the Icicle Kit board, one eMMC chip and an external SD card connect to this controller depending on different configuration. As QEMU does not support eMMC yet, we just emulate the SD card configuration. To test this, the Hart Software Services (HSS) should choose the SD card configuration: $ cp boards/icicle-kit-es/def_config.sdcard .config $ make BOARD=icicle-kit-es The SD card image can be built from the Yocto BSP at: https://github.com/polarfire-soc/meta-polarfire-soc-yocto-bsp Note the generated SD card image should be resized before use: $ qemu-img resize /path/to/sdcard.img 4G Launch QEMU with the following command: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit -sd sdcard.img Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-9-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:39:03 +03:00
hw/riscv: microchip_pfsoc: Connect a DMA controller On the Icicle Kit board, the HSS firmware utilizes the on-chip DMA controller to move the 2nd stage bootloader in the system memory. Let's connect a DMA controller to Microchip PolarFire SoC. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-11-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:39:05 +03:00
object_initialize_child(obj, "dma-controller", &s->dma,
TYPE_SIFIVE_PDMA);
hw/riscv: microchip_pfsoc: Connect the SYSREG module Previously SYSREG was created as an unimplemented device. Now that we have a simple SYSREG module, connect it. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1603863010-15807-8-git-send-email-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-10-28 08:30:07 +03:00
object_initialize_child(obj, "sysreg", &s->sysreg,
TYPE_MCHP_PFSOC_SYSREG);
hw/riscv: microchip_pfsoc: Connect DDR memory controller modules Connect DDR SGMII PHY module and CFG module to the PolarFire SoC. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1603863010-15807-4-git-send-email-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-10-28 08:30:03 +03:00
object_initialize_child(obj, "ddr-sgmii-phy", &s->ddr_sgmii_phy,
TYPE_MCHP_PFSOC_DDR_SGMII_PHY);
object_initialize_child(obj, "ddr-cfg", &s->ddr_cfg,
TYPE_MCHP_PFSOC_DDR_CFG);
hw/riscv: microchip_pfsoc: Connect 2 Cadence GEMs Microchip PolarFire SoC integrates 2 Candence GEMs to provide IEEE 802.3 standard-compliant 10/100/1000 Mbps ethernet interface. On the Icicle Kit board, GEM0 connects to a PHY at address 8 while GEM1 connects to a PHY at address 9. The 2nd stage bootloader (U-Boot) is using GEM1 by default, so we must specify 2 '-nic' options from the command line in order to get a working ethernet. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <1598924352-89526-14-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:39:08 +03:00
object_initialize_child(obj, "gem0", &s->gem0, TYPE_CADENCE_GEM);
object_initialize_child(obj, "gem1", &s->gem1, TYPE_CADENCE_GEM);
hw/riscv: microchip_pfsoc: Connect a Cadence SDHCI controller and an SD card Microchip PolarFire SoC integrates one Cadence SDHCI controller. On the Icicle Kit board, one eMMC chip and an external SD card connect to this controller depending on different configuration. As QEMU does not support eMMC yet, we just emulate the SD card configuration. To test this, the Hart Software Services (HSS) should choose the SD card configuration: $ cp boards/icicle-kit-es/def_config.sdcard .config $ make BOARD=icicle-kit-es The SD card image can be built from the Yocto BSP at: https://github.com/polarfire-soc/meta-polarfire-soc-yocto-bsp Note the generated SD card image should be resized before use: $ qemu-img resize /path/to/sdcard.img 4G Launch QEMU with the following command: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit -sd sdcard.img Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-9-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:39:03 +03:00
object_initialize_child(obj, "sd-controller", &s->sdhci,
TYPE_CADENCE_SDHCI);
hw/riscv: microchip_pfsoc: Connect the IOSCB module Previously IOSCB_CFG was created as an unimplemented device. With the new IOSCB model, its memory range is already covered by the IOSCB hence remove the previous unimplemented device creation in the SoC codes. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1603863010-15807-6-git-send-email-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-10-28 08:30:05 +03:00
object_initialize_child(obj, "ioscb", &s->ioscb, TYPE_MCHP_PFSOC_IOSCB);
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
}
static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
{
MachineState *ms = MACHINE(qdev_get_machine());
MicrochipPFSoCState *s = MICROCHIP_PFSOC(dev);
hw/riscv: Drop 'struct MemmapEntry' There is already a MemMapEntry type defined in hwaddr.h. Let's drop the RISC-V defined `struct MemmapEntry` and use the existing one. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20210220144807.819-2-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-02-20 17:48:04 +03:00
const MemMapEntry *memmap = microchip_pfsoc_memmap;
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
MemoryRegion *system_memory = get_system_memory();
hw/riscv: microchip_pfsoc: Map the reserved memory at address 0 Somehow HSS needs to access address 0 [1] for the DDR calibration data which is in the chipset's reserved memory. Let's map it. [1] See the config_copy() calls in various places in ddr_setup() in the HSS source codes. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1603863010-15807-9-git-send-email-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-10-28 08:30:08 +03:00
MemoryRegion *rsvd0_mem = g_new(MemoryRegion, 1);
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
MemoryRegion *e51_dtim_mem = g_new(MemoryRegion, 1);
MemoryRegion *l2lim_mem = g_new(MemoryRegion, 1);
MemoryRegion *envm_data = g_new(MemoryRegion, 1);
hw/riscv: microchip_pfsoc: add QSPI NOR flash Add QSPI NOR flash definition for Microchip PolarFire SoC. Signed-off-by: Vitaly Wool <vitaly.wool@konsulko.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Message-id: 20201112074950.33283-1-vitaly.wool@konsulko.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-11-12 10:49:51 +03:00
MemoryRegion *qspi_xip_mem = g_new(MemoryRegion, 1);
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
char *plic_hart_config;
int i;
sysbus_realize(SYS_BUS_DEVICE(&s->e_cpus), &error_abort);
sysbus_realize(SYS_BUS_DEVICE(&s->u_cpus), &error_abort);
/*
* The cluster must be realized after the RISC-V hart array container,
* as the container's CPU object is only created on realize, and the
* CPU must exist and have been parented into the cluster before the
* cluster is realized.
*/
qdev_realize(DEVICE(&s->e_cluster), NULL, &error_abort);
qdev_realize(DEVICE(&s->u_cluster), NULL, &error_abort);
hw/riscv: microchip_pfsoc: Map the reserved memory at address 0 Somehow HSS needs to access address 0 [1] for the DDR calibration data which is in the chipset's reserved memory. Let's map it. [1] See the config_copy() calls in various places in ddr_setup() in the HSS source codes. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1603863010-15807-9-git-send-email-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-10-28 08:30:08 +03:00
/* Reserved Memory at address 0 */
memory_region_init_ram(rsvd0_mem, NULL, "microchip.pfsoc.rsvd0_mem",
memmap[MICROCHIP_PFSOC_RSVD0].size, &error_fatal);
memory_region_add_subregion(system_memory,
memmap[MICROCHIP_PFSOC_RSVD0].base,
rsvd0_mem);
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
/* E51 DTIM */
memory_region_init_ram(e51_dtim_mem, NULL, "microchip.pfsoc.e51_dtim_mem",
memmap[MICROCHIP_PFSOC_E51_DTIM].size, &error_fatal);
memory_region_add_subregion(system_memory,
memmap[MICROCHIP_PFSOC_E51_DTIM].base,
e51_dtim_mem);
/* Bus Error Units */
create_unimplemented_device("microchip.pfsoc.buserr_unit0_mem",
memmap[MICROCHIP_PFSOC_BUSERR_UNIT0].base,
memmap[MICROCHIP_PFSOC_BUSERR_UNIT0].size);
create_unimplemented_device("microchip.pfsoc.buserr_unit1_mem",
memmap[MICROCHIP_PFSOC_BUSERR_UNIT1].base,
memmap[MICROCHIP_PFSOC_BUSERR_UNIT1].size);
create_unimplemented_device("microchip.pfsoc.buserr_unit2_mem",
memmap[MICROCHIP_PFSOC_BUSERR_UNIT2].base,
memmap[MICROCHIP_PFSOC_BUSERR_UNIT2].size);
create_unimplemented_device("microchip.pfsoc.buserr_unit3_mem",
memmap[MICROCHIP_PFSOC_BUSERR_UNIT3].base,
memmap[MICROCHIP_PFSOC_BUSERR_UNIT3].size);
create_unimplemented_device("microchip.pfsoc.buserr_unit4_mem",
memmap[MICROCHIP_PFSOC_BUSERR_UNIT4].base,
memmap[MICROCHIP_PFSOC_BUSERR_UNIT4].size);
/* CLINT */
hw/intc: Upgrade the SiFive CLINT implementation to RISC-V ACLINT The RISC-V ACLINT is more modular and backward compatible with original SiFive CLINT so instead of duplicating the original SiFive CLINT implementation we upgrade the current SiFive CLINT implementation to RISC-V ACLINT implementation. Signed-off-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 20210831110603.338681-3-anup.patel@wdc.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-08-31 14:06:01 +03:00
riscv_aclint_swi_create(memmap[MICROCHIP_PFSOC_CLINT].base,
0, ms->smp.cpus, false);
riscv_aclint_mtimer_create(
memmap[MICROCHIP_PFSOC_CLINT].base + RISCV_ACLINT_SWI_SIZE,
RISCV_ACLINT_DEFAULT_MTIMER_SIZE, 0, ms->smp.cpus,
RISCV_ACLINT_DEFAULT_MTIMECMP, RISCV_ACLINT_DEFAULT_MTIME,
hw/riscv: clint: Avoid using hard-coded timebase frequency At present the CLINT timestamp is using a hard-coded timebase frequency value SIFIVE_CLINT_TIMEBASE_FREQ. This might not be true for all boards. Add a new 'timebase-freq' property to the CLINT device, and update various functions to accept this as a parameter. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-16-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:39:10 +03:00
CLINT_TIMEBASE_FREQ, false);
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
/* L2 cache controller */
create_unimplemented_device("microchip.pfsoc.l2cc",
memmap[MICROCHIP_PFSOC_L2CC].base, memmap[MICROCHIP_PFSOC_L2CC].size);
/*
* Add L2-LIM at reset size.
* This should be reduced in size as the L2 Cache Controller WayEnable
* register is incremented. Unfortunately I don't see a nice (or any) way
* to handle reducing or blocking out the L2 LIM while still allowing it
* be re returned to all enabled after a reset. For the time being, just
* leave it enabled all the time. This won't break anything, but will be
* too generous to misbehaving guests.
*/
memory_region_init_ram(l2lim_mem, NULL, "microchip.pfsoc.l2lim",
memmap[MICROCHIP_PFSOC_L2LIM].size, &error_fatal);
memory_region_add_subregion(system_memory,
memmap[MICROCHIP_PFSOC_L2LIM].base,
l2lim_mem);
/* create PLIC hart topology configuration string */
hw/riscv: microchip_pfsoc: Use the PLIC config helper function Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 20211022060133.3045020-4-alistair.francis@opensource.wdc.com
2021-10-22 09:01:32 +03:00
plic_hart_config = riscv_plic_hart_config_string(ms->smp.cpus);
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
/* PLIC */
s->plic = sifive_plic_create(memmap[MICROCHIP_PFSOC_PLIC].base,
hw/intc: sifive_plic: Convert the PLIC to use RISC-V CPU GPIO lines Instead of using riscv_cpu_update_mip() let's instead use the new RISC-V CPU GPIO lines to set the external MIP bits. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 0364190bfa935058a845c0fa1ecf650328840ad5.1630301632.git.alistair.francis@wdc.com
2021-08-30 08:35:02 +03:00
plic_hart_config, ms->smp.cpus, 0,
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
MICROCHIP_PFSOC_PLIC_NUM_SOURCES,
MICROCHIP_PFSOC_PLIC_NUM_PRIORITIES,
MICROCHIP_PFSOC_PLIC_PRIORITY_BASE,
MICROCHIP_PFSOC_PLIC_PENDING_BASE,
MICROCHIP_PFSOC_PLIC_ENABLE_BASE,
MICROCHIP_PFSOC_PLIC_ENABLE_STRIDE,
MICROCHIP_PFSOC_PLIC_CONTEXT_BASE,
MICROCHIP_PFSOC_PLIC_CONTEXT_STRIDE,
memmap[MICROCHIP_PFSOC_PLIC].size);
g_free(plic_hart_config);
hw/riscv: microchip_pfsoc: Connect a DMA controller On the Icicle Kit board, the HSS firmware utilizes the on-chip DMA controller to move the 2nd stage bootloader in the system memory. Let's connect a DMA controller to Microchip PolarFire SoC. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-11-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:39:05 +03:00
/* DMA */
sysbus_realize(SYS_BUS_DEVICE(&s->dma), errp);
sysbus_mmio_map(SYS_BUS_DEVICE(&s->dma), 0,
memmap[MICROCHIP_PFSOC_DMA].base);
for (i = 0; i < SIFIVE_PDMA_IRQS; i++) {
sysbus_connect_irq(SYS_BUS_DEVICE(&s->dma), i,
qdev_get_gpio_in(DEVICE(s->plic),
MICROCHIP_PFSOC_DMA_IRQ0 + i));
}
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
/* SYSREG */
hw/riscv: microchip_pfsoc: Connect the SYSREG module Previously SYSREG was created as an unimplemented device. Now that we have a simple SYSREG module, connect it. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1603863010-15807-8-git-send-email-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-10-28 08:30:07 +03:00
sysbus_realize(SYS_BUS_DEVICE(&s->sysreg), errp);
sysbus_mmio_map(SYS_BUS_DEVICE(&s->sysreg), 0,
memmap[MICROCHIP_PFSOC_SYSREG].base);
hw/{misc, riscv}: pfsoc: add system controller as unimplemented The system controller on PolarFire SoC is access via a mailbox. The control registers for this mailbox lie in the "IOSCB" region & the interrupt is cleared via write to the "SYSREG" region. It also has a QSPI controller, usually connected to a flash chip, that is used for storing FPGA bitstreams and used for In-Application Programming (IAP). Linux has an implementation of the system controller, through which the hwrng is accessed, leading to load/store access faults. Add the QSPI as unimplemented and a very basic (effectively unimplemented) version of the system controller's mailbox. Rather than purely marking the regions as unimplemented, service the mailbox requests by reporting failures and raising the interrupt so a guest can better handle the lack of support. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20221117225518.4102575-4-conor@kernel.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-11-18 01:55:18 +03:00
sysbus_connect_irq(SYS_BUS_DEVICE(&s->sysreg), 0,
qdev_get_gpio_in(DEVICE(s->plic),
MICROCHIP_PFSOC_MAILBOX_IRQ));
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
hw/riscv: microchip_pfsoc: fix kernel panics due to missing peripherals Booting using "Direct Kernel Boot" for PolarFire SoC & skipping u-boot entirely is probably not advisable, but it does at least show signs of life. Recent Linux kernel versions make use of peripherals that are missing definitions in QEMU and lead to kernel panics. These issues almost certain rear their head for other methods of booting, but I was unable to figure out a suitable HSS version that is recent enough to support these peripherals & works with QEMU. With these peripherals added, booting a kernel with the following hangs hangs waiting for the system controller's hwrng, but the kernel no longer panics. With the Linux driver for hwrng disabled, it boots to console. qemu-system-riscv64 -M microchip-icicle-kit \ -m 2G -smp 5 \ -kernel $(vmlinux_bin) \ -dtb $(dtb)\ -initrd $(initramfs) \ -display none -serial null \ -serial stdio More peripherals are added than strictly required to fix the panics in the hopes of avoiding a replication of this problem in the future. Some of the peripherals which are in the device tree for recent kernels are implemented in the FPGA fabric. The eMMC/SD mux, which exists as an unimplemented device is replaced by a wider entry. This updated entry covers both the mux & the remainder of the FPGA fabric connected to the MSS using Fabric Interrconnect (FIC) 3. Link: https://github.com/polarfire-soc/icicle-kit-reference-design#fabric-memory-map Link: https://ww1.microchip.com/downloads/aemDocuments/documents/FPGA/ProductDocuments/SupportingCollateral/V1_4_Register_Map.zip Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20220813135127.2971754-1-mail@conchuod.ie> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-08-13 16:51:27 +03:00
/* AXISW */
create_unimplemented_device("microchip.pfsoc.axisw",
memmap[MICROCHIP_PFSOC_AXISW].base,
memmap[MICROCHIP_PFSOC_AXISW].size);
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
/* MPUCFG */
create_unimplemented_device("microchip.pfsoc.mpucfg",
memmap[MICROCHIP_PFSOC_MPUCFG].base,
memmap[MICROCHIP_PFSOC_MPUCFG].size);
hw/riscv: microchip_pfsoc: fix kernel panics due to missing peripherals Booting using "Direct Kernel Boot" for PolarFire SoC & skipping u-boot entirely is probably not advisable, but it does at least show signs of life. Recent Linux kernel versions make use of peripherals that are missing definitions in QEMU and lead to kernel panics. These issues almost certain rear their head for other methods of booting, but I was unable to figure out a suitable HSS version that is recent enough to support these peripherals & works with QEMU. With these peripherals added, booting a kernel with the following hangs hangs waiting for the system controller's hwrng, but the kernel no longer panics. With the Linux driver for hwrng disabled, it boots to console. qemu-system-riscv64 -M microchip-icicle-kit \ -m 2G -smp 5 \ -kernel $(vmlinux_bin) \ -dtb $(dtb)\ -initrd $(initramfs) \ -display none -serial null \ -serial stdio More peripherals are added than strictly required to fix the panics in the hopes of avoiding a replication of this problem in the future. Some of the peripherals which are in the device tree for recent kernels are implemented in the FPGA fabric. The eMMC/SD mux, which exists as an unimplemented device is replaced by a wider entry. This updated entry covers both the mux & the remainder of the FPGA fabric connected to the MSS using Fabric Interrconnect (FIC) 3. Link: https://github.com/polarfire-soc/icicle-kit-reference-design#fabric-memory-map Link: https://ww1.microchip.com/downloads/aemDocuments/documents/FPGA/ProductDocuments/SupportingCollateral/V1_4_Register_Map.zip Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20220813135127.2971754-1-mail@conchuod.ie> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-08-13 16:51:27 +03:00
/* FMETER */
create_unimplemented_device("microchip.pfsoc.fmeter",
memmap[MICROCHIP_PFSOC_FMETER].base,
memmap[MICROCHIP_PFSOC_FMETER].size);
hw/riscv: microchip_pfsoc: Connect DDR memory controller modules Connect DDR SGMII PHY module and CFG module to the PolarFire SoC. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1603863010-15807-4-git-send-email-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-10-28 08:30:03 +03:00
/* DDR SGMII PHY */
sysbus_realize(SYS_BUS_DEVICE(&s->ddr_sgmii_phy), errp);
sysbus_mmio_map(SYS_BUS_DEVICE(&s->ddr_sgmii_phy), 0,
memmap[MICROCHIP_PFSOC_DDR_SGMII_PHY].base);
/* DDR CFG */
sysbus_realize(SYS_BUS_DEVICE(&s->ddr_cfg), errp);
sysbus_mmio_map(SYS_BUS_DEVICE(&s->ddr_cfg), 0,
memmap[MICROCHIP_PFSOC_DDR_CFG].base);
hw/riscv: microchip_pfsoc: Connect a Cadence SDHCI controller and an SD card Microchip PolarFire SoC integrates one Cadence SDHCI controller. On the Icicle Kit board, one eMMC chip and an external SD card connect to this controller depending on different configuration. As QEMU does not support eMMC yet, we just emulate the SD card configuration. To test this, the Hart Software Services (HSS) should choose the SD card configuration: $ cp boards/icicle-kit-es/def_config.sdcard .config $ make BOARD=icicle-kit-es The SD card image can be built from the Yocto BSP at: https://github.com/polarfire-soc/meta-polarfire-soc-yocto-bsp Note the generated SD card image should be resized before use: $ qemu-img resize /path/to/sdcard.img 4G Launch QEMU with the following command: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit -sd sdcard.img Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-9-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:39:03 +03:00
/* SDHCI */
sysbus_realize(SYS_BUS_DEVICE(&s->sdhci), errp);
sysbus_mmio_map(SYS_BUS_DEVICE(&s->sdhci), 0,
memmap[MICROCHIP_PFSOC_EMMC_SD].base);
sysbus_connect_irq(SYS_BUS_DEVICE(&s->sdhci), 0,
qdev_get_gpio_in(DEVICE(s->plic), MICROCHIP_PFSOC_EMMC_SD_IRQ));
hw/riscv: microchip_pfsoc: Connect 5 MMUARTs Microchip PolarFire SoC has 5 MMUARTs, and the Icicle Kit board wires 4 of them out. Let's connect all 5 MMUARTs. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-7-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:39:01 +03:00
/* MMUARTs */
s->serial0 = mchp_pfsoc_mmuart_create(system_memory,
memmap[MICROCHIP_PFSOC_MMUART0].base,
qdev_get_gpio_in(DEVICE(s->plic), MICROCHIP_PFSOC_MMUART0_IRQ),
serial_hd(0));
s->serial1 = mchp_pfsoc_mmuart_create(system_memory,
memmap[MICROCHIP_PFSOC_MMUART1].base,
qdev_get_gpio_in(DEVICE(s->plic), MICROCHIP_PFSOC_MMUART1_IRQ),
serial_hd(1));
s->serial2 = mchp_pfsoc_mmuart_create(system_memory,
memmap[MICROCHIP_PFSOC_MMUART2].base,
qdev_get_gpio_in(DEVICE(s->plic), MICROCHIP_PFSOC_MMUART2_IRQ),
serial_hd(2));
s->serial3 = mchp_pfsoc_mmuart_create(system_memory,
memmap[MICROCHIP_PFSOC_MMUART3].base,
qdev_get_gpio_in(DEVICE(s->plic), MICROCHIP_PFSOC_MMUART3_IRQ),
serial_hd(3));
s->serial4 = mchp_pfsoc_mmuart_create(system_memory,
memmap[MICROCHIP_PFSOC_MMUART4].base,
qdev_get_gpio_in(DEVICE(s->plic), MICROCHIP_PFSOC_MMUART4_IRQ),
serial_hd(4));
hw/riscv: microchip_pfsoc: fix kernel panics due to missing peripherals Booting using "Direct Kernel Boot" for PolarFire SoC & skipping u-boot entirely is probably not advisable, but it does at least show signs of life. Recent Linux kernel versions make use of peripherals that are missing definitions in QEMU and lead to kernel panics. These issues almost certain rear their head for other methods of booting, but I was unable to figure out a suitable HSS version that is recent enough to support these peripherals & works with QEMU. With these peripherals added, booting a kernel with the following hangs hangs waiting for the system controller's hwrng, but the kernel no longer panics. With the Linux driver for hwrng disabled, it boots to console. qemu-system-riscv64 -M microchip-icicle-kit \ -m 2G -smp 5 \ -kernel $(vmlinux_bin) \ -dtb $(dtb)\ -initrd $(initramfs) \ -display none -serial null \ -serial stdio More peripherals are added than strictly required to fix the panics in the hopes of avoiding a replication of this problem in the future. Some of the peripherals which are in the device tree for recent kernels are implemented in the FPGA fabric. The eMMC/SD mux, which exists as an unimplemented device is replaced by a wider entry. This updated entry covers both the mux & the remainder of the FPGA fabric connected to the MSS using Fabric Interrconnect (FIC) 3. Link: https://github.com/polarfire-soc/icicle-kit-reference-design#fabric-memory-map Link: https://ww1.microchip.com/downloads/aemDocuments/documents/FPGA/ProductDocuments/SupportingCollateral/V1_4_Register_Map.zip Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20220813135127.2971754-1-mail@conchuod.ie> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-08-13 16:51:27 +03:00
/* Watchdogs */
create_unimplemented_device("microchip.pfsoc.watchdog0",
memmap[MICROCHIP_PFSOC_WDOG0].base,
memmap[MICROCHIP_PFSOC_WDOG0].size);
create_unimplemented_device("microchip.pfsoc.watchdog1",
memmap[MICROCHIP_PFSOC_WDOG1].base,
memmap[MICROCHIP_PFSOC_WDOG1].size);
create_unimplemented_device("microchip.pfsoc.watchdog2",
memmap[MICROCHIP_PFSOC_WDOG2].base,
memmap[MICROCHIP_PFSOC_WDOG2].size);
create_unimplemented_device("microchip.pfsoc.watchdog3",
memmap[MICROCHIP_PFSOC_WDOG3].base,
memmap[MICROCHIP_PFSOC_WDOG3].size);
create_unimplemented_device("microchip.pfsoc.watchdog4",
memmap[MICROCHIP_PFSOC_WDOG4].base,
memmap[MICROCHIP_PFSOC_WDOG4].size);
hw/riscv: microchip_pfsoc: add QSPI NOR flash Add QSPI NOR flash definition for Microchip PolarFire SoC. Signed-off-by: Vitaly Wool <vitaly.wool@konsulko.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Message-id: 20201112074950.33283-1-vitaly.wool@konsulko.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-11-12 10:49:51 +03:00
/* SPI */
create_unimplemented_device("microchip.pfsoc.spi0",
memmap[MICROCHIP_PFSOC_SPI0].base,
memmap[MICROCHIP_PFSOC_SPI0].size);
create_unimplemented_device("microchip.pfsoc.spi1",
memmap[MICROCHIP_PFSOC_SPI1].base,
memmap[MICROCHIP_PFSOC_SPI1].size);
hw/riscv: microchip_pfsoc: fix kernel panics due to missing peripherals Booting using "Direct Kernel Boot" for PolarFire SoC & skipping u-boot entirely is probably not advisable, but it does at least show signs of life. Recent Linux kernel versions make use of peripherals that are missing definitions in QEMU and lead to kernel panics. These issues almost certain rear their head for other methods of booting, but I was unable to figure out a suitable HSS version that is recent enough to support these peripherals & works with QEMU. With these peripherals added, booting a kernel with the following hangs hangs waiting for the system controller's hwrng, but the kernel no longer panics. With the Linux driver for hwrng disabled, it boots to console. qemu-system-riscv64 -M microchip-icicle-kit \ -m 2G -smp 5 \ -kernel $(vmlinux_bin) \ -dtb $(dtb)\ -initrd $(initramfs) \ -display none -serial null \ -serial stdio More peripherals are added than strictly required to fix the panics in the hopes of avoiding a replication of this problem in the future. Some of the peripherals which are in the device tree for recent kernels are implemented in the FPGA fabric. The eMMC/SD mux, which exists as an unimplemented device is replaced by a wider entry. This updated entry covers both the mux & the remainder of the FPGA fabric connected to the MSS using Fabric Interrconnect (FIC) 3. Link: https://github.com/polarfire-soc/icicle-kit-reference-design#fabric-memory-map Link: https://ww1.microchip.com/downloads/aemDocuments/documents/FPGA/ProductDocuments/SupportingCollateral/V1_4_Register_Map.zip Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20220813135127.2971754-1-mail@conchuod.ie> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-08-13 16:51:27 +03:00
/* I2C */
create_unimplemented_device("microchip.pfsoc.i2c0",
memmap[MICROCHIP_PFSOC_I2C0].base,
memmap[MICROCHIP_PFSOC_I2C0].size);
hw/riscv: microchip_pfsoc: Hook the I2C1 controller The latest SD card image [1] released by Microchip ships a Linux kernel with built-in PolarFire SoC I2C driver support. The device tree file includes the description for the I2C1 node hence kernel tries to probe the I2C1 device during boot. It is enough to create an unimplemented device for I2C1 to allow the kernel to continue booting to the shell. [1] ftp://ftpsoc.microsemi.com/outgoing/core-image-minimal-dev-icicle-kit-es-sd-20201009141623.rootfs.wic.gz Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1603863010-15807-11-git-send-email-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-10-28 08:30:10 +03:00
create_unimplemented_device("microchip.pfsoc.i2c1",
memmap[MICROCHIP_PFSOC_I2C1].base,
memmap[MICROCHIP_PFSOC_I2C1].size);
hw/riscv: microchip_pfsoc: fix kernel panics due to missing peripherals Booting using "Direct Kernel Boot" for PolarFire SoC & skipping u-boot entirely is probably not advisable, but it does at least show signs of life. Recent Linux kernel versions make use of peripherals that are missing definitions in QEMU and lead to kernel panics. These issues almost certain rear their head for other methods of booting, but I was unable to figure out a suitable HSS version that is recent enough to support these peripherals & works with QEMU. With these peripherals added, booting a kernel with the following hangs hangs waiting for the system controller's hwrng, but the kernel no longer panics. With the Linux driver for hwrng disabled, it boots to console. qemu-system-riscv64 -M microchip-icicle-kit \ -m 2G -smp 5 \ -kernel $(vmlinux_bin) \ -dtb $(dtb)\ -initrd $(initramfs) \ -display none -serial null \ -serial stdio More peripherals are added than strictly required to fix the panics in the hopes of avoiding a replication of this problem in the future. Some of the peripherals which are in the device tree for recent kernels are implemented in the FPGA fabric. The eMMC/SD mux, which exists as an unimplemented device is replaced by a wider entry. This updated entry covers both the mux & the remainder of the FPGA fabric connected to the MSS using Fabric Interrconnect (FIC) 3. Link: https://github.com/polarfire-soc/icicle-kit-reference-design#fabric-memory-map Link: https://ww1.microchip.com/downloads/aemDocuments/documents/FPGA/ProductDocuments/SupportingCollateral/V1_4_Register_Map.zip Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20220813135127.2971754-1-mail@conchuod.ie> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-08-13 16:51:27 +03:00
/* CAN */
create_unimplemented_device("microchip.pfsoc.can0",
memmap[MICROCHIP_PFSOC_CAN0].base,
memmap[MICROCHIP_PFSOC_CAN0].size);
create_unimplemented_device("microchip.pfsoc.can1",
memmap[MICROCHIP_PFSOC_CAN1].base,
memmap[MICROCHIP_PFSOC_CAN1].size);
/* USB */
create_unimplemented_device("microchip.pfsoc.usb",
memmap[MICROCHIP_PFSOC_USB].base,
memmap[MICROCHIP_PFSOC_USB].size);
hw/riscv: microchip_pfsoc: Connect 2 Cadence GEMs Microchip PolarFire SoC integrates 2 Candence GEMs to provide IEEE 802.3 standard-compliant 10/100/1000 Mbps ethernet interface. On the Icicle Kit board, GEM0 connects to a PHY at address 8 while GEM1 connects to a PHY at address 9. The 2nd stage bootloader (U-Boot) is using GEM1 by default, so we must specify 2 '-nic' options from the command line in order to get a working ethernet. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <1598924352-89526-14-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:39:08 +03:00
/* GEMs */
hw/riscv: use qemu_configure_nic_device() Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Thomas Huth <thuth@redhat.com>
2023-10-23 11:37:53 +03:00
qemu_configure_nic_device(DEVICE(&s->gem0), true, NULL);
qemu_configure_nic_device(DEVICE(&s->gem1), true, NULL);
hw/riscv: microchip_pfsoc: Connect 2 Cadence GEMs Microchip PolarFire SoC integrates 2 Candence GEMs to provide IEEE 802.3 standard-compliant 10/100/1000 Mbps ethernet interface. On the Icicle Kit board, GEM0 connects to a PHY at address 8 while GEM1 connects to a PHY at address 9. The 2nd stage bootloader (U-Boot) is using GEM1 by default, so we must specify 2 '-nic' options from the command line in order to get a working ethernet. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <1598924352-89526-14-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:39:08 +03:00
object_property_set_int(OBJECT(&s->gem0), "revision", GEM_REVISION, errp);
object_property_set_int(OBJECT(&s->gem0), "phy-addr", 8, errp);
sysbus_realize(SYS_BUS_DEVICE(&s->gem0), errp);
sysbus_mmio_map(SYS_BUS_DEVICE(&s->gem0), 0,
memmap[MICROCHIP_PFSOC_GEM0].base);
sysbus_connect_irq(SYS_BUS_DEVICE(&s->gem0), 0,
qdev_get_gpio_in(DEVICE(s->plic), MICROCHIP_PFSOC_GEM0_IRQ));
object_property_set_int(OBJECT(&s->gem1), "revision", GEM_REVISION, errp);
object_property_set_int(OBJECT(&s->gem1), "phy-addr", 9, errp);
sysbus_realize(SYS_BUS_DEVICE(&s->gem1), errp);
sysbus_mmio_map(SYS_BUS_DEVICE(&s->gem1), 0,
memmap[MICROCHIP_PFSOC_GEM1].base);
sysbus_connect_irq(SYS_BUS_DEVICE(&s->gem1), 0,
qdev_get_gpio_in(DEVICE(s->plic), MICROCHIP_PFSOC_GEM1_IRQ));
hw/riscv: microchip_pfsoc: Hook GPIO controllers Microchip PolarFire SoC integrates 3 GPIOs controllers. It seems enough to create unimplemented devices to cover their register spaces at this point. With this commit, QEMU can boot to U-Boot (2nd stage bootloader) all the way to the Linux shell login prompt, with a modified HSS (1st stage bootloader). For detailed instructions on how to create images for the Icicle Kit board, please check QEMU RISC-V WiKi page at: https://wiki.qemu.org/Documentation/Platforms/RISCV Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <1598924352-89526-15-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:39:09 +03:00
/* GPIOs */
create_unimplemented_device("microchip.pfsoc.gpio0",
memmap[MICROCHIP_PFSOC_GPIO0].base,
memmap[MICROCHIP_PFSOC_GPIO0].size);
create_unimplemented_device("microchip.pfsoc.gpio1",
memmap[MICROCHIP_PFSOC_GPIO1].base,
memmap[MICROCHIP_PFSOC_GPIO1].size);
create_unimplemented_device("microchip.pfsoc.gpio2",
memmap[MICROCHIP_PFSOC_GPIO2].base,
memmap[MICROCHIP_PFSOC_GPIO2].size);
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
/* eNVM */
memory_region_init_rom(envm_data, OBJECT(dev), "microchip.pfsoc.envm.data",
memmap[MICROCHIP_PFSOC_ENVM_DATA].size,
&error_fatal);
memory_region_add_subregion(system_memory,
memmap[MICROCHIP_PFSOC_ENVM_DATA].base,
envm_data);
hw/riscv: microchip_pfsoc: Connect the IOSCB module Previously IOSCB_CFG was created as an unimplemented device. With the new IOSCB model, its memory range is already covered by the IOSCB hence remove the previous unimplemented device creation in the SoC codes. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1603863010-15807-6-git-send-email-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-10-28 08:30:05 +03:00
/* IOSCB */
sysbus_realize(SYS_BUS_DEVICE(&s->ioscb), errp);
sysbus_mmio_map(SYS_BUS_DEVICE(&s->ioscb), 0,
memmap[MICROCHIP_PFSOC_IOSCB].base);
hw/{misc, riscv}: pfsoc: add system controller as unimplemented The system controller on PolarFire SoC is access via a mailbox. The control registers for this mailbox lie in the "IOSCB" region & the interrupt is cleared via write to the "SYSREG" region. It also has a QSPI controller, usually connected to a flash chip, that is used for storing FPGA bitstreams and used for In-Application Programming (IAP). Linux has an implementation of the system controller, through which the hwrng is accessed, leading to load/store access faults. Add the QSPI as unimplemented and a very basic (effectively unimplemented) version of the system controller's mailbox. Rather than purely marking the regions as unimplemented, service the mailbox requests by reporting failures and raising the interrupt so a guest can better handle the lack of support. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20221117225518.4102575-4-conor@kernel.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-11-18 01:55:18 +03:00
sysbus_connect_irq(SYS_BUS_DEVICE(&s->ioscb), 0,
qdev_get_gpio_in(DEVICE(s->plic),
MICROCHIP_PFSOC_MAILBOX_IRQ));
hw/riscv: microchip_pfsoc: add QSPI NOR flash Add QSPI NOR flash definition for Microchip PolarFire SoC. Signed-off-by: Vitaly Wool <vitaly.wool@konsulko.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Message-id: 20201112074950.33283-1-vitaly.wool@konsulko.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-11-12 10:49:51 +03:00
hw/riscv: microchip_pfsoc: fix kernel panics due to missing peripherals Booting using "Direct Kernel Boot" for PolarFire SoC & skipping u-boot entirely is probably not advisable, but it does at least show signs of life. Recent Linux kernel versions make use of peripherals that are missing definitions in QEMU and lead to kernel panics. These issues almost certain rear their head for other methods of booting, but I was unable to figure out a suitable HSS version that is recent enough to support these peripherals & works with QEMU. With these peripherals added, booting a kernel with the following hangs hangs waiting for the system controller's hwrng, but the kernel no longer panics. With the Linux driver for hwrng disabled, it boots to console. qemu-system-riscv64 -M microchip-icicle-kit \ -m 2G -smp 5 \ -kernel $(vmlinux_bin) \ -dtb $(dtb)\ -initrd $(initramfs) \ -display none -serial null \ -serial stdio More peripherals are added than strictly required to fix the panics in the hopes of avoiding a replication of this problem in the future. Some of the peripherals which are in the device tree for recent kernels are implemented in the FPGA fabric. The eMMC/SD mux, which exists as an unimplemented device is replaced by a wider entry. This updated entry covers both the mux & the remainder of the FPGA fabric connected to the MSS using Fabric Interrconnect (FIC) 3. Link: https://github.com/polarfire-soc/icicle-kit-reference-design#fabric-memory-map Link: https://ww1.microchip.com/downloads/aemDocuments/documents/FPGA/ProductDocuments/SupportingCollateral/V1_4_Register_Map.zip Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20220813135127.2971754-1-mail@conchuod.ie> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-08-13 16:51:27 +03:00
/* FPGA Fabric */
create_unimplemented_device("microchip.pfsoc.fabricfic3",
memmap[MICROCHIP_PFSOC_FABRIC_FIC3].base,
memmap[MICROCHIP_PFSOC_FABRIC_FIC3].size);
hw/riscv: pfsoc: add missing FICs as unimplemented The Fabric Interconnect Controllers provide interfaces between the FPGA fabric and the core complex. There are 5 FICs on PolarFire SoC, numbered 0 through 4. FIC2 is an AXI4 slave interface from the FPGA fabric and does not show up on the MSS memory map. FIC4 is dedicated to the User Crypto Processor and does not show up on the MSS memory map either. FIC 0, 1 & 3 do show up in the MSS memory map and neither FICs 0 or 1 are represented in QEMU, leading to load access violations while booting Linux for Icicle if PCIe is enabled as the root port is connected via either FIC 0 or 1. Acked-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Message-Id: <20221117225518.4102575-3-conor@kernel.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-11-18 01:55:17 +03:00
/* FPGA Fabric */
create_unimplemented_device("microchip.pfsoc.fabricfic0",
memmap[MICROCHIP_PFSOC_FABRIC_FIC0].base,
memmap[MICROCHIP_PFSOC_FABRIC_FIC0].size);
/* FPGA Fabric */
create_unimplemented_device("microchip.pfsoc.fabricfic1",
memmap[MICROCHIP_PFSOC_FABRIC_FIC1].base,
memmap[MICROCHIP_PFSOC_FABRIC_FIC1].size);
hw/riscv: microchip_pfsoc: Map EMMC/SD mux register Since HSS commit c20a89f8dcac, the Icicle Kit reference design has been updated to use a register mapped at 0x4f000000 instead of a GPIO to control whether eMMC or SD card is to be used. With this support the same HSS image can be used for both eMMC and SD card boot flow, while previously two different board configurations were used. This is undocumented but one can take a look at the HSS code HSS_MMCInit() in services/mmc/mmc_api.c. With this commit, HSS image built from 2020.12 release boots again. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210322075248.136255-1-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-03-22 10:52:47 +03:00
hw/riscv: microchip_pfsoc: add QSPI NOR flash Add QSPI NOR flash definition for Microchip PolarFire SoC. Signed-off-by: Vitaly Wool <vitaly.wool@konsulko.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Message-id: 20201112074950.33283-1-vitaly.wool@konsulko.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-11-12 10:49:51 +03:00
/* QSPI Flash */
memory_region_init_rom(qspi_xip_mem, OBJECT(dev),
"microchip.pfsoc.qspi_xip",
memmap[MICROCHIP_PFSOC_QSPI_XIP].size,
&error_fatal);
memory_region_add_subregion(system_memory,
memmap[MICROCHIP_PFSOC_QSPI_XIP].base,
qspi_xip_mem);
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
}
static void microchip_pfsoc_soc_class_init(ObjectClass *oc, void *data)
{
DeviceClass *dc = DEVICE_CLASS(oc);
dc->realize = microchip_pfsoc_soc_realize;
/* Reason: Uses serial_hds in realize function, thus can't be used twice */
dc->user_creatable = false;
}
static const TypeInfo microchip_pfsoc_soc_type_info = {
.name = TYPE_MICROCHIP_PFSOC,
.parent = TYPE_DEVICE,
.instance_size = sizeof(MicrochipPFSoCState),
.instance_init = microchip_pfsoc_soc_instance_init,
.class_init = microchip_pfsoc_soc_class_init,
};
static void microchip_pfsoc_soc_register_types(void)
{
type_register_static(&microchip_pfsoc_soc_type_info);
}
type_init(microchip_pfsoc_soc_register_types)
static void microchip_icicle_kit_machine_init(MachineState *machine)
{
MachineClass *mc = MACHINE_GET_CLASS(machine);
hw/riscv: Drop 'struct MemmapEntry' There is already a MemMapEntry type defined in hwaddr.h. Let's drop the RISC-V defined `struct MemmapEntry` and use the existing one. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20210220144807.819-2-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-02-20 17:48:04 +03:00
const MemMapEntry *memmap = microchip_pfsoc_memmap;
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
MicrochipIcicleKitState *s = MICROCHIP_ICICLE_KIT_MACHINE(machine);
MemoryRegion *system_memory = get_system_memory();
hw/riscv: microchip_pfsoc: Correct DDR memory map When system memory is larger than 1 GiB (high memory), PolarFire SoC maps it at address 0x10_0000_0000. Address 0xC000_0000 and above is aliased to the same 1 GiB low memory with different cache attributes. At present QEMU maps the system memory contiguously from 0x8000_0000. This corrects the wrong QEMU logic. Note address 0x14_0000_0000 is the alias to the high memory, and even physical memory is only 1 GiB, the HSS codes still tries to probe the high memory alias address. It seems there is no issue on the real hardware, so we will have to take that into the consideration in our emulation. Due to this, we we increase the default system memory size to 1537 MiB (the minimum required high memory size by HSS) so that user gets notified an error when less than 1537 MiB is specified. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20201101170538.3732-1-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-11-01 20:05:38 +03:00
MemoryRegion *mem_low = g_new(MemoryRegion, 1);
MemoryRegion *mem_low_alias = g_new(MemoryRegion, 1);
MemoryRegion *mem_high = g_new(MemoryRegion, 1);
MemoryRegion *mem_high_alias = g_new(MemoryRegion, 1);
hw/riscv: microchip_pfsoc: Use MachineState::ram and MachineClass::default_ram_id Using memory_region_init_ram(), which can't possibly handle vhost-user, and can't work as expected with '-numa node,memdev' options. Use MachineState::ram instead of manually initializing RAM memory region, as well as by providing MachineClass::default_ram_id to opt in to memdev scheme. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20211020014112.7336-2-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 04:41:07 +03:00
uint64_t mem_low_size, mem_high_size;
hw/riscv: microchip_pfsoc: Support direct kernel boot At present the Microchip Icicle Kit machine only supports using '-bios' to load the HSS, and does not support '-kernel' for direct kernel booting just like other RISC-V machines do. One has to use U-Boot which is chain-loaded by HSS, to load a kernel for testing. This is not so convenient. Adding '-kernel' support together with the existing '-bios', we follow the following table to select which payload we execute: -bios | -kernel | payload ------+------------+-------- N | N | HSS Y | don't care | HSS N | Y | kernel This ensures backwards compatibility with how we used to expose '-bios' to users. When '-kernel' is used for direct boot, '-dtb' must be present to provide a valid device tree for the board, as we don't generate device tree. When direct kernel boot is used, the OpenSBI fw_dynamic BIOS image is used to boot a payload like U-Boot or OS kernel directly. Documentation is updated to describe the direct kernel boot. Note as of today there is still no PolarFire SoC support in the upstream Linux kernel hence the document does not include instructions for that. It will be updated in the future. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210430071302.1489082-8-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-04-30 10:13:02 +03:00
hwaddr firmware_load_addr;
const char *firmware_name;
bool kernel_as_payload = false;
target_ulong firmware_end_addr, kernel_start_addr;
uint64_t kernel_entry;
uint32_t fdt_load_addr;
hw: Replace trivial drive_get_next() by drive_get() drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new calls appear "in the middle", unit numbers change. ABI break. Hard to spot in review. A number of machines connect just one backend with drive_get_next(). Change them to use drive_get() directly. This makes the (zero) unit number explicit in the code. Cc: Beniamino Galvani <b.galvani@gmail.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Subbaraya Sundeep <sundeep.lkml@gmail.com> Cc: Niek Linnenbank <nieklinnenbank@gmail.com> Cc: Andrew Baumann <Andrew.Baumann@microsoft.com> Cc: "Philippe Mathieu-Daudé" <f4bug@amsat.org> Cc: Jean-Christophe Dubois <jcd@tribudubois.net> Cc: Alistair Francis <Alistair.Francis@wdc.com> Cc: Bin Meng <bin.meng@windriver.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Artyom Tarasenko <atar4qemu@gmail.com> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: Michael Tokarev <mjt@tls.msk.ru> Cc: Laurent Vivier <laurent@vivier.eu> Cc: qemu-arm@nongnu.org Cc: qemu-riscv@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20211117163409.3587705-3-armbru@redhat.com>
2021-11-17 19:33:58 +03:00
DriveInfo *dinfo = drive_get(IF_SD, 0, 0);
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
/* Sanity check on RAM size */
if (machine->ram_size < mc->default_ram_size) {
char *sz = size_to_str(mc->default_ram_size);
error_report("Invalid RAM size, should be bigger than %s", sz);
g_free(sz);
exit(EXIT_FAILURE);
}
/* Initialize SoC */
object_initialize_child(OBJECT(machine), "soc", &s->soc,
TYPE_MICROCHIP_PFSOC);
hw/riscv: Use error_fatal for SoC realisation When realising the SoC use error_fatal instead of error_abort as the process can fail and report useful information to the user. Currently a user can see this: $ ../qemu/bld/qemu-system-riscv64 -M sifive_u -S -monitor stdio -display none -drive if=pflash QEMU 6.1.93 monitor - type 'help' for more information (qemu) Unexpected error in sifive_u_otp_realize() at ../hw/misc/sifive_u_otp.c:229: qemu-system-riscv64: OTP drive size < 16K Aborted (core dumped) Which this patch addresses Reported-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20220105213937.1113508-8-alistair.francis@opensource.wdc.com>
2022-01-06 00:39:36 +03:00
qdev_realize(DEVICE(&s->soc), NULL, &error_fatal);
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
hw/riscv: microchip_pfsoc: Use MachineState::ram and MachineClass::default_ram_id Using memory_region_init_ram(), which can't possibly handle vhost-user, and can't work as expected with '-numa node,memdev' options. Use MachineState::ram instead of manually initializing RAM memory region, as well as by providing MachineClass::default_ram_id to opt in to memdev scheme. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20211020014112.7336-2-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 04:41:07 +03:00
/* Split RAM into low and high regions using aliases to machine->ram */
mem_low_size = memmap[MICROCHIP_PFSOC_DRAM_LO].size;
mem_high_size = machine->ram_size - mem_low_size;
memory_region_init_alias(mem_low, NULL,
"microchip.icicle.kit.ram_low", machine->ram,
0, mem_low_size);
memory_region_init_alias(mem_high, NULL,
"microchip.icicle.kit.ram_high", machine->ram,
mem_low_size, mem_high_size);
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
/* Register RAM */
hw/riscv: microchip_pfsoc: Correct DDR memory map When system memory is larger than 1 GiB (high memory), PolarFire SoC maps it at address 0x10_0000_0000. Address 0xC000_0000 and above is aliased to the same 1 GiB low memory with different cache attributes. At present QEMU maps the system memory contiguously from 0x8000_0000. This corrects the wrong QEMU logic. Note address 0x14_0000_0000 is the alias to the high memory, and even physical memory is only 1 GiB, the HSS codes still tries to probe the high memory alias address. It seems there is no issue on the real hardware, so we will have to take that into the consideration in our emulation. Due to this, we we increase the default system memory size to 1537 MiB (the minimum required high memory size by HSS) so that user gets notified an error when less than 1537 MiB is specified. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20201101170538.3732-1-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-11-01 20:05:38 +03:00
memory_region_add_subregion(system_memory,
memmap[MICROCHIP_PFSOC_DRAM_LO].base,
mem_low);
hw/riscv: microchip_pfsoc: Use MachineState::ram and MachineClass::default_ram_id Using memory_region_init_ram(), which can't possibly handle vhost-user, and can't work as expected with '-numa node,memdev' options. Use MachineState::ram instead of manually initializing RAM memory region, as well as by providing MachineClass::default_ram_id to opt in to memdev scheme. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20211020014112.7336-2-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 04:41:07 +03:00
memory_region_add_subregion(system_memory,
memmap[MICROCHIP_PFSOC_DRAM_HI].base,
mem_high);
/* Create aliases for the low and high RAM regions */
memory_region_init_alias(mem_low_alias, NULL,
"microchip.icicle.kit.ram_low.alias",
mem_low, 0, mem_low_size);
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
memory_region_add_subregion(system_memory,
hw/riscv: microchip_pfsoc: Correct DDR memory map When system memory is larger than 1 GiB (high memory), PolarFire SoC maps it at address 0x10_0000_0000. Address 0xC000_0000 and above is aliased to the same 1 GiB low memory with different cache attributes. At present QEMU maps the system memory contiguously from 0x8000_0000. This corrects the wrong QEMU logic. Note address 0x14_0000_0000 is the alias to the high memory, and even physical memory is only 1 GiB, the HSS codes still tries to probe the high memory alias address. It seems there is no issue on the real hardware, so we will have to take that into the consideration in our emulation. Due to this, we we increase the default system memory size to 1537 MiB (the minimum required high memory size by HSS) so that user gets notified an error when less than 1537 MiB is specified. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20201101170538.3732-1-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-11-01 20:05:38 +03:00
memmap[MICROCHIP_PFSOC_DRAM_LO_ALIAS].base,
mem_low_alias);
memory_region_init_alias(mem_high_alias, NULL,
"microchip.icicle.kit.ram_high.alias",
mem_high, 0, mem_high_size);
memory_region_add_subregion(system_memory,
memmap[MICROCHIP_PFSOC_DRAM_HI_ALIAS].base,
mem_high_alias);
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
hw/riscv: microchip_pfsoc: Connect a Cadence SDHCI controller and an SD card Microchip PolarFire SoC integrates one Cadence SDHCI controller. On the Icicle Kit board, one eMMC chip and an external SD card connect to this controller depending on different configuration. As QEMU does not support eMMC yet, we just emulate the SD card configuration. To test this, the Hart Software Services (HSS) should choose the SD card configuration: $ cp boards/icicle-kit-es/def_config.sdcard .config $ make BOARD=icicle-kit-es The SD card image can be built from the Yocto BSP at: https://github.com/polarfire-soc/meta-polarfire-soc-yocto-bsp Note the generated SD card image should be resized before use: $ qemu-img resize /path/to/sdcard.img 4G Launch QEMU with the following command: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit -sd sdcard.img Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-9-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:39:03 +03:00
/* Attach an SD card */
if (dinfo) {
CadenceSDHCIState *sdhci = &(s->soc.sdhci);
DeviceState *card = qdev_new(TYPE_SD_CARD);
qdev_prop_set_drive_err(card, "drive", blk_by_legacy_dinfo(dinfo),
&error_fatal);
qdev_realize_and_unref(card, sdhci->bus, &error_fatal);
}
hw/riscv: microchip_pfsoc: Support direct kernel boot At present the Microchip Icicle Kit machine only supports using '-bios' to load the HSS, and does not support '-kernel' for direct kernel booting just like other RISC-V machines do. One has to use U-Boot which is chain-loaded by HSS, to load a kernel for testing. This is not so convenient. Adding '-kernel' support together with the existing '-bios', we follow the following table to select which payload we execute: -bios | -kernel | payload ------+------------+-------- N | N | HSS Y | don't care | HSS N | Y | kernel This ensures backwards compatibility with how we used to expose '-bios' to users. When '-kernel' is used for direct boot, '-dtb' must be present to provide a valid device tree for the board, as we don't generate device tree. When direct kernel boot is used, the OpenSBI fw_dynamic BIOS image is used to boot a payload like U-Boot or OS kernel directly. Documentation is updated to describe the direct kernel boot. Note as of today there is still no PolarFire SoC support in the upstream Linux kernel hence the document does not include instructions for that. It will be updated in the future. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210430071302.1489082-8-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-04-30 10:13:02 +03:00
/*
* We follow the following table to select which payload we execute.
*
* -bios | -kernel | payload
* -------+------------+--------
* N | N | HSS
* Y | don't care | HSS
* N | Y | kernel
*
* This ensures backwards compatibility with how we used to expose -bios
* to users but allows them to run through direct kernel booting as well.
*
* When -kernel is used for direct boot, -dtb must be present to provide
* a valid device tree for the board, as we don't generate device tree.
*/
if (machine->kernel_filename && machine->dtb) {
int fdt_size;
machine->fdt = load_device_tree(machine->dtb, &fdt_size);
if (!machine->fdt) {
error_report("load_device_tree() failed");
exit(1);
}
firmware_name = RISCV64_BIOS_BIN;
firmware_load_addr = memmap[MICROCHIP_PFSOC_DRAM_LO].base;
kernel_as_payload = true;
}
if (!kernel_as_payload) {
firmware_name = BIOS_FILENAME;
firmware_load_addr = RESET_VECTOR;
}
/* Load the firmware */
firmware_end_addr = riscv_find_and_load_firmware(machine, firmware_name,
hw/riscv: Respect firmware ELF entry point When riscv_load_firmware() loads an ELF, the ELF segment addresses are used, not the passed-in firmware_load_addr. The machine models assume the firmware entry point is what they provided for firmware_load_addr, and use that address to generate the boot ROM, so if the ELF is linked at any other address, the boot ROM will jump to empty memory. Pass back the ELF entry point to use when generating the boot ROM, so the boot ROM can jump to firmware loaded anywhere in RAM. For example, on the virt machine, this allows using an OpenSBI fw_dynamic.elf built with FW_TEXT_START values other than 0x80000000. Signed-off-by: Samuel Holland <samuel.holland@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240817002651.3209701-1-samuel.holland@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-08-17 03:25:02 +03:00
&firmware_load_addr, NULL);
hw/riscv: microchip_pfsoc: Support direct kernel boot At present the Microchip Icicle Kit machine only supports using '-bios' to load the HSS, and does not support '-kernel' for direct kernel booting just like other RISC-V machines do. One has to use U-Boot which is chain-loaded by HSS, to load a kernel for testing. This is not so convenient. Adding '-kernel' support together with the existing '-bios', we follow the following table to select which payload we execute: -bios | -kernel | payload ------+------------+-------- N | N | HSS Y | don't care | HSS N | Y | kernel This ensures backwards compatibility with how we used to expose '-bios' to users. When '-kernel' is used for direct boot, '-dtb' must be present to provide a valid device tree for the board, as we don't generate device tree. When direct kernel boot is used, the OpenSBI fw_dynamic BIOS image is used to boot a payload like U-Boot or OS kernel directly. Documentation is updated to describe the direct kernel boot. Note as of today there is still no PolarFire SoC support in the upstream Linux kernel hence the document does not include instructions for that. It will be updated in the future. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210430071302.1489082-8-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-04-30 10:13:02 +03:00
if (kernel_as_payload) {
kernel_start_addr = riscv_calc_kernel_start_addr(&s->soc.u_cpus,
firmware_end_addr);
hw/riscv: handle 32 bit CPUs kernel_entry in riscv_load_kernel() Next patch will move all calls to riscv_load_initrd() to riscv_load_kernel(). Machines that want to load initrd will be able to do via an extra flag to riscv_load_kernel(). This change will expose a sign-extend behavior that is happening in load_elf_ram_sym() when running 32 bit guests [1]. This is currently obscured by the fact that riscv_load_initrd() is using the return of riscv_load_kernel(), defined as target_ulong, and this return type will crop the higher 32 bits that would be padded with 1s by the sign extension when running in 32 bit targets. The changes to be done will force riscv_load_initrd() to use an uint64_t instead, exposing it to the padding when dealing with 32 bit CPUs. There is a discussion about whether load_elf_ram_sym() should or should not sign extend the value returned by 'lowaddr'. What we can do is to prevent the behavior change that the next patch will end up doing. riscv_load_initrd() wasn't dealing with 64 bit kernel entries when running 32 bit CPUs, and we want to keep it that way. One way of doing it is to use target_ulong in 'kernel_entry' in riscv_load_kernel() and rely on the fact that this var will not be sign extended for 32 bit targets. Another way is to explictly clear the higher 32 bits when running 32 bit CPUs for all possibilities of kernel_entry. We opted for the later. This will allow us to be clear about the design choices made in the function, while also allowing us to add a small comment about what load_elf_ram_sym() is doing. With this change, the consolation patch can do its job without worrying about unintended behavioral changes. [1] https://lists.gnu.org/archive/html/qemu-devel/2023-01/msg02281.html Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230206140022.2748401-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-02-06 17:00:20 +03:00
kernel_entry = riscv_load_kernel(machine, &s->soc.u_cpus,
hw/riscv/boot.c: consolidate all kernel init in riscv_load_kernel() The microchip_icicle_kit, sifive_u, spike and virt boards are now doing the same steps when '-kernel' is used: - execute load_kernel() - load init_rd() - write kernel_cmdline Let's fold everything inside riscv_load_kernel() to avoid code repetition. To not change the behavior of boards that aren't calling riscv_load_init(), add an 'load_initrd' flag to riscv_load_kernel() and allow these boards to opt out from initrd loading. Cc: Palmer Dabbelt <palmer@dabbelt.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230206140022.2748401-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-02-06 17:00:21 +03:00
kernel_start_addr, true, NULL);
hw/riscv: microchip_pfsoc: Support direct kernel boot At present the Microchip Icicle Kit machine only supports using '-bios' to load the HSS, and does not support '-kernel' for direct kernel booting just like other RISC-V machines do. One has to use U-Boot which is chain-loaded by HSS, to load a kernel for testing. This is not so convenient. Adding '-kernel' support together with the existing '-bios', we follow the following table to select which payload we execute: -bios | -kernel | payload ------+------------+-------- N | N | HSS Y | don't care | HSS N | Y | kernel This ensures backwards compatibility with how we used to expose '-bios' to users. When '-kernel' is used for direct boot, '-dtb' must be present to provide a valid device tree for the board, as we don't generate device tree. When direct kernel boot is used, the OpenSBI fw_dynamic BIOS image is used to boot a payload like U-Boot or OS kernel directly. Documentation is updated to describe the direct kernel boot. Note as of today there is still no PolarFire SoC support in the upstream Linux kernel hence the document does not include instructions for that. It will be updated in the future. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210430071302.1489082-8-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-04-30 10:13:02 +03:00
/* Compute the fdt load address in dram */
hw/riscv: split fdt address calculation from fdt load A common trend in other archs is to calculate the fdt address, which is usually straightforward, and then calling a function that loads the fdt/dtb by using that address. riscv_load_fdt() is doing a bit too much in comparison. It's calculating the fdt address via an elaborated heuristic to put the FDT at the bottom of DRAM, and "bottom of DRAM" will vary across boards and configurations, then it's actually loading the fdt, and finally it's returning the fdt address used to the caller. Reduce the existing complexity of riscv_load_fdt() by splitting its code into a new function, riscv_compute_fdt_addr(), that will take care of all fdt address logic. riscv_load_fdt() can then be a simple function that just loads a fdt at the given fdt address. We're also taken the opportunity to clarify the intentions and assumptions made by these functions. riscv_load_fdt() is now receiving a hwaddr as fdt_addr because there is no restriction of having to load the fdt in higher addresses that doesn't fit in an uint32_t. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230201171212.1219375-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-02-01 20:12:11 +03:00
fdt_load_addr = riscv_compute_fdt_addr(memmap[MICROCHIP_PFSOC_DRAM_LO].base,
hw/riscv: change riscv_compute_fdt_addr() semantics As it is now, riscv_compute_fdt_addr() is receiving a dram_base, a mem_size (which is defaulted to MachineState::ram_size in all boards) and the FDT pointer. And it makes a very important assumption: the DRAM interval dram_base + mem_size is contiguous. This is indeed the case for most boards that use a FDT. The Icicle Kit board works with 2 distinct RAM banks that are separated by a gap. We have a lower bank with 1GiB size, a gap follows, then at 64GiB the high memory starts. MachineClass::default_ram_size for this board is set to 1.5Gb, and machine_init() is enforcing it as minimal RAM size, meaning that there we'll always have at least 512 MiB in the Hi RAM area. Using riscv_compute_fdt_addr() in this board is weird because not only the board has sparse RAM, and it's calling it using the base address of the Lo RAM area, but it's also using a mem_size that we have guarantees that it will go up to the Hi RAM. All the function assumptions doesn't work for this board. In fact, what makes the function works at all in this case is a coincidence. Commit 1a475d39ef54 introduced a 3GB boundary for the FDT, down from 4Gb, that is enforced if dram_base is lower than 3072 MiB. For the Icicle Kit board, memmap[MICROCHIP_PFSOC_DRAM_LO].base is 0x80000000 (2 Gb) and it has a 1Gb size, so it will fall in the conditions to put the FDT under a 3Gb address, which happens to be exactly at the end of DRAM_LO. If the base address of the Lo area started later than 3Gb this function would be unusable by the board. Changing any assumptions inside riscv_compute_fdt_addr() can also break it by accident as well. Let's change riscv_compute_fdt_addr() semantics to be appropriate to the Icicle Kit board and for future boards that might have sparse RAM topologies to worry about: - relieve the condition that the dram_base + mem_size area is contiguous, since this is already not the case today; - receive an extra 'dram_size' size attribute that refers to a contiguous RAM block that the board wants the FDT to reside on. Together with 'mem_size' and 'fdt', which are now now being consumed by a MachineState pointer, we're able to make clear assumptions based on the DRAM block and total mem_size available to ensure that the FDT will be put in a valid RAM address. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230201171212.1219375-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-02-01 20:12:12 +03:00
memmap[MICROCHIP_PFSOC_DRAM_LO].size,
machine);
hw/riscv: split fdt address calculation from fdt load A common trend in other archs is to calculate the fdt address, which is usually straightforward, and then calling a function that loads the fdt/dtb by using that address. riscv_load_fdt() is doing a bit too much in comparison. It's calculating the fdt address via an elaborated heuristic to put the FDT at the bottom of DRAM, and "bottom of DRAM" will vary across boards and configurations, then it's actually loading the fdt, and finally it's returning the fdt address used to the caller. Reduce the existing complexity of riscv_load_fdt() by splitting its code into a new function, riscv_compute_fdt_addr(), that will take care of all fdt address logic. riscv_load_fdt() can then be a simple function that just loads a fdt at the given fdt address. We're also taken the opportunity to clarify the intentions and assumptions made by these functions. riscv_load_fdt() is now receiving a hwaddr as fdt_addr because there is no restriction of having to load the fdt in higher addresses that doesn't fit in an uint32_t. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230201171212.1219375-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-02-01 20:12:11 +03:00
riscv_load_fdt(fdt_load_addr, machine->fdt);
hw/riscv: microchip_pfsoc: Support direct kernel boot At present the Microchip Icicle Kit machine only supports using '-bios' to load the HSS, and does not support '-kernel' for direct kernel booting just like other RISC-V machines do. One has to use U-Boot which is chain-loaded by HSS, to load a kernel for testing. This is not so convenient. Adding '-kernel' support together with the existing '-bios', we follow the following table to select which payload we execute: -bios | -kernel | payload ------+------------+-------- N | N | HSS Y | don't care | HSS N | Y | kernel This ensures backwards compatibility with how we used to expose '-bios' to users. When '-kernel' is used for direct boot, '-dtb' must be present to provide a valid device tree for the board, as we don't generate device tree. When direct kernel boot is used, the OpenSBI fw_dynamic BIOS image is used to boot a payload like U-Boot or OS kernel directly. Documentation is updated to describe the direct kernel boot. Note as of today there is still no PolarFire SoC support in the upstream Linux kernel hence the document does not include instructions for that. It will be updated in the future. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210430071302.1489082-8-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-04-30 10:13:02 +03:00
/* Load the reset vector */
riscv_setup_rom_reset_vec(machine, &s->soc.u_cpus, firmware_load_addr,
memmap[MICROCHIP_PFSOC_ENVM_DATA].base,
memmap[MICROCHIP_PFSOC_ENVM_DATA].size,
hw/riscv: remove 'fdt' param from riscv_setup_rom_reset_vec() The 'fdt' param is not being used in riscv_setup_rom_reset_vec(). Simplify the API by removing it. While we're at it, remove the redundant 'return' statement at the end of function. Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Alistair Francis <alistair.francis@wdc.com> Cc: Bin Meng <bin.meng@windriver.com> Cc: Vijai Kumar K <vijai@behindbytes.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20220728181926.2123771-1-danielhb413@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-07-28 21:19:26 +03:00
kernel_entry, fdt_load_addr);
hw/riscv: microchip_pfsoc: Support direct kernel boot At present the Microchip Icicle Kit machine only supports using '-bios' to load the HSS, and does not support '-kernel' for direct kernel booting just like other RISC-V machines do. One has to use U-Boot which is chain-loaded by HSS, to load a kernel for testing. This is not so convenient. Adding '-kernel' support together with the existing '-bios', we follow the following table to select which payload we execute: -bios | -kernel | payload ------+------------+-------- N | N | HSS Y | don't care | HSS N | Y | kernel This ensures backwards compatibility with how we used to expose '-bios' to users. When '-kernel' is used for direct boot, '-dtb' must be present to provide a valid device tree for the board, as we don't generate device tree. When direct kernel boot is used, the OpenSBI fw_dynamic BIOS image is used to boot a payload like U-Boot or OS kernel directly. Documentation is updated to describe the direct kernel boot. Note as of today there is still no PolarFire SoC support in the upstream Linux kernel hence the document does not include instructions for that. It will be updated in the future. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210430071302.1489082-8-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-04-30 10:13:02 +03:00
}
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
}
static void microchip_icicle_kit_machine_class_init(ObjectClass *oc, void *data)
{
MachineClass *mc = MACHINE_CLASS(oc);
mc->desc = "Microchip PolarFire SoC Icicle Kit";
mc->init = microchip_icicle_kit_machine_init;
mc->max_cpus = MICROCHIP_PFSOC_MANAGEMENT_CPU_COUNT +
MICROCHIP_PFSOC_COMPUTE_CPU_COUNT;
mc->min_cpus = MICROCHIP_PFSOC_MANAGEMENT_CPU_COUNT + 1;
mc->default_cpus = mc->min_cpus;
hw/riscv: microchip_pfsoc: Use MachineState::ram and MachineClass::default_ram_id Using memory_region_init_ram(), which can't possibly handle vhost-user, and can't work as expected with '-numa node,memdev' options. Use MachineState::ram instead of manually initializing RAM memory region, as well as by providing MachineClass::default_ram_id to opt in to memdev scheme. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20211020014112.7336-2-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 04:41:07 +03:00
mc->default_ram_id = "microchip.icicle.kit.ram";
hw/riscv: microchip_pfsoc: Correct DDR memory map When system memory is larger than 1 GiB (high memory), PolarFire SoC maps it at address 0x10_0000_0000. Address 0xC000_0000 and above is aliased to the same 1 GiB low memory with different cache attributes. At present QEMU maps the system memory contiguously from 0x8000_0000. This corrects the wrong QEMU logic. Note address 0x14_0000_0000 is the alias to the high memory, and even physical memory is only 1 GiB, the HSS codes still tries to probe the high memory alias address. It seems there is no issue on the real hardware, so we will have to take that into the consideration in our emulation. Due to this, we we increase the default system memory size to 1537 MiB (the minimum required high memory size by HSS) so that user gets notified an error when less than 1537 MiB is specified. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20201101170538.3732-1-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-11-01 20:05:38 +03:00
/*
riscv: spelling fixes Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Acked-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-14 14:19:10 +03:00
* Map 513 MiB high memory, the minimum required high memory size, because
hw/riscv: microchip_pfsoc: Correct DDR memory map When system memory is larger than 1 GiB (high memory), PolarFire SoC maps it at address 0x10_0000_0000. Address 0xC000_0000 and above is aliased to the same 1 GiB low memory with different cache attributes. At present QEMU maps the system memory contiguously from 0x8000_0000. This corrects the wrong QEMU logic. Note address 0x14_0000_0000 is the alias to the high memory, and even physical memory is only 1 GiB, the HSS codes still tries to probe the high memory alias address. It seems there is no issue on the real hardware, so we will have to take that into the consideration in our emulation. Due to this, we we increase the default system memory size to 1537 MiB (the minimum required high memory size by HSS) so that user gets notified an error when less than 1537 MiB is specified. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20201101170538.3732-1-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-11-01 20:05:38 +03:00
* HSS will do memory test against the high memory address range regardless
* of physical memory installed.
*
* See memory_tests() in mss_ddr.c in the HSS source code.
*/
mc->default_ram_size = 1537 * MiB;
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board This is an initial support for Microchip PolarFire SoC Icicle Kit. The Icicle Kit board integrates a PolarFire SoC, with one SiFive's E51 plus four U54 cores and many on-chip peripherals and an FPGA. For more details about Microchip PolarFire Soc, please see: https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000. The following perepherals are created as an unimplemented device: - Bus Error Uint 0/1/2/3/4 - L2 cache controller - SYSREG - MPUCFG - IOSCBCFG More devices will be added later. The BIOS image used by this machine is hss.bin, aka Hart Software Services, which can be built from: https://github.com/polarfire-soc/hart-software-services To launch this machine: $ qemu-system-riscv64 -nographic -M microchip-icicle-kit The memory is set to 1 GiB by default to match the hardware. A sanity check on ram size is performed in the machine init routine to prompt user to increase the RAM size to > 1 GiB when less than 1 GiB ram is detected. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1598924352-89526-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-01 04:38:59 +03:00
}
static const TypeInfo microchip_icicle_kit_machine_typeinfo = {
.name = MACHINE_TYPE_NAME("microchip-icicle-kit"),
.parent = TYPE_MACHINE,
.class_init = microchip_icicle_kit_machine_class_init,
.instance_size = sizeof(MicrochipIcicleKitState),
};
static void microchip_icicle_kit_machine_init_register_types(void)
{
type_register_static(&microchip_icicle_kit_machine_typeinfo);
}
type_init(microchip_icicle_kit_machine_init_register_types)
Reference in New Issue Copy Permalink