* [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
@ 2020-08-14 16:40 ` Bin Meng
0 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Peter Maydell, Alistair Francis, qemu-block, Jason Wang,
Bin Meng, Paolo Bonzini, Palmer Dabbelt, qemu-arm,
Marc-André Lureau, Edgar E. Iglesias,
Philippe Mathieu-Daudé
From: Bin Meng <bin.meng@windriver.com>
This adds support for Microchip PolarFire SoC Icicle Kit board.
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
The Icicle Kit board information can be found here:
https://www.microsemi.com/existing-parts/parts/152514
Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000.
The RISC-V CPU and HART codes has been updated to set the core's
reset vector based on a configurable property from machine codes.
The following perepherals are created as an unimplemented device:
- Bus Error Uint 0/1/2/3/4
- L2 cache controller
- SYSREG
- MPUCFG
- IOSCBCFG
- GPIO
The following perepherals are emulated:
- SiFive CLINT
- SiFive PLIC
- PolarFire SoC Multi-Mode UART
- PolarFire SoC DMA
- Cadence eMMC/SDHCI controller
- Cadence Gigabit Ethernet MAC
Some bugs in the SD card codes are fixed during the development.
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 -M microchip-icicle-kit -smp 5 \
-bios path/to/hss.bin -sd path/to/sdcard.img \
-nic tap,ifname=tap,script=no,model=cadence_gem \
-display none -serial stdio \
-chardev socket,id=serial1,path=serial1.sock,server,wait \
-serial chardev:serial1
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.
HSS output is on the first serial port (stdio) and U-Boot/Linux
outputs on the 2nd serial port. OpenSBI outputs on a random serial
port due to the lottery mechanism used during the multi-core boot.
Bin Meng (18):
target/riscv: cpu: Add a new 'resetvec' property
hw/riscv: hart: Add a new 'resetvec' property
target/riscv: cpu: Set reset vector based on the configured property
value
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board
hw/char: Add Microchip PolarFire SoC MMUART emulation
hw/riscv: microchip_pfsoc: Connect 5 MMUARTs
hw/sd: sd: Fix incorrect populated function switch status data
structure
hw/sd: sd: Correctly set the high capacity bit
hw/sd: sdhci: Make sdhci_poweron_reset() internal visible
hw/sd: Add Cadence SDHCI emulation
hw/riscv: microchip_pfsoc: Connect a Cadence SDHCI controller and an
SD card
hw/dma: Add Microchip PolarFire Soc DMA controller emulation
hw/riscv: microchip_pfsoc: Connect a DMA controller
hw/net: cadence_gem: Add a new 'phy-addr' property
hw/riscv: microchip_pfsoc: Connect 2 Cadence GEMs
hw/riscv: microchip_pfsoc: Hook GPIO controllers
hw/riscv: clint: Avoid using hard-coded timebase frequency
hw/riscv: microchip_pfsoc: Document the software used for testing
MAINTAINERS | 11 +
default-configs/riscv64-softmmu.mak | 1 +
hw/char/Kconfig | 3 +
hw/char/Makefile.objs | 1 +
hw/char/mchp_pfsoc_mmuart.c | 82 +++++++
hw/dma/Kconfig | 3 +
hw/dma/Makefile.objs | 1 +
hw/dma/mchp_pfsoc_dma.c | 322 +++++++++++++++++++++++++
hw/net/cadence_gem.c | 7 +-
hw/riscv/Kconfig | 9 +
hw/riscv/Makefile.objs | 1 +
hw/riscv/microchip_pfsoc.c | 456 ++++++++++++++++++++++++++++++++++++
hw/riscv/opentitan.c | 1 +
hw/riscv/riscv_hart.c | 3 +
hw/riscv/sifive_clint.c | 25 +-
hw/riscv/sifive_e.c | 4 +-
hw/riscv/sifive_u.c | 5 +-
hw/riscv/spike.c | 2 +-
hw/riscv/virt.c | 3 +-
hw/sd/Kconfig | 4 +
hw/sd/Makefile.objs | 1 +
hw/sd/cadence_sdhci.c | 162 +++++++++++++
hw/sd/sd.c | 8 +-
hw/sd/sdhci-internal.h | 1 +
hw/sd/sdhci.c | 2 +-
include/hw/char/mchp_pfsoc_mmuart.h | 61 +++++
include/hw/dma/mchp_pfsoc_dma.h | 57 +++++
include/hw/net/cadence_gem.h | 2 +
include/hw/riscv/microchip_pfsoc.h | 125 ++++++++++
include/hw/riscv/riscv_hart.h | 1 +
include/hw/riscv/sifive_clint.h | 3 +-
include/hw/sd/cadence_sdhci.h | 65 +++++
target/riscv/cpu.c | 8 +-
target/riscv/cpu.h | 7 +-
target/riscv/cpu_helper.c | 4 +-
target/riscv/csr.c | 4 +-
36 files changed, 1424 insertions(+), 31 deletions(-)
create mode 100644 hw/char/mchp_pfsoc_mmuart.c
create mode 100644 hw/dma/mchp_pfsoc_dma.c
create mode 100644 hw/riscv/microchip_pfsoc.c
create mode 100644 hw/sd/cadence_sdhci.c
create mode 100644 include/hw/char/mchp_pfsoc_mmuart.h
create mode 100644 include/hw/dma/mchp_pfsoc_dma.h
create mode 100644 include/hw/riscv/microchip_pfsoc.h
create mode 100644 include/hw/sd/cadence_sdhci.h
--
2.7.4
^ permalink raw reply [flat|nested] 100+ messages in thread
* [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
@ 2020-08-14 16:40 ` Bin Meng
0 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, Alistair Francis, Edgar E. Iglesias, Jason Wang,
Marc-André Lureau, Palmer Dabbelt, Paolo Bonzini,
Peter Maydell, Philippe Mathieu-Daudé,
qemu-arm, qemu-block
From: Bin Meng <bin.meng@windriver.com>
This adds support for Microchip PolarFire SoC Icicle Kit board.
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
The Icicle Kit board information can be found here:
https://www.microsemi.com/existing-parts/parts/152514
Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000.
The RISC-V CPU and HART codes has been updated to set the core's
reset vector based on a configurable property from machine codes.
The following perepherals are created as an unimplemented device:
- Bus Error Uint 0/1/2/3/4
- L2 cache controller
- SYSREG
- MPUCFG
- IOSCBCFG
- GPIO
The following perepherals are emulated:
- SiFive CLINT
- SiFive PLIC
- PolarFire SoC Multi-Mode UART
- PolarFire SoC DMA
- Cadence eMMC/SDHCI controller
- Cadence Gigabit Ethernet MAC
Some bugs in the SD card codes are fixed during the development.
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 -M microchip-icicle-kit -smp 5 \
-bios path/to/hss.bin -sd path/to/sdcard.img \
-nic tap,ifname=tap,script=no,model=cadence_gem \
-display none -serial stdio \
-chardev socket,id=serial1,path=serial1.sock,server,wait \
-serial chardev:serial1
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.
HSS output is on the first serial port (stdio) and U-Boot/Linux
outputs on the 2nd serial port. OpenSBI outputs on a random serial
port due to the lottery mechanism used during the multi-core boot.
Bin Meng (18):
target/riscv: cpu: Add a new 'resetvec' property
hw/riscv: hart: Add a new 'resetvec' property
target/riscv: cpu: Set reset vector based on the configured property
value
hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board
hw/char: Add Microchip PolarFire SoC MMUART emulation
hw/riscv: microchip_pfsoc: Connect 5 MMUARTs
hw/sd: sd: Fix incorrect populated function switch status data
structure
hw/sd: sd: Correctly set the high capacity bit
hw/sd: sdhci: Make sdhci_poweron_reset() internal visible
hw/sd: Add Cadence SDHCI emulation
hw/riscv: microchip_pfsoc: Connect a Cadence SDHCI controller and an
SD card
hw/dma: Add Microchip PolarFire Soc DMA controller emulation
hw/riscv: microchip_pfsoc: Connect a DMA controller
hw/net: cadence_gem: Add a new 'phy-addr' property
hw/riscv: microchip_pfsoc: Connect 2 Cadence GEMs
hw/riscv: microchip_pfsoc: Hook GPIO controllers
hw/riscv: clint: Avoid using hard-coded timebase frequency
hw/riscv: microchip_pfsoc: Document the software used for testing
MAINTAINERS | 11 +
default-configs/riscv64-softmmu.mak | 1 +
hw/char/Kconfig | 3 +
hw/char/Makefile.objs | 1 +
hw/char/mchp_pfsoc_mmuart.c | 82 +++++++
hw/dma/Kconfig | 3 +
hw/dma/Makefile.objs | 1 +
hw/dma/mchp_pfsoc_dma.c | 322 +++++++++++++++++++++++++
hw/net/cadence_gem.c | 7 +-
hw/riscv/Kconfig | 9 +
hw/riscv/Makefile.objs | 1 +
hw/riscv/microchip_pfsoc.c | 456 ++++++++++++++++++++++++++++++++++++
hw/riscv/opentitan.c | 1 +
hw/riscv/riscv_hart.c | 3 +
hw/riscv/sifive_clint.c | 25 +-
hw/riscv/sifive_e.c | 4 +-
hw/riscv/sifive_u.c | 5 +-
hw/riscv/spike.c | 2 +-
hw/riscv/virt.c | 3 +-
hw/sd/Kconfig | 4 +
hw/sd/Makefile.objs | 1 +
hw/sd/cadence_sdhci.c | 162 +++++++++++++
hw/sd/sd.c | 8 +-
hw/sd/sdhci-internal.h | 1 +
hw/sd/sdhci.c | 2 +-
include/hw/char/mchp_pfsoc_mmuart.h | 61 +++++
include/hw/dma/mchp_pfsoc_dma.h | 57 +++++
include/hw/net/cadence_gem.h | 2 +
include/hw/riscv/microchip_pfsoc.h | 125 ++++++++++
include/hw/riscv/riscv_hart.h | 1 +
include/hw/riscv/sifive_clint.h | 3 +-
include/hw/sd/cadence_sdhci.h | 65 +++++
target/riscv/cpu.c | 8 +-
target/riscv/cpu.h | 7 +-
target/riscv/cpu_helper.c | 4 +-
target/riscv/csr.c | 4 +-
36 files changed, 1424 insertions(+), 31 deletions(-)
create mode 100644 hw/char/mchp_pfsoc_mmuart.c
create mode 100644 hw/dma/mchp_pfsoc_dma.c
create mode 100644 hw/riscv/microchip_pfsoc.c
create mode 100644 hw/sd/cadence_sdhci.c
create mode 100644 include/hw/char/mchp_pfsoc_mmuart.h
create mode 100644 include/hw/dma/mchp_pfsoc_dma.h
create mode 100644 include/hw/riscv/microchip_pfsoc.h
create mode 100644 include/hw/sd/cadence_sdhci.h
--
2.7.4
^ permalink raw reply [flat|nested] 100+ messages in thread
* [PATCH 01/18] target/riscv: cpu: Add a new 'resetvec' property
2020-08-14 16:40 ` Bin Meng
(?)
@ 2020-08-14 16:40 ` Bin Meng
2020-08-17 17:49 ` Alistair Francis
-1 siblings, 1 reply; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, Palmer Dabbelt
From: Bin Meng <bin.meng@windriver.com>
Currently the reset vector address is hard-coded in a RISC-V CPU's
instance_init() routine. In a real world we can have 2 exact same
CPUs except for the reset vector address, which is pretty common in
the RISC-V core IP licensing business.
Normally reset vector address is a configurable parameter. Let's
create a 64-bit property to store the reset vector address which
covers both 32-bit and 64-bit CPUs.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---
target/riscv/cpu.c | 1 +
target/riscv/cpu.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 228b9bd..8067a26 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -518,6 +518,7 @@ static Property riscv_cpu_properties[] = {
DEFINE_PROP_UINT16("elen", RISCVCPU, cfg.elen, 64),
DEFINE_PROP_BOOL("mmu", RISCVCPU, cfg.mmu, true),
DEFINE_PROP_BOOL("pmp", RISCVCPU, cfg.pmp, true),
+ DEFINE_PROP_UINT64("resetvec", RISCVCPU, cfg.resetvec, DEFAULT_RSTVEC),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index a804a5d..d34bcfa 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -291,6 +291,7 @@ typedef struct RISCVCPU {
uint16_t elen;
bool mmu;
bool pmp;
+ uint64_t resetvec;
} cfg;
} RISCVCPU;
--
2.7.4
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH 02/18] hw/riscv: hart: Add a new 'resetvec' property
2020-08-14 16:40 ` Bin Meng
(?)
(?)
@ 2020-08-14 16:40 ` Bin Meng
2020-08-17 17:49 ` Alistair Francis
-1 siblings, 1 reply; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, Palmer Dabbelt
From: Bin Meng <bin.meng@windriver.com>
RISC-V machines do not instantiate RISC-V CPUs directly, instead
they do that via the hart array. Add a new property for the reset
vector address to allow the value to be passed to the CPU, before
CPU is realized.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---
hw/riscv/riscv_hart.c | 3 +++
include/hw/riscv/riscv_hart.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/hw/riscv/riscv_hart.c b/hw/riscv/riscv_hart.c
index f59fe52..613ea2a 100644
--- a/hw/riscv/riscv_hart.c
+++ b/hw/riscv/riscv_hart.c
@@ -31,6 +31,8 @@ static Property riscv_harts_props[] = {
DEFINE_PROP_UINT32("num-harts", RISCVHartArrayState, num_harts, 1),
DEFINE_PROP_UINT32("hartid-base", RISCVHartArrayState, hartid_base, 0),
DEFINE_PROP_STRING("cpu-type", RISCVHartArrayState, cpu_type),
+ DEFINE_PROP_UINT64("resetvec", RISCVHartArrayState, resetvec,
+ DEFAULT_RSTVEC),
DEFINE_PROP_END_OF_LIST(),
};
@@ -44,6 +46,7 @@ static bool riscv_hart_realize(RISCVHartArrayState *s, int idx,
char *cpu_type, Error **errp)
{
object_initialize_child(OBJECT(s), "harts[*]", &s->harts[idx], cpu_type);
+ qdev_prop_set_uint64(DEVICE(&s->harts[idx]), "resetvec", s->resetvec);
s->harts[idx].env.mhartid = s->hartid_base + idx;
qemu_register_reset(riscv_harts_cpu_reset, &s->harts[idx]);
return qdev_realize(DEVICE(&s->harts[idx]), NULL, errp);
diff --git a/include/hw/riscv/riscv_hart.h b/include/hw/riscv/riscv_hart.h
index c75856f..77aa4bc 100644
--- a/include/hw/riscv/riscv_hart.h
+++ b/include/hw/riscv/riscv_hart.h
@@ -37,6 +37,7 @@ typedef struct RISCVHartArrayState {
uint32_t num_harts;
uint32_t hartid_base;
char *cpu_type;
+ uint64_t resetvec;
RISCVCPU *harts;
} RISCVHartArrayState;
--
2.7.4
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH 03/18] target/riscv: cpu: Set reset vector based on the configured property value
2020-08-14 16:40 ` Bin Meng
` (2 preceding siblings ...)
(?)
@ 2020-08-14 16:40 ` Bin Meng
2020-08-17 17:52 ` Alistair Francis
-1 siblings, 1 reply; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, Palmer Dabbelt
From: Bin Meng <bin.meng@windriver.com>
Now that we have the newly introduced 'resetvec' property in the
RISC-V CPU and HART, instead of hard-coding the reset vector addr
in the CPU's instance_init(), move that to riscv_cpu_realize()
based on the configured property value from the RISC-V machines.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---
hw/riscv/opentitan.c | 1 +
hw/riscv/sifive_e.c | 1 +
hw/riscv/sifive_u.c | 2 ++
target/riscv/cpu.c | 7 ++-----
4 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/hw/riscv/opentitan.c b/hw/riscv/opentitan.c
index a8f0039..b0a4eae 100644
--- a/hw/riscv/opentitan.c
+++ b/hw/riscv/opentitan.c
@@ -111,6 +111,7 @@ static void lowrisc_ibex_soc_realize(DeviceState *dev_soc, Error **errp)
&error_abort);
object_property_set_int(OBJECT(&s->cpus), "num-harts", ms->smp.cpus,
&error_abort);
+ object_property_set_int(OBJECT(&s->cpus), "resetvec", 0x8090, &error_abort);
sysbus_realize(SYS_BUS_DEVICE(&s->cpus), &error_abort);
/* Boot ROM */
diff --git a/hw/riscv/sifive_e.c b/hw/riscv/sifive_e.c
index c8b0604..c84d407 100644
--- a/hw/riscv/sifive_e.c
+++ b/hw/riscv/sifive_e.c
@@ -177,6 +177,7 @@ static void sifive_e_soc_init(Object *obj)
object_initialize_child(obj, "cpus", &s->cpus, TYPE_RISCV_HART_ARRAY);
object_property_set_int(OBJECT(&s->cpus), "num-harts", ms->smp.cpus,
&error_abort);
+ object_property_set_int(OBJECT(&s->cpus), "resetvec", 0x1004, &error_abort);
object_initialize_child(obj, "riscv.sifive.e.gpio0", &s->gpio,
TYPE_SIFIVE_GPIO);
}
diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
index 18301e6..e256da2 100644
--- a/hw/riscv/sifive_u.c
+++ b/hw/riscv/sifive_u.c
@@ -611,6 +611,7 @@ static void sifive_u_soc_instance_init(Object *obj)
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", SIFIVE_E_CPU);
+ qdev_prop_set_uint64(DEVICE(&s->e_cpus), "resetvec", 0x1004);
object_initialize_child(obj, "u-cluster", &s->u_cluster, TYPE_CPU_CLUSTER);
qdev_prop_set_uint32(DEVICE(&s->u_cluster), "cluster-id", 1);
@@ -620,6 +621,7 @@ static void sifive_u_soc_instance_init(Object *obj)
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", SIFIVE_U_CPU);
+ qdev_prop_set_uint64(DEVICE(&s->u_cpus), "resetvec", 0x1004);
object_initialize_child(obj, "prci", &s->prci, TYPE_SIFIVE_U_PRCI);
object_initialize_child(obj, "otp", &s->otp, TYPE_SIFIVE_U_OTP);
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 8067a26..bd41286 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -128,7 +128,6 @@ static void riscv_any_cpu_init(Object *obj)
CPURISCVState *env = &RISCV_CPU(obj)->env;
set_misa(env, RVXLEN | RVI | RVM | RVA | RVF | RVD | RVC | RVU);
set_priv_version(env, PRIV_VERSION_1_11_0);
- set_resetvec(env, DEFAULT_RSTVEC);
}
static void riscv_base_cpu_init(Object *obj)
@@ -136,7 +135,6 @@ static void riscv_base_cpu_init(Object *obj)
CPURISCVState *env = &RISCV_CPU(obj)->env;
/* We set this in the realise function */
set_misa(env, 0);
- set_resetvec(env, DEFAULT_RSTVEC);
}
static void rvxx_sifive_u_cpu_init(Object *obj)
@@ -144,7 +142,6 @@ static void rvxx_sifive_u_cpu_init(Object *obj)
CPURISCVState *env = &RISCV_CPU(obj)->env;
set_misa(env, RVXLEN | RVI | RVM | RVA | RVF | RVD | RVC | RVS | RVU);
set_priv_version(env, PRIV_VERSION_1_10_0);
- set_resetvec(env, 0x1004);
}
static void rvxx_sifive_e_cpu_init(Object *obj)
@@ -152,7 +149,6 @@ static void rvxx_sifive_e_cpu_init(Object *obj)
CPURISCVState *env = &RISCV_CPU(obj)->env;
set_misa(env, RVXLEN | RVI | RVM | RVA | RVC | RVU);
set_priv_version(env, PRIV_VERSION_1_10_0);
- set_resetvec(env, 0x1004);
qdev_prop_set_bit(DEVICE(obj), "mmu", false);
}
@@ -163,7 +159,6 @@ static void rv32_ibex_cpu_init(Object *obj)
CPURISCVState *env = &RISCV_CPU(obj)->env;
set_misa(env, RV32 | RVI | RVM | RVC | RVU);
set_priv_version(env, PRIV_VERSION_1_10_0);
- set_resetvec(env, 0x8090);
qdev_prop_set_bit(DEVICE(obj), "mmu", false);
}
@@ -373,6 +368,8 @@ static void riscv_cpu_realize(DeviceState *dev, Error **errp)
set_feature(env, RISCV_FEATURE_PMP);
}
+ set_resetvec(env, cpu->cfg.resetvec);
+
/* If misa isn't set (rv32 and rv64 machines) set it here */
if (!env->misa) {
/* Do some ISA extension error checking */
--
2.7.4
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH 04/18] hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board
2020-08-14 16:40 ` Bin Meng
` (3 preceding siblings ...)
(?)
@ 2020-08-14 16:40 ` Bin Meng
2020-08-17 19:39 ` Alistair Francis
-1 siblings, 1 reply; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, Palmer Dabbelt
From: Bin Meng <bin.meng@windriver.com>
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>
---
MAINTAINERS | 7 +
default-configs/riscv64-softmmu.mak | 1 +
hw/riscv/Kconfig | 6 +
hw/riscv/Makefile.objs | 1 +
hw/riscv/microchip_pfsoc.c | 312 ++++++++++++++++++++++++++++++++++++
include/hw/riscv/microchip_pfsoc.h | 88 ++++++++++
6 files changed, 415 insertions(+)
create mode 100644 hw/riscv/microchip_pfsoc.c
create mode 100644 include/hw/riscv/microchip_pfsoc.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 0886eb3..8716cb6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1314,6 +1314,13 @@ F: include/hw/riscv/opentitan.h
F: include/hw/char/ibex_uart.h
F: include/hw/intc/ibex_plic.h
+Microchip PolarFire SoC Icicle Kit
+M: Bin Meng <bin.meng@windriver.com>
+L: qemu-riscv@nongnu.org
+S: Supported
+F: hw/riscv/microchip_pfsoc.c
+F: include/hw/riscv/microchip_pfsoc.h
+
RX Machines
-----------
rx-gdbsim
diff --git a/default-configs/riscv64-softmmu.mak b/default-configs/riscv64-softmmu.mak
index aaf6d73..76b6195 100644
--- a/default-configs/riscv64-softmmu.mak
+++ b/default-configs/riscv64-softmmu.mak
@@ -10,3 +10,4 @@ CONFIG_SPIKE=y
CONFIG_SIFIVE_E=y
CONFIG_SIFIVE_U=y
CONFIG_RISCV_VIRT=y
+CONFIG_MICROCHIP_PFSOC=y
diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
index 28947ef..3292fae 100644
--- a/hw/riscv/Kconfig
+++ b/hw/riscv/Kconfig
@@ -48,3 +48,9 @@ config RISCV_VIRT
select PCI_EXPRESS_GENERIC_BRIDGE
select PFLASH_CFI01
select SIFIVE
+
+config MICROCHIP_PFSOC
+ bool
+ select HART
+ select SIFIVE
+ select UNIMP
diff --git a/hw/riscv/Makefile.objs b/hw/riscv/Makefile.objs
index 57cc708..419a5a0 100644
--- a/hw/riscv/Makefile.objs
+++ b/hw/riscv/Makefile.objs
@@ -14,3 +14,4 @@ obj-$(CONFIG_SIFIVE_U) += sifive_u_prci.o
obj-$(CONFIG_SIFIVE) += sifive_uart.o
obj-$(CONFIG_SPIKE) += spike.o
obj-$(CONFIG_RISCV_VIRT) += virt.o
+obj-$(CONFIG_MICROCHIP_PFSOC) += microchip_pfsoc.o
diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
new file mode 100644
index 0000000..20a642c
--- /dev/null
+++ b/hw/riscv/microchip_pfsoc.c
@@ -0,0 +1,312 @@
+/*
+ * 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)
+ *
+ * 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/log.h"
+#include "qemu/units.h"
+#include "qemu/cutils.h"
+#include "qapi/error.h"
+#include "hw/boards.h"
+#include "hw/irq.h"
+#include "hw/loader.h"
+#include "hw/sysbus.h"
+#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/sifive_clint.h"
+#include "hw/riscv/sifive_plic.h"
+#include "hw/riscv/microchip_pfsoc.h"
+
+/*
+ * 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
+
+static const struct MemmapEntry {
+ hwaddr base;
+ hwaddr size;
+} microchip_pfsoc_memmap[] = {
+ [MICROCHIP_PFSOC_DEBUG] = { 0x0, 0x1000 },
+ [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_L2LIM] = { 0x8000000, 0x2000000 },
+ [MICROCHIP_PFSOC_PLIC] = { 0xc000000, 0x4000000 },
+ [MICROCHIP_PFSOC_SYSREG] = { 0x20002000, 0x2000 },
+ [MICROCHIP_PFSOC_MPUCFG] = { 0x20005000, 0x1000 },
+ [MICROCHIP_PFSOC_ENVM_CFG] = { 0x20200000, 0x1000 },
+ [MICROCHIP_PFSOC_ENVM_DATA] = { 0x20220000, 0x20000 },
+ [MICROCHIP_PFSOC_IOSCB_CFG] = { 0x37080000, 0x1000 },
+ [MICROCHIP_PFSOC_DRAM] = { 0x80000000, 0x0 },
+};
+
+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);
+}
+
+static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
+{
+ MachineState *ms = MACHINE(qdev_get_machine());
+ MicrochipPFSoCState *s = MICROCHIP_PFSOC(dev);
+ const struct MemmapEntry *memmap = microchip_pfsoc_memmap;
+ MemoryRegion *system_memory = get_system_memory();
+ MemoryRegion *e51_dtim_mem = g_new(MemoryRegion, 1);
+ MemoryRegion *l2lim_mem = g_new(MemoryRegion, 1);
+ MemoryRegion *envm_data = g_new(MemoryRegion, 1);
+ char *plic_hart_config;
+ size_t plic_hart_config_len;
+ 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);
+
+ /* 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 */
+ sifive_clint_create(memmap[MICROCHIP_PFSOC_CLINT].base,
+ memmap[MICROCHIP_PFSOC_CLINT].size, ms->smp.cpus,
+ SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE, false);
+
+ /* 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 */
+ plic_hart_config_len = (strlen(MICROCHIP_PFSOC_PLIC_HART_CONFIG) + 1) *
+ ms->smp.cpus;
+ plic_hart_config = g_malloc0(plic_hart_config_len);
+ for (i = 0; i < ms->smp.cpus; i++) {
+ if (i != 0) {
+ strncat(plic_hart_config, "," MICROCHIP_PFSOC_PLIC_HART_CONFIG,
+ plic_hart_config_len);
+ } else {
+ strncat(plic_hart_config, "M", plic_hart_config_len);
+ }
+ plic_hart_config_len -= (strlen(MICROCHIP_PFSOC_PLIC_HART_CONFIG) + 1);
+ }
+
+ /* PLIC */
+ s->plic = sifive_plic_create(memmap[MICROCHIP_PFSOC_PLIC].base,
+ plic_hart_config,
+ 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);
+
+ /* SYSREG */
+ create_unimplemented_device("microchip.pfsoc.sysreg",
+ memmap[MICROCHIP_PFSOC_SYSREG].base,
+ memmap[MICROCHIP_PFSOC_SYSREG].size);
+
+ /* MPUCFG */
+ create_unimplemented_device("microchip.pfsoc.mpucfg",
+ memmap[MICROCHIP_PFSOC_MPUCFG].base,
+ memmap[MICROCHIP_PFSOC_MPUCFG].size);
+
+ /* 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);
+
+ /* IOSCBCFG */
+ create_unimplemented_device("microchip.pfsoc.ioscb.cfg",
+ memmap[MICROCHIP_PFSOC_IOSCB_CFG].base,
+ memmap[MICROCHIP_PFSOC_IOSCB_CFG].size);
+}
+
+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(µchip_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);
+ const struct MemmapEntry *memmap = microchip_pfsoc_memmap;
+ MicrochipIcicleKitState *s = MICROCHIP_ICICLE_KIT_MACHINE(machine);
+ MemoryRegion *system_memory = get_system_memory();
+ MemoryRegion *main_mem = g_new(MemoryRegion, 1);
+
+ /* 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);
+ qdev_realize(DEVICE(&s->soc), NULL, &error_abort);
+
+ /* Register RAM */
+ memory_region_init_ram(main_mem, NULL, "microchip.icicle.kit.ram",
+ machine->ram_size, &error_fatal);
+ memory_region_add_subregion(system_memory,
+ memmap[MICROCHIP_PFSOC_DRAM].base, main_mem);
+
+ /* Load the firmware */
+ riscv_find_and_load_firmware(machine, BIOS_FILENAME, RESET_VECTOR, NULL);
+}
+
+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;
+ mc->default_ram_size = 1 * GiB;
+}
+
+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(µchip_icicle_kit_machine_typeinfo);
+}
+
+type_init(microchip_icicle_kit_machine_init_register_types)
diff --git a/include/hw/riscv/microchip_pfsoc.h b/include/hw/riscv/microchip_pfsoc.h
new file mode 100644
index 0000000..1953ef1
--- /dev/null
+++ b/include/hw/riscv/microchip_pfsoc.h
@@ -0,0 +1,88 @@
+/*
+ * Microchip PolarFire SoC machine interface
+ *
+ * Copyright (c) 2020 Wind River Systems, Inc.
+ *
+ * Author:
+ * Bin Meng <bin.meng@windriver.com>
+ *
+ * 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/>.
+ */
+
+#ifndef HW_MICROCHIP_PFSOC_H
+#define HW_MICROCHIP_PFSOC_H
+
+typedef struct MicrochipPFSoCState {
+ /*< private >*/
+ DeviceState parent_obj;
+
+ /*< public >*/
+ CPUClusterState e_cluster;
+ CPUClusterState u_cluster;
+ RISCVHartArrayState e_cpus;
+ RISCVHartArrayState u_cpus;
+ DeviceState *plic;
+} MicrochipPFSoCState;
+
+#define TYPE_MICROCHIP_PFSOC "microchip.pfsoc"
+#define MICROCHIP_PFSOC(obj) \
+ OBJECT_CHECK(MicrochipPFSoCState, (obj), TYPE_MICROCHIP_PFSOC)
+
+typedef struct MicrochipIcicleKitState {
+ /*< private >*/
+ MachineState parent_obj;
+
+ /*< public >*/
+ MicrochipPFSoCState soc;
+} MicrochipIcicleKitState;
+
+#define TYPE_MICROCHIP_ICICLE_KIT_MACHINE \
+ MACHINE_TYPE_NAME("microchip-icicle-kit")
+#define MICROCHIP_ICICLE_KIT_MACHINE(obj) \
+ OBJECT_CHECK(MicrochipIcicleKitState, (obj), \
+ TYPE_MICROCHIP_ICICLE_KIT_MACHINE)
+
+enum {
+ MICROCHIP_PFSOC_DEBUG,
+ MICROCHIP_PFSOC_E51_DTIM,
+ MICROCHIP_PFSOC_BUSERR_UNIT0,
+ MICROCHIP_PFSOC_BUSERR_UNIT1,
+ MICROCHIP_PFSOC_BUSERR_UNIT2,
+ MICROCHIP_PFSOC_BUSERR_UNIT3,
+ MICROCHIP_PFSOC_BUSERR_UNIT4,
+ MICROCHIP_PFSOC_CLINT,
+ MICROCHIP_PFSOC_L2CC,
+ MICROCHIP_PFSOC_L2LIM,
+ MICROCHIP_PFSOC_PLIC,
+ MICROCHIP_PFSOC_SYSREG,
+ MICROCHIP_PFSOC_MPUCFG,
+ MICROCHIP_PFSOC_ENVM_CFG,
+ MICROCHIP_PFSOC_ENVM_DATA,
+ MICROCHIP_PFSOC_IOSCB_CFG,
+ MICROCHIP_PFSOC_DRAM,
+};
+
+#define MICROCHIP_PFSOC_MANAGEMENT_CPU_COUNT 1
+#define MICROCHIP_PFSOC_COMPUTE_CPU_COUNT 4
+
+#define MICROCHIP_PFSOC_PLIC_HART_CONFIG "MS"
+#define MICROCHIP_PFSOC_PLIC_NUM_SOURCES 185
+#define MICROCHIP_PFSOC_PLIC_NUM_PRIORITIES 7
+#define MICROCHIP_PFSOC_PLIC_PRIORITY_BASE 0x04
+#define MICROCHIP_PFSOC_PLIC_PENDING_BASE 0x1000
+#define MICROCHIP_PFSOC_PLIC_ENABLE_BASE 0x2000
+#define MICROCHIP_PFSOC_PLIC_ENABLE_STRIDE 0x80
+#define MICROCHIP_PFSOC_PLIC_CONTEXT_BASE 0x200000
+#define MICROCHIP_PFSOC_PLIC_CONTEXT_STRIDE 0x1000
+
+#endif /* HW_MICROCHIP_PFSOC_H */
--
2.7.4
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH 05/18] hw/char: Add Microchip PolarFire SoC MMUART emulation
2020-08-14 16:40 ` Bin Meng
@ 2020-08-14 16:40 ` Bin Meng
-1 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Marc-André Lureau, Bin Meng, Paolo Bonzini
From: Bin Meng <bin.meng@windriver.com>
Microchip PolarFire SoC MMUART is ns16550 compatible, with some
additional registers. Create a simple MMUART model built on top
of the existing ns16550 model.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---
MAINTAINERS | 2 +
hw/char/Kconfig | 3 ++
hw/char/Makefile.objs | 1 +
hw/char/mchp_pfsoc_mmuart.c | 82 +++++++++++++++++++++++++++++++++++++
include/hw/char/mchp_pfsoc_mmuart.h | 61 +++++++++++++++++++++++++++
5 files changed, 149 insertions(+)
create mode 100644 hw/char/mchp_pfsoc_mmuart.c
create mode 100644 include/hw/char/mchp_pfsoc_mmuart.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 8716cb6..e51edac 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1319,7 +1319,9 @@ M: Bin Meng <bin.meng@windriver.com>
L: qemu-riscv@nongnu.org
S: Supported
F: hw/riscv/microchip_pfsoc.c
+F: hw/char/mchp_pfsoc_mmuart.c
F: include/hw/riscv/microchip_pfsoc.h
+F: include/hw/char/mchp_pfsoc_mmuart.h
RX Machines
-----------
diff --git a/hw/char/Kconfig b/hw/char/Kconfig
index b7e0e4d..1d64555 100644
--- a/hw/char/Kconfig
+++ b/hw/char/Kconfig
@@ -52,3 +52,6 @@ config RENESAS_SCI
config AVR_USART
bool
+
+config MCHP_PFSOC_MMUART
+ bool
diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs
index bf177ac..f705845 100644
--- a/hw/char/Makefile.objs
+++ b/hw/char/Makefile.objs
@@ -33,6 +33,7 @@ common-obj-$(CONFIG_LM32) += lm32_juart.o
common-obj-$(CONFIG_LM32) += lm32_uart.o
common-obj-$(CONFIG_MILKYMIST) += milkymist-uart.o
common-obj-$(CONFIG_SCLPCONSOLE) += sclpconsole.o sclpconsole-lm.o
+common-obj-$(CONFIG_MCHP_PFSOC_MMUART) += mchp_pfsoc_mmuart.o
obj-$(CONFIG_VIRTIO) += virtio-serial-bus.o
obj-$(CONFIG_PSERIES) += spapr_vty.o
diff --git a/hw/char/mchp_pfsoc_mmuart.c b/hw/char/mchp_pfsoc_mmuart.c
new file mode 100644
index 0000000..9984acc
--- /dev/null
+++ b/hw/char/mchp_pfsoc_mmuart.c
@@ -0,0 +1,82 @@
+/*
+ * Microchip PolarFire SoC MMUART emulation
+ *
+ * Copyright (c) 2020 Wind River Systems, Inc.
+ *
+ * Author:
+ * Bin Meng <bin.meng@windriver.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) version 3 of the License.
+ *
+ * This program is distributed in the hope that 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/log.h"
+#include "chardev/char.h"
+#include "exec/address-spaces.h"
+#include "hw/char/mchp_pfsoc_mmuart.h"
+
+static uint64_t mchp_pfsoc_mmuart_read(void *opaque, hwaddr addr, unsigned size)
+{
+ MchpPfSoCMMUartState *s = opaque;
+
+ if ((addr % sizeof(uint32_t)) || (addr >= 0x34)) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: read: addr=0x%" HWADDR_PRIx "\n",
+ __func__, addr);
+ return 0;
+ }
+
+ return s->reg[addr / sizeof(uint32_t)];
+}
+
+static void mchp_pfsoc_mmuart_write(void *opaque, hwaddr addr,
+ uint64_t value, unsigned size)
+{
+ MchpPfSoCMMUartState *s = opaque;
+ uint32_t val32 = (uint32_t)value;
+
+ if ((addr % sizeof(uint32_t)) || (addr >= 0x34)) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: bad write: addr=0x%" HWADDR_PRIx
+ " v=0x%x\n", __func__, addr, val32);
+ return;
+ }
+
+ s->reg[addr / sizeof(uint32_t)] = val32;
+}
+
+static const MemoryRegionOps mchp_pfsoc_mmuart_ops = {
+ .read = mchp_pfsoc_mmuart_read,
+ .write = mchp_pfsoc_mmuart_write,
+ .endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+MchpPfSoCMMUartState *mchp_pfsoc_mmuart_create(MemoryRegion *sysmem,
+ hwaddr base, qemu_irq irq, Chardev *chr)
+{
+ MchpPfSoCMMUartState *s;
+
+ s = g_new0(MchpPfSoCMMUartState, 1);
+
+ memory_region_init_io(&s->iomem, NULL, &mchp_pfsoc_mmuart_ops, s,
+ "mchp.pfsoc.mmuart", 0x1000);
+
+ s->base = base;
+ s->irq = irq;
+
+ s->serial = serial_mm_init(sysmem, base, 2, irq, 399193, chr,
+ DEVICE_LITTLE_ENDIAN);
+
+ memory_region_add_subregion(sysmem, base + 0x20, &s->iomem);
+
+ return s;
+}
diff --git a/include/hw/char/mchp_pfsoc_mmuart.h b/include/hw/char/mchp_pfsoc_mmuart.h
new file mode 100644
index 0000000..f619902
--- /dev/null
+++ b/include/hw/char/mchp_pfsoc_mmuart.h
@@ -0,0 +1,61 @@
+/*
+ * Microchip PolarFire SoC MMUART emulation
+ *
+ * Copyright (c) 2020 Wind River Systems, Inc.
+ *
+ * Author:
+ * Bin Meng <bin.meng@windriver.com>
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#ifndef HW_MCHP_PFSOC_MMUART_H
+#define HW_MCHP_PFSOC_MMUART_H
+
+#include "hw/char/serial.h"
+
+#define MCHP_PFSOC_MMUART_REG_SIZE 52
+
+typedef struct MchpPfSoCMMUartState {
+ MemoryRegion iomem;
+ hwaddr base;
+ qemu_irq irq;
+
+ SerialMM *serial;
+
+ uint32_t reg[MCHP_PFSOC_MMUART_REG_SIZE / sizeof(uint32_t)];
+} MchpPfSoCMMUartState;
+
+/**
+ * mchp_pfsoc_mmuart_create - Create a Microchip PolarFire SoC MMUART
+ *
+ * This is a helper routine for board to create a MMUART device that is
+ * compatible with Microchip PolarFire SoC.
+ *
+ * @sysmem: system memory region to map
+ * @base: base address of the MMUART registers
+ * @irq: IRQ number of the MMUART device
+ * @chr: character device to associate to
+ *
+ * @return: a pointer to the device specific control structure
+ */
+MchpPfSoCMMUartState *mchp_pfsoc_mmuart_create(MemoryRegion *sysmem,
+ hwaddr base, qemu_irq irq, Chardev *chr);
+
+#endif /* HW_MCHP_PFSOC_MMUART_H */
--
2.7.4
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH 05/18] hw/char: Add Microchip PolarFire SoC MMUART emulation
@ 2020-08-14 16:40 ` Bin Meng
0 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, Marc-André Lureau, Paolo Bonzini
From: Bin Meng <bin.meng@windriver.com>
Microchip PolarFire SoC MMUART is ns16550 compatible, with some
additional registers. Create a simple MMUART model built on top
of the existing ns16550 model.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---
MAINTAINERS | 2 +
hw/char/Kconfig | 3 ++
hw/char/Makefile.objs | 1 +
hw/char/mchp_pfsoc_mmuart.c | 82 +++++++++++++++++++++++++++++++++++++
include/hw/char/mchp_pfsoc_mmuart.h | 61 +++++++++++++++++++++++++++
5 files changed, 149 insertions(+)
create mode 100644 hw/char/mchp_pfsoc_mmuart.c
create mode 100644 include/hw/char/mchp_pfsoc_mmuart.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 8716cb6..e51edac 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1319,7 +1319,9 @@ M: Bin Meng <bin.meng@windriver.com>
L: qemu-riscv@nongnu.org
S: Supported
F: hw/riscv/microchip_pfsoc.c
+F: hw/char/mchp_pfsoc_mmuart.c
F: include/hw/riscv/microchip_pfsoc.h
+F: include/hw/char/mchp_pfsoc_mmuart.h
RX Machines
-----------
diff --git a/hw/char/Kconfig b/hw/char/Kconfig
index b7e0e4d..1d64555 100644
--- a/hw/char/Kconfig
+++ b/hw/char/Kconfig
@@ -52,3 +52,6 @@ config RENESAS_SCI
config AVR_USART
bool
+
+config MCHP_PFSOC_MMUART
+ bool
diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs
index bf177ac..f705845 100644
--- a/hw/char/Makefile.objs
+++ b/hw/char/Makefile.objs
@@ -33,6 +33,7 @@ common-obj-$(CONFIG_LM32) += lm32_juart.o
common-obj-$(CONFIG_LM32) += lm32_uart.o
common-obj-$(CONFIG_MILKYMIST) += milkymist-uart.o
common-obj-$(CONFIG_SCLPCONSOLE) += sclpconsole.o sclpconsole-lm.o
+common-obj-$(CONFIG_MCHP_PFSOC_MMUART) += mchp_pfsoc_mmuart.o
obj-$(CONFIG_VIRTIO) += virtio-serial-bus.o
obj-$(CONFIG_PSERIES) += spapr_vty.o
diff --git a/hw/char/mchp_pfsoc_mmuart.c b/hw/char/mchp_pfsoc_mmuart.c
new file mode 100644
index 0000000..9984acc
--- /dev/null
+++ b/hw/char/mchp_pfsoc_mmuart.c
@@ -0,0 +1,82 @@
+/*
+ * Microchip PolarFire SoC MMUART emulation
+ *
+ * Copyright (c) 2020 Wind River Systems, Inc.
+ *
+ * Author:
+ * Bin Meng <bin.meng@windriver.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) version 3 of the License.
+ *
+ * This program is distributed in the hope that 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/log.h"
+#include "chardev/char.h"
+#include "exec/address-spaces.h"
+#include "hw/char/mchp_pfsoc_mmuart.h"
+
+static uint64_t mchp_pfsoc_mmuart_read(void *opaque, hwaddr addr, unsigned size)
+{
+ MchpPfSoCMMUartState *s = opaque;
+
+ if ((addr % sizeof(uint32_t)) || (addr >= 0x34)) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: read: addr=0x%" HWADDR_PRIx "\n",
+ __func__, addr);
+ return 0;
+ }
+
+ return s->reg[addr / sizeof(uint32_t)];
+}
+
+static void mchp_pfsoc_mmuart_write(void *opaque, hwaddr addr,
+ uint64_t value, unsigned size)
+{
+ MchpPfSoCMMUartState *s = opaque;
+ uint32_t val32 = (uint32_t)value;
+
+ if ((addr % sizeof(uint32_t)) || (addr >= 0x34)) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: bad write: addr=0x%" HWADDR_PRIx
+ " v=0x%x\n", __func__, addr, val32);
+ return;
+ }
+
+ s->reg[addr / sizeof(uint32_t)] = val32;
+}
+
+static const MemoryRegionOps mchp_pfsoc_mmuart_ops = {
+ .read = mchp_pfsoc_mmuart_read,
+ .write = mchp_pfsoc_mmuart_write,
+ .endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+MchpPfSoCMMUartState *mchp_pfsoc_mmuart_create(MemoryRegion *sysmem,
+ hwaddr base, qemu_irq irq, Chardev *chr)
+{
+ MchpPfSoCMMUartState *s;
+
+ s = g_new0(MchpPfSoCMMUartState, 1);
+
+ memory_region_init_io(&s->iomem, NULL, &mchp_pfsoc_mmuart_ops, s,
+ "mchp.pfsoc.mmuart", 0x1000);
+
+ s->base = base;
+ s->irq = irq;
+
+ s->serial = serial_mm_init(sysmem, base, 2, irq, 399193, chr,
+ DEVICE_LITTLE_ENDIAN);
+
+ memory_region_add_subregion(sysmem, base + 0x20, &s->iomem);
+
+ return s;
+}
diff --git a/include/hw/char/mchp_pfsoc_mmuart.h b/include/hw/char/mchp_pfsoc_mmuart.h
new file mode 100644
index 0000000..f619902
--- /dev/null
+++ b/include/hw/char/mchp_pfsoc_mmuart.h
@@ -0,0 +1,61 @@
+/*
+ * Microchip PolarFire SoC MMUART emulation
+ *
+ * Copyright (c) 2020 Wind River Systems, Inc.
+ *
+ * Author:
+ * Bin Meng <bin.meng@windriver.com>
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#ifndef HW_MCHP_PFSOC_MMUART_H
+#define HW_MCHP_PFSOC_MMUART_H
+
+#include "hw/char/serial.h"
+
+#define MCHP_PFSOC_MMUART_REG_SIZE 52
+
+typedef struct MchpPfSoCMMUartState {
+ MemoryRegion iomem;
+ hwaddr base;
+ qemu_irq irq;
+
+ SerialMM *serial;
+
+ uint32_t reg[MCHP_PFSOC_MMUART_REG_SIZE / sizeof(uint32_t)];
+} MchpPfSoCMMUartState;
+
+/**
+ * mchp_pfsoc_mmuart_create - Create a Microchip PolarFire SoC MMUART
+ *
+ * This is a helper routine for board to create a MMUART device that is
+ * compatible with Microchip PolarFire SoC.
+ *
+ * @sysmem: system memory region to map
+ * @base: base address of the MMUART registers
+ * @irq: IRQ number of the MMUART device
+ * @chr: character device to associate to
+ *
+ * @return: a pointer to the device specific control structure
+ */
+MchpPfSoCMMUartState *mchp_pfsoc_mmuart_create(MemoryRegion *sysmem,
+ hwaddr base, qemu_irq irq, Chardev *chr);
+
+#endif /* HW_MCHP_PFSOC_MMUART_H */
--
2.7.4
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH 06/18] hw/riscv: microchip_pfsoc: Connect 5 MMUARTs
2020-08-14 16:40 ` Bin Meng
` (5 preceding siblings ...)
(?)
@ 2020-08-14 16:40 ` Bin Meng
2020-08-17 21:06 ` Alistair Francis
-1 siblings, 1 reply; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, Palmer Dabbelt
From: Bin Meng <bin.meng@windriver.com>
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>
---
hw/riscv/Kconfig | 1 +
hw/riscv/microchip_pfsoc.c | 30 ++++++++++++++++++++++++++++++
include/hw/riscv/microchip_pfsoc.h | 20 ++++++++++++++++++++
3 files changed, 51 insertions(+)
diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
index 3292fae..ceb7c16 100644
--- a/hw/riscv/Kconfig
+++ b/hw/riscv/Kconfig
@@ -54,3 +54,4 @@ config MICROCHIP_PFSOC
select HART
select SIFIVE
select UNIMP
+ select MCHP_PFSOC_MMUART
diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
index 20a642c..f6b375c 100644
--- a/hw/riscv/microchip_pfsoc.c
+++ b/hw/riscv/microchip_pfsoc.c
@@ -11,6 +11,7 @@
* 0) CLINT (Core Level Interruptor)
* 1) PLIC (Platform Level Interrupt Controller)
* 2) eNVM (Embedded Non-Volatile Memory)
+ * 3) MMUARTs (Multi-Mode UART)
*
* This board currently generates devicetree dynamically that indicates at least
* two harts and up to five harts.
@@ -38,6 +39,7 @@
#include "hw/irq.h"
#include "hw/loader.h"
#include "hw/sysbus.h"
+#include "chardev/char.h"
#include "hw/cpu/cluster.h"
#include "target/riscv/cpu.h"
#include "hw/misc/unimp.h"
@@ -46,6 +48,7 @@
#include "hw/riscv/sifive_clint.h"
#include "hw/riscv/sifive_plic.h"
#include "hw/riscv/microchip_pfsoc.h"
+#include "sysemu/sysemu.h"
/*
* The BIOS image used by this machine is called Hart Software Services (HSS).
@@ -69,8 +72,13 @@ static const struct MemmapEntry {
[MICROCHIP_PFSOC_L2CC] = { 0x2010000, 0x1000 },
[MICROCHIP_PFSOC_L2LIM] = { 0x8000000, 0x2000000 },
[MICROCHIP_PFSOC_PLIC] = { 0xc000000, 0x4000000 },
+ [MICROCHIP_PFSOC_MMUART0] = { 0x20000000, 0x1000 },
[MICROCHIP_PFSOC_SYSREG] = { 0x20002000, 0x2000 },
[MICROCHIP_PFSOC_MPUCFG] = { 0x20005000, 0x1000 },
+ [MICROCHIP_PFSOC_MMUART1] = { 0x20100000, 0x1000 },
+ [MICROCHIP_PFSOC_MMUART2] = { 0x20102000, 0x1000 },
+ [MICROCHIP_PFSOC_MMUART3] = { 0x20104000, 0x1000 },
+ [MICROCHIP_PFSOC_MMUART4] = { 0x20106000, 0x1000 },
[MICROCHIP_PFSOC_ENVM_CFG] = { 0x20200000, 0x1000 },
[MICROCHIP_PFSOC_ENVM_DATA] = { 0x20220000, 0x20000 },
[MICROCHIP_PFSOC_IOSCB_CFG] = { 0x37080000, 0x1000 },
@@ -215,6 +223,28 @@ static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
memmap[MICROCHIP_PFSOC_MPUCFG].base,
memmap[MICROCHIP_PFSOC_MPUCFG].size);
+ /* 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));
+
/* eNVM */
memory_region_init_rom(envm_data, OBJECT(dev), "microchip.pfsoc.envm.data",
memmap[MICROCHIP_PFSOC_ENVM_DATA].size,
diff --git a/include/hw/riscv/microchip_pfsoc.h b/include/hw/riscv/microchip_pfsoc.h
index 1953ef1..a5efa1d 100644
--- a/include/hw/riscv/microchip_pfsoc.h
+++ b/include/hw/riscv/microchip_pfsoc.h
@@ -22,6 +22,8 @@
#ifndef HW_MICROCHIP_PFSOC_H
#define HW_MICROCHIP_PFSOC_H
+#include "hw/char/mchp_pfsoc_mmuart.h"
+
typedef struct MicrochipPFSoCState {
/*< private >*/
DeviceState parent_obj;
@@ -32,6 +34,11 @@ typedef struct MicrochipPFSoCState {
RISCVHartArrayState e_cpus;
RISCVHartArrayState u_cpus;
DeviceState *plic;
+ MchpPfSoCMMUartState *serial0;
+ MchpPfSoCMMUartState *serial1;
+ MchpPfSoCMMUartState *serial2;
+ MchpPfSoCMMUartState *serial3;
+ MchpPfSoCMMUartState *serial4;
} MicrochipPFSoCState;
#define TYPE_MICROCHIP_PFSOC "microchip.pfsoc"
@@ -64,14 +71,27 @@ enum {
MICROCHIP_PFSOC_L2CC,
MICROCHIP_PFSOC_L2LIM,
MICROCHIP_PFSOC_PLIC,
+ MICROCHIP_PFSOC_MMUART0,
MICROCHIP_PFSOC_SYSREG,
MICROCHIP_PFSOC_MPUCFG,
+ MICROCHIP_PFSOC_MMUART1,
+ MICROCHIP_PFSOC_MMUART2,
+ MICROCHIP_PFSOC_MMUART3,
+ MICROCHIP_PFSOC_MMUART4,
MICROCHIP_PFSOC_ENVM_CFG,
MICROCHIP_PFSOC_ENVM_DATA,
MICROCHIP_PFSOC_IOSCB_CFG,
MICROCHIP_PFSOC_DRAM,
};
+enum {
+ MICROCHIP_PFSOC_MMUART0_IRQ = 90,
+ MICROCHIP_PFSOC_MMUART1_IRQ = 91,
+ MICROCHIP_PFSOC_MMUART2_IRQ = 92,
+ MICROCHIP_PFSOC_MMUART3_IRQ = 93,
+ MICROCHIP_PFSOC_MMUART4_IRQ = 94,
+};
+
#define MICROCHIP_PFSOC_MANAGEMENT_CPU_COUNT 1
#define MICROCHIP_PFSOC_COMPUTE_CPU_COUNT 4
--
2.7.4
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH 07/18] hw/sd: sd: Fix incorrect populated function switch status data structure
2020-08-14 16:40 ` Bin Meng
` (6 preceding siblings ...)
(?)
@ 2020-08-14 16:40 ` Bin Meng
2020-08-15 7:58 ` Philippe Mathieu-Daudé
-1 siblings, 1 reply; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, Philippe Mathieu-Daudé, qemu-block
From: Bin Meng <bin.meng@windriver.com>
At present the function switch status data structure bit [399:376]
are wrongly pupulated. These 3 bytes encode function switch status
for the 6 function groups, with 4 bits per group, starting from
function group 6 at bit 399, then followed by function group 5 at
bit 395, and so on.
However the codes mistakenly fills in the function group 1 status
at bit 399. This fixes the code logic.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---
hw/sd/sd.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/hw/sd/sd.c b/hw/sd/sd.c
index fad9cf1..51f5900 100644
--- a/hw/sd/sd.c
+++ b/hw/sd/sd.c
@@ -806,11 +806,15 @@ static void sd_function_switch(SDState *sd, uint32_t arg)
sd->data[11] = 0x43;
sd->data[12] = 0x80; /* Supported group 1 functions */
sd->data[13] = 0x03;
+
+ sd->data[14] = 0;
+ sd->data[15] = 0;
+ sd->data[16] = 0;
for (i = 0; i < 6; i ++) {
new_func = (arg >> (i * 4)) & 0x0f;
if (mode && new_func != 0x0f)
sd->function_group[i] = new_func;
- sd->data[14 + (i >> 1)] = new_func << ((i * 4) & 4);
+ sd->data[16 - (i >> 1)] |= new_func << ((i % 2) * 4);
}
memset(&sd->data[17], 0, 47);
stw_be_p(sd->data + 64, sd_crc16(sd->data, 64));
--
2.7.4
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH 08/18] hw/sd: sd: Correctly set the high capacity bit
2020-08-14 16:40 ` Bin Meng
` (7 preceding siblings ...)
(?)
@ 2020-08-14 16:40 ` Bin Meng
2020-08-15 8:38 ` Philippe Mathieu-Daudé
-1 siblings, 1 reply; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, Philippe Mathieu-Daudé, qemu-block
From: Bin Meng <bin.meng@windriver.com>
Per the SD spec, Standard Capacity SD Memory Card (SDSC) supports
capacity up to and including 2 GiB.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---
hw/sd/sd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/sd/sd.c b/hw/sd/sd.c
index 51f5900..5e7fc3f 100644
--- a/hw/sd/sd.c
+++ b/hw/sd/sd.c
@@ -313,7 +313,7 @@ static void sd_ocr_powerup(void *opaque)
/* card power-up OK */
sd->ocr = FIELD_DP32(sd->ocr, OCR, CARD_POWER_UP, 1);
- if (sd->size > 1 * GiB) {
+ if (sd->size > 2 * GiB) {
sd->ocr = FIELD_DP32(sd->ocr, OCR, CARD_CAPACITY, 1);
}
}
--
2.7.4
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH 09/18] hw/sd: sdhci: Make sdhci_poweron_reset() internal visible
2020-08-14 16:40 ` Bin Meng
` (8 preceding siblings ...)
(?)
@ 2020-08-14 16:40 ` Bin Meng
2020-08-15 7:51 ` Philippe Mathieu-Daudé
-1 siblings, 1 reply; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, Philippe Mathieu-Daudé, qemu-block
From: Bin Meng <bin.meng@windriver.com>
sdhci_poweron_reset() might be needed for any SDHCI compatible
device that is built on top of the generic SDHCI device.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---
hw/sd/sdhci-internal.h | 1 +
hw/sd/sdhci.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/sd/sdhci-internal.h b/hw/sd/sdhci-internal.h
index e8c753d..b587e8e 100644
--- a/hw/sd/sdhci-internal.h
+++ b/hw/sd/sdhci-internal.h
@@ -342,5 +342,6 @@ void sdhci_uninitfn(SDHCIState *s);
void sdhci_common_realize(SDHCIState *s, Error **errp);
void sdhci_common_unrealize(SDHCIState *s);
void sdhci_common_class_init(ObjectClass *klass, void *data);
+void sdhci_poweron_reset(DeviceState *dev);
#endif
diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index deac181..20f2fe0 100644
--- a/hw/sd/sdhci.c
+++ b/hw/sd/sdhci.c
@@ -294,7 +294,7 @@ static void sdhci_reset(SDHCIState *s)
s->pending_insert_state = false;
}
-static void sdhci_poweron_reset(DeviceState *dev)
+void sdhci_poweron_reset(DeviceState *dev)
{
/* QOM (ie power-on) reset. This is identical to reset
* commanded via device register apart from handling of the
--
2.7.4
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH 10/18] hw/sd: Add Cadence SDHCI emulation
2020-08-14 16:40 ` Bin Meng
@ 2020-08-14 16:40 ` Bin Meng
-1 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Edgar E. Iglesias, Bin Meng, qemu-arm, Alistair Francis, Peter Maydell
From: Bin Meng <bin.meng@windriver.com>
Cadence SD/SDIO/eMMC Host Controller (SD4HC) is an SDHCI compatible
controller. The SDHCI compatible registers start from offset 0x200,
which are called Slot Register Set (SRS) in its datasheet.
This creates a Cadence SDHCI model built on top of the existing
generic SDHCI model. Cadence specific Host Register Set (HRS) is
implemented to make guest software happy.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---
hw/sd/Kconfig | 4 ++
hw/sd/Makefile.objs | 1 +
hw/sd/cadence_sdhci.c | 162 ++++++++++++++++++++++++++++++++++++++++++
include/hw/sd/cadence_sdhci.h | 65 +++++++++++++++++
4 files changed, 232 insertions(+)
create mode 100644 hw/sd/cadence_sdhci.c
create mode 100644 include/hw/sd/cadence_sdhci.h
diff --git a/hw/sd/Kconfig b/hw/sd/Kconfig
index c5e1e55..633b9af 100644
--- a/hw/sd/Kconfig
+++ b/hw/sd/Kconfig
@@ -19,3 +19,7 @@ config SDHCI_PCI
default y if PCI_DEVICES
depends on PCI
select SDHCI
+
+config CADENCE_SDHCI
+ bool
+ select SDHCI
diff --git a/hw/sd/Makefile.objs b/hw/sd/Makefile.objs
index 0d1df17..4d500a6 100644
--- a/hw/sd/Makefile.objs
+++ b/hw/sd/Makefile.objs
@@ -10,3 +10,4 @@ common-obj-$(CONFIG_OMAP) += omap_mmc.o
common-obj-$(CONFIG_PXA2XX) += pxa2xx_mmci.o
common-obj-$(CONFIG_RASPI) += bcm2835_sdhost.o
common-obj-$(CONFIG_ASPEED_SOC) += aspeed_sdhci.o
+common-obj-$(CONFIG_CADENCE_SDHCI) += cadence_sdhci.o
diff --git a/hw/sd/cadence_sdhci.c b/hw/sd/cadence_sdhci.c
new file mode 100644
index 0000000..67ffd14
--- /dev/null
+++ b/hw/sd/cadence_sdhci.c
@@ -0,0 +1,162 @@
+/*
+ * Cadence SDHCI emulation
+ *
+ * Copyright (c) 2020 Wind River Systems, Inc.
+ *
+ * Author:
+ * Bin Meng <bin.meng@windriver.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) version 3 of the License.
+ *
+ * This program is distributed in the hope that 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/log.h"
+#include "qapi/error.h"
+#include "migration/vmstate.h"
+#include "hw/irq.h"
+#include "hw/sd/cadence_sdhci.h"
+#include "sdhci-internal.h"
+
+#define TO_REG(addr) ((addr) / sizeof(uint32_t))
+
+static void cadence_sdhci_reset(DeviceState *dev)
+{
+ CadenceSDHCIState *sdhci = CADENCE_SDHCI(dev);
+
+ memset(sdhci->regs, 0, CADENCE_SDHCI_REG_SIZE);
+ sdhci->regs[TO_REG(SDHCI_CDNS_HRS00)] = SDHCI_CDNS_HRS00_POR_VAL;
+}
+
+static uint64_t cadence_sdhci_read(void *opaque, hwaddr addr, unsigned int size)
+{
+ uint32_t val = 0;
+ CadenceSDHCIState *sdhci = opaque;
+
+ if (addr < CADENCE_SDHCI_REG_SIZE) {
+ val = sdhci->regs[TO_REG(addr)];
+ } else {
+ qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: Out-of-bounds read at 0x%" HWADDR_PRIx "\n",
+ __func__, addr);
+ }
+
+ return (uint64_t)val;
+}
+
+static void cadence_sdhci_write(void *opaque, hwaddr addr, uint64_t val,
+ unsigned int size)
+{
+ CadenceSDHCIState *sdhci = opaque;
+ uint32_t val32 = (uint32_t)val;
+
+ switch (addr) {
+ case SDHCI_CDNS_HRS00:
+ /*
+ * The only writable bit is SWR (software reset) and it automatically
+ * clears to zero, so essentially this register remains unchanged.
+ */
+ if (val32 & SDHCI_CDNS_HRS00_SWR) {
+ cadence_sdhci_reset(DEVICE(sdhci));
+ sdhci_poweron_reset(DEVICE(&sdhci->slot));
+ }
+
+ break;
+ case SDHCI_CDNS_HRS04:
+ /*
+ * Only emulate the ACK bit behavior when read or write transaction
+ * are requested.
+ */
+ if (val32 & (SDHCI_CDNS_HRS04_WR | SDHCI_CDNS_HRS04_RD)) {
+ val32 |= SDHCI_CDNS_HRS04_ACK;
+ } else {
+ val32 &= ~SDHCI_CDNS_HRS04_ACK;
+ }
+
+ sdhci->regs[TO_REG(addr)] = val32;
+ break;
+ case SDHCI_CDNS_HRS06:
+ if (val32 & SDHCI_CDNS_HRS06_TUNE_UP) {
+ val32 &= ~SDHCI_CDNS_HRS06_TUNE_UP;
+ }
+
+ sdhci->regs[TO_REG(addr)] = val32;
+ break;
+ default:
+ if (addr < CADENCE_SDHCI_REG_SIZE) {
+ sdhci->regs[TO_REG(addr)] = val32;
+ } else {
+ qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: Out-of-bounds write at 0x%" HWADDR_PRIx "\n",
+ __func__, addr);
+ }
+ }
+}
+
+static const MemoryRegionOps cadence_sdhci_ops = {
+ .read = cadence_sdhci_read,
+ .write = cadence_sdhci_write,
+ .endianness = DEVICE_NATIVE_ENDIAN,
+ .valid = {
+ .min_access_size = 4,
+ .max_access_size = 4,
+ }
+};
+
+static void cadence_sdhci_realize(DeviceState *dev, Error **errp)
+{
+ SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
+ CadenceSDHCIState *sdhci = CADENCE_SDHCI(dev);
+ SysBusDevice *sbd_slot = SYS_BUS_DEVICE(&sdhci->slot);
+
+ memory_region_init_io(&sdhci->iomem, OBJECT(sdhci), &cadence_sdhci_ops,
+ sdhci, TYPE_CADENCE_SDHCI, 0x1000);
+ sysbus_init_mmio(sbd, &sdhci->iomem);
+
+ sysbus_realize(sbd_slot, errp);
+ memory_region_add_subregion(&sdhci->iomem, SDHCI_CDNS_SRS_BASE,
+ &sdhci->slot.iomem);
+}
+
+static const VMStateDescription vmstate_cadence_sdhci = {
+ .name = TYPE_CADENCE_SDHCI,
+ .version_id = 1,
+ .fields = (VMStateField[]) {
+ VMSTATE_UINT32_ARRAY(regs, CadenceSDHCIState, CADENCE_SDHCI_NUM_REGS),
+ VMSTATE_END_OF_LIST(),
+ },
+};
+
+static void cadence_sdhci_class_init(ObjectClass *classp, void *data)
+{
+ DeviceClass *dc = DEVICE_CLASS(classp);
+
+ dc->realize = cadence_sdhci_realize;
+ dc->reset = cadence_sdhci_reset;
+ dc->vmsd = &vmstate_cadence_sdhci;
+}
+
+static TypeInfo cadence_sdhci_info = {
+ .name = TYPE_CADENCE_SDHCI,
+ .parent = TYPE_SYS_BUS_DEVICE,
+ .instance_size = sizeof(CadenceSDHCIState),
+ .class_init = cadence_sdhci_class_init,
+};
+
+static void cadence_sdhci_register_types(void)
+{
+ type_register_static(&cadence_sdhci_info);
+}
+
+type_init(cadence_sdhci_register_types)
diff --git a/include/hw/sd/cadence_sdhci.h b/include/hw/sd/cadence_sdhci.h
new file mode 100644
index 0000000..9ff78a9
--- /dev/null
+++ b/include/hw/sd/cadence_sdhci.h
@@ -0,0 +1,65 @@
+/*
+ * Cadence SDHCI emulation
+ *
+ * Copyright (c) 2020 Wind River Systems, Inc.
+ *
+ * Author:
+ * Bin Meng <bin.meng@windriver.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) version 3 of the License.
+ *
+ * This program is distributed in the hope that 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/>.
+ */
+
+#ifndef CADENCE_SDHCI_H
+#define CADENCE_SDHCI_H
+
+#include "qemu/bitops.h"
+#include "hw/sd/sdhci.h"
+
+/* HRS - Host Register Set (specific to Cadence) */
+
+#define SDHCI_CDNS_HRS00 0x00 /* general information */
+#define SDHCI_CDNS_HRS00_SWR BIT(0)
+#define SDHCI_CDNS_HRS00_POR_VAL 0x00010000
+
+#define SDHCI_CDNS_HRS04 0x10 /* PHY access port */
+#define SDHCI_CDNS_HRS04_WR BIT(24)
+#define SDHCI_CDNS_HRS04_RD BIT(25)
+#define SDHCI_CDNS_HRS04_ACK BIT(26)
+
+#define SDHCI_CDNS_HRS06 0x18 /* eMMC control */
+#define SDHCI_CDNS_HRS06_TUNE_UP BIT(15)
+
+/* SRS - Slot Register Set (SDHCI-compatible) */
+#define SDHCI_CDNS_SRS_BASE 0x200
+
+#define CADENCE_SDHCI_CAPABILITIES 0x01E80080
+#define CADENCE_SDHCI_REG_SIZE 0x100
+#define CADENCE_SDHCI_NUM_REGS (CADENCE_SDHCI_REG_SIZE / sizeof(uint32_t))
+
+typedef struct CadenceSDHCIState {
+ SysBusDevice parent;
+
+ MemoryRegion iomem;
+ qemu_irq irq;
+
+ uint32_t regs[CADENCE_SDHCI_NUM_REGS];
+
+ SDHCIState slot;
+} CadenceSDHCIState;
+
+#define TYPE_CADENCE_SDHCI "cadence.sdhci"
+#define CADENCE_SDHCI(obj) OBJECT_CHECK(CadenceSDHCIState, (obj), \
+ TYPE_CADENCE_SDHCI)
+
+#endif /* CADENCE_SDHCI_H */
--
2.7.4
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH 10/18] hw/sd: Add Cadence SDHCI emulation
@ 2020-08-14 16:40 ` Bin Meng
0 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, Alistair Francis, Edgar E. Iglesias, Peter Maydell, qemu-arm
From: Bin Meng <bin.meng@windriver.com>
Cadence SD/SDIO/eMMC Host Controller (SD4HC) is an SDHCI compatible
controller. The SDHCI compatible registers start from offset 0x200,
which are called Slot Register Set (SRS) in its datasheet.
This creates a Cadence SDHCI model built on top of the existing
generic SDHCI model. Cadence specific Host Register Set (HRS) is
implemented to make guest software happy.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---
hw/sd/Kconfig | 4 ++
hw/sd/Makefile.objs | 1 +
hw/sd/cadence_sdhci.c | 162 ++++++++++++++++++++++++++++++++++++++++++
include/hw/sd/cadence_sdhci.h | 65 +++++++++++++++++
4 files changed, 232 insertions(+)
create mode 100644 hw/sd/cadence_sdhci.c
create mode 100644 include/hw/sd/cadence_sdhci.h
diff --git a/hw/sd/Kconfig b/hw/sd/Kconfig
index c5e1e55..633b9af 100644
--- a/hw/sd/Kconfig
+++ b/hw/sd/Kconfig
@@ -19,3 +19,7 @@ config SDHCI_PCI
default y if PCI_DEVICES
depends on PCI
select SDHCI
+
+config CADENCE_SDHCI
+ bool
+ select SDHCI
diff --git a/hw/sd/Makefile.objs b/hw/sd/Makefile.objs
index 0d1df17..4d500a6 100644
--- a/hw/sd/Makefile.objs
+++ b/hw/sd/Makefile.objs
@@ -10,3 +10,4 @@ common-obj-$(CONFIG_OMAP) += omap_mmc.o
common-obj-$(CONFIG_PXA2XX) += pxa2xx_mmci.o
common-obj-$(CONFIG_RASPI) += bcm2835_sdhost.o
common-obj-$(CONFIG_ASPEED_SOC) += aspeed_sdhci.o
+common-obj-$(CONFIG_CADENCE_SDHCI) += cadence_sdhci.o
diff --git a/hw/sd/cadence_sdhci.c b/hw/sd/cadence_sdhci.c
new file mode 100644
index 0000000..67ffd14
--- /dev/null
+++ b/hw/sd/cadence_sdhci.c
@@ -0,0 +1,162 @@
+/*
+ * Cadence SDHCI emulation
+ *
+ * Copyright (c) 2020 Wind River Systems, Inc.
+ *
+ * Author:
+ * Bin Meng <bin.meng@windriver.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) version 3 of the License.
+ *
+ * This program is distributed in the hope that 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/log.h"
+#include "qapi/error.h"
+#include "migration/vmstate.h"
+#include "hw/irq.h"
+#include "hw/sd/cadence_sdhci.h"
+#include "sdhci-internal.h"
+
+#define TO_REG(addr) ((addr) / sizeof(uint32_t))
+
+static void cadence_sdhci_reset(DeviceState *dev)
+{
+ CadenceSDHCIState *sdhci = CADENCE_SDHCI(dev);
+
+ memset(sdhci->regs, 0, CADENCE_SDHCI_REG_SIZE);
+ sdhci->regs[TO_REG(SDHCI_CDNS_HRS00)] = SDHCI_CDNS_HRS00_POR_VAL;
+}
+
+static uint64_t cadence_sdhci_read(void *opaque, hwaddr addr, unsigned int size)
+{
+ uint32_t val = 0;
+ CadenceSDHCIState *sdhci = opaque;
+
+ if (addr < CADENCE_SDHCI_REG_SIZE) {
+ val = sdhci->regs[TO_REG(addr)];
+ } else {
+ qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: Out-of-bounds read at 0x%" HWADDR_PRIx "\n",
+ __func__, addr);
+ }
+
+ return (uint64_t)val;
+}
+
+static void cadence_sdhci_write(void *opaque, hwaddr addr, uint64_t val,
+ unsigned int size)
+{
+ CadenceSDHCIState *sdhci = opaque;
+ uint32_t val32 = (uint32_t)val;
+
+ switch (addr) {
+ case SDHCI_CDNS_HRS00:
+ /*
+ * The only writable bit is SWR (software reset) and it automatically
+ * clears to zero, so essentially this register remains unchanged.
+ */
+ if (val32 & SDHCI_CDNS_HRS00_SWR) {
+ cadence_sdhci_reset(DEVICE(sdhci));
+ sdhci_poweron_reset(DEVICE(&sdhci->slot));
+ }
+
+ break;
+ case SDHCI_CDNS_HRS04:
+ /*
+ * Only emulate the ACK bit behavior when read or write transaction
+ * are requested.
+ */
+ if (val32 & (SDHCI_CDNS_HRS04_WR | SDHCI_CDNS_HRS04_RD)) {
+ val32 |= SDHCI_CDNS_HRS04_ACK;
+ } else {
+ val32 &= ~SDHCI_CDNS_HRS04_ACK;
+ }
+
+ sdhci->regs[TO_REG(addr)] = val32;
+ break;
+ case SDHCI_CDNS_HRS06:
+ if (val32 & SDHCI_CDNS_HRS06_TUNE_UP) {
+ val32 &= ~SDHCI_CDNS_HRS06_TUNE_UP;
+ }
+
+ sdhci->regs[TO_REG(addr)] = val32;
+ break;
+ default:
+ if (addr < CADENCE_SDHCI_REG_SIZE) {
+ sdhci->regs[TO_REG(addr)] = val32;
+ } else {
+ qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: Out-of-bounds write at 0x%" HWADDR_PRIx "\n",
+ __func__, addr);
+ }
+ }
+}
+
+static const MemoryRegionOps cadence_sdhci_ops = {
+ .read = cadence_sdhci_read,
+ .write = cadence_sdhci_write,
+ .endianness = DEVICE_NATIVE_ENDIAN,
+ .valid = {
+ .min_access_size = 4,
+ .max_access_size = 4,
+ }
+};
+
+static void cadence_sdhci_realize(DeviceState *dev, Error **errp)
+{
+ SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
+ CadenceSDHCIState *sdhci = CADENCE_SDHCI(dev);
+ SysBusDevice *sbd_slot = SYS_BUS_DEVICE(&sdhci->slot);
+
+ memory_region_init_io(&sdhci->iomem, OBJECT(sdhci), &cadence_sdhci_ops,
+ sdhci, TYPE_CADENCE_SDHCI, 0x1000);
+ sysbus_init_mmio(sbd, &sdhci->iomem);
+
+ sysbus_realize(sbd_slot, errp);
+ memory_region_add_subregion(&sdhci->iomem, SDHCI_CDNS_SRS_BASE,
+ &sdhci->slot.iomem);
+}
+
+static const VMStateDescription vmstate_cadence_sdhci = {
+ .name = TYPE_CADENCE_SDHCI,
+ .version_id = 1,
+ .fields = (VMStateField[]) {
+ VMSTATE_UINT32_ARRAY(regs, CadenceSDHCIState, CADENCE_SDHCI_NUM_REGS),
+ VMSTATE_END_OF_LIST(),
+ },
+};
+
+static void cadence_sdhci_class_init(ObjectClass *classp, void *data)
+{
+ DeviceClass *dc = DEVICE_CLASS(classp);
+
+ dc->realize = cadence_sdhci_realize;
+ dc->reset = cadence_sdhci_reset;
+ dc->vmsd = &vmstate_cadence_sdhci;
+}
+
+static TypeInfo cadence_sdhci_info = {
+ .name = TYPE_CADENCE_SDHCI,
+ .parent = TYPE_SYS_BUS_DEVICE,
+ .instance_size = sizeof(CadenceSDHCIState),
+ .class_init = cadence_sdhci_class_init,
+};
+
+static void cadence_sdhci_register_types(void)
+{
+ type_register_static(&cadence_sdhci_info);
+}
+
+type_init(cadence_sdhci_register_types)
diff --git a/include/hw/sd/cadence_sdhci.h b/include/hw/sd/cadence_sdhci.h
new file mode 100644
index 0000000..9ff78a9
--- /dev/null
+++ b/include/hw/sd/cadence_sdhci.h
@@ -0,0 +1,65 @@
+/*
+ * Cadence SDHCI emulation
+ *
+ * Copyright (c) 2020 Wind River Systems, Inc.
+ *
+ * Author:
+ * Bin Meng <bin.meng@windriver.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) version 3 of the License.
+ *
+ * This program is distributed in the hope that 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/>.
+ */
+
+#ifndef CADENCE_SDHCI_H
+#define CADENCE_SDHCI_H
+
+#include "qemu/bitops.h"
+#include "hw/sd/sdhci.h"
+
+/* HRS - Host Register Set (specific to Cadence) */
+
+#define SDHCI_CDNS_HRS00 0x00 /* general information */
+#define SDHCI_CDNS_HRS00_SWR BIT(0)
+#define SDHCI_CDNS_HRS00_POR_VAL 0x00010000
+
+#define SDHCI_CDNS_HRS04 0x10 /* PHY access port */
+#define SDHCI_CDNS_HRS04_WR BIT(24)
+#define SDHCI_CDNS_HRS04_RD BIT(25)
+#define SDHCI_CDNS_HRS04_ACK BIT(26)
+
+#define SDHCI_CDNS_HRS06 0x18 /* eMMC control */
+#define SDHCI_CDNS_HRS06_TUNE_UP BIT(15)
+
+/* SRS - Slot Register Set (SDHCI-compatible) */
+#define SDHCI_CDNS_SRS_BASE 0x200
+
+#define CADENCE_SDHCI_CAPABILITIES 0x01E80080
+#define CADENCE_SDHCI_REG_SIZE 0x100
+#define CADENCE_SDHCI_NUM_REGS (CADENCE_SDHCI_REG_SIZE / sizeof(uint32_t))
+
+typedef struct CadenceSDHCIState {
+ SysBusDevice parent;
+
+ MemoryRegion iomem;
+ qemu_irq irq;
+
+ uint32_t regs[CADENCE_SDHCI_NUM_REGS];
+
+ SDHCIState slot;
+} CadenceSDHCIState;
+
+#define TYPE_CADENCE_SDHCI "cadence.sdhci"
+#define CADENCE_SDHCI(obj) OBJECT_CHECK(CadenceSDHCIState, (obj), \
+ TYPE_CADENCE_SDHCI)
+
+#endif /* CADENCE_SDHCI_H */
--
2.7.4
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH 11/18] hw/riscv: microchip_pfsoc: Connect a Cadence SDHCI controller and an SD card
2020-08-14 16:40 ` Bin Meng
` (10 preceding siblings ...)
(?)
@ 2020-08-14 16:40 ` Bin Meng
2020-08-15 8:55 ` Philippe Mathieu-Daudé
-1 siblings, 1 reply; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, Palmer Dabbelt
From: Bin Meng <bin.meng@windriver.com>
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>
---
hw/riscv/Kconfig | 1 +
hw/riscv/microchip_pfsoc.c | 26 ++++++++++++++++++++++++++
include/hw/riscv/microchip_pfsoc.h | 4 ++++
3 files changed, 31 insertions(+)
diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
index ceb7c16..7412db9 100644
--- a/hw/riscv/Kconfig
+++ b/hw/riscv/Kconfig
@@ -55,3 +55,4 @@ config MICROCHIP_PFSOC
select SIFIVE
select UNIMP
select MCHP_PFSOC_MMUART
+ select CADENCE_SDHCI
diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
index f6b375c..7c09078 100644
--- a/hw/riscv/microchip_pfsoc.c
+++ b/hw/riscv/microchip_pfsoc.c
@@ -12,6 +12,7 @@
* 1) PLIC (Platform Level Interrupt Controller)
* 2) eNVM (Embedded Non-Volatile Memory)
* 3) MMUARTs (Multi-Mode UART)
+ * 4) Cadence eMMC/SDHC controller and an SD card connected to it
*
* This board currently generates devicetree dynamically that indicates at least
* two harts and up to five harts.
@@ -75,6 +76,7 @@ static const struct MemmapEntry {
[MICROCHIP_PFSOC_MMUART0] = { 0x20000000, 0x1000 },
[MICROCHIP_PFSOC_SYSREG] = { 0x20002000, 0x2000 },
[MICROCHIP_PFSOC_MPUCFG] = { 0x20005000, 0x1000 },
+ [MICROCHIP_PFSOC_EMMC_SD] = { 0x20008000, 0x1000 },
[MICROCHIP_PFSOC_MMUART1] = { 0x20100000, 0x1000 },
[MICROCHIP_PFSOC_MMUART2] = { 0x20102000, 0x1000 },
[MICROCHIP_PFSOC_MMUART3] = { 0x20104000, 0x1000 },
@@ -111,6 +113,11 @@ static void microchip_pfsoc_soc_instance_init(Object *obj)
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);
+
+ object_initialize_child(obj, "sd-controller", &s->sdhci,
+ TYPE_CADENCE_SDHCI);
+ object_initialize_child(OBJECT(&s->sdhci), "sd-controller.sdhci",
+ &s->sdhci.slot, TYPE_SYSBUS_SDHCI);
}
static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
@@ -223,6 +230,13 @@ static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
memmap[MICROCHIP_PFSOC_MPUCFG].base,
memmap[MICROCHIP_PFSOC_MPUCFG].size);
+ /* 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.slot), 0,
+ qdev_get_gpio_in(DEVICE(s->plic), MICROCHIP_PFSOC_EMMC_SD_IRQ));
+
/* MMUARTs */
s->serial0 = mchp_pfsoc_mmuart_create(system_memory,
memmap[MICROCHIP_PFSOC_MMUART0].base,
@@ -290,6 +304,7 @@ static void microchip_icicle_kit_machine_init(MachineState *machine)
MicrochipIcicleKitState *s = MICROCHIP_ICICLE_KIT_MACHINE(machine);
MemoryRegion *system_memory = get_system_memory();
MemoryRegion *main_mem = g_new(MemoryRegion, 1);
+ DriveInfo *dinfo = drive_get_next(IF_SD);
/* Sanity check on RAM size */
if (machine->ram_size < mc->default_ram_size) {
@@ -312,6 +327,17 @@ static void microchip_icicle_kit_machine_init(MachineState *machine)
/* Load the firmware */
riscv_find_and_load_firmware(machine, BIOS_FILENAME, RESET_VECTOR, NULL);
+
+ /* Attach an SD card */
+ if (dinfo) {
+ SDHCIState *sdhci = &(s->soc.sdhci.slot);
+ DeviceState *card = qdev_new(TYPE_SD_CARD);
+ BusState *bus = qdev_get_child_bus(DEVICE(sdhci), "sd-bus");
+
+ qdev_prop_set_drive_err(card, "drive", blk_by_legacy_dinfo(dinfo),
+ &error_fatal);
+ qdev_realize_and_unref(card, bus, &error_fatal);
+ }
}
static void microchip_icicle_kit_machine_class_init(ObjectClass *oc, void *data)
diff --git a/include/hw/riscv/microchip_pfsoc.h b/include/hw/riscv/microchip_pfsoc.h
index a5efa1d..d810ee8 100644
--- a/include/hw/riscv/microchip_pfsoc.h
+++ b/include/hw/riscv/microchip_pfsoc.h
@@ -23,6 +23,7 @@
#define HW_MICROCHIP_PFSOC_H
#include "hw/char/mchp_pfsoc_mmuart.h"
+#include "hw/sd/cadence_sdhci.h"
typedef struct MicrochipPFSoCState {
/*< private >*/
@@ -39,6 +40,7 @@ typedef struct MicrochipPFSoCState {
MchpPfSoCMMUartState *serial2;
MchpPfSoCMMUartState *serial3;
MchpPfSoCMMUartState *serial4;
+ CadenceSDHCIState sdhci;
} MicrochipPFSoCState;
#define TYPE_MICROCHIP_PFSOC "microchip.pfsoc"
@@ -74,6 +76,7 @@ enum {
MICROCHIP_PFSOC_MMUART0,
MICROCHIP_PFSOC_SYSREG,
MICROCHIP_PFSOC_MPUCFG,
+ MICROCHIP_PFSOC_EMMC_SD,
MICROCHIP_PFSOC_MMUART1,
MICROCHIP_PFSOC_MMUART2,
MICROCHIP_PFSOC_MMUART3,
@@ -85,6 +88,7 @@ enum {
};
enum {
+ MICROCHIP_PFSOC_EMMC_SD_IRQ = 88,
MICROCHIP_PFSOC_MMUART0_IRQ = 90,
MICROCHIP_PFSOC_MMUART1_IRQ = 91,
MICROCHIP_PFSOC_MMUART2_IRQ = 92,
--
2.7.4
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH 12/18] hw/dma: Add Microchip PolarFire Soc DMA controller emulation
2020-08-14 16:40 ` Bin Meng
` (11 preceding siblings ...)
(?)
@ 2020-08-14 16:40 ` Bin Meng
-1 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng
From: Bin Meng <bin.meng@windriver.com>
Microchip PolarFire SoC integrates a DMA engine that supports:
* Independent concurrent DMA transfers using 4 DMA channels
* Generation of interrupts on various conditions during execution
This creates a simple model to support polling mode which is
enough for firmware usage. While there are codes for interrupts
handling, please note the interrupt path has not been validated
due to missing kernel driver for testing as of now.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---
MAINTAINERS | 2 +
hw/dma/Kconfig | 3 +
hw/dma/Makefile.objs | 1 +
hw/dma/mchp_pfsoc_dma.c | 322 ++++++++++++++++++++++++++++++++++++++++
include/hw/dma/mchp_pfsoc_dma.h | 57 +++++++
5 files changed, 385 insertions(+)
create mode 100644 hw/dma/mchp_pfsoc_dma.c
create mode 100644 include/hw/dma/mchp_pfsoc_dma.h
diff --git a/MAINTAINERS b/MAINTAINERS
index e51edac..0aacc90 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1320,8 +1320,10 @@ L: qemu-riscv@nongnu.org
S: Supported
F: hw/riscv/microchip_pfsoc.c
F: hw/char/mchp_pfsoc_mmuart.c
+F: hw/dma/mchp_pfsoc_dma.c
F: include/hw/riscv/microchip_pfsoc.h
F: include/hw/char/mchp_pfsoc_mmuart.h
+F: include/hw/dma/mchp_pfsoc_dma.h
RX Machines
-----------
diff --git a/hw/dma/Kconfig b/hw/dma/Kconfig
index 5c61b67..778e20b 100644
--- a/hw/dma/Kconfig
+++ b/hw/dma/Kconfig
@@ -20,3 +20,6 @@ config ZYNQ_DEVCFG
config STP2000
bool
+
+config MCHP_PFSOC_DMA
+ bool
diff --git a/hw/dma/Makefile.objs b/hw/dma/Makefile.objs
index f4b1cfe..fd7e836 100644
--- a/hw/dma/Makefile.objs
+++ b/hw/dma/Makefile.objs
@@ -14,3 +14,4 @@ common-obj-$(CONFIG_XLNX_ZYNQMP_ARM) += xlnx-zdma.o
common-obj-$(CONFIG_OMAP) += omap_dma.o soc_dma.o
common-obj-$(CONFIG_PXA2XX) += pxa2xx_dma.o
common-obj-$(CONFIG_RASPI) += bcm2835_dma.o
+common-obj-$(CONFIG_MCHP_PFSOC_DMA) += mchp_pfsoc_dma.o
diff --git a/hw/dma/mchp_pfsoc_dma.c b/hw/dma/mchp_pfsoc_dma.c
new file mode 100644
index 0000000..8531a6f
--- /dev/null
+++ b/hw/dma/mchp_pfsoc_dma.c
@@ -0,0 +1,322 @@
+/*
+ * Microchip PolarFire SoC DMA emulation
+ *
+ * Copyright (c) 2020 Wind River Systems, Inc.
+ *
+ * Author:
+ * Bin Meng <bin.meng@windriver.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) version 3 of the License.
+ *
+ * This program is distributed in the hope that 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/bitops.h"
+#include "qemu/log.h"
+#include "qapi/error.h"
+#include "hw/hw.h"
+#include "hw/irq.h"
+#include "hw/qdev-properties.h"
+#include "hw/sysbus.h"
+#include "migration/vmstate.h"
+#include "sysemu/dma.h"
+#include "hw/dma/mchp_pfsoc_dma.h"
+
+#define DMA_CONTROL 0x000
+#define CONTROL_CLAIM BIT(0)
+#define CONTROL_RUN BIT(1)
+#define CONTROL_DONE_IE BIT(14)
+#define CONTROL_ERR_IE BIT(15)
+#define CONTROL_DONE BIT(30)
+#define CONTROL_ERR BIT(31)
+
+#define DMA_NEXT_CONFIG 0x004
+#define CONFIG_REPEAT BIT(2)
+#define CONFIG_ORDER BIT(3)
+#define CONFIG_WRSZ_SHIFT 24
+#define CONFIG_RDSZ_SHIFT 28
+#define CONFIG_SZ_MASK 0xf
+
+#define DMA_NEXT_BYTES 0x008
+#define DMA_NEXT_DST 0x010
+#define DMA_NEXT_SRC 0x018
+#define DMA_EXEC_CONFIG 0x104
+#define DMA_EXEC_BYTES 0x108
+#define DMA_EXEC_DST 0x110
+#define DMA_EXEC_SRC 0x118
+
+enum dma_chan_state {
+ DMA_CHAN_STATE_IDLE,
+ DMA_CHAN_STATE_STARTED,
+ DMA_CHAN_STATE_ERROR,
+ DMA_CHAN_STATE_DONE
+};
+
+static void mchp_pfsoc_dma_run(MchpPfSoCDMAState *s, int ch)
+{
+ uint64_t bytes = s->chan[ch].next_bytes;
+ uint64_t dst = s->chan[ch].next_dst;
+ uint64_t src = s->chan[ch].next_src;
+ uint32_t config = s->chan[ch].next_config;
+ int wsize, rsize, size;
+ uint8_t buf[64];
+ int n;
+
+ /* do nothing if bytes to transfer is zero */
+ if (!bytes) {
+ goto error;
+ }
+
+ /*
+ * The manual does not describe how the hardware behaviors when
+ * config.wsize and config.rsize are given different values.
+ * A common case is memory to memory DMA, and in this case they
+ * are normally the same. Abort if this expectation fails.
+ */
+ wsize = (config >> CONFIG_WRSZ_SHIFT) & CONFIG_SZ_MASK;
+ rsize = (config >> CONFIG_RDSZ_SHIFT) & CONFIG_SZ_MASK;
+ if (wsize != rsize) {
+ goto error;
+ }
+
+ /*
+ * Calculate the transaction size
+ *
+ * size field is base 2 logarithm of DMA transaction size,
+ * but there is an upper limit of 64 bytes per transaction.
+ */
+ size = wsize;
+ if (size > 6) {
+ size = 6;
+ }
+ size = 1 << size;
+
+ /* the bytes to transfer should be multiple of transaction size */
+ if (bytes % size) {
+ goto error;
+ }
+
+ /* inidate a DMA transfer is started */
+ s->chan[ch].state = DMA_CHAN_STATE_STARTED;
+ s->chan[ch].control |= CONTROL_CLAIM;
+ s->chan[ch].control &= ~CONTROL_DONE;
+ s->chan[ch].control &= ~CONTROL_ERR;
+
+ /* load the next_ registers into their exec_ counterparts */
+ s->chan[ch].exec_config = config;
+ s->chan[ch].exec_bytes = bytes;
+ s->chan[ch].exec_dst = dst;
+ s->chan[ch].exec_src = src;
+
+ for (n = 0; n < bytes / size; n++) {
+ cpu_physical_memory_read(s->chan[ch].exec_src, buf, size);
+ cpu_physical_memory_write(s->chan[ch].exec_dst, buf, size);
+ s->chan[ch].exec_src += size;
+ s->chan[ch].exec_dst += size;
+ s->chan[ch].exec_bytes -= size;
+ }
+
+ /* inidate a DMA transfer is done */
+ s->chan[ch].state = DMA_CHAN_STATE_DONE;
+ s->chan[ch].control &= ~CONTROL_CLAIM;
+ s->chan[ch].control &= ~CONTROL_RUN;
+ s->chan[ch].control |= CONTROL_DONE;
+
+ /* reload exec_ registers if repeat is required */
+ if (s->chan[ch].next_config & CONFIG_REPEAT) {
+ s->chan[ch].exec_bytes = bytes;
+ s->chan[ch].exec_dst = dst;
+ s->chan[ch].exec_src = src;
+ }
+
+ return;
+
+error:
+ s->chan[ch].state = DMA_CHAN_STATE_ERROR;
+ s->chan[ch].control |= CONTROL_ERR;
+ return;
+}
+
+static inline void mchp_pfsoc_dma_update_irq(MchpPfSoCDMAState *s, int ch)
+{
+ bool done_ie, err_ie;
+
+ done_ie = !!(s->chan[ch].control & CONTROL_DONE_IE);
+ err_ie = !!(s->chan[ch].control & CONTROL_ERR_IE);
+
+ /*
+ * Todo:
+ *
+ * It's unclear from the manual when the interrupt will be lowered.
+ * It might be that the ISR reads the status bits and writes 1 to clear,
+ * Right now there is no driver that uses ISR to validate this guess.
+ *
+ * Also the manual does not clear describe how the 2 interrupt lines
+ * are routed to PLIC hence we assume only 1 line for now.
+ */
+ if ((done_ie && (s->chan[ch].control & CONTROL_DONE)) ||
+ (err_ie && (s->chan[ch].control & CONTROL_ERR))) {
+ qemu_irq_raise(s->irq);
+ } else {
+ qemu_irq_lower(s->irq);
+ }
+
+ s->chan[ch].state = DMA_CHAN_STATE_IDLE;
+}
+
+static uint64_t mchp_pfsoc_dma_read(void *opaque, hwaddr offset, unsigned size)
+{
+ MchpPfSoCDMAState *s = opaque;
+ int no = MCHP_PFSOC_DMA_CHAN_NO(offset);
+ uint64_t val = 0;
+
+ if (no >= MCHP_PFSOC_DMA_CHANS) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: Invalid channel no %d\n",
+ __func__, no);
+ return 0;
+ }
+
+ switch (offset) {
+ case DMA_CONTROL:
+ val = s->chan[no].control;
+ break;
+ case DMA_NEXT_CONFIG:
+ val = s->chan[no].next_config;
+ break;
+ case DMA_NEXT_BYTES:
+ val = s->chan[no].next_bytes;
+ break;
+ case DMA_NEXT_DST:
+ val = s->chan[no].next_dst;
+ break;
+ case DMA_NEXT_SRC:
+ val = s->chan[no].next_src;
+ break;
+ case DMA_EXEC_CONFIG:
+ val = s->chan[no].exec_config;
+ break;
+ case DMA_EXEC_BYTES:
+ val = s->chan[no].exec_bytes;
+ break;
+ case DMA_EXEC_DST:
+ val = s->chan[no].exec_dst;
+ break;
+ case DMA_EXEC_SRC:
+ val = s->chan[no].exec_src;
+ break;
+ default:
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: Bad offset 0x%" HWADDR_PRIX "\n",
+ __func__, offset);
+ break;
+ }
+
+ return val;
+}
+
+static void mchp_pfsoc_dma_write(void *opaque, hwaddr offset,
+ uint64_t value, unsigned size)
+{
+ MchpPfSoCDMAState *s = opaque;
+ int no = MCHP_PFSOC_DMA_CHAN_NO(offset);
+
+ if (no >= MCHP_PFSOC_DMA_CHANS) {
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: Invalid channel no %d\n",
+ __func__, no);
+ return;
+ }
+
+ switch (offset) {
+ case DMA_CONTROL:
+ s->chan[no].control = value;
+
+ if (value & CONTROL_CLAIM) {
+ s->chan[no].next_config = 0;
+ s->chan[no].next_bytes = 0;
+ s->chan[no].next_dst = 0;
+ s->chan[no].next_src = 0;
+ s->chan[no].control &= ~CONTROL_CLAIM;
+ }
+
+ if (value & CONTROL_RUN) {
+ mchp_pfsoc_dma_run(s, no);
+ }
+
+ mchp_pfsoc_dma_update_irq(s, no);
+ break;
+ case DMA_NEXT_CONFIG:
+ s->chan[no].next_config = value;
+ break;
+ case DMA_NEXT_BYTES:
+ s->chan[no].next_bytes = value;
+ break;
+ case DMA_NEXT_DST:
+ s->chan[no].next_dst = value;
+ break;
+ case DMA_NEXT_SRC:
+ s->chan[no].next_src = value;
+ break;
+ case DMA_EXEC_CONFIG:
+ case DMA_EXEC_BYTES:
+ case DMA_EXEC_DST:
+ case DMA_EXEC_SRC:
+ /* these are read-only registers */
+ break;
+ default:
+ qemu_log_mask(LOG_GUEST_ERROR, "%s: Bad offset 0x%" HWADDR_PRIX "\n",
+ __func__, offset);
+ break;
+ }
+}
+
+static const MemoryRegionOps mchp_pfsoc_dma_ops = {
+ .read = mchp_pfsoc_dma_read,
+ .write = mchp_pfsoc_dma_write,
+ .endianness = DEVICE_LITTLE_ENDIAN,
+ /* there are 32-bit and 64-bit wide registers */
+ .impl = {
+ .min_access_size = 4,
+ .max_access_size = 8,
+ }
+};
+
+static void mchp_pfsoc_dma_realize(DeviceState *dev, Error **errp)
+{
+ MchpPfSoCDMAState *s = MCHP_PFSOC_DMA(dev);
+
+ memory_region_init_io(&s->iomem, OBJECT(dev), &mchp_pfsoc_dma_ops, s,
+ "mchp.pfsoc.dma", MCHP_PFSOC_DMA_REG_SIZE);
+ sysbus_init_mmio(SYS_BUS_DEVICE(dev), &s->iomem);
+ sysbus_init_irq(SYS_BUS_DEVICE(dev), &s->irq);
+}
+
+static void mchp_pfsoc_dma_class_init(ObjectClass *klass, void *data)
+{
+ DeviceClass *dc = DEVICE_CLASS(klass);
+
+ dc->desc = "Microchip PolarFire SoC DMA controller";
+ dc->realize = mchp_pfsoc_dma_realize;
+}
+
+static const TypeInfo mchp_pfsoc_dma_info = {
+ .name = TYPE_MCHP_PFSOC_DMA,
+ .parent = TYPE_SYS_BUS_DEVICE,
+ .instance_size = sizeof(MchpPfSoCDMAState),
+ .class_init = mchp_pfsoc_dma_class_init,
+};
+
+static void mchp_pfsoc_dma_register_types(void)
+{
+ type_register_static(&mchp_pfsoc_dma_info);
+}
+
+type_init(mchp_pfsoc_dma_register_types)
diff --git a/include/hw/dma/mchp_pfsoc_dma.h b/include/hw/dma/mchp_pfsoc_dma.h
new file mode 100644
index 0000000..e474f67
--- /dev/null
+++ b/include/hw/dma/mchp_pfsoc_dma.h
@@ -0,0 +1,57 @@
+/*
+ * Microchip PolarFire SoC DMA emulation
+ *
+ * Copyright (c) 2020 Wind River Systems, Inc.
+ *
+ * Author:
+ * Bin Meng <bin.meng@windriver.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) version 3 of the License.
+ *
+ * This program is distributed in the hope that 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/>.
+ */
+
+#ifndef MCHP_PFSOC_DMA_H
+#define MCHP_PFSOC_DMA_H
+
+struct mchp_pfsoc_dma_chan {
+ uint32_t control;
+ uint32_t next_config;
+ uint64_t next_bytes;
+ uint64_t next_dst;
+ uint64_t next_src;
+ uint32_t exec_config;
+ uint64_t exec_bytes;
+ uint64_t exec_dst;
+ uint64_t exec_src;
+ int state;
+};
+
+#define MCHP_PFSOC_DMA_CHANS 4
+#define MCHP_PFSOC_DMA_REG_SIZE 0x100000
+#define MCHP_PFSOC_DMA_CHAN_NO(reg) \
+ ((reg & (MCHP_PFSOC_DMA_REG_SIZE - 1)) >> 12)
+
+typedef struct MchpPfSoCDMAState {
+ SysBusDevice parent;
+ MemoryRegion iomem;
+ qemu_irq irq;
+
+ struct mchp_pfsoc_dma_chan chan[MCHP_PFSOC_DMA_CHANS];
+} MchpPfSoCDMAState;
+
+#define TYPE_MCHP_PFSOC_DMA "mchp.pfsoc.dma"
+
+#define MCHP_PFSOC_DMA(obj) \
+ OBJECT_CHECK(MchpPfSoCDMAState, (obj), TYPE_MCHP_PFSOC_DMA)
+
+#endif /* MCHP_PFSOC_DMA_H */
--
2.7.4
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH 13/18] hw/riscv: microchip_pfsoc: Connect a DMA controller
2020-08-14 16:40 ` Bin Meng
` (12 preceding siblings ...)
(?)
@ 2020-08-14 16:40 ` Bin Meng
2020-08-15 9:00 ` Philippe Mathieu-Daudé
-1 siblings, 1 reply; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, Palmer Dabbelt
From: Bin Meng <bin.meng@windriver.com>
Connect a DMA controller to Microchip PolarFire SoC. Note interrupt
has not been connected due to missing information in the manual how
interrupts are routed to PLIC.
On the Icicle Kit board, the HSS firmware utilizes the on-chip DMA
controller to move the 2nd stage bootloader in the system memory.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---
hw/riscv/Kconfig | 1 +
hw/riscv/microchip_pfsoc.c | 10 ++++++++++
include/hw/riscv/microchip_pfsoc.h | 3 +++
3 files changed, 14 insertions(+)
diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
index 7412db9..9323701 100644
--- a/hw/riscv/Kconfig
+++ b/hw/riscv/Kconfig
@@ -55,4 +55,5 @@ config MICROCHIP_PFSOC
select SIFIVE
select UNIMP
select MCHP_PFSOC_MMUART
+ select MCHP_PFSOC_DMA
select CADENCE_SDHCI
diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
index 7c09078..1c67cbc 100644
--- a/hw/riscv/microchip_pfsoc.c
+++ b/hw/riscv/microchip_pfsoc.c
@@ -13,6 +13,7 @@
* 2) eNVM (Embedded Non-Volatile Memory)
* 3) MMUARTs (Multi-Mode UART)
* 4) Cadence eMMC/SDHC controller and an SD card connected to it
+ * 5) DMA (Direct Memory Access Controller)
*
* This board currently generates devicetree dynamically that indicates at least
* two harts and up to five harts.
@@ -71,6 +72,7 @@ static const struct MemmapEntry {
[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 },
@@ -114,6 +116,9 @@ static void microchip_pfsoc_soc_instance_init(Object *obj)
TYPE_RISCV_CPU_SIFIVE_U54);
qdev_prop_set_uint64(DEVICE(&s->u_cpus), "resetvec", RESET_VECTOR);
+ object_initialize_child(obj, "dma-controller", &s->dma,
+ TYPE_MCHP_PFSOC_DMA);
+
object_initialize_child(obj, "sd-controller", &s->sdhci,
TYPE_CADENCE_SDHCI);
object_initialize_child(OBJECT(&s->sdhci), "sd-controller.sdhci",
@@ -220,6 +225,11 @@ static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
memmap[MICROCHIP_PFSOC_PLIC].size);
g_free(plic_hart_config);
+ /* DMA */
+ sysbus_realize(SYS_BUS_DEVICE(&s->dma), errp);
+ sysbus_mmio_map(SYS_BUS_DEVICE(&s->dma), 0,
+ memmap[MICROCHIP_PFSOC_DMA].base);
+
/* SYSREG */
create_unimplemented_device("microchip.pfsoc.sysreg",
memmap[MICROCHIP_PFSOC_SYSREG].base,
diff --git a/include/hw/riscv/microchip_pfsoc.h b/include/hw/riscv/microchip_pfsoc.h
index d810ee8..7825935 100644
--- a/include/hw/riscv/microchip_pfsoc.h
+++ b/include/hw/riscv/microchip_pfsoc.h
@@ -23,6 +23,7 @@
#define HW_MICROCHIP_PFSOC_H
#include "hw/char/mchp_pfsoc_mmuart.h"
+#include "hw/dma/mchp_pfsoc_dma.h"
#include "hw/sd/cadence_sdhci.h"
typedef struct MicrochipPFSoCState {
@@ -40,6 +41,7 @@ typedef struct MicrochipPFSoCState {
MchpPfSoCMMUartState *serial2;
MchpPfSoCMMUartState *serial3;
MchpPfSoCMMUartState *serial4;
+ MchpPfSoCDMAState dma;
CadenceSDHCIState sdhci;
} MicrochipPFSoCState;
@@ -71,6 +73,7 @@ enum {
MICROCHIP_PFSOC_BUSERR_UNIT4,
MICROCHIP_PFSOC_CLINT,
MICROCHIP_PFSOC_L2CC,
+ MICROCHIP_PFSOC_DMA,
MICROCHIP_PFSOC_L2LIM,
MICROCHIP_PFSOC_PLIC,
MICROCHIP_PFSOC_MMUART0,
--
2.7.4
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH 14/18] hw/net: cadence_gem: Add a new 'phy-addr' property
2020-08-14 16:40 ` Bin Meng
@ 2020-08-14 16:40 ` Bin Meng
-1 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Peter Maydell, Alistair Francis, Jason Wang, Bin Meng, qemu-arm,
Edgar E. Iglesias
From: Bin Meng <bin.meng@windriver.com>
At present the PHY address of the PHY connected to GEM is hard-coded
to either 23 (BOARD_PHY_ADDRESS) or 0. This might not be the case for
all boards. Add a new 'phy-addr' property so that board can specify
the PHY address for each GEM instance.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---
hw/net/cadence_gem.c | 7 +++++--
include/hw/net/cadence_gem.h | 2 ++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
index a93b5c0..9fa03de 100644
--- a/hw/net/cadence_gem.c
+++ b/hw/net/cadence_gem.c
@@ -1446,7 +1446,8 @@ static uint64_t gem_read(void *opaque, hwaddr offset, unsigned size)
uint32_t phy_addr, reg_num;
phy_addr = (retval & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
- if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
+ if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
+ phy_addr == s->phy_addr) {
reg_num = (retval & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
retval &= 0xFFFF0000;
retval |= gem_phy_read(s, reg_num);
@@ -1569,7 +1570,8 @@ static void gem_write(void *opaque, hwaddr offset, uint64_t val,
uint32_t phy_addr, reg_num;
phy_addr = (val & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
- if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
+ if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
+ phy_addr == s->phy_addr) {
reg_num = (val & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
gem_phy_write(s, reg_num, val);
}
@@ -1682,6 +1684,7 @@ static Property gem_properties[] = {
DEFINE_NIC_PROPERTIES(CadenceGEMState, conf),
DEFINE_PROP_UINT32("revision", CadenceGEMState, revision,
GEM_MODID_VALUE),
+ DEFINE_PROP_UINT8("phy-addr", CadenceGEMState, phy_addr, 0),
DEFINE_PROP_UINT8("num-priority-queues", CadenceGEMState,
num_priority_queues, 1),
DEFINE_PROP_UINT8("num-type1-screeners", CadenceGEMState,
diff --git a/include/hw/net/cadence_gem.h b/include/hw/net/cadence_gem.h
index 54e646f..01c6189 100644
--- a/include/hw/net/cadence_gem.h
+++ b/include/hw/net/cadence_gem.h
@@ -73,6 +73,8 @@ typedef struct CadenceGEMState {
/* Mask of register bits which are write 1 to clear */
uint32_t regs_w1c[CADENCE_GEM_MAXREG];
+ /* PHY address */
+ uint8_t phy_addr;
/* PHY registers backing store */
uint16_t phy_regs[32];
--
2.7.4
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH 14/18] hw/net: cadence_gem: Add a new 'phy-addr' property
@ 2020-08-14 16:40 ` Bin Meng
0 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, Alistair Francis, Edgar E. Iglesias, Jason Wang,
Peter Maydell, qemu-arm
From: Bin Meng <bin.meng@windriver.com>
At present the PHY address of the PHY connected to GEM is hard-coded
to either 23 (BOARD_PHY_ADDRESS) or 0. This might not be the case for
all boards. Add a new 'phy-addr' property so that board can specify
the PHY address for each GEM instance.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---
hw/net/cadence_gem.c | 7 +++++--
include/hw/net/cadence_gem.h | 2 ++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
index a93b5c0..9fa03de 100644
--- a/hw/net/cadence_gem.c
+++ b/hw/net/cadence_gem.c
@@ -1446,7 +1446,8 @@ static uint64_t gem_read(void *opaque, hwaddr offset, unsigned size)
uint32_t phy_addr, reg_num;
phy_addr = (retval & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
- if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
+ if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
+ phy_addr == s->phy_addr) {
reg_num = (retval & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
retval &= 0xFFFF0000;
retval |= gem_phy_read(s, reg_num);
@@ -1569,7 +1570,8 @@ static void gem_write(void *opaque, hwaddr offset, uint64_t val,
uint32_t phy_addr, reg_num;
phy_addr = (val & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
- if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
+ if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
+ phy_addr == s->phy_addr) {
reg_num = (val & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
gem_phy_write(s, reg_num, val);
}
@@ -1682,6 +1684,7 @@ static Property gem_properties[] = {
DEFINE_NIC_PROPERTIES(CadenceGEMState, conf),
DEFINE_PROP_UINT32("revision", CadenceGEMState, revision,
GEM_MODID_VALUE),
+ DEFINE_PROP_UINT8("phy-addr", CadenceGEMState, phy_addr, 0),
DEFINE_PROP_UINT8("num-priority-queues", CadenceGEMState,
num_priority_queues, 1),
DEFINE_PROP_UINT8("num-type1-screeners", CadenceGEMState,
diff --git a/include/hw/net/cadence_gem.h b/include/hw/net/cadence_gem.h
index 54e646f..01c6189 100644
--- a/include/hw/net/cadence_gem.h
+++ b/include/hw/net/cadence_gem.h
@@ -73,6 +73,8 @@ typedef struct CadenceGEMState {
/* Mask of register bits which are write 1 to clear */
uint32_t regs_w1c[CADENCE_GEM_MAXREG];
+ /* PHY address */
+ uint8_t phy_addr;
/* PHY registers backing store */
uint16_t phy_regs[32];
--
2.7.4
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH 15/18] hw/riscv: microchip_pfsoc: Connect 2 Cadence GEMs
2020-08-14 16:40 ` Bin Meng
` (14 preceding siblings ...)
(?)
@ 2020-08-14 16:40 ` Bin Meng
2020-08-21 18:46 ` Alistair Francis
-1 siblings, 1 reply; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, Palmer Dabbelt
From: Bin Meng <bin.meng@windriver.com>
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>
---
hw/riscv/microchip_pfsoc.c | 39 ++++++++++++++++++++++++++++++++++++++
include/hw/riscv/microchip_pfsoc.h | 7 +++++++
2 files changed, 46 insertions(+)
diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
index 1c67cbc..625b511 100644
--- a/hw/riscv/microchip_pfsoc.c
+++ b/hw/riscv/microchip_pfsoc.c
@@ -14,6 +14,7 @@
* 3) MMUARTs (Multi-Mode UART)
* 4) Cadence eMMC/SDHC controller and an SD card connected to it
* 5) DMA (Direct Memory Access Controller)
+ * 6) GEM (Gigabit Ethernet MAC Controller)
*
* This board currently generates devicetree dynamically that indicates at least
* two harts and up to five harts.
@@ -59,6 +60,9 @@
#define BIOS_FILENAME "hss.bin"
#define RESET_VECTOR 0x20220000
+/* GEM version */
+#define GEM_REVISION 0x0107010c
+
static const struct MemmapEntry {
hwaddr base;
hwaddr size;
@@ -83,6 +87,8 @@ static const struct MemmapEntry {
[MICROCHIP_PFSOC_MMUART2] = { 0x20102000, 0x1000 },
[MICROCHIP_PFSOC_MMUART3] = { 0x20104000, 0x1000 },
[MICROCHIP_PFSOC_MMUART4] = { 0x20106000, 0x1000 },
+ [MICROCHIP_PFSOC_GEM0] = { 0x20110000, 0x2000 },
+ [MICROCHIP_PFSOC_GEM1] = { 0x20112000, 0x2000 },
[MICROCHIP_PFSOC_ENVM_CFG] = { 0x20200000, 0x1000 },
[MICROCHIP_PFSOC_ENVM_DATA] = { 0x20220000, 0x20000 },
[MICROCHIP_PFSOC_IOSCB_CFG] = { 0x37080000, 0x1000 },
@@ -119,6 +125,9 @@ static void microchip_pfsoc_soc_instance_init(Object *obj)
object_initialize_child(obj, "dma-controller", &s->dma,
TYPE_MCHP_PFSOC_DMA);
+ object_initialize_child(obj, "gem0", &s->gem0, TYPE_CADENCE_GEM);
+ object_initialize_child(obj, "gem1", &s->gem1, TYPE_CADENCE_GEM);
+
object_initialize_child(obj, "sd-controller", &s->sdhci,
TYPE_CADENCE_SDHCI);
object_initialize_child(OBJECT(&s->sdhci), "sd-controller.sdhci",
@@ -136,6 +145,7 @@ static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
MemoryRegion *envm_data = g_new(MemoryRegion, 1);
char *plic_hart_config;
size_t plic_hart_config_len;
+ NICInfo *nd;
int i;
sysbus_realize(SYS_BUS_DEVICE(&s->e_cpus), &error_abort);
@@ -269,6 +279,35 @@ static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
qdev_get_gpio_in(DEVICE(s->plic), MICROCHIP_PFSOC_MMUART4_IRQ),
serial_hd(4));
+ /* GEMs */
+
+ nd = &nd_table[0];
+ if (nd->used) {
+ qemu_check_nic_model(nd, TYPE_CADENCE_GEM);
+ qdev_set_nic_properties(DEVICE(&s->gem0), nd);
+ }
+ nd = &nd_table[1];
+ if (nd->used) {
+ qemu_check_nic_model(nd, TYPE_CADENCE_GEM);
+ qdev_set_nic_properties(DEVICE(&s->gem1), nd);
+ }
+
+ 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));
+
/* eNVM */
memory_region_init_rom(envm_data, OBJECT(dev), "microchip.pfsoc.envm.data",
memmap[MICROCHIP_PFSOC_ENVM_DATA].size,
diff --git a/include/hw/riscv/microchip_pfsoc.h b/include/hw/riscv/microchip_pfsoc.h
index 7825935..60f994c 100644
--- a/include/hw/riscv/microchip_pfsoc.h
+++ b/include/hw/riscv/microchip_pfsoc.h
@@ -24,6 +24,7 @@
#include "hw/char/mchp_pfsoc_mmuart.h"
#include "hw/dma/mchp_pfsoc_dma.h"
+#include "hw/net/cadence_gem.h"
#include "hw/sd/cadence_sdhci.h"
typedef struct MicrochipPFSoCState {
@@ -42,6 +43,8 @@ typedef struct MicrochipPFSoCState {
MchpPfSoCMMUartState *serial3;
MchpPfSoCMMUartState *serial4;
MchpPfSoCDMAState dma;
+ CadenceGEMState gem0;
+ CadenceGEMState gem1;
CadenceSDHCIState sdhci;
} MicrochipPFSoCState;
@@ -84,6 +87,8 @@ enum {
MICROCHIP_PFSOC_MMUART2,
MICROCHIP_PFSOC_MMUART3,
MICROCHIP_PFSOC_MMUART4,
+ MICROCHIP_PFSOC_GEM0,
+ MICROCHIP_PFSOC_GEM1,
MICROCHIP_PFSOC_ENVM_CFG,
MICROCHIP_PFSOC_ENVM_DATA,
MICROCHIP_PFSOC_IOSCB_CFG,
@@ -91,6 +96,8 @@ enum {
};
enum {
+ MICROCHIP_PFSOC_GEM0_IRQ = 64,
+ MICROCHIP_PFSOC_GEM1_IRQ = 70,
MICROCHIP_PFSOC_EMMC_SD_IRQ = 88,
MICROCHIP_PFSOC_MMUART0_IRQ = 90,
MICROCHIP_PFSOC_MMUART1_IRQ = 91,
--
2.7.4
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH 16/18] hw/riscv: microchip_pfsoc: Hook GPIO controllers
2020-08-14 16:40 ` Bin Meng
` (15 preceding siblings ...)
(?)
@ 2020-08-14 16:40 ` Bin Meng
2020-08-21 18:47 ` Alistair Francis
-1 siblings, 1 reply; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, Palmer Dabbelt
From: Bin Meng <bin.meng@windriver.com>
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).
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---
hw/riscv/microchip_pfsoc.c | 14 ++++++++++++++
include/hw/riscv/microchip_pfsoc.h | 3 +++
2 files changed, 17 insertions(+)
diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
index 625b511..139284a 100644
--- a/hw/riscv/microchip_pfsoc.c
+++ b/hw/riscv/microchip_pfsoc.c
@@ -89,6 +89,9 @@ static const struct MemmapEntry {
[MICROCHIP_PFSOC_MMUART4] = { 0x20106000, 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_ENVM_CFG] = { 0x20200000, 0x1000 },
[MICROCHIP_PFSOC_ENVM_DATA] = { 0x20220000, 0x20000 },
[MICROCHIP_PFSOC_IOSCB_CFG] = { 0x37080000, 0x1000 },
@@ -308,6 +311,17 @@ static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
sysbus_connect_irq(SYS_BUS_DEVICE(&s->gem1), 0,
qdev_get_gpio_in(DEVICE(s->plic), MICROCHIP_PFSOC_GEM1_IRQ));
+ /* 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);
+
/* eNVM */
memory_region_init_rom(envm_data, OBJECT(dev), "microchip.pfsoc.envm.data",
memmap[MICROCHIP_PFSOC_ENVM_DATA].size,
diff --git a/include/hw/riscv/microchip_pfsoc.h b/include/hw/riscv/microchip_pfsoc.h
index 60f994c..993b17c 100644
--- a/include/hw/riscv/microchip_pfsoc.h
+++ b/include/hw/riscv/microchip_pfsoc.h
@@ -89,6 +89,9 @@ enum {
MICROCHIP_PFSOC_MMUART4,
MICROCHIP_PFSOC_GEM0,
MICROCHIP_PFSOC_GEM1,
+ MICROCHIP_PFSOC_GPIO0,
+ MICROCHIP_PFSOC_GPIO1,
+ MICROCHIP_PFSOC_GPIO2,
MICROCHIP_PFSOC_ENVM_CFG,
MICROCHIP_PFSOC_ENVM_DATA,
MICROCHIP_PFSOC_IOSCB_CFG,
--
2.7.4
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH 17/18] hw/riscv: clint: Avoid using hard-coded timebase frequency
2020-08-14 16:40 ` Bin Meng
` (16 preceding siblings ...)
(?)
@ 2020-08-14 16:40 ` Bin Meng
2020-08-25 18:33 ` Alistair Francis
-1 siblings, 1 reply; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, Palmer Dabbelt
From: Bin Meng <bin.meng@windriver.com>
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>
---
hw/riscv/microchip_pfsoc.c | 6 +++++-
hw/riscv/sifive_clint.c | 25 ++++++++++++++-----------
hw/riscv/sifive_e.c | 3 ++-
hw/riscv/sifive_u.c | 3 ++-
hw/riscv/spike.c | 2 +-
hw/riscv/virt.c | 3 ++-
include/hw/riscv/sifive_clint.h | 3 ++-
target/riscv/cpu.h | 6 ++++--
target/riscv/cpu_helper.c | 4 +++-
target/riscv/csr.c | 4 ++--
10 files changed, 37 insertions(+), 22 deletions(-)
diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
index 139284a..e8b7f86 100644
--- a/hw/riscv/microchip_pfsoc.c
+++ b/hw/riscv/microchip_pfsoc.c
@@ -60,6 +60,9 @@
#define BIOS_FILENAME "hss.bin"
#define RESET_VECTOR 0x20220000
+/* CLINT timebase frequency */
+#define CLINT_TIMEBASE_FREQ 1000000
+
/* GEM version */
#define GEM_REVISION 0x0107010c
@@ -189,7 +192,8 @@ static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
/* CLINT */
sifive_clint_create(memmap[MICROCHIP_PFSOC_CLINT].base,
memmap[MICROCHIP_PFSOC_CLINT].size, ms->smp.cpus,
- SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE, false);
+ SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE,
+ CLINT_TIMEBASE_FREQ, false);
/* L2 cache controller */
create_unimplemented_device("microchip.pfsoc.l2cc",
diff --git a/hw/riscv/sifive_clint.c b/hw/riscv/sifive_clint.c
index 669c21a..a568568 100644
--- a/hw/riscv/sifive_clint.c
+++ b/hw/riscv/sifive_clint.c
@@ -29,22 +29,23 @@
#include "hw/riscv/sifive_clint.h"
#include "qemu/timer.h"
-static uint64_t cpu_riscv_read_rtc(void)
+static uint64_t cpu_riscv_read_rtc(uint32_t timebase_freq)
{
return muldiv64(qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL),
- SIFIVE_CLINT_TIMEBASE_FREQ, NANOSECONDS_PER_SECOND);
+ timebase_freq, NANOSECONDS_PER_SECOND);
}
/*
* Called when timecmp is written to update the QEMU timer or immediately
* trigger timer interrupt if mtimecmp <= current timer value.
*/
-static void sifive_clint_write_timecmp(RISCVCPU *cpu, uint64_t value)
+static void sifive_clint_write_timecmp(RISCVCPU *cpu, uint64_t value,
+ uint32_t timebase_freq)
{
uint64_t next;
uint64_t diff;
- uint64_t rtc_r = cpu_riscv_read_rtc();
+ uint64_t rtc_r = cpu_riscv_read_rtc(timebase_freq);
cpu->env.timecmp = value;
if (cpu->env.timecmp <= rtc_r) {
@@ -59,7 +60,7 @@ static void sifive_clint_write_timecmp(RISCVCPU *cpu, uint64_t value)
diff = cpu->env.timecmp - rtc_r;
/* back to ns (note args switched in muldiv64) */
next = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
- muldiv64(diff, NANOSECONDS_PER_SECOND, SIFIVE_CLINT_TIMEBASE_FREQ);
+ muldiv64(diff, NANOSECONDS_PER_SECOND, timebase_freq);
timer_mod(cpu->env.timer, next);
}
@@ -111,10 +112,10 @@ static uint64_t sifive_clint_read(void *opaque, hwaddr addr, unsigned size)
}
} else if (addr == clint->time_base) {
/* time_lo */
- return cpu_riscv_read_rtc() & 0xFFFFFFFF;
+ return cpu_riscv_read_rtc(clint->timebase_freq) & 0xFFFFFFFF;
} else if (addr == clint->time_base + 4) {
/* time_hi */
- return (cpu_riscv_read_rtc() >> 32) & 0xFFFFFFFF;
+ return (cpu_riscv_read_rtc(clint->timebase_freq) >> 32) & 0xFFFFFFFF;
}
error_report("clint: invalid read: %08x", (uint32_t)addr);
@@ -151,13 +152,13 @@ static void sifive_clint_write(void *opaque, hwaddr addr, uint64_t value,
/* timecmp_lo */
uint64_t timecmp_hi = env->timecmp >> 32;
sifive_clint_write_timecmp(RISCV_CPU(cpu),
- timecmp_hi << 32 | (value & 0xFFFFFFFF));
+ timecmp_hi << 32 | (value & 0xFFFFFFFF), clint->timebase_freq);
return;
} else if ((addr & 0x7) == 4) {
/* timecmp_hi */
uint64_t timecmp_lo = env->timecmp;
sifive_clint_write_timecmp(RISCV_CPU(cpu),
- value << 32 | (timecmp_lo & 0xFFFFFFFF));
+ value << 32 | (timecmp_lo & 0xFFFFFFFF), clint->timebase_freq);
} else {
error_report("clint: invalid timecmp write: %08x", (uint32_t)addr);
}
@@ -191,6 +192,7 @@ static Property sifive_clint_properties[] = {
DEFINE_PROP_UINT32("timecmp-base", SiFiveCLINTState, timecmp_base, 0),
DEFINE_PROP_UINT32("time-base", SiFiveCLINTState, time_base, 0),
DEFINE_PROP_UINT32("aperture-size", SiFiveCLINTState, aperture_size, 0),
+ DEFINE_PROP_UINT32("timebase-freq", SiFiveCLINTState, timebase_freq, 0),
DEFINE_PROP_END_OF_LIST(),
};
@@ -229,7 +231,7 @@ type_init(sifive_clint_register_types)
*/
DeviceState *sifive_clint_create(hwaddr addr, hwaddr size, uint32_t num_harts,
uint32_t sip_base, uint32_t timecmp_base, uint32_t time_base,
- bool provide_rdtime)
+ uint32_t timebase_freq, bool provide_rdtime)
{
int i;
for (i = 0; i < num_harts; i++) {
@@ -239,7 +241,7 @@ DeviceState *sifive_clint_create(hwaddr addr, hwaddr size, uint32_t num_harts,
continue;
}
if (provide_rdtime) {
- riscv_cpu_set_rdtime_fn(env, cpu_riscv_read_rtc);
+ riscv_cpu_set_rdtime_fn(env, cpu_riscv_read_rtc, timebase_freq);
}
env->timer = timer_new_ns(QEMU_CLOCK_VIRTUAL,
&sifive_clint_timer_cb, cpu);
@@ -252,6 +254,7 @@ DeviceState *sifive_clint_create(hwaddr addr, hwaddr size, uint32_t num_harts,
qdev_prop_set_uint32(dev, "timecmp-base", timecmp_base);
qdev_prop_set_uint32(dev, "time-base", time_base);
qdev_prop_set_uint32(dev, "aperture-size", size);
+ qdev_prop_set_uint32(dev, "timebase-freq", timebase_freq);
sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), &error_fatal);
sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, addr);
return dev;
diff --git a/hw/riscv/sifive_e.c b/hw/riscv/sifive_e.c
index c84d407..e7f6460 100644
--- a/hw/riscv/sifive_e.c
+++ b/hw/riscv/sifive_e.c
@@ -213,7 +213,8 @@ static void sifive_e_soc_realize(DeviceState *dev, Error **errp)
memmap[SIFIVE_E_PLIC].size);
sifive_clint_create(memmap[SIFIVE_E_CLINT].base,
memmap[SIFIVE_E_CLINT].size, ms->smp.cpus,
- SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE, false);
+ SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE,
+ SIFIVE_CLINT_TIMEBASE_FREQ, false);
create_unimplemented_device("riscv.sifive.e.aon",
memmap[SIFIVE_E_AON].base, memmap[SIFIVE_E_AON].size);
sifive_e_prci_create(memmap[SIFIVE_E_PRCI].base);
diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
index e256da2..5ec9fca 100644
--- a/hw/riscv/sifive_u.c
+++ b/hw/riscv/sifive_u.c
@@ -706,7 +706,8 @@ static void sifive_u_soc_realize(DeviceState *dev, Error **errp)
serial_hd(1), qdev_get_gpio_in(DEVICE(s->plic), SIFIVE_U_UART1_IRQ));
sifive_clint_create(memmap[SIFIVE_U_CLINT].base,
memmap[SIFIVE_U_CLINT].size, ms->smp.cpus,
- SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE, false);
+ SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE,
+ SIFIVE_CLINT_TIMEBASE_FREQ, false);
if (!sysbus_realize(SYS_BUS_DEVICE(&s->prci), errp)) {
return;
diff --git a/hw/riscv/spike.c b/hw/riscv/spike.c
index 13958bd..ae8593a 100644
--- a/hw/riscv/spike.c
+++ b/hw/riscv/spike.c
@@ -235,7 +235,7 @@ static void spike_board_init(MachineState *machine)
/* Core Local Interruptor (timer and IPI) */
sifive_clint_create(memmap[SPIKE_CLINT].base, memmap[SPIKE_CLINT].size,
smp_cpus, SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE,
- false);
+ SIFIVE_CLINT_TIMEBASE_FREQ, false);
}
static void spike_machine_init(MachineClass *mc)
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index 6e91cf1..af0d06a 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -572,7 +572,8 @@ static void virt_machine_init(MachineState *machine)
memmap[VIRT_PLIC].size);
sifive_clint_create(memmap[VIRT_CLINT].base,
memmap[VIRT_CLINT].size, smp_cpus,
- SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE, true);
+ SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE,
+ SIFIVE_CLINT_TIMEBASE_FREQ, true);
sifive_test_create(memmap[VIRT_TEST].base);
for (i = 0; i < VIRTIO_COUNT; i++) {
diff --git a/include/hw/riscv/sifive_clint.h b/include/hw/riscv/sifive_clint.h
index 4a720bf..eb8577a 100644
--- a/include/hw/riscv/sifive_clint.h
+++ b/include/hw/riscv/sifive_clint.h
@@ -38,11 +38,12 @@ typedef struct SiFiveCLINTState {
uint32_t timecmp_base;
uint32_t time_base;
uint32_t aperture_size;
+ uint32_t timebase_freq;
} SiFiveCLINTState;
DeviceState *sifive_clint_create(hwaddr addr, hwaddr size, uint32_t num_harts,
uint32_t sip_base, uint32_t timecmp_base, uint32_t time_base,
- bool provide_rdtime);
+ uint32_t timebase_freq, bool provide_rdtime);
enum {
SIFIVE_SIP_BASE = 0x0,
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index d34bcfa..02486c3 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -219,7 +219,8 @@ struct CPURISCVState {
pmp_table_t pmp_state;
/* machine specific rdtime callback */
- uint64_t (*rdtime_fn)(void);
+ uint64_t (*rdtime_fn)(uint32_t);
+ uint32_t rdtime_fn_arg;
/* True if in debugger mode. */
bool debugger;
@@ -347,7 +348,8 @@ void riscv_cpu_swap_hypervisor_regs(CPURISCVState *env);
int riscv_cpu_claim_interrupts(RISCVCPU *cpu, uint32_t interrupts);
uint32_t riscv_cpu_update_mip(RISCVCPU *cpu, uint32_t mask, uint32_t value);
#define BOOL_TO_MASK(x) (-!!(x)) /* helper for riscv_cpu_update_mip value */
-void riscv_cpu_set_rdtime_fn(CPURISCVState *env, uint64_t (*fn)(void));
+void riscv_cpu_set_rdtime_fn(CPURISCVState *env, uint64_t (*fn)(uint32_t),
+ uint32_t arg);
#endif
void riscv_cpu_set_mode(CPURISCVState *env, target_ulong newpriv);
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index fd1d373..c82a521 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -258,9 +258,11 @@ uint32_t riscv_cpu_update_mip(RISCVCPU *cpu, uint32_t mask, uint32_t value)
return old;
}
-void riscv_cpu_set_rdtime_fn(CPURISCVState *env, uint64_t (*fn)(void))
+void riscv_cpu_set_rdtime_fn(CPURISCVState *env, uint64_t (*fn)(uint32_t),
+ uint32_t arg)
{
env->rdtime_fn = fn;
+ env->rdtime_fn_arg = arg;
}
void riscv_cpu_set_mode(CPURISCVState *env, target_ulong newpriv)
diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index 6a96a01..6cef1ac 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -294,7 +294,7 @@ static int read_time(CPURISCVState *env, int csrno, target_ulong *val)
return -1;
}
- *val = env->rdtime_fn() + delta;
+ *val = env->rdtime_fn(env->rdtime_fn_arg) + delta;
return 0;
}
@@ -307,7 +307,7 @@ static int read_timeh(CPURISCVState *env, int csrno, target_ulong *val)
return -1;
}
- *val = (env->rdtime_fn() + delta) >> 32;
+ *val = (env->rdtime_fn(env->rdtime_fn_arg) + delta) >> 32;
return 0;
}
#endif
--
2.7.4
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH 18/18] hw/riscv: microchip_pfsoc: Document the software used for testing
2020-08-14 16:40 ` Bin Meng
` (17 preceding siblings ...)
(?)
@ 2020-08-14 16:40 ` Bin Meng
2020-08-21 18:51 ` Alistair Francis
-1 siblings, 1 reply; 100+ messages in thread
From: Bin Meng @ 2020-08-14 16:40 UTC (permalink / raw)
To: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, Palmer Dabbelt
From: Bin Meng <bin.meng@windriver.com>
Add some useful comments to document the software used for testing.
including how to patch HSS to bypass the DDR memory initialization,
HSS and Yocto BSP build instructions, etc.
To launch this machine for testing:
$ qemu-system-riscv64 -M microchip-icicle-kit -smp 5 \
-bios path/to/hss.bin -sd path/to/sdcard.img \
-nic user,model=cadence_gem \
-nic tap,ifname=tap,model=cadence_gem \
-display none -serial stdio \
-chardev socket,id=serial1,path=serial1.sock,server,wait \
-serial chardev:serial1
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---
hw/riscv/microchip_pfsoc.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
index e8b7f86..1575fef 100644
--- a/hw/riscv/microchip_pfsoc.c
+++ b/hw/riscv/microchip_pfsoc.c
@@ -56,6 +56,27 @@
/*
* The BIOS image used by this machine is called Hart Software Services (HSS).
* See https://github.com/polarfire-soc/hart-software-services
+ *
+ * As of now the DDR memory controller in the Microchip PolarFire SoC has not
+ * been modeled. Simply creating unimplemented devices does not make HSS happy.
+ * Emulating the DDR memory controller is tedious, so a patched HSS should be
+ * used as the BIOS for this machine.
+ *
+ * To patch HSS, open boards/icicle-kit-es/hss_board_init.c in the HSS source
+ * tree, find the boardInitFunctions[] array that contains the initialization
+ * routines for this board, and remove the line that contains 'HSS_DDRInit'.
+ *
+ * QEMU does not support eMMC hence the SD configuration shall be used in the
+ * HSS and Yocto BSP build. The eMMC configuration is not supported.
+ *
+ * Instructions to build HSS:
+ * $ cp boards/icicle-kit-es/def_config.sdcard .config
+ * $ make BOARD=icicle-kit-es
+ *
+ * For Yocto build, "MACHINE=icicle-kit-es-sd" should be specified, otherwise
+ * when booting Linux kernel the rootfs cannot be mounted. The generated image
+ * is something like: mpfs-dev-cli-icicle-kit-es-sd.rootfs.wic. Resize the file
+ * with 'qemu-image' to a power of 2 before passing to QEMU '-sd' command line.
*/
#define BIOS_FILENAME "hss.bin"
#define RESET_VECTOR 0x20220000
--
2.7.4
^ permalink raw reply related [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
2020-08-14 16:40 ` Bin Meng
@ 2020-08-14 17:44 ` Anup Patel
-1 siblings, 0 replies; 100+ messages in thread
From: Anup Patel @ 2020-08-14 17:44 UTC (permalink / raw)
To: Bin Meng
Cc: Peter Maydell, Alistair Francis, open list:RISC-V, qemu-block,
Sagar Karandikar, Bin Meng, Bastian Koppelmann, Jason Wang,
Palmer Dabbelt, Edgar E. Iglesias, QEMU Developers, qemu-arm,
Alistair Francis, Marc-André Lureau, Paolo Bonzini,
Philippe Mathieu-Daudé,
Palmer Dabbelt
On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> This adds support for Microchip PolarFire SoC Icicle Kit board.
> 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.
Nice Work !!! This is very helpful.
>
> For more details about Microchip PolarFire Soc, please see:
> https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga
>
> The Icicle Kit board information can be found here:
> https://www.microsemi.com/existing-parts/parts/152514
>
> Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000.
> The RISC-V CPU and HART codes has been updated to set the core's
> reset vector based on a configurable property from machine codes.
>
> The following perepherals are created as an unimplemented device:
>
> - Bus Error Uint 0/1/2/3/4
> - L2 cache controller
> - SYSREG
> - MPUCFG
> - IOSCBCFG
> - GPIO
>
> The following perepherals are emulated:
> - SiFive CLINT
> - SiFive PLIC
> - PolarFire SoC Multi-Mode UART
> - PolarFire SoC DMA
> - Cadence eMMC/SDHCI controller
> - Cadence Gigabit Ethernet MAC
>
> Some bugs in the SD card codes are fixed during the development.
>
> 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 -M microchip-icicle-kit -smp 5 \
> -bios path/to/hss.bin -sd path/to/sdcard.img \
> -nic tap,ifname=tap,script=no,model=cadence_gem \
> -display none -serial stdio \
> -chardev socket,id=serial1,path=serial1.sock,server,wait \
> -serial chardev:serial1
Currently, it is fine to use HSS (with OpenSBI v0.6 as a library) but
this is not aligned with the existing booting flow of many RISC-V
systems.
It will be nice to have standard U-Boot RISC-V boot-flow working
on Microchip PolarFire SoC:
U-Boot SPL (BIOS) => FW_DYNAMIC (Generic) => U-Boot S-mode
The Microchip HSS is quite convoluted. It has:
1. DDR Init
2. Boot device support
3. SBI support using OpenSBI as library
4. Simple TEE support
I think point 1) and 2) above should be part of U-Boot SPL.
The point 3) can be OpenSBI FW_DYNAMIC.
Lastly,for point 4), we are working on a new OpenSBI feature using
which we can run independent Secure OS and Non-Secure OS using
U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
PolarFire).
Do you have plans for adding U-Boot SPL support for this board ??
Regards,
Anup
>
> 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.
>
> HSS output is on the first serial port (stdio) and U-Boot/Linux
> outputs on the 2nd serial port. OpenSBI outputs on a random serial
> port due to the lottery mechanism used during the multi-core boot.
>
>
> Bin Meng (18):
> target/riscv: cpu: Add a new 'resetvec' property
> hw/riscv: hart: Add a new 'resetvec' property
> target/riscv: cpu: Set reset vector based on the configured property
> value
> hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board
> hw/char: Add Microchip PolarFire SoC MMUART emulation
> hw/riscv: microchip_pfsoc: Connect 5 MMUARTs
> hw/sd: sd: Fix incorrect populated function switch status data
> structure
> hw/sd: sd: Correctly set the high capacity bit
> hw/sd: sdhci: Make sdhci_poweron_reset() internal visible
> hw/sd: Add Cadence SDHCI emulation
> hw/riscv: microchip_pfsoc: Connect a Cadence SDHCI controller and an
> SD card
> hw/dma: Add Microchip PolarFire Soc DMA controller emulation
> hw/riscv: microchip_pfsoc: Connect a DMA controller
> hw/net: cadence_gem: Add a new 'phy-addr' property
> hw/riscv: microchip_pfsoc: Connect 2 Cadence GEMs
> hw/riscv: microchip_pfsoc: Hook GPIO controllers
> hw/riscv: clint: Avoid using hard-coded timebase frequency
> hw/riscv: microchip_pfsoc: Document the software used for testing
>
> MAINTAINERS | 11 +
> default-configs/riscv64-softmmu.mak | 1 +
> hw/char/Kconfig | 3 +
> hw/char/Makefile.objs | 1 +
> hw/char/mchp_pfsoc_mmuart.c | 82 +++++++
> hw/dma/Kconfig | 3 +
> hw/dma/Makefile.objs | 1 +
> hw/dma/mchp_pfsoc_dma.c | 322 +++++++++++++++++++++++++
> hw/net/cadence_gem.c | 7 +-
> hw/riscv/Kconfig | 9 +
> hw/riscv/Makefile.objs | 1 +
> hw/riscv/microchip_pfsoc.c | 456 ++++++++++++++++++++++++++++++++++++
> hw/riscv/opentitan.c | 1 +
> hw/riscv/riscv_hart.c | 3 +
> hw/riscv/sifive_clint.c | 25 +-
> hw/riscv/sifive_e.c | 4 +-
> hw/riscv/sifive_u.c | 5 +-
> hw/riscv/spike.c | 2 +-
> hw/riscv/virt.c | 3 +-
> hw/sd/Kconfig | 4 +
> hw/sd/Makefile.objs | 1 +
> hw/sd/cadence_sdhci.c | 162 +++++++++++++
> hw/sd/sd.c | 8 +-
> hw/sd/sdhci-internal.h | 1 +
> hw/sd/sdhci.c | 2 +-
> include/hw/char/mchp_pfsoc_mmuart.h | 61 +++++
> include/hw/dma/mchp_pfsoc_dma.h | 57 +++++
> include/hw/net/cadence_gem.h | 2 +
> include/hw/riscv/microchip_pfsoc.h | 125 ++++++++++
> include/hw/riscv/riscv_hart.h | 1 +
> include/hw/riscv/sifive_clint.h | 3 +-
> include/hw/sd/cadence_sdhci.h | 65 +++++
> target/riscv/cpu.c | 8 +-
> target/riscv/cpu.h | 7 +-
> target/riscv/cpu_helper.c | 4 +-
> target/riscv/csr.c | 4 +-
> 36 files changed, 1424 insertions(+), 31 deletions(-)
> create mode 100644 hw/char/mchp_pfsoc_mmuart.c
> create mode 100644 hw/dma/mchp_pfsoc_dma.c
> create mode 100644 hw/riscv/microchip_pfsoc.c
> create mode 100644 hw/sd/cadence_sdhci.c
> create mode 100644 include/hw/char/mchp_pfsoc_mmuart.h
> create mode 100644 include/hw/dma/mchp_pfsoc_dma.h
> create mode 100644 include/hw/riscv/microchip_pfsoc.h
> create mode 100644 include/hw/sd/cadence_sdhci.h
>
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
@ 2020-08-14 17:44 ` Anup Patel
0 siblings, 0 replies; 100+ messages in thread
From: Anup Patel @ 2020-08-14 17:44 UTC (permalink / raw)
To: Bin Meng
Cc: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, QEMU Developers, open list:RISC-V,
Peter Maydell, Alistair Francis, qemu-block, Jason Wang,
Bin Meng, Paolo Bonzini, Palmer Dabbelt, qemu-arm,
Marc-André Lureau, Edgar E. Iglesias,
Philippe Mathieu-Daudé
On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> This adds support for Microchip PolarFire SoC Icicle Kit board.
> 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.
Nice Work !!! This is very helpful.
>
> For more details about Microchip PolarFire Soc, please see:
> https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga
>
> The Icicle Kit board information can be found here:
> https://www.microsemi.com/existing-parts/parts/152514
>
> Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000.
> The RISC-V CPU and HART codes has been updated to set the core's
> reset vector based on a configurable property from machine codes.
>
> The following perepherals are created as an unimplemented device:
>
> - Bus Error Uint 0/1/2/3/4
> - L2 cache controller
> - SYSREG
> - MPUCFG
> - IOSCBCFG
> - GPIO
>
> The following perepherals are emulated:
> - SiFive CLINT
> - SiFive PLIC
> - PolarFire SoC Multi-Mode UART
> - PolarFire SoC DMA
> - Cadence eMMC/SDHCI controller
> - Cadence Gigabit Ethernet MAC
>
> Some bugs in the SD card codes are fixed during the development.
>
> 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 -M microchip-icicle-kit -smp 5 \
> -bios path/to/hss.bin -sd path/to/sdcard.img \
> -nic tap,ifname=tap,script=no,model=cadence_gem \
> -display none -serial stdio \
> -chardev socket,id=serial1,path=serial1.sock,server,wait \
> -serial chardev:serial1
Currently, it is fine to use HSS (with OpenSBI v0.6 as a library) but
this is not aligned with the existing booting flow of many RISC-V
systems.
It will be nice to have standard U-Boot RISC-V boot-flow working
on Microchip PolarFire SoC:
U-Boot SPL (BIOS) => FW_DYNAMIC (Generic) => U-Boot S-mode
The Microchip HSS is quite convoluted. It has:
1. DDR Init
2. Boot device support
3. SBI support using OpenSBI as library
4. Simple TEE support
I think point 1) and 2) above should be part of U-Boot SPL.
The point 3) can be OpenSBI FW_DYNAMIC.
Lastly,for point 4), we are working on a new OpenSBI feature using
which we can run independent Secure OS and Non-Secure OS using
U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
PolarFire).
Do you have plans for adding U-Boot SPL support for this board ??
Regards,
Anup
>
> 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.
>
> HSS output is on the first serial port (stdio) and U-Boot/Linux
> outputs on the 2nd serial port. OpenSBI outputs on a random serial
> port due to the lottery mechanism used during the multi-core boot.
>
>
> Bin Meng (18):
> target/riscv: cpu: Add a new 'resetvec' property
> hw/riscv: hart: Add a new 'resetvec' property
> target/riscv: cpu: Set reset vector based on the configured property
> value
> hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board
> hw/char: Add Microchip PolarFire SoC MMUART emulation
> hw/riscv: microchip_pfsoc: Connect 5 MMUARTs
> hw/sd: sd: Fix incorrect populated function switch status data
> structure
> hw/sd: sd: Correctly set the high capacity bit
> hw/sd: sdhci: Make sdhci_poweron_reset() internal visible
> hw/sd: Add Cadence SDHCI emulation
> hw/riscv: microchip_pfsoc: Connect a Cadence SDHCI controller and an
> SD card
> hw/dma: Add Microchip PolarFire Soc DMA controller emulation
> hw/riscv: microchip_pfsoc: Connect a DMA controller
> hw/net: cadence_gem: Add a new 'phy-addr' property
> hw/riscv: microchip_pfsoc: Connect 2 Cadence GEMs
> hw/riscv: microchip_pfsoc: Hook GPIO controllers
> hw/riscv: clint: Avoid using hard-coded timebase frequency
> hw/riscv: microchip_pfsoc: Document the software used for testing
>
> MAINTAINERS | 11 +
> default-configs/riscv64-softmmu.mak | 1 +
> hw/char/Kconfig | 3 +
> hw/char/Makefile.objs | 1 +
> hw/char/mchp_pfsoc_mmuart.c | 82 +++++++
> hw/dma/Kconfig | 3 +
> hw/dma/Makefile.objs | 1 +
> hw/dma/mchp_pfsoc_dma.c | 322 +++++++++++++++++++++++++
> hw/net/cadence_gem.c | 7 +-
> hw/riscv/Kconfig | 9 +
> hw/riscv/Makefile.objs | 1 +
> hw/riscv/microchip_pfsoc.c | 456 ++++++++++++++++++++++++++++++++++++
> hw/riscv/opentitan.c | 1 +
> hw/riscv/riscv_hart.c | 3 +
> hw/riscv/sifive_clint.c | 25 +-
> hw/riscv/sifive_e.c | 4 +-
> hw/riscv/sifive_u.c | 5 +-
> hw/riscv/spike.c | 2 +-
> hw/riscv/virt.c | 3 +-
> hw/sd/Kconfig | 4 +
> hw/sd/Makefile.objs | 1 +
> hw/sd/cadence_sdhci.c | 162 +++++++++++++
> hw/sd/sd.c | 8 +-
> hw/sd/sdhci-internal.h | 1 +
> hw/sd/sdhci.c | 2 +-
> include/hw/char/mchp_pfsoc_mmuart.h | 61 +++++
> include/hw/dma/mchp_pfsoc_dma.h | 57 +++++
> include/hw/net/cadence_gem.h | 2 +
> include/hw/riscv/microchip_pfsoc.h | 125 ++++++++++
> include/hw/riscv/riscv_hart.h | 1 +
> include/hw/riscv/sifive_clint.h | 3 +-
> include/hw/sd/cadence_sdhci.h | 65 +++++
> target/riscv/cpu.c | 8 +-
> target/riscv/cpu.h | 7 +-
> target/riscv/cpu_helper.c | 4 +-
> target/riscv/csr.c | 4 +-
> 36 files changed, 1424 insertions(+), 31 deletions(-)
> create mode 100644 hw/char/mchp_pfsoc_mmuart.c
> create mode 100644 hw/dma/mchp_pfsoc_dma.c
> create mode 100644 hw/riscv/microchip_pfsoc.c
> create mode 100644 hw/sd/cadence_sdhci.c
> create mode 100644 include/hw/char/mchp_pfsoc_mmuart.h
> create mode 100644 include/hw/dma/mchp_pfsoc_dma.h
> create mode 100644 include/hw/riscv/microchip_pfsoc.h
> create mode 100644 include/hw/sd/cadence_sdhci.h
>
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
2020-08-14 16:40 ` Bin Meng
@ 2020-08-14 18:10 ` no-reply
-1 siblings, 0 replies; 100+ messages in thread
From: no-reply @ 2020-08-14 18:10 UTC (permalink / raw)
To: bmeng.cn
Cc: peter.maydell, alistair, qemu-riscv, qemu-block, sagark,
bin.meng, kbastian, jasowang, palmerdabbelt, edgar.iglesias,
qemu-devel, qemu-arm, Alistair.Francis, marcandre.lureau,
pbonzini, philmd, palmer
Patchew URL: https://patchew.org/QEMU/1597423256-14847-1-git-send-email-bmeng.cn@gmail.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===
TEST check-unit: tests/test-char
Unexpected error in object_property_try_add() at /tmp/qemu-test/src/qom/object.c:1181:
attempt to add duplicate property 'serial-id' to object (type 'container')
ERROR test-char - too few tests run (expected 38, got 9)
make: *** [check-unit] Error 1
make: *** Waiting for unfinished jobs....
TEST check-qtest-x86_64: tests/qtest/hd-geo-test
qemu-system-aarch64: -accel kvm: invalid accelerator kvm
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--label', 'com.qemu.instance.uuid=5d87ed4b32104d3fa300f89248e59809', '-u', '1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-okrr9kbl/src/docker-src.2020-08-14-13.56.55.12251:/var/tmp/qemu:z,ro', 'qemu/centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit status 2.
filter=--filter=label=com.qemu.instance.uuid=5d87ed4b32104d3fa300f89248e59809
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-okrr9kbl/src'
make: *** [docker-run-test-quick@centos7] Error 2
real 13m35.300s
user 0m8.266s
The full log is available at
http://patchew.org/logs/1597423256-14847-1-git-send-email-bmeng.cn@gmail.com/testing.docker-quick@centos7/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
@ 2020-08-14 18:10 ` no-reply
0 siblings, 0 replies; 100+ messages in thread
From: no-reply @ 2020-08-14 18:10 UTC (permalink / raw)
To: bmeng.cn
Cc: Alistair.Francis, kbastian, palmerdabbelt, sagark, qemu-devel,
qemu-riscv, peter.maydell, alistair, qemu-block, jasowang,
bin.meng, pbonzini, palmer, qemu-arm, marcandre.lureau,
edgar.iglesias, philmd
Patchew URL: https://patchew.org/QEMU/1597423256-14847-1-git-send-email-bmeng.cn@gmail.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===
TEST check-unit: tests/test-char
Unexpected error in object_property_try_add() at /tmp/qemu-test/src/qom/object.c:1181:
attempt to add duplicate property 'serial-id' to object (type 'container')
ERROR test-char - too few tests run (expected 38, got 9)
make: *** [check-unit] Error 1
make: *** Waiting for unfinished jobs....
TEST check-qtest-x86_64: tests/qtest/hd-geo-test
qemu-system-aarch64: -accel kvm: invalid accelerator kvm
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--label', 'com.qemu.instance.uuid=5d87ed4b32104d3fa300f89248e59809', '-u', '1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-okrr9kbl/src/docker-src.2020-08-14-13.56.55.12251:/var/tmp/qemu:z,ro', 'qemu/centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit status 2.
filter=--filter=label=com.qemu.instance.uuid=5d87ed4b32104d3fa300f89248e59809
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-okrr9kbl/src'
make: *** [docker-run-test-quick@centos7] Error 2
real 13m35.300s
user 0m8.266s
The full log is available at
http://patchew.org/logs/1597423256-14847-1-git-send-email-bmeng.cn@gmail.com/testing.docker-quick@centos7/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 09/18] hw/sd: sdhci: Make sdhci_poweron_reset() internal visible
2020-08-14 16:40 ` [PATCH 09/18] hw/sd: sdhci: Make sdhci_poweron_reset() internal visible Bin Meng
@ 2020-08-15 7:51 ` Philippe Mathieu-Daudé
2020-08-16 8:50 ` Bin Meng
0 siblings, 1 reply; 100+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-08-15 7:51 UTC (permalink / raw)
To: Bin Meng, Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, qemu-block
On 8/14/20 6:40 PM, Bin Meng wrote:
> From: Bin Meng <bin.meng@windriver.com>
>
> sdhci_poweron_reset() might be needed for any SDHCI compatible
> device that is built on top of the generic SDHCI device.
NAck. Please use device_legacy_reset() instead.
In next patch:
device_legacy_reset(DEVICE(&sdhci->slot));
Thanks,
Phil.
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
> ---
>
> hw/sd/sdhci-internal.h | 1 +
> hw/sd/sdhci.c | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/hw/sd/sdhci-internal.h b/hw/sd/sdhci-internal.h
> index e8c753d..b587e8e 100644
> --- a/hw/sd/sdhci-internal.h
> +++ b/hw/sd/sdhci-internal.h
> @@ -342,5 +342,6 @@ void sdhci_uninitfn(SDHCIState *s);
> void sdhci_common_realize(SDHCIState *s, Error **errp);
> void sdhci_common_unrealize(SDHCIState *s);
> void sdhci_common_class_init(ObjectClass *klass, void *data);
> +void sdhci_poweron_reset(DeviceState *dev);
>
> #endif
> diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
> index deac181..20f2fe0 100644
> --- a/hw/sd/sdhci.c
> +++ b/hw/sd/sdhci.c
> @@ -294,7 +294,7 @@ static void sdhci_reset(SDHCIState *s)
> s->pending_insert_state = false;
> }
>
> -static void sdhci_poweron_reset(DeviceState *dev)
> +void sdhci_poweron_reset(DeviceState *dev)
> {
> /* QOM (ie power-on) reset. This is identical to reset
> * commanded via device register apart from handling of the
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 07/18] hw/sd: sd: Fix incorrect populated function switch status data structure
2020-08-14 16:40 ` [PATCH 07/18] hw/sd: sd: Fix incorrect populated function switch status data structure Bin Meng
@ 2020-08-15 7:58 ` Philippe Mathieu-Daudé
2020-08-18 16:30 ` Sai Pavan Boddu
0 siblings, 1 reply; 100+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-08-15 7:58 UTC (permalink / raw)
To: Bin Meng, Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv, Sai Pavan Boddu
Cc: Bin Meng, qemu-block
+Sai Pavan
On 8/14/20 6:40 PM, Bin Meng wrote:
> From: Bin Meng <bin.meng@windriver.com>
>
> At present the function switch status data structure bit [399:376]
> are wrongly pupulated. These 3 bytes encode function switch status
> for the 6 function groups, with 4 bits per group, starting from
> function group 6 at bit 399, then followed by function group 5 at
> bit 395, and so on.
>
> However the codes mistakenly fills in the function group 1 status
> at bit 399. This fixes the code logic.
>
Fixes: a1bb27b1e9 ("SD card emulation (initial implementation)")
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
> ---
>
> hw/sd/sd.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/hw/sd/sd.c b/hw/sd/sd.c
> index fad9cf1..51f5900 100644
> --- a/hw/sd/sd.c
> +++ b/hw/sd/sd.c
> @@ -806,11 +806,15 @@ static void sd_function_switch(SDState *sd, uint32_t arg)
> sd->data[11] = 0x43;
> sd->data[12] = 0x80; /* Supported group 1 functions */
> sd->data[13] = 0x03;
> +
> + sd->data[14] = 0;
> + sd->data[15] = 0;
> + sd->data[16] = 0;
Pointless zero initialization.
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
I'll wait until next week in case Sai Pavan wants to test this
patch (I don't have access to the Xilinx images anymore) then
I'll queue this via my sd-next tree.
Regards,
Phil.
> for (i = 0; i < 6; i ++) {
> new_func = (arg >> (i * 4)) & 0x0f;
> if (mode && new_func != 0x0f)
> sd->function_group[i] = new_func;
> - sd->data[14 + (i >> 1)] = new_func << ((i * 4) & 4);
> + sd->data[16 - (i >> 1)] |= new_func << ((i % 2) * 4);
> }
> memset(&sd->data[17], 0, 47);
> stw_be_p(sd->data + 64, sd_crc16(sd->data, 64));
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 08/18] hw/sd: sd: Correctly set the high capacity bit
2020-08-14 16:40 ` [PATCH 08/18] hw/sd: sd: Correctly set the high capacity bit Bin Meng
@ 2020-08-15 8:38 ` Philippe Mathieu-Daudé
2020-08-16 8:54 ` Bin Meng
0 siblings, 1 reply; 100+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-08-15 8:38 UTC (permalink / raw)
To: Bin Meng, Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, qemu-block
On 8/14/20 6:40 PM, Bin Meng wrote:
> From: Bin Meng <bin.meng@windriver.com>
>
> Per the SD spec, Standard Capacity SD Memory Card (SDSC) supports
> capacity up to and including 2 GiB.
>
Fixes: 2d7adea4fe ("hw/sd: Support SDHC size cards")
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
> ---
>
> hw/sd/sd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/sd/sd.c b/hw/sd/sd.c
> index 51f5900..5e7fc3f 100644
> --- a/hw/sd/sd.c
> +++ b/hw/sd/sd.c
> @@ -313,7 +313,7 @@ static void sd_ocr_powerup(void *opaque)
> /* card power-up OK */
> sd->ocr = FIELD_DP32(sd->ocr, OCR, CARD_POWER_UP, 1);
>
> - if (sd->size > 1 * GiB) {
> + if (sd->size > 2 * GiB) {
But you need to fix sd_set_csd() too, else this is incomplete.
Thanks,
Phil.
> sd->ocr = FIELD_DP32(sd->ocr, OCR, CARD_CAPACITY, 1);
> }
> }
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 10/18] hw/sd: Add Cadence SDHCI emulation
2020-08-14 16:40 ` Bin Meng
@ 2020-08-15 8:51 ` Philippe Mathieu-Daudé
-1 siblings, 0 replies; 100+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-08-15 8:51 UTC (permalink / raw)
To: Bin Meng, Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Edgar E. Iglesias, Alistair Francis, Bin Meng, qemu-arm, Peter Maydell
On 8/14/20 6:40 PM, Bin Meng wrote:
> From: Bin Meng <bin.meng@windriver.com>
>
> Cadence SD/SDIO/eMMC Host Controller (SD4HC) is an SDHCI compatible
> controller. The SDHCI compatible registers start from offset 0x200,
> which are called Slot Register Set (SRS) in its datasheet.
>
> This creates a Cadence SDHCI model built on top of the existing
> generic SDHCI model. Cadence specific Host Register Set (HRS) is
> implemented to make guest software happy.
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
> ---
>
> hw/sd/Kconfig | 4 ++
> hw/sd/Makefile.objs | 1 +
> hw/sd/cadence_sdhci.c | 162 ++++++++++++++++++++++++++++++++++++++++++
> include/hw/sd/cadence_sdhci.h | 65 +++++++++++++++++
> 4 files changed, 232 insertions(+)
> create mode 100644 hw/sd/cadence_sdhci.c
> create mode 100644 include/hw/sd/cadence_sdhci.h
Please consider using scripts/git.orderfile.
>
> diff --git a/hw/sd/Kconfig b/hw/sd/Kconfig
> index c5e1e55..633b9af 100644
> --- a/hw/sd/Kconfig
> +++ b/hw/sd/Kconfig
> @@ -19,3 +19,7 @@ config SDHCI_PCI
> default y if PCI_DEVICES
> depends on PCI
> select SDHCI
> +
> +config CADENCE_SDHCI
> + bool
> + select SDHCI
> diff --git a/hw/sd/Makefile.objs b/hw/sd/Makefile.objs
> index 0d1df17..4d500a6 100644
> --- a/hw/sd/Makefile.objs
> +++ b/hw/sd/Makefile.objs
> @@ -10,3 +10,4 @@ common-obj-$(CONFIG_OMAP) += omap_mmc.o
> common-obj-$(CONFIG_PXA2XX) += pxa2xx_mmci.o
> common-obj-$(CONFIG_RASPI) += bcm2835_sdhost.o
> common-obj-$(CONFIG_ASPEED_SOC) += aspeed_sdhci.o
> +common-obj-$(CONFIG_CADENCE_SDHCI) += cadence_sdhci.o
> diff --git a/hw/sd/cadence_sdhci.c b/hw/sd/cadence_sdhci.c
> new file mode 100644
> index 0000000..67ffd14
> --- /dev/null
> +++ b/hw/sd/cadence_sdhci.c
> @@ -0,0 +1,162 @@
> +/*
> + * Cadence SDHCI emulation
> + *
> + * Copyright (c) 2020 Wind River Systems, Inc.
> + *
> + * Author:
> + * Bin Meng <bin.meng@windriver.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 or
> + * (at your option) version 3 of the License.
> + *
> + * This program is distributed in the hope that 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/log.h"
> +#include "qapi/error.h"
> +#include "migration/vmstate.h"
> +#include "hw/irq.h"
> +#include "hw/sd/cadence_sdhci.h"
> +#include "sdhci-internal.h"
> +
> +#define TO_REG(addr) ((addr) / sizeof(uint32_t))
> +
> +static void cadence_sdhci_reset(DeviceState *dev)
> +{
> + CadenceSDHCIState *sdhci = CADENCE_SDHCI(dev);
We usually use 's' for the model state.
> +
> + memset(sdhci->regs, 0, CADENCE_SDHCI_REG_SIZE);
> + sdhci->regs[TO_REG(SDHCI_CDNS_HRS00)] = SDHCI_CDNS_HRS00_POR_VAL;
As commented in previous patch, here goes:
device_legacy_reset(DEVICE(&sdhci->slot));
> +}
> +
> +static uint64_t cadence_sdhci_read(void *opaque, hwaddr addr, unsigned int size)
> +{
> + uint32_t val = 0;
> + CadenceSDHCIState *sdhci = opaque;
> +
> + if (addr < CADENCE_SDHCI_REG_SIZE) {
> + val = sdhci->regs[TO_REG(addr)];
> + } else {
> + qemu_log_mask(LOG_GUEST_ERROR,
> + "%s: Out-of-bounds read at 0x%" HWADDR_PRIx "\n",
> + __func__, addr);
> + }
> +
> + return (uint64_t)val;
> +}
> +
> +static void cadence_sdhci_write(void *opaque, hwaddr addr, uint64_t val,
> + unsigned int size)
> +{
> + CadenceSDHCIState *sdhci = opaque;
> + uint32_t val32 = (uint32_t)val;
> +
> + switch (addr) {
> + case SDHCI_CDNS_HRS00:
> + /*
> + * The only writable bit is SWR (software reset) and it automatically
> + * clears to zero, so essentially this register remains unchanged.
> + */
> + if (val32 & SDHCI_CDNS_HRS00_SWR) {
> + cadence_sdhci_reset(DEVICE(sdhci));
> + sdhci_poweron_reset(DEVICE(&sdhci->slot));
The 'slot' reset has to go in cadence_sdhci_reset().
> + }
> +
> + break;
> + case SDHCI_CDNS_HRS04:
> + /*
> + * Only emulate the ACK bit behavior when read or write transaction
> + * are requested.
> + */
> + if (val32 & (SDHCI_CDNS_HRS04_WR | SDHCI_CDNS_HRS04_RD)) {
> + val32 |= SDHCI_CDNS_HRS04_ACK;
> + } else {
> + val32 &= ~SDHCI_CDNS_HRS04_ACK;
> + }
> +
> + sdhci->regs[TO_REG(addr)] = val32;
> + break;
> + case SDHCI_CDNS_HRS06:
> + if (val32 & SDHCI_CDNS_HRS06_TUNE_UP) {
> + val32 &= ~SDHCI_CDNS_HRS06_TUNE_UP;
> + }
> +
> + sdhci->regs[TO_REG(addr)] = val32;
> + break;
> + default:
> + if (addr < CADENCE_SDHCI_REG_SIZE) {
> + sdhci->regs[TO_REG(addr)] = val32;
> + } else {
> + qemu_log_mask(LOG_GUEST_ERROR,
> + "%s: Out-of-bounds write at 0x%" HWADDR_PRIx "\n",
> + __func__, addr);
> + }
> + }
> +}
> +
> +static const MemoryRegionOps cadence_sdhci_ops = {
> + .read = cadence_sdhci_read,
> + .write = cadence_sdhci_write,
> + .endianness = DEVICE_NATIVE_ENDIAN,
To make it obvious, please also add:
.impl = {
.min_access_size = 4,
.max_access_size = 4,
},
> + .valid = {
> + .min_access_size = 4,
> + .max_access_size = 4,
> + }
> +};
> +
> +static void cadence_sdhci_realize(DeviceState *dev, Error **errp)
> +{
> + SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
> + CadenceSDHCIState *sdhci = CADENCE_SDHCI(dev);
> + SysBusDevice *sbd_slot = SYS_BUS_DEVICE(&sdhci->slot);
Where is sdhci->slot initialized??
> +
> + memory_region_init_io(&sdhci->iomem, OBJECT(sdhci), &cadence_sdhci_ops,
> + sdhci, TYPE_CADENCE_SDHCI, 0x1000);
> + sysbus_init_mmio(sbd, &sdhci->iomem);
> +
> + sysbus_realize(sbd_slot, errp);
> + memory_region_add_subregion(&sdhci->iomem, SDHCI_CDNS_SRS_BASE,
> + &sdhci->slot.iomem);
You should not access private field that way, you have to use
the public interface:
memory_region_add_subregion(&sdhci->iomem, SDHCI_CDNS_SRS_BASE,
sysbus_mmio_get_region(SYS_BUS_DEVICE(&sdhci->slot), 0));
To have this model useful, you need to propagate at least the 'sd-bus'
and 'dma' properties from the 'slot', else how the TYPE_CADENCE_SDHCI
user is supposed to set them?
> +}
> +
> +static const VMStateDescription vmstate_cadence_sdhci = {
> + .name = TYPE_CADENCE_SDHCI,
> + .version_id = 1,
> + .fields = (VMStateField[]) {
> + VMSTATE_UINT32_ARRAY(regs, CadenceSDHCIState, CADENCE_SDHCI_NUM_REGS),
> + VMSTATE_END_OF_LIST(),
> + },
> +};
> +
> +static void cadence_sdhci_class_init(ObjectClass *classp, void *data)
> +{
> + DeviceClass *dc = DEVICE_CLASS(classp);
> +
> + dc->realize = cadence_sdhci_realize;
> + dc->reset = cadence_sdhci_reset;
> + dc->vmsd = &vmstate_cadence_sdhci;
> +}
> +
> +static TypeInfo cadence_sdhci_info = {
> + .name = TYPE_CADENCE_SDHCI,
> + .parent = TYPE_SYS_BUS_DEVICE,
> + .instance_size = sizeof(CadenceSDHCIState),
> + .class_init = cadence_sdhci_class_init,
> +};
> +
> +static void cadence_sdhci_register_types(void)
> +{
> + type_register_static(&cadence_sdhci_info);
> +}
> +
> +type_init(cadence_sdhci_register_types)
> diff --git a/include/hw/sd/cadence_sdhci.h b/include/hw/sd/cadence_sdhci.h
> new file mode 100644
> index 0000000..9ff78a9
> --- /dev/null
> +++ b/include/hw/sd/cadence_sdhci.h
> @@ -0,0 +1,65 @@
> +/*
> + * Cadence SDHCI emulation
> + *
> + * Copyright (c) 2020 Wind River Systems, Inc.
> + *
> + * Author:
> + * Bin Meng <bin.meng@windriver.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 or
> + * (at your option) version 3 of the License.
> + *
> + * This program is distributed in the hope that 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/>.
> + */
> +
> +#ifndef CADENCE_SDHCI_H
> +#define CADENCE_SDHCI_H
> +
> +#include "qemu/bitops.h"
> +#include "hw/sd/sdhci.h"
> +
> +/* HRS - Host Register Set (specific to Cadence) */
> +
> +#define SDHCI_CDNS_HRS00 0x00 /* general information */
> +#define SDHCI_CDNS_HRS00_SWR BIT(0)
> +#define SDHCI_CDNS_HRS00_POR_VAL 0x00010000
> +
> +#define SDHCI_CDNS_HRS04 0x10 /* PHY access port */
> +#define SDHCI_CDNS_HRS04_WR BIT(24)
> +#define SDHCI_CDNS_HRS04_RD BIT(25)
> +#define SDHCI_CDNS_HRS04_ACK BIT(26)
> +
> +#define SDHCI_CDNS_HRS06 0x18 /* eMMC control */
> +#define SDHCI_CDNS_HRS06_TUNE_UP BIT(15)
> +
> +/* SRS - Slot Register Set (SDHCI-compatible) */
> +#define SDHCI_CDNS_SRS_BASE 0x200
Please keep the previous definitions local to cadence_sdhci.c.
> +
> +#define CADENCE_SDHCI_CAPABILITIES 0x01E80080
> +#define CADENCE_SDHCI_REG_SIZE 0x100
> +#define CADENCE_SDHCI_NUM_REGS (CADENCE_SDHCI_REG_SIZE / sizeof(uint32_t))
> +
> +typedef struct CadenceSDHCIState {
> + SysBusDevice parent;
> +
> + MemoryRegion iomem;
> + qemu_irq irq;
> +
> + uint32_t regs[CADENCE_SDHCI_NUM_REGS];
> +
> + SDHCIState slot;
Why name this 'slot' and not 'sdhci' or 'generic_sdhci'?
Thanks,
Phil.
> +} CadenceSDHCIState;
> +
> +#define TYPE_CADENCE_SDHCI "cadence.sdhci"
> +#define CADENCE_SDHCI(obj) OBJECT_CHECK(CadenceSDHCIState, (obj), \
> + TYPE_CADENCE_SDHCI)
> +
> +#endif /* CADENCE_SDHCI_H */
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 10/18] hw/sd: Add Cadence SDHCI emulation
@ 2020-08-15 8:51 ` Philippe Mathieu-Daudé
0 siblings, 0 replies; 100+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-08-15 8:51 UTC (permalink / raw)
To: Bin Meng, Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Edgar E. Iglesias, Bin Meng, qemu-arm, Alistair Francis, Peter Maydell
On 8/14/20 6:40 PM, Bin Meng wrote:
> From: Bin Meng <bin.meng@windriver.com>
>
> Cadence SD/SDIO/eMMC Host Controller (SD4HC) is an SDHCI compatible
> controller. The SDHCI compatible registers start from offset 0x200,
> which are called Slot Register Set (SRS) in its datasheet.
>
> This creates a Cadence SDHCI model built on top of the existing
> generic SDHCI model. Cadence specific Host Register Set (HRS) is
> implemented to make guest software happy.
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
> ---
>
> hw/sd/Kconfig | 4 ++
> hw/sd/Makefile.objs | 1 +
> hw/sd/cadence_sdhci.c | 162 ++++++++++++++++++++++++++++++++++++++++++
> include/hw/sd/cadence_sdhci.h | 65 +++++++++++++++++
> 4 files changed, 232 insertions(+)
> create mode 100644 hw/sd/cadence_sdhci.c
> create mode 100644 include/hw/sd/cadence_sdhci.h
Please consider using scripts/git.orderfile.
>
> diff --git a/hw/sd/Kconfig b/hw/sd/Kconfig
> index c5e1e55..633b9af 100644
> --- a/hw/sd/Kconfig
> +++ b/hw/sd/Kconfig
> @@ -19,3 +19,7 @@ config SDHCI_PCI
> default y if PCI_DEVICES
> depends on PCI
> select SDHCI
> +
> +config CADENCE_SDHCI
> + bool
> + select SDHCI
> diff --git a/hw/sd/Makefile.objs b/hw/sd/Makefile.objs
> index 0d1df17..4d500a6 100644
> --- a/hw/sd/Makefile.objs
> +++ b/hw/sd/Makefile.objs
> @@ -10,3 +10,4 @@ common-obj-$(CONFIG_OMAP) += omap_mmc.o
> common-obj-$(CONFIG_PXA2XX) += pxa2xx_mmci.o
> common-obj-$(CONFIG_RASPI) += bcm2835_sdhost.o
> common-obj-$(CONFIG_ASPEED_SOC) += aspeed_sdhci.o
> +common-obj-$(CONFIG_CADENCE_SDHCI) += cadence_sdhci.o
> diff --git a/hw/sd/cadence_sdhci.c b/hw/sd/cadence_sdhci.c
> new file mode 100644
> index 0000000..67ffd14
> --- /dev/null
> +++ b/hw/sd/cadence_sdhci.c
> @@ -0,0 +1,162 @@
> +/*
> + * Cadence SDHCI emulation
> + *
> + * Copyright (c) 2020 Wind River Systems, Inc.
> + *
> + * Author:
> + * Bin Meng <bin.meng@windriver.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 or
> + * (at your option) version 3 of the License.
> + *
> + * This program is distributed in the hope that 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/log.h"
> +#include "qapi/error.h"
> +#include "migration/vmstate.h"
> +#include "hw/irq.h"
> +#include "hw/sd/cadence_sdhci.h"
> +#include "sdhci-internal.h"
> +
> +#define TO_REG(addr) ((addr) / sizeof(uint32_t))
> +
> +static void cadence_sdhci_reset(DeviceState *dev)
> +{
> + CadenceSDHCIState *sdhci = CADENCE_SDHCI(dev);
We usually use 's' for the model state.
> +
> + memset(sdhci->regs, 0, CADENCE_SDHCI_REG_SIZE);
> + sdhci->regs[TO_REG(SDHCI_CDNS_HRS00)] = SDHCI_CDNS_HRS00_POR_VAL;
As commented in previous patch, here goes:
device_legacy_reset(DEVICE(&sdhci->slot));
> +}
> +
> +static uint64_t cadence_sdhci_read(void *opaque, hwaddr addr, unsigned int size)
> +{
> + uint32_t val = 0;
> + CadenceSDHCIState *sdhci = opaque;
> +
> + if (addr < CADENCE_SDHCI_REG_SIZE) {
> + val = sdhci->regs[TO_REG(addr)];
> + } else {
> + qemu_log_mask(LOG_GUEST_ERROR,
> + "%s: Out-of-bounds read at 0x%" HWADDR_PRIx "\n",
> + __func__, addr);
> + }
> +
> + return (uint64_t)val;
> +}
> +
> +static void cadence_sdhci_write(void *opaque, hwaddr addr, uint64_t val,
> + unsigned int size)
> +{
> + CadenceSDHCIState *sdhci = opaque;
> + uint32_t val32 = (uint32_t)val;
> +
> + switch (addr) {
> + case SDHCI_CDNS_HRS00:
> + /*
> + * The only writable bit is SWR (software reset) and it automatically
> + * clears to zero, so essentially this register remains unchanged.
> + */
> + if (val32 & SDHCI_CDNS_HRS00_SWR) {
> + cadence_sdhci_reset(DEVICE(sdhci));
> + sdhci_poweron_reset(DEVICE(&sdhci->slot));
The 'slot' reset has to go in cadence_sdhci_reset().
> + }
> +
> + break;
> + case SDHCI_CDNS_HRS04:
> + /*
> + * Only emulate the ACK bit behavior when read or write transaction
> + * are requested.
> + */
> + if (val32 & (SDHCI_CDNS_HRS04_WR | SDHCI_CDNS_HRS04_RD)) {
> + val32 |= SDHCI_CDNS_HRS04_ACK;
> + } else {
> + val32 &= ~SDHCI_CDNS_HRS04_ACK;
> + }
> +
> + sdhci->regs[TO_REG(addr)] = val32;
> + break;
> + case SDHCI_CDNS_HRS06:
> + if (val32 & SDHCI_CDNS_HRS06_TUNE_UP) {
> + val32 &= ~SDHCI_CDNS_HRS06_TUNE_UP;
> + }
> +
> + sdhci->regs[TO_REG(addr)] = val32;
> + break;
> + default:
> + if (addr < CADENCE_SDHCI_REG_SIZE) {
> + sdhci->regs[TO_REG(addr)] = val32;
> + } else {
> + qemu_log_mask(LOG_GUEST_ERROR,
> + "%s: Out-of-bounds write at 0x%" HWADDR_PRIx "\n",
> + __func__, addr);
> + }
> + }
> +}
> +
> +static const MemoryRegionOps cadence_sdhci_ops = {
> + .read = cadence_sdhci_read,
> + .write = cadence_sdhci_write,
> + .endianness = DEVICE_NATIVE_ENDIAN,
To make it obvious, please also add:
.impl = {
.min_access_size = 4,
.max_access_size = 4,
},
> + .valid = {
> + .min_access_size = 4,
> + .max_access_size = 4,
> + }
> +};
> +
> +static void cadence_sdhci_realize(DeviceState *dev, Error **errp)
> +{
> + SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
> + CadenceSDHCIState *sdhci = CADENCE_SDHCI(dev);
> + SysBusDevice *sbd_slot = SYS_BUS_DEVICE(&sdhci->slot);
Where is sdhci->slot initialized??
> +
> + memory_region_init_io(&sdhci->iomem, OBJECT(sdhci), &cadence_sdhci_ops,
> + sdhci, TYPE_CADENCE_SDHCI, 0x1000);
> + sysbus_init_mmio(sbd, &sdhci->iomem);
> +
> + sysbus_realize(sbd_slot, errp);
> + memory_region_add_subregion(&sdhci->iomem, SDHCI_CDNS_SRS_BASE,
> + &sdhci->slot.iomem);
You should not access private field that way, you have to use
the public interface:
memory_region_add_subregion(&sdhci->iomem, SDHCI_CDNS_SRS_BASE,
sysbus_mmio_get_region(SYS_BUS_DEVICE(&sdhci->slot), 0));
To have this model useful, you need to propagate at least the 'sd-bus'
and 'dma' properties from the 'slot', else how the TYPE_CADENCE_SDHCI
user is supposed to set them?
> +}
> +
> +static const VMStateDescription vmstate_cadence_sdhci = {
> + .name = TYPE_CADENCE_SDHCI,
> + .version_id = 1,
> + .fields = (VMStateField[]) {
> + VMSTATE_UINT32_ARRAY(regs, CadenceSDHCIState, CADENCE_SDHCI_NUM_REGS),
> + VMSTATE_END_OF_LIST(),
> + },
> +};
> +
> +static void cadence_sdhci_class_init(ObjectClass *classp, void *data)
> +{
> + DeviceClass *dc = DEVICE_CLASS(classp);
> +
> + dc->realize = cadence_sdhci_realize;
> + dc->reset = cadence_sdhci_reset;
> + dc->vmsd = &vmstate_cadence_sdhci;
> +}
> +
> +static TypeInfo cadence_sdhci_info = {
> + .name = TYPE_CADENCE_SDHCI,
> + .parent = TYPE_SYS_BUS_DEVICE,
> + .instance_size = sizeof(CadenceSDHCIState),
> + .class_init = cadence_sdhci_class_init,
> +};
> +
> +static void cadence_sdhci_register_types(void)
> +{
> + type_register_static(&cadence_sdhci_info);
> +}
> +
> +type_init(cadence_sdhci_register_types)
> diff --git a/include/hw/sd/cadence_sdhci.h b/include/hw/sd/cadence_sdhci.h
> new file mode 100644
> index 0000000..9ff78a9
> --- /dev/null
> +++ b/include/hw/sd/cadence_sdhci.h
> @@ -0,0 +1,65 @@
> +/*
> + * Cadence SDHCI emulation
> + *
> + * Copyright (c) 2020 Wind River Systems, Inc.
> + *
> + * Author:
> + * Bin Meng <bin.meng@windriver.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 or
> + * (at your option) version 3 of the License.
> + *
> + * This program is distributed in the hope that 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/>.
> + */
> +
> +#ifndef CADENCE_SDHCI_H
> +#define CADENCE_SDHCI_H
> +
> +#include "qemu/bitops.h"
> +#include "hw/sd/sdhci.h"
> +
> +/* HRS - Host Register Set (specific to Cadence) */
> +
> +#define SDHCI_CDNS_HRS00 0x00 /* general information */
> +#define SDHCI_CDNS_HRS00_SWR BIT(0)
> +#define SDHCI_CDNS_HRS00_POR_VAL 0x00010000
> +
> +#define SDHCI_CDNS_HRS04 0x10 /* PHY access port */
> +#define SDHCI_CDNS_HRS04_WR BIT(24)
> +#define SDHCI_CDNS_HRS04_RD BIT(25)
> +#define SDHCI_CDNS_HRS04_ACK BIT(26)
> +
> +#define SDHCI_CDNS_HRS06 0x18 /* eMMC control */
> +#define SDHCI_CDNS_HRS06_TUNE_UP BIT(15)
> +
> +/* SRS - Slot Register Set (SDHCI-compatible) */
> +#define SDHCI_CDNS_SRS_BASE 0x200
Please keep the previous definitions local to cadence_sdhci.c.
> +
> +#define CADENCE_SDHCI_CAPABILITIES 0x01E80080
> +#define CADENCE_SDHCI_REG_SIZE 0x100
> +#define CADENCE_SDHCI_NUM_REGS (CADENCE_SDHCI_REG_SIZE / sizeof(uint32_t))
> +
> +typedef struct CadenceSDHCIState {
> + SysBusDevice parent;
> +
> + MemoryRegion iomem;
> + qemu_irq irq;
> +
> + uint32_t regs[CADENCE_SDHCI_NUM_REGS];
> +
> + SDHCIState slot;
Why name this 'slot' and not 'sdhci' or 'generic_sdhci'?
Thanks,
Phil.
> +} CadenceSDHCIState;
> +
> +#define TYPE_CADENCE_SDHCI "cadence.sdhci"
> +#define CADENCE_SDHCI(obj) OBJECT_CHECK(CadenceSDHCIState, (obj), \
> + TYPE_CADENCE_SDHCI)
> +
> +#endif /* CADENCE_SDHCI_H */
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 11/18] hw/riscv: microchip_pfsoc: Connect a Cadence SDHCI controller and an SD card
2020-08-14 16:40 ` [PATCH 11/18] hw/riscv: microchip_pfsoc: Connect a Cadence SDHCI controller and an SD card Bin Meng
@ 2020-08-15 8:55 ` Philippe Mathieu-Daudé
0 siblings, 0 replies; 100+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-08-15 8:55 UTC (permalink / raw)
To: Bin Meng, Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, Palmer Dabbelt
On 8/14/20 6:40 PM, Bin Meng wrote:
> From: Bin Meng <bin.meng@windriver.com>
>
> 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>
> ---
>
> hw/riscv/Kconfig | 1 +
> hw/riscv/microchip_pfsoc.c | 26 ++++++++++++++++++++++++++
> include/hw/riscv/microchip_pfsoc.h | 4 ++++
> 3 files changed, 31 insertions(+)
>
> diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
> index ceb7c16..7412db9 100644
> --- a/hw/riscv/Kconfig
> +++ b/hw/riscv/Kconfig
> @@ -55,3 +55,4 @@ config MICROCHIP_PFSOC
> select SIFIVE
> select UNIMP
> select MCHP_PFSOC_MMUART
> + select CADENCE_SDHCI
> diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
> index f6b375c..7c09078 100644
> --- a/hw/riscv/microchip_pfsoc.c
> +++ b/hw/riscv/microchip_pfsoc.c
> @@ -12,6 +12,7 @@
> * 1) PLIC (Platform Level Interrupt Controller)
> * 2) eNVM (Embedded Non-Volatile Memory)
> * 3) MMUARTs (Multi-Mode UART)
> + * 4) Cadence eMMC/SDHC controller and an SD card connected to it
> *
> * This board currently generates devicetree dynamically that indicates at least
> * two harts and up to five harts.
> @@ -75,6 +76,7 @@ static const struct MemmapEntry {
> [MICROCHIP_PFSOC_MMUART0] = { 0x20000000, 0x1000 },
> [MICROCHIP_PFSOC_SYSREG] = { 0x20002000, 0x2000 },
> [MICROCHIP_PFSOC_MPUCFG] = { 0x20005000, 0x1000 },
> + [MICROCHIP_PFSOC_EMMC_SD] = { 0x20008000, 0x1000 },
> [MICROCHIP_PFSOC_MMUART1] = { 0x20100000, 0x1000 },
> [MICROCHIP_PFSOC_MMUART2] = { 0x20102000, 0x1000 },
> [MICROCHIP_PFSOC_MMUART3] = { 0x20104000, 0x1000 },
> @@ -111,6 +113,11 @@ static void microchip_pfsoc_soc_instance_init(Object *obj)
> 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);
> +
> + object_initialize_child(obj, "sd-controller", &s->sdhci,
> + TYPE_CADENCE_SDHCI);
> + object_initialize_child(OBJECT(&s->sdhci), "sd-controller.sdhci",
> + &s->sdhci.slot, TYPE_SYSBUS_SDHCI);
OK now I see this patch, so NAck. TYPE_SYSBUS_SDHCI has to be
initialized in TYPE_CADENCE_SDHCI, not in all TYPE_CADENCE_SDHCI
users.
> }
>
> static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
> @@ -223,6 +230,13 @@ static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
> memmap[MICROCHIP_PFSOC_MPUCFG].base,
> memmap[MICROCHIP_PFSOC_MPUCFG].size);
>
> + /* SDHCI */
Consider setting the SDHCI DMA MR here.
> + 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.slot), 0,
> + qdev_get_gpio_in(DEVICE(s->plic), MICROCHIP_PFSOC_EMMC_SD_IRQ));
> +
> /* MMUARTs */
> s->serial0 = mchp_pfsoc_mmuart_create(system_memory,
> memmap[MICROCHIP_PFSOC_MMUART0].base,
> @@ -290,6 +304,7 @@ static void microchip_icicle_kit_machine_init(MachineState *machine)
> MicrochipIcicleKitState *s = MICROCHIP_ICICLE_KIT_MACHINE(machine);
> MemoryRegion *system_memory = get_system_memory();
> MemoryRegion *main_mem = g_new(MemoryRegion, 1);
> + DriveInfo *dinfo = drive_get_next(IF_SD);
>
> /* Sanity check on RAM size */
> if (machine->ram_size < mc->default_ram_size) {
> @@ -312,6 +327,17 @@ static void microchip_icicle_kit_machine_init(MachineState *machine)
>
> /* Load the firmware */
> riscv_find_and_load_firmware(machine, BIOS_FILENAME, RESET_VECTOR, NULL);
> +
> + /* Attach an SD card */
> + if (dinfo) {
> + SDHCIState *sdhci = &(s->soc.sdhci.slot);
NAck again, you are not supposed to access this field here.
This is why in the previous patch I asked why the "sd-bus" property
was not propagated from child to parent.
Thanks,
Phil.
> + DeviceState *card = qdev_new(TYPE_SD_CARD);
> + BusState *bus = qdev_get_child_bus(DEVICE(sdhci), "sd-bus");
> +
> + qdev_prop_set_drive_err(card, "drive", blk_by_legacy_dinfo(dinfo),
> + &error_fatal);
> + qdev_realize_and_unref(card, bus, &error_fatal);
> + }
> }
>
> static void microchip_icicle_kit_machine_class_init(ObjectClass *oc, void *data)
> diff --git a/include/hw/riscv/microchip_pfsoc.h b/include/hw/riscv/microchip_pfsoc.h
> index a5efa1d..d810ee8 100644
> --- a/include/hw/riscv/microchip_pfsoc.h
> +++ b/include/hw/riscv/microchip_pfsoc.h
> @@ -23,6 +23,7 @@
> #define HW_MICROCHIP_PFSOC_H
>
> #include "hw/char/mchp_pfsoc_mmuart.h"
> +#include "hw/sd/cadence_sdhci.h"
>
> typedef struct MicrochipPFSoCState {
> /*< private >*/
> @@ -39,6 +40,7 @@ typedef struct MicrochipPFSoCState {
> MchpPfSoCMMUartState *serial2;
> MchpPfSoCMMUartState *serial3;
> MchpPfSoCMMUartState *serial4;
> + CadenceSDHCIState sdhci;
> } MicrochipPFSoCState;
>
> #define TYPE_MICROCHIP_PFSOC "microchip.pfsoc"
> @@ -74,6 +76,7 @@ enum {
> MICROCHIP_PFSOC_MMUART0,
> MICROCHIP_PFSOC_SYSREG,
> MICROCHIP_PFSOC_MPUCFG,
> + MICROCHIP_PFSOC_EMMC_SD,
> MICROCHIP_PFSOC_MMUART1,
> MICROCHIP_PFSOC_MMUART2,
> MICROCHIP_PFSOC_MMUART3,
> @@ -85,6 +88,7 @@ enum {
> };
>
> enum {
> + MICROCHIP_PFSOC_EMMC_SD_IRQ = 88,
> MICROCHIP_PFSOC_MMUART0_IRQ = 90,
> MICROCHIP_PFSOC_MMUART1_IRQ = 91,
> MICROCHIP_PFSOC_MMUART2_IRQ = 92,
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 13/18] hw/riscv: microchip_pfsoc: Connect a DMA controller
2020-08-14 16:40 ` [PATCH 13/18] hw/riscv: microchip_pfsoc: Connect a DMA controller Bin Meng
@ 2020-08-15 9:00 ` Philippe Mathieu-Daudé
2020-08-16 8:57 ` Bin Meng
0 siblings, 1 reply; 100+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-08-15 9:00 UTC (permalink / raw)
To: Bin Meng, Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, Palmer Dabbelt
On 8/14/20 6:40 PM, Bin Meng wrote:
> From: Bin Meng <bin.meng@windriver.com>
>
> Connect a DMA controller to Microchip PolarFire SoC. Note interrupt
> has not been connected due to missing information in the manual how
> interrupts are routed to PLIC.
>
> On the Icicle Kit board, the HSS firmware utilizes the on-chip DMA
> controller to move the 2nd stage bootloader in the system memory.
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
> ---
>
> hw/riscv/Kconfig | 1 +
> hw/riscv/microchip_pfsoc.c | 10 ++++++++++
> include/hw/riscv/microchip_pfsoc.h | 3 +++
> 3 files changed, 14 insertions(+)
>
> diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
> index 7412db9..9323701 100644
> --- a/hw/riscv/Kconfig
> +++ b/hw/riscv/Kconfig
> @@ -55,4 +55,5 @@ config MICROCHIP_PFSOC
> select SIFIVE
> select UNIMP
> select MCHP_PFSOC_MMUART
> + select MCHP_PFSOC_DMA
> select CADENCE_SDHCI
> diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
> index 7c09078..1c67cbc 100644
> --- a/hw/riscv/microchip_pfsoc.c
> +++ b/hw/riscv/microchip_pfsoc.c
> @@ -13,6 +13,7 @@
> * 2) eNVM (Embedded Non-Volatile Memory)
> * 3) MMUARTs (Multi-Mode UART)
> * 4) Cadence eMMC/SDHC controller and an SD card connected to it
> + * 5) DMA (Direct Memory Access Controller)
> *
> * This board currently generates devicetree dynamically that indicates at least
> * two harts and up to five harts.
> @@ -71,6 +72,7 @@ static const struct MemmapEntry {
> [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 },
> @@ -114,6 +116,9 @@ static void microchip_pfsoc_soc_instance_init(Object *obj)
> TYPE_RISCV_CPU_SIFIVE_U54);
> qdev_prop_set_uint64(DEVICE(&s->u_cpus), "resetvec", RESET_VECTOR);
>
> + object_initialize_child(obj, "dma-controller", &s->dma,
> + TYPE_MCHP_PFSOC_DMA);
> +
> object_initialize_child(obj, "sd-controller", &s->sdhci,
> TYPE_CADENCE_SDHCI);
I haven't looked at the chip specs, but maybe you can add the SD
controller after the DMA controller so so you can directly link
a DMA address space to it.
> object_initialize_child(OBJECT(&s->sdhci), "sd-controller.sdhci",
> @@ -220,6 +225,11 @@ static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
> memmap[MICROCHIP_PFSOC_PLIC].size);
> g_free(plic_hart_config);
>
> + /* DMA */
> + sysbus_realize(SYS_BUS_DEVICE(&s->dma), errp);
> + sysbus_mmio_map(SYS_BUS_DEVICE(&s->dma), 0,
> + memmap[MICROCHIP_PFSOC_DMA].base);
> +
> /* SYSREG */
> create_unimplemented_device("microchip.pfsoc.sysreg",
> memmap[MICROCHIP_PFSOC_SYSREG].base,
> diff --git a/include/hw/riscv/microchip_pfsoc.h b/include/hw/riscv/microchip_pfsoc.h
> index d810ee8..7825935 100644
> --- a/include/hw/riscv/microchip_pfsoc.h
> +++ b/include/hw/riscv/microchip_pfsoc.h
> @@ -23,6 +23,7 @@
> #define HW_MICROCHIP_PFSOC_H
>
> #include "hw/char/mchp_pfsoc_mmuart.h"
> +#include "hw/dma/mchp_pfsoc_dma.h"
> #include "hw/sd/cadence_sdhci.h"
>
> typedef struct MicrochipPFSoCState {
> @@ -40,6 +41,7 @@ typedef struct MicrochipPFSoCState {
> MchpPfSoCMMUartState *serial2;
> MchpPfSoCMMUartState *serial3;
> MchpPfSoCMMUartState *serial4;
> + MchpPfSoCDMAState dma;
> CadenceSDHCIState sdhci;
> } MicrochipPFSoCState;
>
> @@ -71,6 +73,7 @@ enum {
> MICROCHIP_PFSOC_BUSERR_UNIT4,
> MICROCHIP_PFSOC_CLINT,
> MICROCHIP_PFSOC_L2CC,
> + MICROCHIP_PFSOC_DMA,
> MICROCHIP_PFSOC_L2LIM,
> MICROCHIP_PFSOC_PLIC,
> MICROCHIP_PFSOC_MMUART0,
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 14/18] hw/net: cadence_gem: Add a new 'phy-addr' property
2020-08-14 16:40 ` Bin Meng
(?)
@ 2020-08-15 9:06 ` Philippe Mathieu-Daudé
2020-08-16 8:29 ` Bin Meng
-1 siblings, 1 reply; 100+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-08-15 9:06 UTC (permalink / raw)
To: Bin Meng, Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Peter Maydell, Alistair Francis, Jason Wang, Bin Meng, qemu-arm,
Edgar E. Iglesias
On 8/14/20 6:40 PM, Bin Meng wrote:
> From: Bin Meng <bin.meng@windriver.com>
>
> At present the PHY address of the PHY connected to GEM is hard-coded
> to either 23 (BOARD_PHY_ADDRESS) or 0. This might not be the case for
> all boards. Add a new 'phy-addr' property so that board can specify
> the PHY address for each GEM instance.
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
> ---
>
> hw/net/cadence_gem.c | 7 +++++--
> include/hw/net/cadence_gem.h | 2 ++
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
> index a93b5c0..9fa03de 100644
> --- a/hw/net/cadence_gem.c
> +++ b/hw/net/cadence_gem.c
> @@ -1446,7 +1446,8 @@ static uint64_t gem_read(void *opaque, hwaddr offset, unsigned size)
> uint32_t phy_addr, reg_num;
>
> phy_addr = (retval & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
> - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
> + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
> + phy_addr == s->phy_addr) {
> reg_num = (retval & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
> retval &= 0xFFFF0000;
> retval |= gem_phy_read(s, reg_num);
> @@ -1569,7 +1570,8 @@ static void gem_write(void *opaque, hwaddr offset, uint64_t val,
> uint32_t phy_addr, reg_num;
>
> phy_addr = (val & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
> - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
> + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
> + phy_addr == s->phy_addr) {
> reg_num = (val & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
> gem_phy_write(s, reg_num, val);
> }
> @@ -1682,6 +1684,7 @@ static Property gem_properties[] = {
> DEFINE_NIC_PROPERTIES(CadenceGEMState, conf),
> DEFINE_PROP_UINT32("revision", CadenceGEMState, revision,
> GEM_MODID_VALUE),
> + DEFINE_PROP_UINT8("phy-addr", CadenceGEMState, phy_addr, 0),
This patch would be complete by moving the BOARD_PHY_ADDRESS definition
to each board using this NIC, and setting the "phy-addr" property to
this value.
> DEFINE_PROP_UINT8("num-priority-queues", CadenceGEMState,
> num_priority_queues, 1),
> DEFINE_PROP_UINT8("num-type1-screeners", CadenceGEMState,
> diff --git a/include/hw/net/cadence_gem.h b/include/hw/net/cadence_gem.h
> index 54e646f..01c6189 100644
> --- a/include/hw/net/cadence_gem.h
> +++ b/include/hw/net/cadence_gem.h
> @@ -73,6 +73,8 @@ typedef struct CadenceGEMState {
> /* Mask of register bits which are write 1 to clear */
> uint32_t regs_w1c[CADENCE_GEM_MAXREG];
>
> + /* PHY address */
> + uint8_t phy_addr;
> /* PHY registers backing store */
> uint16_t phy_regs[32];
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 14/18] hw/net: cadence_gem: Add a new 'phy-addr' property
2020-08-15 9:06 ` Philippe Mathieu-Daudé
@ 2020-08-16 8:29 ` Bin Meng
0 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-16 8:29 UTC (permalink / raw)
To: Philippe Mathieu-Daudé,
John Linn, Peter A. G. Crosthwaite, Peter Crosthwaite,
Nathan Rossi
Cc: Peter Maydell, Alistair Francis, open list:RISC-V,
Sagar Karandikar, Bin Meng, Bastian Koppelmann, Jason Wang,
Palmer Dabbelt, qemu-devel@nongnu.org Developers, qemu-arm,
Alistair Francis, Edgar E. Iglesias
On Sat, Aug 15, 2020 at 5:06 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> On 8/14/20 6:40 PM, Bin Meng wrote:
> > From: Bin Meng <bin.meng@windriver.com>
> >
> > At present the PHY address of the PHY connected to GEM is hard-coded
> > to either 23 (BOARD_PHY_ADDRESS) or 0. This might not be the case for
> > all boards. Add a new 'phy-addr' property so that board can specify
> > the PHY address for each GEM instance.
> >
> > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > ---
> >
> > hw/net/cadence_gem.c | 7 +++++--
> > include/hw/net/cadence_gem.h | 2 ++
> > 2 files changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
> > index a93b5c0..9fa03de 100644
> > --- a/hw/net/cadence_gem.c
> > +++ b/hw/net/cadence_gem.c
> > @@ -1446,7 +1446,8 @@ static uint64_t gem_read(void *opaque, hwaddr offset, unsigned size)
> > uint32_t phy_addr, reg_num;
> >
> > phy_addr = (retval & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
> > - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
> > + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
> > + phy_addr == s->phy_addr) {
> > reg_num = (retval & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
> > retval &= 0xFFFF0000;
> > retval |= gem_phy_read(s, reg_num);
> > @@ -1569,7 +1570,8 @@ static void gem_write(void *opaque, hwaddr offset, uint64_t val,
> > uint32_t phy_addr, reg_num;
> >
> > phy_addr = (val & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
> > - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
> > + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
> > + phy_addr == s->phy_addr) {
> > reg_num = (val & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
> > gem_phy_write(s, reg_num, val);
> > }
> > @@ -1682,6 +1684,7 @@ static Property gem_properties[] = {
> > DEFINE_NIC_PROPERTIES(CadenceGEMState, conf),
> > DEFINE_PROP_UINT32("revision", CadenceGEMState, revision,
> > GEM_MODID_VALUE),
> > + DEFINE_PROP_UINT8("phy-addr", CadenceGEMState, phy_addr, 0),
>
> This patch would be complete by moving the BOARD_PHY_ADDRESS definition
> to each board using this NIC, and setting the "phy-addr" property to
> this value.
I actually have no idea which board in QEMU is using this special PHY
address instead of default 0.
It looks BOARD_PHY_ADDRESS has been there since the initial version of
the cadence_gem model.
commit e9f186e514a70557d695cadd2c2287ef97737023
Author: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
Date: Mon Mar 5 14:39:12 2012 +1000
cadence_gem: initial version of device model
Device model for cadence gem ethernet controller.
Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
Signed-off-by: John Linn <john.linn@xilinx.com>
Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Later PHY address 0 was added via the following commit:
commit 553893736885e4f2dda424bff3e2200e1b6482a5
Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Date: Thu Apr 3 23:55:19 2014 -0700
net: cadence_gem: Make phy respond to broadcast
Phys must respond to address 0 by specification. Implement.
Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Message-id:
6f4d53b04ddbfb19895bfb61a595e69f1c08859a.1396594056.git.peter.crosthwaite@xilinx.com
Reviewed-by: Beniamino Galvani <b.galvani@gmail.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
I doubt the commit message said that PHYs must respond to address 0. I
am not aware of such specs. The issue was probably that whatever board
2nd commit was tested against did not have a PHY at address
BOARD_PHY_ADDRESS.
+ a couple of Xilinx folks to comment.
>
> > DEFINE_PROP_UINT8("num-priority-queues", CadenceGEMState,
> > num_priority_queues, 1),
> > DEFINE_PROP_UINT8("num-type1-screeners", CadenceGEMState,
> > diff --git a/include/hw/net/cadence_gem.h b/include/hw/net/cadence_gem.h
> > index 54e646f..01c6189 100644
> > --- a/include/hw/net/cadence_gem.h
> > +++ b/include/hw/net/cadence_gem.h
> > @@ -73,6 +73,8 @@ typedef struct CadenceGEMState {
> > /* Mask of register bits which are write 1 to clear */
> > uint32_t regs_w1c[CADENCE_GEM_MAXREG];
> >
> > + /* PHY address */
> > + uint8_t phy_addr;
> > /* PHY registers backing store */
> > uint16_t phy_regs[32];
Regards,
Bin
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 14/18] hw/net: cadence_gem: Add a new 'phy-addr' property
@ 2020-08-16 8:29 ` Bin Meng
0 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-16 8:29 UTC (permalink / raw)
To: Philippe Mathieu-Daudé,
John Linn, Peter A. G. Crosthwaite, Peter Crosthwaite,
Nathan Rossi
Cc: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel@nongnu.org Developers,
open list:RISC-V, Peter Maydell, Alistair Francis, Jason Wang,
Bin Meng, qemu-arm, Edgar E. Iglesias
On Sat, Aug 15, 2020 at 5:06 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> On 8/14/20 6:40 PM, Bin Meng wrote:
> > From: Bin Meng <bin.meng@windriver.com>
> >
> > At present the PHY address of the PHY connected to GEM is hard-coded
> > to either 23 (BOARD_PHY_ADDRESS) or 0. This might not be the case for
> > all boards. Add a new 'phy-addr' property so that board can specify
> > the PHY address for each GEM instance.
> >
> > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > ---
> >
> > hw/net/cadence_gem.c | 7 +++++--
> > include/hw/net/cadence_gem.h | 2 ++
> > 2 files changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
> > index a93b5c0..9fa03de 100644
> > --- a/hw/net/cadence_gem.c
> > +++ b/hw/net/cadence_gem.c
> > @@ -1446,7 +1446,8 @@ static uint64_t gem_read(void *opaque, hwaddr offset, unsigned size)
> > uint32_t phy_addr, reg_num;
> >
> > phy_addr = (retval & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
> > - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
> > + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
> > + phy_addr == s->phy_addr) {
> > reg_num = (retval & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
> > retval &= 0xFFFF0000;
> > retval |= gem_phy_read(s, reg_num);
> > @@ -1569,7 +1570,8 @@ static void gem_write(void *opaque, hwaddr offset, uint64_t val,
> > uint32_t phy_addr, reg_num;
> >
> > phy_addr = (val & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
> > - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
> > + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
> > + phy_addr == s->phy_addr) {
> > reg_num = (val & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
> > gem_phy_write(s, reg_num, val);
> > }
> > @@ -1682,6 +1684,7 @@ static Property gem_properties[] = {
> > DEFINE_NIC_PROPERTIES(CadenceGEMState, conf),
> > DEFINE_PROP_UINT32("revision", CadenceGEMState, revision,
> > GEM_MODID_VALUE),
> > + DEFINE_PROP_UINT8("phy-addr", CadenceGEMState, phy_addr, 0),
>
> This patch would be complete by moving the BOARD_PHY_ADDRESS definition
> to each board using this NIC, and setting the "phy-addr" property to
> this value.
I actually have no idea which board in QEMU is using this special PHY
address instead of default 0.
It looks BOARD_PHY_ADDRESS has been there since the initial version of
the cadence_gem model.
commit e9f186e514a70557d695cadd2c2287ef97737023
Author: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
Date: Mon Mar 5 14:39:12 2012 +1000
cadence_gem: initial version of device model
Device model for cadence gem ethernet controller.
Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
Signed-off-by: John Linn <john.linn@xilinx.com>
Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Later PHY address 0 was added via the following commit:
commit 553893736885e4f2dda424bff3e2200e1b6482a5
Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Date: Thu Apr 3 23:55:19 2014 -0700
net: cadence_gem: Make phy respond to broadcast
Phys must respond to address 0 by specification. Implement.
Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Message-id:
6f4d53b04ddbfb19895bfb61a595e69f1c08859a.1396594056.git.peter.crosthwaite@xilinx.com
Reviewed-by: Beniamino Galvani <b.galvani@gmail.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
I doubt the commit message said that PHYs must respond to address 0. I
am not aware of such specs. The issue was probably that whatever board
2nd commit was tested against did not have a PHY at address
BOARD_PHY_ADDRESS.
+ a couple of Xilinx folks to comment.
>
> > DEFINE_PROP_UINT8("num-priority-queues", CadenceGEMState,
> > num_priority_queues, 1),
> > DEFINE_PROP_UINT8("num-type1-screeners", CadenceGEMState,
> > diff --git a/include/hw/net/cadence_gem.h b/include/hw/net/cadence_gem.h
> > index 54e646f..01c6189 100644
> > --- a/include/hw/net/cadence_gem.h
> > +++ b/include/hw/net/cadence_gem.h
> > @@ -73,6 +73,8 @@ typedef struct CadenceGEMState {
> > /* Mask of register bits which are write 1 to clear */
> > uint32_t regs_w1c[CADENCE_GEM_MAXREG];
> >
> > + /* PHY address */
> > + uint8_t phy_addr;
> > /* PHY registers backing store */
> > uint16_t phy_regs[32];
Regards,
Bin
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 09/18] hw/sd: sdhci: Make sdhci_poweron_reset() internal visible
2020-08-15 7:51 ` Philippe Mathieu-Daudé
@ 2020-08-16 8:50 ` Bin Meng
0 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-16 8:50 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Bin Meng, open list:RISC-V, qemu-block, Sagar Karandikar,
Bastian Koppelmann, Palmer Dabbelt,
qemu-devel@nongnu.org Developers, Alistair Francis
Hi Philippe,
On Sat, Aug 15, 2020 at 3:51 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> On 8/14/20 6:40 PM, Bin Meng wrote:
> > From: Bin Meng <bin.meng@windriver.com>
> >
> > sdhci_poweron_reset() might be needed for any SDHCI compatible
> > device that is built on top of the generic SDHCI device.
>
> NAck. Please use device_legacy_reset() instead.
>
> In next patch:
>
> device_legacy_reset(DEVICE(&sdhci->slot));
>
The function comments say this API is deprecated.
/**
* device_legacy_reset:
*
* Reset a single device (by calling the reset method).
* Note: This function is deprecated and will be removed when it becomes unused.
* Please use device_cold_reset() now.
*/
Should we use device_cold_reset() here?
Regards,
Bin
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 09/18] hw/sd: sdhci: Make sdhci_poweron_reset() internal visible
@ 2020-08-16 8:50 ` Bin Meng
0 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-16 8:50 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel@nongnu.org Developers,
open list:RISC-V, Bin Meng, qemu-block
Hi Philippe,
On Sat, Aug 15, 2020 at 3:51 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> On 8/14/20 6:40 PM, Bin Meng wrote:
> > From: Bin Meng <bin.meng@windriver.com>
> >
> > sdhci_poweron_reset() might be needed for any SDHCI compatible
> > device that is built on top of the generic SDHCI device.
>
> NAck. Please use device_legacy_reset() instead.
>
> In next patch:
>
> device_legacy_reset(DEVICE(&sdhci->slot));
>
The function comments say this API is deprecated.
/**
* device_legacy_reset:
*
* Reset a single device (by calling the reset method).
* Note: This function is deprecated and will be removed when it becomes unused.
* Please use device_cold_reset() now.
*/
Should we use device_cold_reset() here?
Regards,
Bin
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 08/18] hw/sd: sd: Correctly set the high capacity bit
2020-08-15 8:38 ` Philippe Mathieu-Daudé
@ 2020-08-16 8:54 ` Bin Meng
0 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-16 8:54 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Bin Meng, open list:RISC-V, qemu-block, Sagar Karandikar,
Bastian Koppelmann, Palmer Dabbelt,
qemu-devel@nongnu.org Developers, Alistair Francis
Hi Philippe,
On Sat, Aug 15, 2020 at 4:38 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> On 8/14/20 6:40 PM, Bin Meng wrote:
> > From: Bin Meng <bin.meng@windriver.com>
> >
> > Per the SD spec, Standard Capacity SD Memory Card (SDSC) supports
> > capacity up to and including 2 GiB.
> >
>
> Fixes: 2d7adea4fe ("hw/sd: Support SDHC size cards")
>
> > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > ---
> >
> > hw/sd/sd.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/hw/sd/sd.c b/hw/sd/sd.c
> > index 51f5900..5e7fc3f 100644
> > --- a/hw/sd/sd.c
> > +++ b/hw/sd/sd.c
> > @@ -313,7 +313,7 @@ static void sd_ocr_powerup(void *opaque)
> > /* card power-up OK */
> > sd->ocr = FIELD_DP32(sd->ocr, OCR, CARD_POWER_UP, 1);
> >
> > - if (sd->size > 1 * GiB) {
> > + if (sd->size > 2 * GiB) {
>
> But you need to fix sd_set_csd() too, else this is incomplete.
>
Ah yes, I missed that. Will fix in v2. Thanks for the review.
Regards,
Bin
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 08/18] hw/sd: sd: Correctly set the high capacity bit
@ 2020-08-16 8:54 ` Bin Meng
0 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-16 8:54 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel@nongnu.org Developers,
open list:RISC-V, Bin Meng, qemu-block
Hi Philippe,
On Sat, Aug 15, 2020 at 4:38 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> On 8/14/20 6:40 PM, Bin Meng wrote:
> > From: Bin Meng <bin.meng@windriver.com>
> >
> > Per the SD spec, Standard Capacity SD Memory Card (SDSC) supports
> > capacity up to and including 2 GiB.
> >
>
> Fixes: 2d7adea4fe ("hw/sd: Support SDHC size cards")
>
> > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > ---
> >
> > hw/sd/sd.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/hw/sd/sd.c b/hw/sd/sd.c
> > index 51f5900..5e7fc3f 100644
> > --- a/hw/sd/sd.c
> > +++ b/hw/sd/sd.c
> > @@ -313,7 +313,7 @@ static void sd_ocr_powerup(void *opaque)
> > /* card power-up OK */
> > sd->ocr = FIELD_DP32(sd->ocr, OCR, CARD_POWER_UP, 1);
> >
> > - if (sd->size > 1 * GiB) {
> > + if (sd->size > 2 * GiB) {
>
> But you need to fix sd_set_csd() too, else this is incomplete.
>
Ah yes, I missed that. Will fix in v2. Thanks for the review.
Regards,
Bin
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 13/18] hw/riscv: microchip_pfsoc: Connect a DMA controller
2020-08-15 9:00 ` Philippe Mathieu-Daudé
@ 2020-08-16 8:57 ` Bin Meng
0 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-16 8:57 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Bin Meng, open list:RISC-V, Sagar Karandikar, Bastian Koppelmann,
Palmer Dabbelt, qemu-devel@nongnu.org Developers,
Alistair Francis, Palmer Dabbelt
Hi Philippe,
On Sat, Aug 15, 2020 at 5:00 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> On 8/14/20 6:40 PM, Bin Meng wrote:
> > From: Bin Meng <bin.meng@windriver.com>
> >
> > Connect a DMA controller to Microchip PolarFire SoC. Note interrupt
> > has not been connected due to missing information in the manual how
> > interrupts are routed to PLIC.
> >
> > On the Icicle Kit board, the HSS firmware utilizes the on-chip DMA
> > controller to move the 2nd stage bootloader in the system memory.
> >
> > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > ---
> >
> > hw/riscv/Kconfig | 1 +
> > hw/riscv/microchip_pfsoc.c | 10 ++++++++++
> > include/hw/riscv/microchip_pfsoc.h | 3 +++
> > 3 files changed, 14 insertions(+)
> >
> > diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
> > index 7412db9..9323701 100644
> > --- a/hw/riscv/Kconfig
> > +++ b/hw/riscv/Kconfig
> > @@ -55,4 +55,5 @@ config MICROCHIP_PFSOC
> > select SIFIVE
> > select UNIMP
> > select MCHP_PFSOC_MMUART
> > + select MCHP_PFSOC_DMA
> > select CADENCE_SDHCI
> > diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
> > index 7c09078..1c67cbc 100644
> > --- a/hw/riscv/microchip_pfsoc.c
> > +++ b/hw/riscv/microchip_pfsoc.c
> > @@ -13,6 +13,7 @@
> > * 2) eNVM (Embedded Non-Volatile Memory)
> > * 3) MMUARTs (Multi-Mode UART)
> > * 4) Cadence eMMC/SDHC controller and an SD card connected to it
> > + * 5) DMA (Direct Memory Access Controller)
> > *
> > * This board currently generates devicetree dynamically that indicates at least
> > * two harts and up to five harts.
> > @@ -71,6 +72,7 @@ static const struct MemmapEntry {
> > [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 },
> > @@ -114,6 +116,9 @@ static void microchip_pfsoc_soc_instance_init(Object *obj)
> > TYPE_RISCV_CPU_SIFIVE_U54);
> > qdev_prop_set_uint64(DEVICE(&s->u_cpus), "resetvec", RESET_VECTOR);
> >
> > + object_initialize_child(obj, "dma-controller", &s->dma,
> > + TYPE_MCHP_PFSOC_DMA);
> > +
> > object_initialize_child(obj, "sd-controller", &s->sdhci,
> > TYPE_CADENCE_SDHCI);
>
> I haven't looked at the chip specs, but maybe you can add the SD
> controller after the DMA controller so so you can directly link
> a DMA address space to it.
>
I am not sure I understand what you meant about adding the SD
controller after the DMA controller. The Cadence SD controller has its
own built-in DMA and does not depend on this DMA controller.
Regards,
Bin
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 13/18] hw/riscv: microchip_pfsoc: Connect a DMA controller
@ 2020-08-16 8:57 ` Bin Meng
0 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-16 8:57 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel@nongnu.org Developers,
open list:RISC-V, Bin Meng, Palmer Dabbelt
Hi Philippe,
On Sat, Aug 15, 2020 at 5:00 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> On 8/14/20 6:40 PM, Bin Meng wrote:
> > From: Bin Meng <bin.meng@windriver.com>
> >
> > Connect a DMA controller to Microchip PolarFire SoC. Note interrupt
> > has not been connected due to missing information in the manual how
> > interrupts are routed to PLIC.
> >
> > On the Icicle Kit board, the HSS firmware utilizes the on-chip DMA
> > controller to move the 2nd stage bootloader in the system memory.
> >
> > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > ---
> >
> > hw/riscv/Kconfig | 1 +
> > hw/riscv/microchip_pfsoc.c | 10 ++++++++++
> > include/hw/riscv/microchip_pfsoc.h | 3 +++
> > 3 files changed, 14 insertions(+)
> >
> > diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
> > index 7412db9..9323701 100644
> > --- a/hw/riscv/Kconfig
> > +++ b/hw/riscv/Kconfig
> > @@ -55,4 +55,5 @@ config MICROCHIP_PFSOC
> > select SIFIVE
> > select UNIMP
> > select MCHP_PFSOC_MMUART
> > + select MCHP_PFSOC_DMA
> > select CADENCE_SDHCI
> > diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
> > index 7c09078..1c67cbc 100644
> > --- a/hw/riscv/microchip_pfsoc.c
> > +++ b/hw/riscv/microchip_pfsoc.c
> > @@ -13,6 +13,7 @@
> > * 2) eNVM (Embedded Non-Volatile Memory)
> > * 3) MMUARTs (Multi-Mode UART)
> > * 4) Cadence eMMC/SDHC controller and an SD card connected to it
> > + * 5) DMA (Direct Memory Access Controller)
> > *
> > * This board currently generates devicetree dynamically that indicates at least
> > * two harts and up to five harts.
> > @@ -71,6 +72,7 @@ static const struct MemmapEntry {
> > [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 },
> > @@ -114,6 +116,9 @@ static void microchip_pfsoc_soc_instance_init(Object *obj)
> > TYPE_RISCV_CPU_SIFIVE_U54);
> > qdev_prop_set_uint64(DEVICE(&s->u_cpus), "resetvec", RESET_VECTOR);
> >
> > + object_initialize_child(obj, "dma-controller", &s->dma,
> > + TYPE_MCHP_PFSOC_DMA);
> > +
> > object_initialize_child(obj, "sd-controller", &s->sdhci,
> > TYPE_CADENCE_SDHCI);
>
> I haven't looked at the chip specs, but maybe you can add the SD
> controller after the DMA controller so so you can directly link
> a DMA address space to it.
>
I am not sure I understand what you meant about adding the SD
controller after the DMA controller. The Cadence SD controller has its
own built-in DMA and does not depend on this DMA controller.
Regards,
Bin
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 09/18] hw/sd: sdhci: Make sdhci_poweron_reset() internal visible
2020-08-16 8:50 ` Bin Meng
(?)
@ 2020-08-16 11:06 ` Philippe Mathieu-Daudé
-1 siblings, 0 replies; 100+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-08-16 11:06 UTC (permalink / raw)
To: Bin Meng
Cc: Bin Meng, open list:RISC-V, qemu-block, Sagar Karandikar,
Bastian Koppelmann, Palmer Dabbelt,
qemu-devel@nongnu.org Developers, Alistair Francis
On 8/16/20 10:50 AM, Bin Meng wrote:
> Hi Philippe,
>
> On Sat, Aug 15, 2020 at 3:51 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>
>> On 8/14/20 6:40 PM, Bin Meng wrote:
>>> From: Bin Meng <bin.meng@windriver.com>
>>>
>>> sdhci_poweron_reset() might be needed for any SDHCI compatible
>>> device that is built on top of the generic SDHCI device.
>>
>> NAck. Please use device_legacy_reset() instead.
>>
>> In next patch:
>>
>> device_legacy_reset(DEVICE(&sdhci->slot));
>>
>
> The function comments say this API is deprecated.
>
> /**
> * device_legacy_reset:
> *
> * Reset a single device (by calling the reset method).
> * Note: This function is deprecated and will be removed when it becomes unused.
> * Please use device_cold_reset() now.
> */
>
> Should we use device_cold_reset() here?
Oops yes, certainly.
>
> Regards,
> Bin
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 13/18] hw/riscv: microchip_pfsoc: Connect a DMA controller
2020-08-16 8:57 ` Bin Meng
(?)
@ 2020-08-16 11:08 ` Philippe Mathieu-Daudé
-1 siblings, 0 replies; 100+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-08-16 11:08 UTC (permalink / raw)
To: Bin Meng
Cc: Bin Meng, open list:RISC-V, Sagar Karandikar, Bastian Koppelmann,
Palmer Dabbelt, qemu-devel@nongnu.org Developers,
Alistair Francis, Palmer Dabbelt
On 8/16/20 10:57 AM, Bin Meng wrote:
> Hi Philippe,
>
> On Sat, Aug 15, 2020 at 5:00 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>
>> On 8/14/20 6:40 PM, Bin Meng wrote:
>>> From: Bin Meng <bin.meng@windriver.com>
>>>
>>> Connect a DMA controller to Microchip PolarFire SoC. Note interrupt
>>> has not been connected due to missing information in the manual how
>>> interrupts are routed to PLIC.
>>>
>>> On the Icicle Kit board, the HSS firmware utilizes the on-chip DMA
>>> controller to move the 2nd stage bootloader in the system memory.
>>>
>>> Signed-off-by: Bin Meng <bin.meng@windriver.com>
>>> ---
>>>
>>> hw/riscv/Kconfig | 1 +
>>> hw/riscv/microchip_pfsoc.c | 10 ++++++++++
>>> include/hw/riscv/microchip_pfsoc.h | 3 +++
>>> 3 files changed, 14 insertions(+)
>>>
>>> diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
>>> index 7412db9..9323701 100644
>>> --- a/hw/riscv/Kconfig
>>> +++ b/hw/riscv/Kconfig
>>> @@ -55,4 +55,5 @@ config MICROCHIP_PFSOC
>>> select SIFIVE
>>> select UNIMP
>>> select MCHP_PFSOC_MMUART
>>> + select MCHP_PFSOC_DMA
>>> select CADENCE_SDHCI
>>> diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
>>> index 7c09078..1c67cbc 100644
>>> --- a/hw/riscv/microchip_pfsoc.c
>>> +++ b/hw/riscv/microchip_pfsoc.c
>>> @@ -13,6 +13,7 @@
>>> * 2) eNVM (Embedded Non-Volatile Memory)
>>> * 3) MMUARTs (Multi-Mode UART)
>>> * 4) Cadence eMMC/SDHC controller and an SD card connected to it
>>> + * 5) DMA (Direct Memory Access Controller)
>>> *
>>> * This board currently generates devicetree dynamically that indicates at least
>>> * two harts and up to five harts.
>>> @@ -71,6 +72,7 @@ static const struct MemmapEntry {
>>> [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 },
>>> @@ -114,6 +116,9 @@ static void microchip_pfsoc_soc_instance_init(Object *obj)
>>> TYPE_RISCV_CPU_SIFIVE_U54);
>>> qdev_prop_set_uint64(DEVICE(&s->u_cpus), "resetvec", RESET_VECTOR);
>>>
>>> + object_initialize_child(obj, "dma-controller", &s->dma,
>>> + TYPE_MCHP_PFSOC_DMA);
>>> +
>>> object_initialize_child(obj, "sd-controller", &s->sdhci,
>>> TYPE_CADENCE_SDHCI);
>>
>> I haven't looked at the chip specs, but maybe you can add the SD
>> controller after the DMA controller so so you can directly link
>> a DMA address space to it.
>>
>
> I am not sure I understand what you meant about adding the SD
> controller after the DMA controller. The Cadence SD controller has its
> own built-in DMA and does not depend on this DMA controller.
Ah OK. What I'm concerned about is the SD controller do its DMA
access in a proper DMA address space.
>
> Regards,
> Bin
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 14/18] hw/net: cadence_gem: Add a new 'phy-addr' property
2020-08-16 8:29 ` Bin Meng
@ 2020-08-16 11:14 ` Philippe Mathieu-Daudé
-1 siblings, 0 replies; 100+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-08-16 11:14 UTC (permalink / raw)
To: Bin Meng, John Linn, Peter A. G. Crosthwaite, Peter Crosthwaite,
Nathan Rossi
Cc: Peter Maydell, Alistair Francis, open list:RISC-V,
Sagar Karandikar, Bastian Koppelmann, Jason Wang, Bin Meng,
qemu-devel@nongnu.org Developers, qemu-arm, Alistair Francis,
Palmer Dabbelt
On 8/16/20 10:29 AM, Bin Meng wrote:
> On Sat, Aug 15, 2020 at 5:06 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>
>> On 8/14/20 6:40 PM, Bin Meng wrote:
>>> From: Bin Meng <bin.meng@windriver.com>
>>>
>>> At present the PHY address of the PHY connected to GEM is hard-coded
>>> to either 23 (BOARD_PHY_ADDRESS) or 0. This might not be the case for
>>> all boards. Add a new 'phy-addr' property so that board can specify
>>> the PHY address for each GEM instance.
>>>
>>> Signed-off-by: Bin Meng <bin.meng@windriver.com>
>>> ---
>>>
>>> hw/net/cadence_gem.c | 7 +++++--
>>> include/hw/net/cadence_gem.h | 2 ++
>>> 2 files changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
>>> index a93b5c0..9fa03de 100644
>>> --- a/hw/net/cadence_gem.c
>>> +++ b/hw/net/cadence_gem.c
>>> @@ -1446,7 +1446,8 @@ static uint64_t gem_read(void *opaque, hwaddr offset, unsigned size)
>>> uint32_t phy_addr, reg_num;
>>>
>>> phy_addr = (retval & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
>>> - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
>>> + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
>>> + phy_addr == s->phy_addr) {
>>> reg_num = (retval & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
>>> retval &= 0xFFFF0000;
>>> retval |= gem_phy_read(s, reg_num);
>>> @@ -1569,7 +1570,8 @@ static void gem_write(void *opaque, hwaddr offset, uint64_t val,
>>> uint32_t phy_addr, reg_num;
>>>
>>> phy_addr = (val & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
>>> - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
>>> + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
>>> + phy_addr == s->phy_addr) {
>>> reg_num = (val & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
>>> gem_phy_write(s, reg_num, val);
>>> }
>>> @@ -1682,6 +1684,7 @@ static Property gem_properties[] = {
>>> DEFINE_NIC_PROPERTIES(CadenceGEMState, conf),
>>> DEFINE_PROP_UINT32("revision", CadenceGEMState, revision,
>>> GEM_MODID_VALUE),
>>> + DEFINE_PROP_UINT8("phy-addr", CadenceGEMState, phy_addr, 0),
>>
>> This patch would be complete by moving the BOARD_PHY_ADDRESS definition
>> to each board using this NIC, and setting the "phy-addr" property to
>> this value.
>
> I actually have no idea which board in QEMU is using this special PHY
> address instead of default 0.
It seems safe to assume all do use address 23.
Anyway you can simply get ride of BOARD_PHY_ADDRESS in the read/write
using:
DEFINE_PROP_UINT8("phy-addr", CadenceGEMState,
phy_addr, BOARD_PHY_ADDRESS),
>
> It looks BOARD_PHY_ADDRESS has been there since the initial version of
> the cadence_gem model.
>
> commit e9f186e514a70557d695cadd2c2287ef97737023
> Author: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
> Date: Mon Mar 5 14:39:12 2012 +1000
>
> cadence_gem: initial version of device model
>
> Device model for cadence gem ethernet controller.
>
> Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
> Signed-off-by: John Linn <john.linn@xilinx.com>
> Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
>
> Later PHY address 0 was added via the following commit:
>
> commit 553893736885e4f2dda424bff3e2200e1b6482a5
> Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
> Date: Thu Apr 3 23:55:19 2014 -0700
>
> net: cadence_gem: Make phy respond to broadcast
>
> Phys must respond to address 0 by specification. Implement.
>
> Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
> Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
> Message-id:
> 6f4d53b04ddbfb19895bfb61a595e69f1c08859a.1396594056.git.peter.crosthwaite@xilinx.com
> Reviewed-by: Beniamino Galvani <b.galvani@gmail.com>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
>
> I doubt the commit message said that PHYs must respond to address 0. I
> am not aware of such specs. The issue was probably that whatever board
> 2nd commit was tested against did not have a PHY at address
> BOARD_PHY_ADDRESS.
>
> + a couple of Xilinx folks to comment.
>
>>
>>> DEFINE_PROP_UINT8("num-priority-queues", CadenceGEMState,
>>> num_priority_queues, 1),
>>> DEFINE_PROP_UINT8("num-type1-screeners", CadenceGEMState,
>>> diff --git a/include/hw/net/cadence_gem.h b/include/hw/net/cadence_gem.h
>>> index 54e646f..01c6189 100644
>>> --- a/include/hw/net/cadence_gem.h
>>> +++ b/include/hw/net/cadence_gem.h
>>> @@ -73,6 +73,8 @@ typedef struct CadenceGEMState {
>>> /* Mask of register bits which are write 1 to clear */
>>> uint32_t regs_w1c[CADENCE_GEM_MAXREG];
>>>
>>> + /* PHY address */
>>> + uint8_t phy_addr;
>>> /* PHY registers backing store */
>>> uint16_t phy_regs[32];
>
> Regards,
> Bin
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 14/18] hw/net: cadence_gem: Add a new 'phy-addr' property
@ 2020-08-16 11:14 ` Philippe Mathieu-Daudé
0 siblings, 0 replies; 100+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-08-16 11:14 UTC (permalink / raw)
To: Bin Meng, John Linn, Peter A. G. Crosthwaite, Peter Crosthwaite,
Nathan Rossi
Cc: Peter Maydell, Alistair Francis, open list:RISC-V,
Sagar Karandikar, Bin Meng, Bastian Koppelmann, Jason Wang,
Palmer Dabbelt, qemu-devel@nongnu.org Developers, qemu-arm,
Alistair Francis
On 8/16/20 10:29 AM, Bin Meng wrote:
> On Sat, Aug 15, 2020 at 5:06 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>
>> On 8/14/20 6:40 PM, Bin Meng wrote:
>>> From: Bin Meng <bin.meng@windriver.com>
>>>
>>> At present the PHY address of the PHY connected to GEM is hard-coded
>>> to either 23 (BOARD_PHY_ADDRESS) or 0. This might not be the case for
>>> all boards. Add a new 'phy-addr' property so that board can specify
>>> the PHY address for each GEM instance.
>>>
>>> Signed-off-by: Bin Meng <bin.meng@windriver.com>
>>> ---
>>>
>>> hw/net/cadence_gem.c | 7 +++++--
>>> include/hw/net/cadence_gem.h | 2 ++
>>> 2 files changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
>>> index a93b5c0..9fa03de 100644
>>> --- a/hw/net/cadence_gem.c
>>> +++ b/hw/net/cadence_gem.c
>>> @@ -1446,7 +1446,8 @@ static uint64_t gem_read(void *opaque, hwaddr offset, unsigned size)
>>> uint32_t phy_addr, reg_num;
>>>
>>> phy_addr = (retval & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
>>> - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
>>> + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
>>> + phy_addr == s->phy_addr) {
>>> reg_num = (retval & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
>>> retval &= 0xFFFF0000;
>>> retval |= gem_phy_read(s, reg_num);
>>> @@ -1569,7 +1570,8 @@ static void gem_write(void *opaque, hwaddr offset, uint64_t val,
>>> uint32_t phy_addr, reg_num;
>>>
>>> phy_addr = (val & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
>>> - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
>>> + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
>>> + phy_addr == s->phy_addr) {
>>> reg_num = (val & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
>>> gem_phy_write(s, reg_num, val);
>>> }
>>> @@ -1682,6 +1684,7 @@ static Property gem_properties[] = {
>>> DEFINE_NIC_PROPERTIES(CadenceGEMState, conf),
>>> DEFINE_PROP_UINT32("revision", CadenceGEMState, revision,
>>> GEM_MODID_VALUE),
>>> + DEFINE_PROP_UINT8("phy-addr", CadenceGEMState, phy_addr, 0),
>>
>> This patch would be complete by moving the BOARD_PHY_ADDRESS definition
>> to each board using this NIC, and setting the "phy-addr" property to
>> this value.
>
> I actually have no idea which board in QEMU is using this special PHY
> address instead of default 0.
It seems safe to assume all do use address 23.
Anyway you can simply get ride of BOARD_PHY_ADDRESS in the read/write
using:
DEFINE_PROP_UINT8("phy-addr", CadenceGEMState,
phy_addr, BOARD_PHY_ADDRESS),
>
> It looks BOARD_PHY_ADDRESS has been there since the initial version of
> the cadence_gem model.
>
> commit e9f186e514a70557d695cadd2c2287ef97737023
> Author: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
> Date: Mon Mar 5 14:39:12 2012 +1000
>
> cadence_gem: initial version of device model
>
> Device model for cadence gem ethernet controller.
>
> Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
> Signed-off-by: John Linn <john.linn@xilinx.com>
> Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
>
> Later PHY address 0 was added via the following commit:
>
> commit 553893736885e4f2dda424bff3e2200e1b6482a5
> Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
> Date: Thu Apr 3 23:55:19 2014 -0700
>
> net: cadence_gem: Make phy respond to broadcast
>
> Phys must respond to address 0 by specification. Implement.
>
> Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
> Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
> Message-id:
> 6f4d53b04ddbfb19895bfb61a595e69f1c08859a.1396594056.git.peter.crosthwaite@xilinx.com
> Reviewed-by: Beniamino Galvani <b.galvani@gmail.com>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
>
> I doubt the commit message said that PHYs must respond to address 0. I
> am not aware of such specs. The issue was probably that whatever board
> 2nd commit was tested against did not have a PHY at address
> BOARD_PHY_ADDRESS.
>
> + a couple of Xilinx folks to comment.
>
>>
>>> DEFINE_PROP_UINT8("num-priority-queues", CadenceGEMState,
>>> num_priority_queues, 1),
>>> DEFINE_PROP_UINT8("num-type1-screeners", CadenceGEMState,
>>> diff --git a/include/hw/net/cadence_gem.h b/include/hw/net/cadence_gem.h
>>> index 54e646f..01c6189 100644
>>> --- a/include/hw/net/cadence_gem.h
>>> +++ b/include/hw/net/cadence_gem.h
>>> @@ -73,6 +73,8 @@ typedef struct CadenceGEMState {
>>> /* Mask of register bits which are write 1 to clear */
>>> uint32_t regs_w1c[CADENCE_GEM_MAXREG];
>>>
>>> + /* PHY address */
>>> + uint8_t phy_addr;
>>> /* PHY registers backing store */
>>> uint16_t phy_regs[32];
>
> Regards,
> Bin
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 14/18] hw/net: cadence_gem: Add a new 'phy-addr' property
2020-08-16 8:29 ` Bin Meng
@ 2020-08-16 12:08 ` Nathan Rossi
-1 siblings, 0 replies; 100+ messages in thread
From: Nathan Rossi @ 2020-08-16 12:08 UTC (permalink / raw)
To: Bin Meng
Cc: Peter Maydell, Peter Crosthwaite, Alistair Francis,
open list:RISC-V, Sagar Karandikar, Bin Meng, Bastian Koppelmann,
Jason Wang, Palmer Dabbelt, Philippe Mathieu-Daudé,
qemu-devel@nongnu.org Developers, Peter A. G. Crosthwaite,
qemu-arm, Alistair Francis, Edgar E. Iglesias, John Linn
On Sun, 16 Aug 2020 at 18:29, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> On Sat, Aug 15, 2020 at 5:06 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> >
> > On 8/14/20 6:40 PM, Bin Meng wrote:
> > > From: Bin Meng <bin.meng@windriver.com>
> > >
> > > At present the PHY address of the PHY connected to GEM is hard-coded
> > > to either 23 (BOARD_PHY_ADDRESS) or 0. This might not be the case for
> > > all boards. Add a new 'phy-addr' property so that board can specify
> > > the PHY address for each GEM instance.
> > >
> > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > ---
> > >
> > > hw/net/cadence_gem.c | 7 +++++--
> > > include/hw/net/cadence_gem.h | 2 ++
> > > 2 files changed, 7 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
> > > index a93b5c0..9fa03de 100644
> > > --- a/hw/net/cadence_gem.c
> > > +++ b/hw/net/cadence_gem.c
> > > @@ -1446,7 +1446,8 @@ static uint64_t gem_read(void *opaque, hwaddr offset, unsigned size)
> > > uint32_t phy_addr, reg_num;
> > >
> > > phy_addr = (retval & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
> > > - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
> > > + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
> > > + phy_addr == s->phy_addr) {
> > > reg_num = (retval & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
> > > retval &= 0xFFFF0000;
> > > retval |= gem_phy_read(s, reg_num);
> > > @@ -1569,7 +1570,8 @@ static void gem_write(void *opaque, hwaddr offset, uint64_t val,
> > > uint32_t phy_addr, reg_num;
> > >
> > > phy_addr = (val & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
> > > - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
> > > + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
> > > + phy_addr == s->phy_addr) {
> > > reg_num = (val & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
> > > gem_phy_write(s, reg_num, val);
> > > }
> > > @@ -1682,6 +1684,7 @@ static Property gem_properties[] = {
> > > DEFINE_NIC_PROPERTIES(CadenceGEMState, conf),
> > > DEFINE_PROP_UINT32("revision", CadenceGEMState, revision,
> > > GEM_MODID_VALUE),
> > > + DEFINE_PROP_UINT8("phy-addr", CadenceGEMState, phy_addr, 0),
> >
> > This patch would be complete by moving the BOARD_PHY_ADDRESS definition
> > to each board using this NIC, and setting the "phy-addr" property to
> > this value.
>
> I actually have no idea which board in QEMU is using this special PHY
> address instead of default 0.
Given Xilinx's QEMU fork has not used this value for quite some time,
I suspect it was only used to match an early chip emulation
platform/board.
https://github.com/Xilinx/qemu/blame/master/hw/net/cadence_gem.c#L248
>
> It looks BOARD_PHY_ADDRESS has been there since the initial version of
> the cadence_gem model.
>
> commit e9f186e514a70557d695cadd2c2287ef97737023
> Author: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
> Date: Mon Mar 5 14:39:12 2012 +1000
>
> cadence_gem: initial version of device model
>
> Device model for cadence gem ethernet controller.
>
> Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
> Signed-off-by: John Linn <john.linn@xilinx.com>
> Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
>
> Later PHY address 0 was added via the following commit:
>
> commit 553893736885e4f2dda424bff3e2200e1b6482a5
> Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
> Date: Thu Apr 3 23:55:19 2014 -0700
>
> net: cadence_gem: Make phy respond to broadcast
>
> Phys must respond to address 0 by specification. Implement.
>
> Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
> Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
> Message-id:
> 6f4d53b04ddbfb19895bfb61a595e69f1c08859a.1396594056.git.peter.crosthwaite@xilinx.com
> Reviewed-by: Beniamino Galvani <b.galvani@gmail.com>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
>
> I doubt the commit message said that PHYs must respond to address 0. I
> am not aware of such specs. The issue was probably that whatever board
> 2nd commit was tested against did not have a PHY at address
> BOARD_PHY_ADDRESS.
It is common for phy devices to support it as a broadcast address. It
is also commonly written in Xilinx documentation that it is treated as
a broadcast address. e.g. the axi ethernet core
(https://www.xilinx.com/support/documentation/ip_documentation/axi_ethernet/v7_0/pg138-axi-ethernet.pdf
page 45). But 802.3 does not require it, instead address 0 is only
reserved.
With this commit the "must" refers to the device specification, in
that QEMU is emulating a real phy (though more specifically the phy(s)
that were being emulated for Zynq boards) that does respond to address
0 as a broadcast. This change was a trade off in order to make QEMU
behave as it would on hardware, such that software using address 0 as
broadcast would work correctly.
Regards,
Nathan
>
> + a couple of Xilinx folks to comment.
>
> >
> > > DEFINE_PROP_UINT8("num-priority-queues", CadenceGEMState,
> > > num_priority_queues, 1),
> > > DEFINE_PROP_UINT8("num-type1-screeners", CadenceGEMState,
> > > diff --git a/include/hw/net/cadence_gem.h b/include/hw/net/cadence_gem.h
> > > index 54e646f..01c6189 100644
> > > --- a/include/hw/net/cadence_gem.h
> > > +++ b/include/hw/net/cadence_gem.h
> > > @@ -73,6 +73,8 @@ typedef struct CadenceGEMState {
> > > /* Mask of register bits which are write 1 to clear */
> > > uint32_t regs_w1c[CADENCE_GEM_MAXREG];
> > >
> > > + /* PHY address */
> > > + uint8_t phy_addr;
> > > /* PHY registers backing store */
> > > uint16_t phy_regs[32];
>
> Regards,
> Bin
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 14/18] hw/net: cadence_gem: Add a new 'phy-addr' property
@ 2020-08-16 12:08 ` Nathan Rossi
0 siblings, 0 replies; 100+ messages in thread
From: Nathan Rossi @ 2020-08-16 12:08 UTC (permalink / raw)
To: Bin Meng
Cc: Philippe Mathieu-Daudé,
John Linn, Peter A. G. Crosthwaite, Peter Crosthwaite,
Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel@nongnu.org Developers,
open list:RISC-V, Peter Maydell, Alistair Francis, Jason Wang,
Bin Meng, qemu-arm, Edgar E. Iglesias
On Sun, 16 Aug 2020 at 18:29, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> On Sat, Aug 15, 2020 at 5:06 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> >
> > On 8/14/20 6:40 PM, Bin Meng wrote:
> > > From: Bin Meng <bin.meng@windriver.com>
> > >
> > > At present the PHY address of the PHY connected to GEM is hard-coded
> > > to either 23 (BOARD_PHY_ADDRESS) or 0. This might not be the case for
> > > all boards. Add a new 'phy-addr' property so that board can specify
> > > the PHY address for each GEM instance.
> > >
> > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > ---
> > >
> > > hw/net/cadence_gem.c | 7 +++++--
> > > include/hw/net/cadence_gem.h | 2 ++
> > > 2 files changed, 7 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
> > > index a93b5c0..9fa03de 100644
> > > --- a/hw/net/cadence_gem.c
> > > +++ b/hw/net/cadence_gem.c
> > > @@ -1446,7 +1446,8 @@ static uint64_t gem_read(void *opaque, hwaddr offset, unsigned size)
> > > uint32_t phy_addr, reg_num;
> > >
> > > phy_addr = (retval & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
> > > - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
> > > + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
> > > + phy_addr == s->phy_addr) {
> > > reg_num = (retval & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
> > > retval &= 0xFFFF0000;
> > > retval |= gem_phy_read(s, reg_num);
> > > @@ -1569,7 +1570,8 @@ static void gem_write(void *opaque, hwaddr offset, uint64_t val,
> > > uint32_t phy_addr, reg_num;
> > >
> > > phy_addr = (val & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
> > > - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
> > > + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
> > > + phy_addr == s->phy_addr) {
> > > reg_num = (val & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
> > > gem_phy_write(s, reg_num, val);
> > > }
> > > @@ -1682,6 +1684,7 @@ static Property gem_properties[] = {
> > > DEFINE_NIC_PROPERTIES(CadenceGEMState, conf),
> > > DEFINE_PROP_UINT32("revision", CadenceGEMState, revision,
> > > GEM_MODID_VALUE),
> > > + DEFINE_PROP_UINT8("phy-addr", CadenceGEMState, phy_addr, 0),
> >
> > This patch would be complete by moving the BOARD_PHY_ADDRESS definition
> > to each board using this NIC, and setting the "phy-addr" property to
> > this value.
>
> I actually have no idea which board in QEMU is using this special PHY
> address instead of default 0.
Given Xilinx's QEMU fork has not used this value for quite some time,
I suspect it was only used to match an early chip emulation
platform/board.
https://github.com/Xilinx/qemu/blame/master/hw/net/cadence_gem.c#L248
>
> It looks BOARD_PHY_ADDRESS has been there since the initial version of
> the cadence_gem model.
>
> commit e9f186e514a70557d695cadd2c2287ef97737023
> Author: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
> Date: Mon Mar 5 14:39:12 2012 +1000
>
> cadence_gem: initial version of device model
>
> Device model for cadence gem ethernet controller.
>
> Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
> Signed-off-by: John Linn <john.linn@xilinx.com>
> Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
>
> Later PHY address 0 was added via the following commit:
>
> commit 553893736885e4f2dda424bff3e2200e1b6482a5
> Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
> Date: Thu Apr 3 23:55:19 2014 -0700
>
> net: cadence_gem: Make phy respond to broadcast
>
> Phys must respond to address 0 by specification. Implement.
>
> Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
> Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
> Message-id:
> 6f4d53b04ddbfb19895bfb61a595e69f1c08859a.1396594056.git.peter.crosthwaite@xilinx.com
> Reviewed-by: Beniamino Galvani <b.galvani@gmail.com>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
>
> I doubt the commit message said that PHYs must respond to address 0. I
> am not aware of such specs. The issue was probably that whatever board
> 2nd commit was tested against did not have a PHY at address
> BOARD_PHY_ADDRESS.
It is common for phy devices to support it as a broadcast address. It
is also commonly written in Xilinx documentation that it is treated as
a broadcast address. e.g. the axi ethernet core
(https://www.xilinx.com/support/documentation/ip_documentation/axi_ethernet/v7_0/pg138-axi-ethernet.pdf
page 45). But 802.3 does not require it, instead address 0 is only
reserved.
With this commit the "must" refers to the device specification, in
that QEMU is emulating a real phy (though more specifically the phy(s)
that were being emulated for Zynq boards) that does respond to address
0 as a broadcast. This change was a trade off in order to make QEMU
behave as it would on hardware, such that software using address 0 as
broadcast would work correctly.
Regards,
Nathan
>
> + a couple of Xilinx folks to comment.
>
> >
> > > DEFINE_PROP_UINT8("num-priority-queues", CadenceGEMState,
> > > num_priority_queues, 1),
> > > DEFINE_PROP_UINT8("num-type1-screeners", CadenceGEMState,
> > > diff --git a/include/hw/net/cadence_gem.h b/include/hw/net/cadence_gem.h
> > > index 54e646f..01c6189 100644
> > > --- a/include/hw/net/cadence_gem.h
> > > +++ b/include/hw/net/cadence_gem.h
> > > @@ -73,6 +73,8 @@ typedef struct CadenceGEMState {
> > > /* Mask of register bits which are write 1 to clear */
> > > uint32_t regs_w1c[CADENCE_GEM_MAXREG];
> > >
> > > + /* PHY address */
> > > + uint8_t phy_addr;
> > > /* PHY registers backing store */
> > > uint16_t phy_regs[32];
>
> Regards,
> Bin
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 14/18] hw/net: cadence_gem: Add a new 'phy-addr' property
2020-08-16 12:08 ` Nathan Rossi
@ 2020-08-16 13:42 ` Bin Meng
-1 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-16 13:42 UTC (permalink / raw)
To: Nathan Rossi
Cc: Peter Maydell, Peter Crosthwaite, Alistair Francis,
open list:RISC-V, Sagar Karandikar, Bin Meng, Bastian Koppelmann,
Jason Wang, Palmer Dabbelt, Philippe Mathieu-Daudé,
qemu-devel@nongnu.org Developers, Peter A. G. Crosthwaite,
qemu-arm, Alistair Francis, Edgar E. Iglesias, John Linn
On Sun, Aug 16, 2020 at 8:08 PM Nathan Rossi <nathan@nathanrossi.com> wrote:
>
> On Sun, 16 Aug 2020 at 18:29, Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > On Sat, Aug 15, 2020 at 5:06 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> > >
> > > On 8/14/20 6:40 PM, Bin Meng wrote:
> > > > From: Bin Meng <bin.meng@windriver.com>
> > > >
> > > > At present the PHY address of the PHY connected to GEM is hard-coded
> > > > to either 23 (BOARD_PHY_ADDRESS) or 0. This might not be the case for
> > > > all boards. Add a new 'phy-addr' property so that board can specify
> > > > the PHY address for each GEM instance.
> > > >
> > > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > > ---
> > > >
> > > > hw/net/cadence_gem.c | 7 +++++--
> > > > include/hw/net/cadence_gem.h | 2 ++
> > > > 2 files changed, 7 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
> > > > index a93b5c0..9fa03de 100644
> > > > --- a/hw/net/cadence_gem.c
> > > > +++ b/hw/net/cadence_gem.c
> > > > @@ -1446,7 +1446,8 @@ static uint64_t gem_read(void *opaque, hwaddr offset, unsigned size)
> > > > uint32_t phy_addr, reg_num;
> > > >
> > > > phy_addr = (retval & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
> > > > - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
> > > > + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
> > > > + phy_addr == s->phy_addr) {
> > > > reg_num = (retval & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
> > > > retval &= 0xFFFF0000;
> > > > retval |= gem_phy_read(s, reg_num);
> > > > @@ -1569,7 +1570,8 @@ static void gem_write(void *opaque, hwaddr offset, uint64_t val,
> > > > uint32_t phy_addr, reg_num;
> > > >
> > > > phy_addr = (val & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
> > > > - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
> > > > + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
> > > > + phy_addr == s->phy_addr) {
> > > > reg_num = (val & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
> > > > gem_phy_write(s, reg_num, val);
> > > > }
> > > > @@ -1682,6 +1684,7 @@ static Property gem_properties[] = {
> > > > DEFINE_NIC_PROPERTIES(CadenceGEMState, conf),
> > > > DEFINE_PROP_UINT32("revision", CadenceGEMState, revision,
> > > > GEM_MODID_VALUE),
> > > > + DEFINE_PROP_UINT8("phy-addr", CadenceGEMState, phy_addr, 0),
> > >
> > > This patch would be complete by moving the BOARD_PHY_ADDRESS definition
> > > to each board using this NIC, and setting the "phy-addr" property to
> > > this value.
> >
> > I actually have no idea which board in QEMU is using this special PHY
> > address instead of default 0.
>
> Given Xilinx's QEMU fork has not used this value for quite some time,
> I suspect it was only used to match an early chip emulation
> platform/board.
>
> https://github.com/Xilinx/qemu/blame/master/hw/net/cadence_gem.c#L248
>
> >
> > It looks BOARD_PHY_ADDRESS has been there since the initial version of
> > the cadence_gem model.
> >
> > commit e9f186e514a70557d695cadd2c2287ef97737023
> > Author: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
> > Date: Mon Mar 5 14:39:12 2012 +1000
> >
> > cadence_gem: initial version of device model
> >
> > Device model for cadence gem ethernet controller.
> >
> > Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
> > Signed-off-by: John Linn <john.linn@xilinx.com>
> > Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
> > Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
> >
> > Later PHY address 0 was added via the following commit:
> >
> > commit 553893736885e4f2dda424bff3e2200e1b6482a5
> > Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
> > Date: Thu Apr 3 23:55:19 2014 -0700
> >
> > net: cadence_gem: Make phy respond to broadcast
> >
> > Phys must respond to address 0 by specification. Implement.
> >
> > Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
> > Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
> > Message-id:
> > 6f4d53b04ddbfb19895bfb61a595e69f1c08859a.1396594056.git.peter.crosthwaite@xilinx.com
> > Reviewed-by: Beniamino Galvani <b.galvani@gmail.com>
> > Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> >
> > I doubt the commit message said that PHYs must respond to address 0. I
> > am not aware of such specs. The issue was probably that whatever board
> > 2nd commit was tested against did not have a PHY at address
> > BOARD_PHY_ADDRESS.
>
> It is common for phy devices to support it as a broadcast address. It
> is also commonly written in Xilinx documentation that it is treated as
> a broadcast address. e.g. the axi ethernet core
> (https://www.xilinx.com/support/documentation/ip_documentation/axi_ethernet/v7_0/pg138-axi-ethernet.pdf
> page 45). But 802.3 does not require it, instead address 0 is only
> reserved.
>
> With this commit the "must" refers to the device specification, in
> that QEMU is emulating a real phy (though more specifically the phy(s)
> that were being emulated for Zynq boards) that does respond to address
> 0 as a broadcast. This change was a trade off in order to make QEMU
> behave as it would on hardware, such that software using address 0 as
> broadcast would work correctly.
>
Thanks Nathan. So is it safe to just remove BOARD_PHY_ADDRESS and set
"phy-addr" property default value to 0?
Regards,
Bin
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 14/18] hw/net: cadence_gem: Add a new 'phy-addr' property
@ 2020-08-16 13:42 ` Bin Meng
0 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-16 13:42 UTC (permalink / raw)
To: Nathan Rossi
Cc: Philippe Mathieu-Daudé,
John Linn, Peter A. G. Crosthwaite, Peter Crosthwaite,
Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel@nongnu.org Developers,
open list:RISC-V, Peter Maydell, Alistair Francis, Jason Wang,
Bin Meng, qemu-arm, Edgar E. Iglesias
On Sun, Aug 16, 2020 at 8:08 PM Nathan Rossi <nathan@nathanrossi.com> wrote:
>
> On Sun, 16 Aug 2020 at 18:29, Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > On Sat, Aug 15, 2020 at 5:06 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> > >
> > > On 8/14/20 6:40 PM, Bin Meng wrote:
> > > > From: Bin Meng <bin.meng@windriver.com>
> > > >
> > > > At present the PHY address of the PHY connected to GEM is hard-coded
> > > > to either 23 (BOARD_PHY_ADDRESS) or 0. This might not be the case for
> > > > all boards. Add a new 'phy-addr' property so that board can specify
> > > > the PHY address for each GEM instance.
> > > >
> > > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > > ---
> > > >
> > > > hw/net/cadence_gem.c | 7 +++++--
> > > > include/hw/net/cadence_gem.h | 2 ++
> > > > 2 files changed, 7 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
> > > > index a93b5c0..9fa03de 100644
> > > > --- a/hw/net/cadence_gem.c
> > > > +++ b/hw/net/cadence_gem.c
> > > > @@ -1446,7 +1446,8 @@ static uint64_t gem_read(void *opaque, hwaddr offset, unsigned size)
> > > > uint32_t phy_addr, reg_num;
> > > >
> > > > phy_addr = (retval & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
> > > > - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
> > > > + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
> > > > + phy_addr == s->phy_addr) {
> > > > reg_num = (retval & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
> > > > retval &= 0xFFFF0000;
> > > > retval |= gem_phy_read(s, reg_num);
> > > > @@ -1569,7 +1570,8 @@ static void gem_write(void *opaque, hwaddr offset, uint64_t val,
> > > > uint32_t phy_addr, reg_num;
> > > >
> > > > phy_addr = (val & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
> > > > - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
> > > > + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
> > > > + phy_addr == s->phy_addr) {
> > > > reg_num = (val & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
> > > > gem_phy_write(s, reg_num, val);
> > > > }
> > > > @@ -1682,6 +1684,7 @@ static Property gem_properties[] = {
> > > > DEFINE_NIC_PROPERTIES(CadenceGEMState, conf),
> > > > DEFINE_PROP_UINT32("revision", CadenceGEMState, revision,
> > > > GEM_MODID_VALUE),
> > > > + DEFINE_PROP_UINT8("phy-addr", CadenceGEMState, phy_addr, 0),
> > >
> > > This patch would be complete by moving the BOARD_PHY_ADDRESS definition
> > > to each board using this NIC, and setting the "phy-addr" property to
> > > this value.
> >
> > I actually have no idea which board in QEMU is using this special PHY
> > address instead of default 0.
>
> Given Xilinx's QEMU fork has not used this value for quite some time,
> I suspect it was only used to match an early chip emulation
> platform/board.
>
> https://github.com/Xilinx/qemu/blame/master/hw/net/cadence_gem.c#L248
>
> >
> > It looks BOARD_PHY_ADDRESS has been there since the initial version of
> > the cadence_gem model.
> >
> > commit e9f186e514a70557d695cadd2c2287ef97737023
> > Author: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
> > Date: Mon Mar 5 14:39:12 2012 +1000
> >
> > cadence_gem: initial version of device model
> >
> > Device model for cadence gem ethernet controller.
> >
> > Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
> > Signed-off-by: John Linn <john.linn@xilinx.com>
> > Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
> > Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
> >
> > Later PHY address 0 was added via the following commit:
> >
> > commit 553893736885e4f2dda424bff3e2200e1b6482a5
> > Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
> > Date: Thu Apr 3 23:55:19 2014 -0700
> >
> > net: cadence_gem: Make phy respond to broadcast
> >
> > Phys must respond to address 0 by specification. Implement.
> >
> > Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
> > Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
> > Message-id:
> > 6f4d53b04ddbfb19895bfb61a595e69f1c08859a.1396594056.git.peter.crosthwaite@xilinx.com
> > Reviewed-by: Beniamino Galvani <b.galvani@gmail.com>
> > Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> >
> > I doubt the commit message said that PHYs must respond to address 0. I
> > am not aware of such specs. The issue was probably that whatever board
> > 2nd commit was tested against did not have a PHY at address
> > BOARD_PHY_ADDRESS.
>
> It is common for phy devices to support it as a broadcast address. It
> is also commonly written in Xilinx documentation that it is treated as
> a broadcast address. e.g. the axi ethernet core
> (https://www.xilinx.com/support/documentation/ip_documentation/axi_ethernet/v7_0/pg138-axi-ethernet.pdf
> page 45). But 802.3 does not require it, instead address 0 is only
> reserved.
>
> With this commit the "must" refers to the device specification, in
> that QEMU is emulating a real phy (though more specifically the phy(s)
> that were being emulated for Zynq boards) that does respond to address
> 0 as a broadcast. This change was a trade off in order to make QEMU
> behave as it would on hardware, such that software using address 0 as
> broadcast would work correctly.
>
Thanks Nathan. So is it safe to just remove BOARD_PHY_ADDRESS and set
"phy-addr" property default value to 0?
Regards,
Bin
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 14/18] hw/net: cadence_gem: Add a new 'phy-addr' property
2020-08-16 13:42 ` Bin Meng
@ 2020-08-16 16:31 ` Philippe Mathieu-Daudé
-1 siblings, 0 replies; 100+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-08-16 16:31 UTC (permalink / raw)
To: Bin Meng, Nathan Rossi
Cc: Peter Maydell, Peter Crosthwaite, Alistair Francis,
open list:RISC-V, Sagar Karandikar, Bastian Koppelmann,
Jason Wang, Bin Meng, qemu-devel@nongnu.org Developers,
Peter A. G. Crosthwaite, qemu-arm, Alistair Francis,
Palmer Dabbelt, John Linn
On 8/16/20 3:42 PM, Bin Meng wrote:
> On Sun, Aug 16, 2020 at 8:08 PM Nathan Rossi <nathan@nathanrossi.com> wrote:
>>
>> On Sun, 16 Aug 2020 at 18:29, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>
>>> On Sat, Aug 15, 2020 at 5:06 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>>>
>>>> On 8/14/20 6:40 PM, Bin Meng wrote:
>>>>> From: Bin Meng <bin.meng@windriver.com>
>>>>>
>>>>> At present the PHY address of the PHY connected to GEM is hard-coded
>>>>> to either 23 (BOARD_PHY_ADDRESS) or 0. This might not be the case for
>>>>> all boards. Add a new 'phy-addr' property so that board can specify
>>>>> the PHY address for each GEM instance.
>>>>>
>>>>> Signed-off-by: Bin Meng <bin.meng@windriver.com>
>>>>> ---
>>>>>
>>>>> hw/net/cadence_gem.c | 7 +++++--
>>>>> include/hw/net/cadence_gem.h | 2 ++
>>>>> 2 files changed, 7 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
>>>>> index a93b5c0..9fa03de 100644
>>>>> --- a/hw/net/cadence_gem.c
>>>>> +++ b/hw/net/cadence_gem.c
>>>>> @@ -1446,7 +1446,8 @@ static uint64_t gem_read(void *opaque, hwaddr offset, unsigned size)
>>>>> uint32_t phy_addr, reg_num;
>>>>>
>>>>> phy_addr = (retval & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
>>>>> - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
>>>>> + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
>>>>> + phy_addr == s->phy_addr) {
>>>>> reg_num = (retval & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
>>>>> retval &= 0xFFFF0000;
>>>>> retval |= gem_phy_read(s, reg_num);
>>>>> @@ -1569,7 +1570,8 @@ static void gem_write(void *opaque, hwaddr offset, uint64_t val,
>>>>> uint32_t phy_addr, reg_num;
>>>>>
>>>>> phy_addr = (val & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
>>>>> - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
>>>>> + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
>>>>> + phy_addr == s->phy_addr) {
>>>>> reg_num = (val & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
>>>>> gem_phy_write(s, reg_num, val);
>>>>> }
>>>>> @@ -1682,6 +1684,7 @@ static Property gem_properties[] = {
>>>>> DEFINE_NIC_PROPERTIES(CadenceGEMState, conf),
>>>>> DEFINE_PROP_UINT32("revision", CadenceGEMState, revision,
>>>>> GEM_MODID_VALUE),
>>>>> + DEFINE_PROP_UINT8("phy-addr", CadenceGEMState, phy_addr, 0),
>>>>
>>>> This patch would be complete by moving the BOARD_PHY_ADDRESS definition
>>>> to each board using this NIC, and setting the "phy-addr" property to
>>>> this value.
>>>
>>> I actually have no idea which board in QEMU is using this special PHY
>>> address instead of default 0.
>>
>> Given Xilinx's QEMU fork has not used this value for quite some time,
>> I suspect it was only used to match an early chip emulation
>> platform/board.
>>
>> https://github.com/Xilinx/qemu/blame/master/hw/net/cadence_gem.c#L248
>>
>>>
>>> It looks BOARD_PHY_ADDRESS has been there since the initial version of
>>> the cadence_gem model.
>>>
>>> commit e9f186e514a70557d695cadd2c2287ef97737023
>>> Author: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
>>> Date: Mon Mar 5 14:39:12 2012 +1000
>>>
>>> cadence_gem: initial version of device model
>>>
>>> Device model for cadence gem ethernet controller.
>>>
>>> Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
>>> Signed-off-by: John Linn <john.linn@xilinx.com>
>>> Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
>>> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
>>>
>>> Later PHY address 0 was added via the following commit:
>>>
>>> commit 553893736885e4f2dda424bff3e2200e1b6482a5
>>> Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>>> Date: Thu Apr 3 23:55:19 2014 -0700
>>>
>>> net: cadence_gem: Make phy respond to broadcast
>>>
>>> Phys must respond to address 0 by specification. Implement.
>>>
>>> Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
>>> Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>>> Message-id:
>>> 6f4d53b04ddbfb19895bfb61a595e69f1c08859a.1396594056.git.peter.crosthwaite@xilinx.com
>>> Reviewed-by: Beniamino Galvani <b.galvani@gmail.com>
>>> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
>>>
>>> I doubt the commit message said that PHYs must respond to address 0. I
>>> am not aware of such specs. The issue was probably that whatever board
>>> 2nd commit was tested against did not have a PHY at address
>>> BOARD_PHY_ADDRESS.
>>
>> It is common for phy devices to support it as a broadcast address. It
>> is also commonly written in Xilinx documentation that it is treated as
>> a broadcast address. e.g. the axi ethernet core
>> (https://www.xilinx.com/support/documentation/ip_documentation/axi_ethernet/v7_0/pg138-axi-ethernet.pdf
>> page 45). But 802.3 does not require it, instead address 0 is only
>> reserved.
>>
>> With this commit the "must" refers to the device specification, in
>> that QEMU is emulating a real phy (though more specifically the phy(s)
>> that were being emulated for Zynq boards) that does respond to address
>> 0 as a broadcast. This change was a trade off in order to make QEMU
>> behave as it would on hardware, such that software using address 0 as
>> broadcast would work correctly.
>>
>
> Thanks Nathan. So is it safe to just remove BOARD_PHY_ADDRESS and set
> "phy-addr" property default value to 0?
I'd do as following:
First patch, introduce "phy-addr" property (default to
BOARD_PHY_ADDRESS) and remove BOARD_PHY_ADDRESS in code:
DEFINE_PROP_UINT8("phy-addr", CadenceGEMState,
phy_addr, BOARD_PHY_ADDRESS),
Second patch set "phy-addr" to BOARD_PHY_ADDRESS in all
current boards using this PHY and set the default to 0.
Thanks,
Phil.
>
> Regards,
> Bin
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 14/18] hw/net: cadence_gem: Add a new 'phy-addr' property
@ 2020-08-16 16:31 ` Philippe Mathieu-Daudé
0 siblings, 0 replies; 100+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-08-16 16:31 UTC (permalink / raw)
To: Bin Meng, Nathan Rossi
Cc: Peter Maydell, Peter Crosthwaite, Alistair Francis,
open list:RISC-V, Sagar Karandikar, Bin Meng, Bastian Koppelmann,
Jason Wang, Palmer Dabbelt, qemu-devel@nongnu.org Developers,
Peter A. G. Crosthwaite, qemu-arm, Alistair Francis, John Linn
On 8/16/20 3:42 PM, Bin Meng wrote:
> On Sun, Aug 16, 2020 at 8:08 PM Nathan Rossi <nathan@nathanrossi.com> wrote:
>>
>> On Sun, 16 Aug 2020 at 18:29, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>
>>> On Sat, Aug 15, 2020 at 5:06 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>>>
>>>> On 8/14/20 6:40 PM, Bin Meng wrote:
>>>>> From: Bin Meng <bin.meng@windriver.com>
>>>>>
>>>>> At present the PHY address of the PHY connected to GEM is hard-coded
>>>>> to either 23 (BOARD_PHY_ADDRESS) or 0. This might not be the case for
>>>>> all boards. Add a new 'phy-addr' property so that board can specify
>>>>> the PHY address for each GEM instance.
>>>>>
>>>>> Signed-off-by: Bin Meng <bin.meng@windriver.com>
>>>>> ---
>>>>>
>>>>> hw/net/cadence_gem.c | 7 +++++--
>>>>> include/hw/net/cadence_gem.h | 2 ++
>>>>> 2 files changed, 7 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
>>>>> index a93b5c0..9fa03de 100644
>>>>> --- a/hw/net/cadence_gem.c
>>>>> +++ b/hw/net/cadence_gem.c
>>>>> @@ -1446,7 +1446,8 @@ static uint64_t gem_read(void *opaque, hwaddr offset, unsigned size)
>>>>> uint32_t phy_addr, reg_num;
>>>>>
>>>>> phy_addr = (retval & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
>>>>> - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
>>>>> + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
>>>>> + phy_addr == s->phy_addr) {
>>>>> reg_num = (retval & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
>>>>> retval &= 0xFFFF0000;
>>>>> retval |= gem_phy_read(s, reg_num);
>>>>> @@ -1569,7 +1570,8 @@ static void gem_write(void *opaque, hwaddr offset, uint64_t val,
>>>>> uint32_t phy_addr, reg_num;
>>>>>
>>>>> phy_addr = (val & GEM_PHYMNTNC_ADDR) >> GEM_PHYMNTNC_ADDR_SHFT;
>>>>> - if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0) {
>>>>> + if (phy_addr == BOARD_PHY_ADDRESS || phy_addr == 0 ||
>>>>> + phy_addr == s->phy_addr) {
>>>>> reg_num = (val & GEM_PHYMNTNC_REG) >> GEM_PHYMNTNC_REG_SHIFT;
>>>>> gem_phy_write(s, reg_num, val);
>>>>> }
>>>>> @@ -1682,6 +1684,7 @@ static Property gem_properties[] = {
>>>>> DEFINE_NIC_PROPERTIES(CadenceGEMState, conf),
>>>>> DEFINE_PROP_UINT32("revision", CadenceGEMState, revision,
>>>>> GEM_MODID_VALUE),
>>>>> + DEFINE_PROP_UINT8("phy-addr", CadenceGEMState, phy_addr, 0),
>>>>
>>>> This patch would be complete by moving the BOARD_PHY_ADDRESS definition
>>>> to each board using this NIC, and setting the "phy-addr" property to
>>>> this value.
>>>
>>> I actually have no idea which board in QEMU is using this special PHY
>>> address instead of default 0.
>>
>> Given Xilinx's QEMU fork has not used this value for quite some time,
>> I suspect it was only used to match an early chip emulation
>> platform/board.
>>
>> https://github.com/Xilinx/qemu/blame/master/hw/net/cadence_gem.c#L248
>>
>>>
>>> It looks BOARD_PHY_ADDRESS has been there since the initial version of
>>> the cadence_gem model.
>>>
>>> commit e9f186e514a70557d695cadd2c2287ef97737023
>>> Author: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
>>> Date: Mon Mar 5 14:39:12 2012 +1000
>>>
>>> cadence_gem: initial version of device model
>>>
>>> Device model for cadence gem ethernet controller.
>>>
>>> Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwaite@petalogix.com>
>>> Signed-off-by: John Linn <john.linn@xilinx.com>
>>> Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
>>> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
>>>
>>> Later PHY address 0 was added via the following commit:
>>>
>>> commit 553893736885e4f2dda424bff3e2200e1b6482a5
>>> Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>>> Date: Thu Apr 3 23:55:19 2014 -0700
>>>
>>> net: cadence_gem: Make phy respond to broadcast
>>>
>>> Phys must respond to address 0 by specification. Implement.
>>>
>>> Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
>>> Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>>> Message-id:
>>> 6f4d53b04ddbfb19895bfb61a595e69f1c08859a.1396594056.git.peter.crosthwaite@xilinx.com
>>> Reviewed-by: Beniamino Galvani <b.galvani@gmail.com>
>>> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
>>>
>>> I doubt the commit message said that PHYs must respond to address 0. I
>>> am not aware of such specs. The issue was probably that whatever board
>>> 2nd commit was tested against did not have a PHY at address
>>> BOARD_PHY_ADDRESS.
>>
>> It is common for phy devices to support it as a broadcast address. It
>> is also commonly written in Xilinx documentation that it is treated as
>> a broadcast address. e.g. the axi ethernet core
>> (https://www.xilinx.com/support/documentation/ip_documentation/axi_ethernet/v7_0/pg138-axi-ethernet.pdf
>> page 45). But 802.3 does not require it, instead address 0 is only
>> reserved.
>>
>> With this commit the "must" refers to the device specification, in
>> that QEMU is emulating a real phy (though more specifically the phy(s)
>> that were being emulated for Zynq boards) that does respond to address
>> 0 as a broadcast. This change was a trade off in order to make QEMU
>> behave as it would on hardware, such that software using address 0 as
>> broadcast would work correctly.
>>
>
> Thanks Nathan. So is it safe to just remove BOARD_PHY_ADDRESS and set
> "phy-addr" property default value to 0?
I'd do as following:
First patch, introduce "phy-addr" property (default to
BOARD_PHY_ADDRESS) and remove BOARD_PHY_ADDRESS in code:
DEFINE_PROP_UINT8("phy-addr", CadenceGEMState,
phy_addr, BOARD_PHY_ADDRESS),
Second patch set "phy-addr" to BOARD_PHY_ADDRESS in all
current boards using this PHY and set the default to 0.
Thanks,
Phil.
>
> Regards,
> Bin
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
2020-08-14 17:44 ` Anup Patel
@ 2020-08-17 10:30 ` Bin Meng
-1 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-17 10:30 UTC (permalink / raw)
To: Anup Patel, Cyril.Jean
Cc: Peter Maydell, Alistair Francis, open list:RISC-V, qemu-block,
Sagar Karandikar, Bin Meng, Bastian Koppelmann, Jason Wang,
Palmer Dabbelt, Edgar E. Iglesias, QEMU Developers, qemu-arm,
Alistair Francis, Marc-André Lureau, Paolo Bonzini,
Philippe Mathieu-Daudé,
Palmer Dabbelt
Hi Anup,
On Sat, Aug 15, 2020 at 1:44 AM Anup Patel <anup@brainfault.org> wrote:
>
> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > From: Bin Meng <bin.meng@windriver.com>
> >
> > This adds support for Microchip PolarFire SoC Icicle Kit board.
> > 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.
>
> Nice Work !!! This is very helpful.
Thanks!
>
> >
> > For more details about Microchip PolarFire Soc, please see:
> > https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga
> >
> > The Icicle Kit board information can be found here:
> > https://www.microsemi.com/existing-parts/parts/152514
> >
> > Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000.
> > The RISC-V CPU and HART codes has been updated to set the core's
> > reset vector based on a configurable property from machine codes.
> >
> > The following perepherals are created as an unimplemented device:
> >
> > - Bus Error Uint 0/1/2/3/4
> > - L2 cache controller
> > - SYSREG
> > - MPUCFG
> > - IOSCBCFG
> > - GPIO
> >
> > The following perepherals are emulated:
> > - SiFive CLINT
> > - SiFive PLIC
> > - PolarFire SoC Multi-Mode UART
> > - PolarFire SoC DMA
> > - Cadence eMMC/SDHCI controller
> > - Cadence Gigabit Ethernet MAC
> >
> > Some bugs in the SD card codes are fixed during the development.
> >
> > 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 -M microchip-icicle-kit -smp 5 \
> > -bios path/to/hss.bin -sd path/to/sdcard.img \
> > -nic tap,ifname=tap,script=no,model=cadence_gem \
> > -display none -serial stdio \
> > -chardev socket,id=serial1,path=serial1.sock,server,wait \
> > -serial chardev:serial1
>
> Currently, it is fine to use HSS (with OpenSBI v0.6 as a library) but
> this is not aligned with the existing booting flow of many RISC-V
> systems.
Yep, unfortunately this is the case currently.
>
> It will be nice to have standard U-Boot RISC-V boot-flow working
> on Microchip PolarFire SoC:
> U-Boot SPL (BIOS) => FW_DYNAMIC (Generic) => U-Boot S-mode
>
Agreed.
> The Microchip HSS is quite convoluted. It has:
> 1. DDR Init
> 2. Boot device support
> 3. SBI support using OpenSBI as library
> 4. Simple TEE support
>
> I think point 1) and 2) above should be part of U-Boot SPL.
> The point 3) can be OpenSBI FW_DYNAMIC.
>
> Lastly,for point 4), we are working on a new OpenSBI feature using
> which we can run independent Secure OS and Non-Secure OS using
> U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
> PolarFire).
>
> Do you have plans for adding U-Boot SPL support for this board ??
+ Cyril Jean from Microchip
I will have to leave this question to Cyril to comment.
Regards,
Bin
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
@ 2020-08-17 10:30 ` Bin Meng
0 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-17 10:30 UTC (permalink / raw)
To: Anup Patel, Cyril.Jean
Cc: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, QEMU Developers, open list:RISC-V,
Peter Maydell, Alistair Francis, qemu-block, Jason Wang,
Bin Meng, Paolo Bonzini, Palmer Dabbelt, qemu-arm,
Marc-André Lureau, Edgar E. Iglesias,
Philippe Mathieu-Daudé
Hi Anup,
On Sat, Aug 15, 2020 at 1:44 AM Anup Patel <anup@brainfault.org> wrote:
>
> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > From: Bin Meng <bin.meng@windriver.com>
> >
> > This adds support for Microchip PolarFire SoC Icicle Kit board.
> > 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.
>
> Nice Work !!! This is very helpful.
Thanks!
>
> >
> > For more details about Microchip PolarFire Soc, please see:
> > https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga
> >
> > The Icicle Kit board information can be found here:
> > https://www.microsemi.com/existing-parts/parts/152514
> >
> > Unlike SiFive FU540, the RISC-V core resect vector is at 0x20220000.
> > The RISC-V CPU and HART codes has been updated to set the core's
> > reset vector based on a configurable property from machine codes.
> >
> > The following perepherals are created as an unimplemented device:
> >
> > - Bus Error Uint 0/1/2/3/4
> > - L2 cache controller
> > - SYSREG
> > - MPUCFG
> > - IOSCBCFG
> > - GPIO
> >
> > The following perepherals are emulated:
> > - SiFive CLINT
> > - SiFive PLIC
> > - PolarFire SoC Multi-Mode UART
> > - PolarFire SoC DMA
> > - Cadence eMMC/SDHCI controller
> > - Cadence Gigabit Ethernet MAC
> >
> > Some bugs in the SD card codes are fixed during the development.
> >
> > 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 -M microchip-icicle-kit -smp 5 \
> > -bios path/to/hss.bin -sd path/to/sdcard.img \
> > -nic tap,ifname=tap,script=no,model=cadence_gem \
> > -display none -serial stdio \
> > -chardev socket,id=serial1,path=serial1.sock,server,wait \
> > -serial chardev:serial1
>
> Currently, it is fine to use HSS (with OpenSBI v0.6 as a library) but
> this is not aligned with the existing booting flow of many RISC-V
> systems.
Yep, unfortunately this is the case currently.
>
> It will be nice to have standard U-Boot RISC-V boot-flow working
> on Microchip PolarFire SoC:
> U-Boot SPL (BIOS) => FW_DYNAMIC (Generic) => U-Boot S-mode
>
Agreed.
> The Microchip HSS is quite convoluted. It has:
> 1. DDR Init
> 2. Boot device support
> 3. SBI support using OpenSBI as library
> 4. Simple TEE support
>
> I think point 1) and 2) above should be part of U-Boot SPL.
> The point 3) can be OpenSBI FW_DYNAMIC.
>
> Lastly,for point 4), we are working on a new OpenSBI feature using
> which we can run independent Secure OS and Non-Secure OS using
> U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
> PolarFire).
>
> Do you have plans for adding U-Boot SPL support for this board ??
+ Cyril Jean from Microchip
I will have to leave this question to Cyril to comment.
Regards,
Bin
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
2020-08-17 10:30 ` Bin Meng
@ 2020-08-17 15:44 ` Cyril.Jean
-1 siblings, 0 replies; 100+ messages in thread
From: via @ 2020-08-17 15:44 UTC (permalink / raw)
To: bmeng.cn, anup
Cc: Alistair.Francis, kbastian, palmerdabbelt, sagark, qemu-devel,
qemu-riscv, peter.maydell, alistair, qemu-block, jasowang,
bin.meng, pbonzini, palmer, qemu-arm, marcandre.lureau,
edgar.iglesias, philmd
Hi Anup,
On 8/17/20 11:30 AM, Bin Meng wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> Hi Anup,
>
> On Sat, Aug 15, 2020 at 1:44 AM Anup Patel <anup@brainfault.org> wrote:
>> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>>> From: Bin Meng <bin.meng@windriver.com>
>>>
>>> This adds support for Microchip PolarFire SoC Icicle Kit board.
>>> 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.
>> Nice Work !!! This is very helpful.
> Thanks!
>
>> The Microchip HSS is quite convoluted. It has:
>> 1. DDR Init
>> 2. Boot device support
>> 3. SBI support using OpenSBI as library
>> 4. Simple TEE support
>>
>> I think point 1) and 2) above should be part of U-Boot SPL.
>> The point 3) can be OpenSBI FW_DYNAMIC.
>>
>> Lastly,for point 4), we are working on a new OpenSBI feature using
>> which we can run independent Secure OS and Non-Secure OS using
>> U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
>> PolarFire).
>>
>> Do you have plans for adding U-Boot SPL support for this board ??
> + Cyril Jean from Microchip
>
> I will have to leave this question to Cyril to comment.
>
I currently do not have a plan to support U-Boot SPL. The idea of the
HSS is to contain all the silicon specific initialization and
configuration code within the HSS before jumping to U-Boot S-mode. I
would rather keep all this within the HSS for the time being. I would
wait until we reach production silicon before attempting to move this to
U-Boot SPL as the HSS is likely to contain some opaque silicon related
changes for another while.
Regards,
Cyril.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
@ 2020-08-17 15:44 ` Cyril.Jean
0 siblings, 0 replies; 100+ messages in thread
From: Cyril.Jean @ 2020-08-17 15:44 UTC (permalink / raw)
To: bmeng.cn, anup
Cc: Alistair.Francis, kbastian, palmerdabbelt, sagark, qemu-devel,
qemu-riscv, peter.maydell, alistair, qemu-block, jasowang,
bin.meng, pbonzini, palmer, qemu-arm, marcandre.lureau,
edgar.iglesias, philmd
Hi Anup,
On 8/17/20 11:30 AM, Bin Meng wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> Hi Anup,
>
> On Sat, Aug 15, 2020 at 1:44 AM Anup Patel <anup@brainfault.org> wrote:
>> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>>> From: Bin Meng <bin.meng@windriver.com>
>>>
>>> This adds support for Microchip PolarFire SoC Icicle Kit board.
>>> 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.
>> Nice Work !!! This is very helpful.
> Thanks!
>
>> The Microchip HSS is quite convoluted. It has:
>> 1. DDR Init
>> 2. Boot device support
>> 3. SBI support using OpenSBI as library
>> 4. Simple TEE support
>>
>> I think point 1) and 2) above should be part of U-Boot SPL.
>> The point 3) can be OpenSBI FW_DYNAMIC.
>>
>> Lastly,for point 4), we are working on a new OpenSBI feature using
>> which we can run independent Secure OS and Non-Secure OS using
>> U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
>> PolarFire).
>>
>> Do you have plans for adding U-Boot SPL support for this board ??
> + Cyril Jean from Microchip
>
> I will have to leave this question to Cyril to comment.
>
I currently do not have a plan to support U-Boot SPL. The idea of the
HSS is to contain all the silicon specific initialization and
configuration code within the HSS before jumping to U-Boot S-mode. I
would rather keep all this within the HSS for the time being. I would
wait until we reach production silicon before attempting to move this to
U-Boot SPL as the HSS is likely to contain some opaque silicon related
changes for another while.
Regards,
Cyril.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 01/18] target/riscv: cpu: Add a new 'resetvec' property
2020-08-14 16:40 ` [PATCH 01/18] target/riscv: cpu: Add a new 'resetvec' property Bin Meng
@ 2020-08-17 17:49 ` Alistair Francis
0 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-17 17:49 UTC (permalink / raw)
To: Bin Meng
Cc: Bin Meng, open list:RISC-V, Sagar Karandikar, Bastian Koppelmann,
Palmer Dabbelt, qemu-devel@nongnu.org Developers,
Alistair Francis, Palmer Dabbelt
On Fri, Aug 14, 2020 at 9:43 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> Currently the reset vector address is hard-coded in a RISC-V CPU's
> instance_init() routine. In a real world we can have 2 exact same
> CPUs except for the reset vector address, which is pretty common in
> the RISC-V core IP licensing business.
>
> Normally reset vector address is a configurable parameter. Let's
> create a 64-bit property to store the reset vector address which
> covers both 32-bit and 64-bit CPUs.
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Alistair
> ---
>
> target/riscv/cpu.c | 1 +
> target/riscv/cpu.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 228b9bd..8067a26 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -518,6 +518,7 @@ static Property riscv_cpu_properties[] = {
> DEFINE_PROP_UINT16("elen", RISCVCPU, cfg.elen, 64),
> DEFINE_PROP_BOOL("mmu", RISCVCPU, cfg.mmu, true),
> DEFINE_PROP_BOOL("pmp", RISCVCPU, cfg.pmp, true),
> + DEFINE_PROP_UINT64("resetvec", RISCVCPU, cfg.resetvec, DEFAULT_RSTVEC),
> DEFINE_PROP_END_OF_LIST(),
> };
>
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index a804a5d..d34bcfa 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -291,6 +291,7 @@ typedef struct RISCVCPU {
> uint16_t elen;
> bool mmu;
> bool pmp;
> + uint64_t resetvec;
> } cfg;
> } RISCVCPU;
>
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 01/18] target/riscv: cpu: Add a new 'resetvec' property
@ 2020-08-17 17:49 ` Alistair Francis
0 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-17 17:49 UTC (permalink / raw)
To: Bin Meng
Cc: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel@nongnu.org Developers,
open list:RISC-V, Bin Meng, Palmer Dabbelt
On Fri, Aug 14, 2020 at 9:43 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> Currently the reset vector address is hard-coded in a RISC-V CPU's
> instance_init() routine. In a real world we can have 2 exact same
> CPUs except for the reset vector address, which is pretty common in
> the RISC-V core IP licensing business.
>
> Normally reset vector address is a configurable parameter. Let's
> create a 64-bit property to store the reset vector address which
> covers both 32-bit and 64-bit CPUs.
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Alistair
> ---
>
> target/riscv/cpu.c | 1 +
> target/riscv/cpu.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 228b9bd..8067a26 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -518,6 +518,7 @@ static Property riscv_cpu_properties[] = {
> DEFINE_PROP_UINT16("elen", RISCVCPU, cfg.elen, 64),
> DEFINE_PROP_BOOL("mmu", RISCVCPU, cfg.mmu, true),
> DEFINE_PROP_BOOL("pmp", RISCVCPU, cfg.pmp, true),
> + DEFINE_PROP_UINT64("resetvec", RISCVCPU, cfg.resetvec, DEFAULT_RSTVEC),
> DEFINE_PROP_END_OF_LIST(),
> };
>
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index a804a5d..d34bcfa 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -291,6 +291,7 @@ typedef struct RISCVCPU {
> uint16_t elen;
> bool mmu;
> bool pmp;
> + uint64_t resetvec;
> } cfg;
> } RISCVCPU;
>
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 02/18] hw/riscv: hart: Add a new 'resetvec' property
2020-08-14 16:40 ` [PATCH 02/18] hw/riscv: hart: " Bin Meng
@ 2020-08-17 17:49 ` Alistair Francis
0 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-17 17:49 UTC (permalink / raw)
To: Bin Meng
Cc: Bin Meng, open list:RISC-V, Sagar Karandikar, Bastian Koppelmann,
Palmer Dabbelt, qemu-devel@nongnu.org Developers,
Alistair Francis, Palmer Dabbelt
On Fri, Aug 14, 2020 at 9:41 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> RISC-V machines do not instantiate RISC-V CPUs directly, instead
> they do that via the hart array. Add a new property for the reset
> vector address to allow the value to be passed to the CPU, before
> CPU is realized.
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Alistair
> ---
>
> hw/riscv/riscv_hart.c | 3 +++
> include/hw/riscv/riscv_hart.h | 1 +
> 2 files changed, 4 insertions(+)
>
> diff --git a/hw/riscv/riscv_hart.c b/hw/riscv/riscv_hart.c
> index f59fe52..613ea2a 100644
> --- a/hw/riscv/riscv_hart.c
> +++ b/hw/riscv/riscv_hart.c
> @@ -31,6 +31,8 @@ static Property riscv_harts_props[] = {
> DEFINE_PROP_UINT32("num-harts", RISCVHartArrayState, num_harts, 1),
> DEFINE_PROP_UINT32("hartid-base", RISCVHartArrayState, hartid_base, 0),
> DEFINE_PROP_STRING("cpu-type", RISCVHartArrayState, cpu_type),
> + DEFINE_PROP_UINT64("resetvec", RISCVHartArrayState, resetvec,
> + DEFAULT_RSTVEC),
> DEFINE_PROP_END_OF_LIST(),
> };
>
> @@ -44,6 +46,7 @@ static bool riscv_hart_realize(RISCVHartArrayState *s, int idx,
> char *cpu_type, Error **errp)
> {
> object_initialize_child(OBJECT(s), "harts[*]", &s->harts[idx], cpu_type);
> + qdev_prop_set_uint64(DEVICE(&s->harts[idx]), "resetvec", s->resetvec);
> s->harts[idx].env.mhartid = s->hartid_base + idx;
> qemu_register_reset(riscv_harts_cpu_reset, &s->harts[idx]);
> return qdev_realize(DEVICE(&s->harts[idx]), NULL, errp);
> diff --git a/include/hw/riscv/riscv_hart.h b/include/hw/riscv/riscv_hart.h
> index c75856f..77aa4bc 100644
> --- a/include/hw/riscv/riscv_hart.h
> +++ b/include/hw/riscv/riscv_hart.h
> @@ -37,6 +37,7 @@ typedef struct RISCVHartArrayState {
> uint32_t num_harts;
> uint32_t hartid_base;
> char *cpu_type;
> + uint64_t resetvec;
> RISCVCPU *harts;
> } RISCVHartArrayState;
>
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 02/18] hw/riscv: hart: Add a new 'resetvec' property
@ 2020-08-17 17:49 ` Alistair Francis
0 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-17 17:49 UTC (permalink / raw)
To: Bin Meng
Cc: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel@nongnu.org Developers,
open list:RISC-V, Bin Meng, Palmer Dabbelt
On Fri, Aug 14, 2020 at 9:41 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> RISC-V machines do not instantiate RISC-V CPUs directly, instead
> they do that via the hart array. Add a new property for the reset
> vector address to allow the value to be passed to the CPU, before
> CPU is realized.
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Alistair
> ---
>
> hw/riscv/riscv_hart.c | 3 +++
> include/hw/riscv/riscv_hart.h | 1 +
> 2 files changed, 4 insertions(+)
>
> diff --git a/hw/riscv/riscv_hart.c b/hw/riscv/riscv_hart.c
> index f59fe52..613ea2a 100644
> --- a/hw/riscv/riscv_hart.c
> +++ b/hw/riscv/riscv_hart.c
> @@ -31,6 +31,8 @@ static Property riscv_harts_props[] = {
> DEFINE_PROP_UINT32("num-harts", RISCVHartArrayState, num_harts, 1),
> DEFINE_PROP_UINT32("hartid-base", RISCVHartArrayState, hartid_base, 0),
> DEFINE_PROP_STRING("cpu-type", RISCVHartArrayState, cpu_type),
> + DEFINE_PROP_UINT64("resetvec", RISCVHartArrayState, resetvec,
> + DEFAULT_RSTVEC),
> DEFINE_PROP_END_OF_LIST(),
> };
>
> @@ -44,6 +46,7 @@ static bool riscv_hart_realize(RISCVHartArrayState *s, int idx,
> char *cpu_type, Error **errp)
> {
> object_initialize_child(OBJECT(s), "harts[*]", &s->harts[idx], cpu_type);
> + qdev_prop_set_uint64(DEVICE(&s->harts[idx]), "resetvec", s->resetvec);
> s->harts[idx].env.mhartid = s->hartid_base + idx;
> qemu_register_reset(riscv_harts_cpu_reset, &s->harts[idx]);
> return qdev_realize(DEVICE(&s->harts[idx]), NULL, errp);
> diff --git a/include/hw/riscv/riscv_hart.h b/include/hw/riscv/riscv_hart.h
> index c75856f..77aa4bc 100644
> --- a/include/hw/riscv/riscv_hart.h
> +++ b/include/hw/riscv/riscv_hart.h
> @@ -37,6 +37,7 @@ typedef struct RISCVHartArrayState {
> uint32_t num_harts;
> uint32_t hartid_base;
> char *cpu_type;
> + uint64_t resetvec;
> RISCVCPU *harts;
> } RISCVHartArrayState;
>
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 03/18] target/riscv: cpu: Set reset vector based on the configured property value
2020-08-14 16:40 ` [PATCH 03/18] target/riscv: cpu: Set reset vector based on the configured property value Bin Meng
@ 2020-08-17 17:52 ` Alistair Francis
0 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-17 17:52 UTC (permalink / raw)
To: Bin Meng
Cc: Bin Meng, open list:RISC-V, Sagar Karandikar, Bastian Koppelmann,
Palmer Dabbelt, qemu-devel@nongnu.org Developers,
Alistair Francis, Palmer Dabbelt
On Fri, Aug 14, 2020 at 9:45 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> Now that we have the newly introduced 'resetvec' property in the
> RISC-V CPU and HART, instead of hard-coding the reset vector addr
> in the CPU's instance_init(), move that to riscv_cpu_realize()
> based on the configured property value from the RISC-V machines.
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Alistair
> ---
>
> hw/riscv/opentitan.c | 1 +
> hw/riscv/sifive_e.c | 1 +
> hw/riscv/sifive_u.c | 2 ++
> target/riscv/cpu.c | 7 ++-----
> 4 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/hw/riscv/opentitan.c b/hw/riscv/opentitan.c
> index a8f0039..b0a4eae 100644
> --- a/hw/riscv/opentitan.c
> +++ b/hw/riscv/opentitan.c
> @@ -111,6 +111,7 @@ static void lowrisc_ibex_soc_realize(DeviceState *dev_soc, Error **errp)
> &error_abort);
> object_property_set_int(OBJECT(&s->cpus), "num-harts", ms->smp.cpus,
> &error_abort);
> + object_property_set_int(OBJECT(&s->cpus), "resetvec", 0x8090, &error_abort);
> sysbus_realize(SYS_BUS_DEVICE(&s->cpus), &error_abort);
>
> /* Boot ROM */
> diff --git a/hw/riscv/sifive_e.c b/hw/riscv/sifive_e.c
> index c8b0604..c84d407 100644
> --- a/hw/riscv/sifive_e.c
> +++ b/hw/riscv/sifive_e.c
> @@ -177,6 +177,7 @@ static void sifive_e_soc_init(Object *obj)
> object_initialize_child(obj, "cpus", &s->cpus, TYPE_RISCV_HART_ARRAY);
> object_property_set_int(OBJECT(&s->cpus), "num-harts", ms->smp.cpus,
> &error_abort);
> + object_property_set_int(OBJECT(&s->cpus), "resetvec", 0x1004, &error_abort);
> object_initialize_child(obj, "riscv.sifive.e.gpio0", &s->gpio,
> TYPE_SIFIVE_GPIO);
> }
> diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> index 18301e6..e256da2 100644
> --- a/hw/riscv/sifive_u.c
> +++ b/hw/riscv/sifive_u.c
> @@ -611,6 +611,7 @@ static void sifive_u_soc_instance_init(Object *obj)
> 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", SIFIVE_E_CPU);
> + qdev_prop_set_uint64(DEVICE(&s->e_cpus), "resetvec", 0x1004);
>
> object_initialize_child(obj, "u-cluster", &s->u_cluster, TYPE_CPU_CLUSTER);
> qdev_prop_set_uint32(DEVICE(&s->u_cluster), "cluster-id", 1);
> @@ -620,6 +621,7 @@ static void sifive_u_soc_instance_init(Object *obj)
> 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", SIFIVE_U_CPU);
> + qdev_prop_set_uint64(DEVICE(&s->u_cpus), "resetvec", 0x1004);
>
> object_initialize_child(obj, "prci", &s->prci, TYPE_SIFIVE_U_PRCI);
> object_initialize_child(obj, "otp", &s->otp, TYPE_SIFIVE_U_OTP);
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 8067a26..bd41286 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -128,7 +128,6 @@ static void riscv_any_cpu_init(Object *obj)
> CPURISCVState *env = &RISCV_CPU(obj)->env;
> set_misa(env, RVXLEN | RVI | RVM | RVA | RVF | RVD | RVC | RVU);
> set_priv_version(env, PRIV_VERSION_1_11_0);
> - set_resetvec(env, DEFAULT_RSTVEC);
> }
>
> static void riscv_base_cpu_init(Object *obj)
> @@ -136,7 +135,6 @@ static void riscv_base_cpu_init(Object *obj)
> CPURISCVState *env = &RISCV_CPU(obj)->env;
> /* We set this in the realise function */
> set_misa(env, 0);
> - set_resetvec(env, DEFAULT_RSTVEC);
> }
>
> static void rvxx_sifive_u_cpu_init(Object *obj)
> @@ -144,7 +142,6 @@ static void rvxx_sifive_u_cpu_init(Object *obj)
> CPURISCVState *env = &RISCV_CPU(obj)->env;
> set_misa(env, RVXLEN | RVI | RVM | RVA | RVF | RVD | RVC | RVS | RVU);
> set_priv_version(env, PRIV_VERSION_1_10_0);
> - set_resetvec(env, 0x1004);
> }
>
> static void rvxx_sifive_e_cpu_init(Object *obj)
> @@ -152,7 +149,6 @@ static void rvxx_sifive_e_cpu_init(Object *obj)
> CPURISCVState *env = &RISCV_CPU(obj)->env;
> set_misa(env, RVXLEN | RVI | RVM | RVA | RVC | RVU);
> set_priv_version(env, PRIV_VERSION_1_10_0);
> - set_resetvec(env, 0x1004);
> qdev_prop_set_bit(DEVICE(obj), "mmu", false);
> }
>
> @@ -163,7 +159,6 @@ static void rv32_ibex_cpu_init(Object *obj)
> CPURISCVState *env = &RISCV_CPU(obj)->env;
> set_misa(env, RV32 | RVI | RVM | RVC | RVU);
> set_priv_version(env, PRIV_VERSION_1_10_0);
> - set_resetvec(env, 0x8090);
> qdev_prop_set_bit(DEVICE(obj), "mmu", false);
> }
>
> @@ -373,6 +368,8 @@ static void riscv_cpu_realize(DeviceState *dev, Error **errp)
> set_feature(env, RISCV_FEATURE_PMP);
> }
>
> + set_resetvec(env, cpu->cfg.resetvec);
> +
> /* If misa isn't set (rv32 and rv64 machines) set it here */
> if (!env->misa) {
> /* Do some ISA extension error checking */
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 03/18] target/riscv: cpu: Set reset vector based on the configured property value
@ 2020-08-17 17:52 ` Alistair Francis
0 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-17 17:52 UTC (permalink / raw)
To: Bin Meng
Cc: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel@nongnu.org Developers,
open list:RISC-V, Bin Meng, Palmer Dabbelt
On Fri, Aug 14, 2020 at 9:45 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> Now that we have the newly introduced 'resetvec' property in the
> RISC-V CPU and HART, instead of hard-coding the reset vector addr
> in the CPU's instance_init(), move that to riscv_cpu_realize()
> based on the configured property value from the RISC-V machines.
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Alistair
> ---
>
> hw/riscv/opentitan.c | 1 +
> hw/riscv/sifive_e.c | 1 +
> hw/riscv/sifive_u.c | 2 ++
> target/riscv/cpu.c | 7 ++-----
> 4 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/hw/riscv/opentitan.c b/hw/riscv/opentitan.c
> index a8f0039..b0a4eae 100644
> --- a/hw/riscv/opentitan.c
> +++ b/hw/riscv/opentitan.c
> @@ -111,6 +111,7 @@ static void lowrisc_ibex_soc_realize(DeviceState *dev_soc, Error **errp)
> &error_abort);
> object_property_set_int(OBJECT(&s->cpus), "num-harts", ms->smp.cpus,
> &error_abort);
> + object_property_set_int(OBJECT(&s->cpus), "resetvec", 0x8090, &error_abort);
> sysbus_realize(SYS_BUS_DEVICE(&s->cpus), &error_abort);
>
> /* Boot ROM */
> diff --git a/hw/riscv/sifive_e.c b/hw/riscv/sifive_e.c
> index c8b0604..c84d407 100644
> --- a/hw/riscv/sifive_e.c
> +++ b/hw/riscv/sifive_e.c
> @@ -177,6 +177,7 @@ static void sifive_e_soc_init(Object *obj)
> object_initialize_child(obj, "cpus", &s->cpus, TYPE_RISCV_HART_ARRAY);
> object_property_set_int(OBJECT(&s->cpus), "num-harts", ms->smp.cpus,
> &error_abort);
> + object_property_set_int(OBJECT(&s->cpus), "resetvec", 0x1004, &error_abort);
> object_initialize_child(obj, "riscv.sifive.e.gpio0", &s->gpio,
> TYPE_SIFIVE_GPIO);
> }
> diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> index 18301e6..e256da2 100644
> --- a/hw/riscv/sifive_u.c
> +++ b/hw/riscv/sifive_u.c
> @@ -611,6 +611,7 @@ static void sifive_u_soc_instance_init(Object *obj)
> 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", SIFIVE_E_CPU);
> + qdev_prop_set_uint64(DEVICE(&s->e_cpus), "resetvec", 0x1004);
>
> object_initialize_child(obj, "u-cluster", &s->u_cluster, TYPE_CPU_CLUSTER);
> qdev_prop_set_uint32(DEVICE(&s->u_cluster), "cluster-id", 1);
> @@ -620,6 +621,7 @@ static void sifive_u_soc_instance_init(Object *obj)
> 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", SIFIVE_U_CPU);
> + qdev_prop_set_uint64(DEVICE(&s->u_cpus), "resetvec", 0x1004);
>
> object_initialize_child(obj, "prci", &s->prci, TYPE_SIFIVE_U_PRCI);
> object_initialize_child(obj, "otp", &s->otp, TYPE_SIFIVE_U_OTP);
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 8067a26..bd41286 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -128,7 +128,6 @@ static void riscv_any_cpu_init(Object *obj)
> CPURISCVState *env = &RISCV_CPU(obj)->env;
> set_misa(env, RVXLEN | RVI | RVM | RVA | RVF | RVD | RVC | RVU);
> set_priv_version(env, PRIV_VERSION_1_11_0);
> - set_resetvec(env, DEFAULT_RSTVEC);
> }
>
> static void riscv_base_cpu_init(Object *obj)
> @@ -136,7 +135,6 @@ static void riscv_base_cpu_init(Object *obj)
> CPURISCVState *env = &RISCV_CPU(obj)->env;
> /* We set this in the realise function */
> set_misa(env, 0);
> - set_resetvec(env, DEFAULT_RSTVEC);
> }
>
> static void rvxx_sifive_u_cpu_init(Object *obj)
> @@ -144,7 +142,6 @@ static void rvxx_sifive_u_cpu_init(Object *obj)
> CPURISCVState *env = &RISCV_CPU(obj)->env;
> set_misa(env, RVXLEN | RVI | RVM | RVA | RVF | RVD | RVC | RVS | RVU);
> set_priv_version(env, PRIV_VERSION_1_10_0);
> - set_resetvec(env, 0x1004);
> }
>
> static void rvxx_sifive_e_cpu_init(Object *obj)
> @@ -152,7 +149,6 @@ static void rvxx_sifive_e_cpu_init(Object *obj)
> CPURISCVState *env = &RISCV_CPU(obj)->env;
> set_misa(env, RVXLEN | RVI | RVM | RVA | RVC | RVU);
> set_priv_version(env, PRIV_VERSION_1_10_0);
> - set_resetvec(env, 0x1004);
> qdev_prop_set_bit(DEVICE(obj), "mmu", false);
> }
>
> @@ -163,7 +159,6 @@ static void rv32_ibex_cpu_init(Object *obj)
> CPURISCVState *env = &RISCV_CPU(obj)->env;
> set_misa(env, RV32 | RVI | RVM | RVC | RVU);
> set_priv_version(env, PRIV_VERSION_1_10_0);
> - set_resetvec(env, 0x8090);
> qdev_prop_set_bit(DEVICE(obj), "mmu", false);
> }
>
> @@ -373,6 +368,8 @@ static void riscv_cpu_realize(DeviceState *dev, Error **errp)
> set_feature(env, RISCV_FEATURE_PMP);
> }
>
> + set_resetvec(env, cpu->cfg.resetvec);
> +
> /* If misa isn't set (rv32 and rv64 machines) set it here */
> if (!env->misa) {
> /* Do some ISA extension error checking */
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
2020-08-17 15:44 ` Cyril.Jean
@ 2020-08-17 19:28 ` Alistair Francis
-1 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-17 19:28 UTC (permalink / raw)
To: Cyril.Jean
Cc: Peter Maydell, Alistair Francis, open list:RISC-V, Qemu-block,
Sagar Karandikar, Bin Meng, Anup Patel, Jason Wang,
Palmer Dabbelt, Edgar Iglesias, qemu-devel@nongnu.org Developers,
Marc-André Lureau, qemu-arm, Alistair Francis,
Bastian Koppelmann, Paolo Bonzini, Bin Meng,
Philippe Mathieu-Daudé,
Palmer Dabbelt
On Mon, Aug 17, 2020 at 11:12 AM via <qemu-devel@nongnu.org> wrote:
>
> Hi Anup,
>
> On 8/17/20 11:30 AM, Bin Meng wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > Hi Anup,
> >
> > On Sat, Aug 15, 2020 at 1:44 AM Anup Patel <anup@brainfault.org> wrote:
> >> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >>> From: Bin Meng <bin.meng@windriver.com>
> >>>
> >>> This adds support for Microchip PolarFire SoC Icicle Kit board.
> >>> 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.
> >> Nice Work !!! This is very helpful.
> > Thanks!
> >
> >> The Microchip HSS is quite convoluted. It has:
> >> 1. DDR Init
> >> 2. Boot device support
> >> 3. SBI support using OpenSBI as library
> >> 4. Simple TEE support
> >>
> >> I think point 1) and 2) above should be part of U-Boot SPL.
> >> The point 3) can be OpenSBI FW_DYNAMIC.
> >>
> >> Lastly,for point 4), we are working on a new OpenSBI feature using
> >> which we can run independent Secure OS and Non-Secure OS using
> >> U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
> >> PolarFire).
> >>
> >> Do you have plans for adding U-Boot SPL support for this board ??
> > + Cyril Jean from Microchip
> >
> > I will have to leave this question to Cyril to comment.
> >
> I currently do not have a plan to support U-Boot SPL. The idea of the
> HSS is to contain all the silicon specific initialization and
> configuration code within the HSS before jumping to U-Boot S-mode. I
> would rather keep all this within the HSS for the time being. I would
> wait until we reach production silicon before attempting to move this to
> U-Boot SPL as the HSS is likely to contain some opaque silicon related
> changes for another while.
That is unfortunate, a lot of work has gone into making the boot flow
simple and easy to use.
QEMU now includes OpenSBI by default to make it easy for users to boot
Linux. The Icicle Kit board is now the most difficult QEMU board to
boot Linux on. Not to mention it makes it hard to impossible to
support it in standard tool flows such as meta-riscv.
Alistair
>
>
> Regards,
>
> Cyril.
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
@ 2020-08-17 19:28 ` Alistair Francis
0 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-17 19:28 UTC (permalink / raw)
To: Cyril.Jean
Cc: Bin Meng, Anup Patel, Alistair Francis, Bastian Koppelmann,
Palmer Dabbelt, Sagar Karandikar,
qemu-devel@nongnu.org Developers, open list:RISC-V,
Peter Maydell, Alistair Francis, Qemu-block, Jason Wang,
Bin Meng, Paolo Bonzini, Palmer Dabbelt, qemu-arm,
Marc-André Lureau, Edgar Iglesias,
Philippe Mathieu-Daudé
On Mon, Aug 17, 2020 at 11:12 AM via <qemu-devel@nongnu.org> wrote:
>
> Hi Anup,
>
> On 8/17/20 11:30 AM, Bin Meng wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > Hi Anup,
> >
> > On Sat, Aug 15, 2020 at 1:44 AM Anup Patel <anup@brainfault.org> wrote:
> >> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >>> From: Bin Meng <bin.meng@windriver.com>
> >>>
> >>> This adds support for Microchip PolarFire SoC Icicle Kit board.
> >>> 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.
> >> Nice Work !!! This is very helpful.
> > Thanks!
> >
> >> The Microchip HSS is quite convoluted. It has:
> >> 1. DDR Init
> >> 2. Boot device support
> >> 3. SBI support using OpenSBI as library
> >> 4. Simple TEE support
> >>
> >> I think point 1) and 2) above should be part of U-Boot SPL.
> >> The point 3) can be OpenSBI FW_DYNAMIC.
> >>
> >> Lastly,for point 4), we are working on a new OpenSBI feature using
> >> which we can run independent Secure OS and Non-Secure OS using
> >> U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
> >> PolarFire).
> >>
> >> Do you have plans for adding U-Boot SPL support for this board ??
> > + Cyril Jean from Microchip
> >
> > I will have to leave this question to Cyril to comment.
> >
> I currently do not have a plan to support U-Boot SPL. The idea of the
> HSS is to contain all the silicon specific initialization and
> configuration code within the HSS before jumping to U-Boot S-mode. I
> would rather keep all this within the HSS for the time being. I would
> wait until we reach production silicon before attempting to move this to
> U-Boot SPL as the HSS is likely to contain some opaque silicon related
> changes for another while.
That is unfortunate, a lot of work has gone into making the boot flow
simple and easy to use.
QEMU now includes OpenSBI by default to make it easy for users to boot
Linux. The Icicle Kit board is now the most difficult QEMU board to
boot Linux on. Not to mention it makes it hard to impossible to
support it in standard tool flows such as meta-riscv.
Alistair
>
>
> Regards,
>
> Cyril.
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 04/18] hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board
2020-08-14 16:40 ` [PATCH 04/18] hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board Bin Meng
@ 2020-08-17 19:39 ` Alistair Francis
0 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-17 19:39 UTC (permalink / raw)
To: Bin Meng
Cc: Bin Meng, open list:RISC-V, Sagar Karandikar, Bastian Koppelmann,
Palmer Dabbelt, qemu-devel@nongnu.org Developers,
Alistair Francis, Palmer Dabbelt
On Fri, Aug 14, 2020 at 9:43 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> 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>
Looks good. I didn't check the addresses and PLIC config data with the
datasheet, but I'm assuming it's correct.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Alistair
> ---
>
> MAINTAINERS | 7 +
> default-configs/riscv64-softmmu.mak | 1 +
> hw/riscv/Kconfig | 6 +
> hw/riscv/Makefile.objs | 1 +
> hw/riscv/microchip_pfsoc.c | 312 ++++++++++++++++++++++++++++++++++++
> include/hw/riscv/microchip_pfsoc.h | 88 ++++++++++
> 6 files changed, 415 insertions(+)
> create mode 100644 hw/riscv/microchip_pfsoc.c
> create mode 100644 include/hw/riscv/microchip_pfsoc.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0886eb3..8716cb6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1314,6 +1314,13 @@ F: include/hw/riscv/opentitan.h
> F: include/hw/char/ibex_uart.h
> F: include/hw/intc/ibex_plic.h
>
> +Microchip PolarFire SoC Icicle Kit
> +M: Bin Meng <bin.meng@windriver.com>
> +L: qemu-riscv@nongnu.org
> +S: Supported
> +F: hw/riscv/microchip_pfsoc.c
> +F: include/hw/riscv/microchip_pfsoc.h
> +
> RX Machines
> -----------
> rx-gdbsim
> diff --git a/default-configs/riscv64-softmmu.mak b/default-configs/riscv64-softmmu.mak
> index aaf6d73..76b6195 100644
> --- a/default-configs/riscv64-softmmu.mak
> +++ b/default-configs/riscv64-softmmu.mak
> @@ -10,3 +10,4 @@ CONFIG_SPIKE=y
> CONFIG_SIFIVE_E=y
> CONFIG_SIFIVE_U=y
> CONFIG_RISCV_VIRT=y
> +CONFIG_MICROCHIP_PFSOC=y
> diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
> index 28947ef..3292fae 100644
> --- a/hw/riscv/Kconfig
> +++ b/hw/riscv/Kconfig
> @@ -48,3 +48,9 @@ config RISCV_VIRT
> select PCI_EXPRESS_GENERIC_BRIDGE
> select PFLASH_CFI01
> select SIFIVE
> +
> +config MICROCHIP_PFSOC
> + bool
> + select HART
> + select SIFIVE
> + select UNIMP
> diff --git a/hw/riscv/Makefile.objs b/hw/riscv/Makefile.objs
> index 57cc708..419a5a0 100644
> --- a/hw/riscv/Makefile.objs
> +++ b/hw/riscv/Makefile.objs
> @@ -14,3 +14,4 @@ obj-$(CONFIG_SIFIVE_U) += sifive_u_prci.o
> obj-$(CONFIG_SIFIVE) += sifive_uart.o
> obj-$(CONFIG_SPIKE) += spike.o
> obj-$(CONFIG_RISCV_VIRT) += virt.o
> +obj-$(CONFIG_MICROCHIP_PFSOC) += microchip_pfsoc.o
> diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
> new file mode 100644
> index 0000000..20a642c
> --- /dev/null
> +++ b/hw/riscv/microchip_pfsoc.c
> @@ -0,0 +1,312 @@
> +/*
> + * 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)
> + *
> + * 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/log.h"
> +#include "qemu/units.h"
> +#include "qemu/cutils.h"
> +#include "qapi/error.h"
> +#include "hw/boards.h"
> +#include "hw/irq.h"
> +#include "hw/loader.h"
> +#include "hw/sysbus.h"
> +#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/sifive_clint.h"
> +#include "hw/riscv/sifive_plic.h"
> +#include "hw/riscv/microchip_pfsoc.h"
> +
> +/*
> + * 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
> +
> +static const struct MemmapEntry {
> + hwaddr base;
> + hwaddr size;
> +} microchip_pfsoc_memmap[] = {
> + [MICROCHIP_PFSOC_DEBUG] = { 0x0, 0x1000 },
> + [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_L2LIM] = { 0x8000000, 0x2000000 },
> + [MICROCHIP_PFSOC_PLIC] = { 0xc000000, 0x4000000 },
> + [MICROCHIP_PFSOC_SYSREG] = { 0x20002000, 0x2000 },
> + [MICROCHIP_PFSOC_MPUCFG] = { 0x20005000, 0x1000 },
> + [MICROCHIP_PFSOC_ENVM_CFG] = { 0x20200000, 0x1000 },
> + [MICROCHIP_PFSOC_ENVM_DATA] = { 0x20220000, 0x20000 },
> + [MICROCHIP_PFSOC_IOSCB_CFG] = { 0x37080000, 0x1000 },
> + [MICROCHIP_PFSOC_DRAM] = { 0x80000000, 0x0 },
> +};
> +
> +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);
> +}
> +
> +static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
> +{
> + MachineState *ms = MACHINE(qdev_get_machine());
> + MicrochipPFSoCState *s = MICROCHIP_PFSOC(dev);
> + const struct MemmapEntry *memmap = microchip_pfsoc_memmap;
> + MemoryRegion *system_memory = get_system_memory();
> + MemoryRegion *e51_dtim_mem = g_new(MemoryRegion, 1);
> + MemoryRegion *l2lim_mem = g_new(MemoryRegion, 1);
> + MemoryRegion *envm_data = g_new(MemoryRegion, 1);
> + char *plic_hart_config;
> + size_t plic_hart_config_len;
> + 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);
> +
> + /* 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 */
> + sifive_clint_create(memmap[MICROCHIP_PFSOC_CLINT].base,
> + memmap[MICROCHIP_PFSOC_CLINT].size, ms->smp.cpus,
> + SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE, false);
> +
> + /* 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 */
> + plic_hart_config_len = (strlen(MICROCHIP_PFSOC_PLIC_HART_CONFIG) + 1) *
> + ms->smp.cpus;
> + plic_hart_config = g_malloc0(plic_hart_config_len);
> + for (i = 0; i < ms->smp.cpus; i++) {
> + if (i != 0) {
> + strncat(plic_hart_config, "," MICROCHIP_PFSOC_PLIC_HART_CONFIG,
> + plic_hart_config_len);
> + } else {
> + strncat(plic_hart_config, "M", plic_hart_config_len);
> + }
> + plic_hart_config_len -= (strlen(MICROCHIP_PFSOC_PLIC_HART_CONFIG) + 1);
> + }
> +
> + /* PLIC */
> + s->plic = sifive_plic_create(memmap[MICROCHIP_PFSOC_PLIC].base,
> + plic_hart_config,
> + 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);
> +
> + /* SYSREG */
> + create_unimplemented_device("microchip.pfsoc.sysreg",
> + memmap[MICROCHIP_PFSOC_SYSREG].base,
> + memmap[MICROCHIP_PFSOC_SYSREG].size);
> +
> + /* MPUCFG */
> + create_unimplemented_device("microchip.pfsoc.mpucfg",
> + memmap[MICROCHIP_PFSOC_MPUCFG].base,
> + memmap[MICROCHIP_PFSOC_MPUCFG].size);
> +
> + /* 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);
> +
> + /* IOSCBCFG */
> + create_unimplemented_device("microchip.pfsoc.ioscb.cfg",
> + memmap[MICROCHIP_PFSOC_IOSCB_CFG].base,
> + memmap[MICROCHIP_PFSOC_IOSCB_CFG].size);
> +}
> +
> +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(µchip_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);
> + const struct MemmapEntry *memmap = microchip_pfsoc_memmap;
> + MicrochipIcicleKitState *s = MICROCHIP_ICICLE_KIT_MACHINE(machine);
> + MemoryRegion *system_memory = get_system_memory();
> + MemoryRegion *main_mem = g_new(MemoryRegion, 1);
> +
> + /* 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);
> + qdev_realize(DEVICE(&s->soc), NULL, &error_abort);
> +
> + /* Register RAM */
> + memory_region_init_ram(main_mem, NULL, "microchip.icicle.kit.ram",
> + machine->ram_size, &error_fatal);
> + memory_region_add_subregion(system_memory,
> + memmap[MICROCHIP_PFSOC_DRAM].base, main_mem);
> +
> + /* Load the firmware */
> + riscv_find_and_load_firmware(machine, BIOS_FILENAME, RESET_VECTOR, NULL);
> +}
> +
> +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;
> + mc->default_ram_size = 1 * GiB;
> +}
> +
> +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(µchip_icicle_kit_machine_typeinfo);
> +}
> +
> +type_init(microchip_icicle_kit_machine_init_register_types)
> diff --git a/include/hw/riscv/microchip_pfsoc.h b/include/hw/riscv/microchip_pfsoc.h
> new file mode 100644
> index 0000000..1953ef1
> --- /dev/null
> +++ b/include/hw/riscv/microchip_pfsoc.h
> @@ -0,0 +1,88 @@
> +/*
> + * Microchip PolarFire SoC machine interface
> + *
> + * Copyright (c) 2020 Wind River Systems, Inc.
> + *
> + * Author:
> + * Bin Meng <bin.meng@windriver.com>
> + *
> + * 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/>.
> + */
> +
> +#ifndef HW_MICROCHIP_PFSOC_H
> +#define HW_MICROCHIP_PFSOC_H
> +
> +typedef struct MicrochipPFSoCState {
> + /*< private >*/
> + DeviceState parent_obj;
> +
> + /*< public >*/
> + CPUClusterState e_cluster;
> + CPUClusterState u_cluster;
> + RISCVHartArrayState e_cpus;
> + RISCVHartArrayState u_cpus;
> + DeviceState *plic;
> +} MicrochipPFSoCState;
> +
> +#define TYPE_MICROCHIP_PFSOC "microchip.pfsoc"
> +#define MICROCHIP_PFSOC(obj) \
> + OBJECT_CHECK(MicrochipPFSoCState, (obj), TYPE_MICROCHIP_PFSOC)
> +
> +typedef struct MicrochipIcicleKitState {
> + /*< private >*/
> + MachineState parent_obj;
> +
> + /*< public >*/
> + MicrochipPFSoCState soc;
> +} MicrochipIcicleKitState;
> +
> +#define TYPE_MICROCHIP_ICICLE_KIT_MACHINE \
> + MACHINE_TYPE_NAME("microchip-icicle-kit")
> +#define MICROCHIP_ICICLE_KIT_MACHINE(obj) \
> + OBJECT_CHECK(MicrochipIcicleKitState, (obj), \
> + TYPE_MICROCHIP_ICICLE_KIT_MACHINE)
> +
> +enum {
> + MICROCHIP_PFSOC_DEBUG,
> + MICROCHIP_PFSOC_E51_DTIM,
> + MICROCHIP_PFSOC_BUSERR_UNIT0,
> + MICROCHIP_PFSOC_BUSERR_UNIT1,
> + MICROCHIP_PFSOC_BUSERR_UNIT2,
> + MICROCHIP_PFSOC_BUSERR_UNIT3,
> + MICROCHIP_PFSOC_BUSERR_UNIT4,
> + MICROCHIP_PFSOC_CLINT,
> + MICROCHIP_PFSOC_L2CC,
> + MICROCHIP_PFSOC_L2LIM,
> + MICROCHIP_PFSOC_PLIC,
> + MICROCHIP_PFSOC_SYSREG,
> + MICROCHIP_PFSOC_MPUCFG,
> + MICROCHIP_PFSOC_ENVM_CFG,
> + MICROCHIP_PFSOC_ENVM_DATA,
> + MICROCHIP_PFSOC_IOSCB_CFG,
> + MICROCHIP_PFSOC_DRAM,
> +};
> +
> +#define MICROCHIP_PFSOC_MANAGEMENT_CPU_COUNT 1
> +#define MICROCHIP_PFSOC_COMPUTE_CPU_COUNT 4
> +
> +#define MICROCHIP_PFSOC_PLIC_HART_CONFIG "MS"
> +#define MICROCHIP_PFSOC_PLIC_NUM_SOURCES 185
> +#define MICROCHIP_PFSOC_PLIC_NUM_PRIORITIES 7
> +#define MICROCHIP_PFSOC_PLIC_PRIORITY_BASE 0x04
> +#define MICROCHIP_PFSOC_PLIC_PENDING_BASE 0x1000
> +#define MICROCHIP_PFSOC_PLIC_ENABLE_BASE 0x2000
> +#define MICROCHIP_PFSOC_PLIC_ENABLE_STRIDE 0x80
> +#define MICROCHIP_PFSOC_PLIC_CONTEXT_BASE 0x200000
> +#define MICROCHIP_PFSOC_PLIC_CONTEXT_STRIDE 0x1000
> +
> +#endif /* HW_MICROCHIP_PFSOC_H */
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 04/18] hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board
@ 2020-08-17 19:39 ` Alistair Francis
0 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-17 19:39 UTC (permalink / raw)
To: Bin Meng
Cc: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel@nongnu.org Developers,
open list:RISC-V, Bin Meng, Palmer Dabbelt
On Fri, Aug 14, 2020 at 9:43 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> 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>
Looks good. I didn't check the addresses and PLIC config data with the
datasheet, but I'm assuming it's correct.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Alistair
> ---
>
> MAINTAINERS | 7 +
> default-configs/riscv64-softmmu.mak | 1 +
> hw/riscv/Kconfig | 6 +
> hw/riscv/Makefile.objs | 1 +
> hw/riscv/microchip_pfsoc.c | 312 ++++++++++++++++++++++++++++++++++++
> include/hw/riscv/microchip_pfsoc.h | 88 ++++++++++
> 6 files changed, 415 insertions(+)
> create mode 100644 hw/riscv/microchip_pfsoc.c
> create mode 100644 include/hw/riscv/microchip_pfsoc.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0886eb3..8716cb6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1314,6 +1314,13 @@ F: include/hw/riscv/opentitan.h
> F: include/hw/char/ibex_uart.h
> F: include/hw/intc/ibex_plic.h
>
> +Microchip PolarFire SoC Icicle Kit
> +M: Bin Meng <bin.meng@windriver.com>
> +L: qemu-riscv@nongnu.org
> +S: Supported
> +F: hw/riscv/microchip_pfsoc.c
> +F: include/hw/riscv/microchip_pfsoc.h
> +
> RX Machines
> -----------
> rx-gdbsim
> diff --git a/default-configs/riscv64-softmmu.mak b/default-configs/riscv64-softmmu.mak
> index aaf6d73..76b6195 100644
> --- a/default-configs/riscv64-softmmu.mak
> +++ b/default-configs/riscv64-softmmu.mak
> @@ -10,3 +10,4 @@ CONFIG_SPIKE=y
> CONFIG_SIFIVE_E=y
> CONFIG_SIFIVE_U=y
> CONFIG_RISCV_VIRT=y
> +CONFIG_MICROCHIP_PFSOC=y
> diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
> index 28947ef..3292fae 100644
> --- a/hw/riscv/Kconfig
> +++ b/hw/riscv/Kconfig
> @@ -48,3 +48,9 @@ config RISCV_VIRT
> select PCI_EXPRESS_GENERIC_BRIDGE
> select PFLASH_CFI01
> select SIFIVE
> +
> +config MICROCHIP_PFSOC
> + bool
> + select HART
> + select SIFIVE
> + select UNIMP
> diff --git a/hw/riscv/Makefile.objs b/hw/riscv/Makefile.objs
> index 57cc708..419a5a0 100644
> --- a/hw/riscv/Makefile.objs
> +++ b/hw/riscv/Makefile.objs
> @@ -14,3 +14,4 @@ obj-$(CONFIG_SIFIVE_U) += sifive_u_prci.o
> obj-$(CONFIG_SIFIVE) += sifive_uart.o
> obj-$(CONFIG_SPIKE) += spike.o
> obj-$(CONFIG_RISCV_VIRT) += virt.o
> +obj-$(CONFIG_MICROCHIP_PFSOC) += microchip_pfsoc.o
> diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
> new file mode 100644
> index 0000000..20a642c
> --- /dev/null
> +++ b/hw/riscv/microchip_pfsoc.c
> @@ -0,0 +1,312 @@
> +/*
> + * 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)
> + *
> + * 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/log.h"
> +#include "qemu/units.h"
> +#include "qemu/cutils.h"
> +#include "qapi/error.h"
> +#include "hw/boards.h"
> +#include "hw/irq.h"
> +#include "hw/loader.h"
> +#include "hw/sysbus.h"
> +#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/sifive_clint.h"
> +#include "hw/riscv/sifive_plic.h"
> +#include "hw/riscv/microchip_pfsoc.h"
> +
> +/*
> + * 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
> +
> +static const struct MemmapEntry {
> + hwaddr base;
> + hwaddr size;
> +} microchip_pfsoc_memmap[] = {
> + [MICROCHIP_PFSOC_DEBUG] = { 0x0, 0x1000 },
> + [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_L2LIM] = { 0x8000000, 0x2000000 },
> + [MICROCHIP_PFSOC_PLIC] = { 0xc000000, 0x4000000 },
> + [MICROCHIP_PFSOC_SYSREG] = { 0x20002000, 0x2000 },
> + [MICROCHIP_PFSOC_MPUCFG] = { 0x20005000, 0x1000 },
> + [MICROCHIP_PFSOC_ENVM_CFG] = { 0x20200000, 0x1000 },
> + [MICROCHIP_PFSOC_ENVM_DATA] = { 0x20220000, 0x20000 },
> + [MICROCHIP_PFSOC_IOSCB_CFG] = { 0x37080000, 0x1000 },
> + [MICROCHIP_PFSOC_DRAM] = { 0x80000000, 0x0 },
> +};
> +
> +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);
> +}
> +
> +static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
> +{
> + MachineState *ms = MACHINE(qdev_get_machine());
> + MicrochipPFSoCState *s = MICROCHIP_PFSOC(dev);
> + const struct MemmapEntry *memmap = microchip_pfsoc_memmap;
> + MemoryRegion *system_memory = get_system_memory();
> + MemoryRegion *e51_dtim_mem = g_new(MemoryRegion, 1);
> + MemoryRegion *l2lim_mem = g_new(MemoryRegion, 1);
> + MemoryRegion *envm_data = g_new(MemoryRegion, 1);
> + char *plic_hart_config;
> + size_t plic_hart_config_len;
> + 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);
> +
> + /* 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 */
> + sifive_clint_create(memmap[MICROCHIP_PFSOC_CLINT].base,
> + memmap[MICROCHIP_PFSOC_CLINT].size, ms->smp.cpus,
> + SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE, false);
> +
> + /* 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 */
> + plic_hart_config_len = (strlen(MICROCHIP_PFSOC_PLIC_HART_CONFIG) + 1) *
> + ms->smp.cpus;
> + plic_hart_config = g_malloc0(plic_hart_config_len);
> + for (i = 0; i < ms->smp.cpus; i++) {
> + if (i != 0) {
> + strncat(plic_hart_config, "," MICROCHIP_PFSOC_PLIC_HART_CONFIG,
> + plic_hart_config_len);
> + } else {
> + strncat(plic_hart_config, "M", plic_hart_config_len);
> + }
> + plic_hart_config_len -= (strlen(MICROCHIP_PFSOC_PLIC_HART_CONFIG) + 1);
> + }
> +
> + /* PLIC */
> + s->plic = sifive_plic_create(memmap[MICROCHIP_PFSOC_PLIC].base,
> + plic_hart_config,
> + 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);
> +
> + /* SYSREG */
> + create_unimplemented_device("microchip.pfsoc.sysreg",
> + memmap[MICROCHIP_PFSOC_SYSREG].base,
> + memmap[MICROCHIP_PFSOC_SYSREG].size);
> +
> + /* MPUCFG */
> + create_unimplemented_device("microchip.pfsoc.mpucfg",
> + memmap[MICROCHIP_PFSOC_MPUCFG].base,
> + memmap[MICROCHIP_PFSOC_MPUCFG].size);
> +
> + /* 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);
> +
> + /* IOSCBCFG */
> + create_unimplemented_device("microchip.pfsoc.ioscb.cfg",
> + memmap[MICROCHIP_PFSOC_IOSCB_CFG].base,
> + memmap[MICROCHIP_PFSOC_IOSCB_CFG].size);
> +}
> +
> +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(µchip_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);
> + const struct MemmapEntry *memmap = microchip_pfsoc_memmap;
> + MicrochipIcicleKitState *s = MICROCHIP_ICICLE_KIT_MACHINE(machine);
> + MemoryRegion *system_memory = get_system_memory();
> + MemoryRegion *main_mem = g_new(MemoryRegion, 1);
> +
> + /* 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);
> + qdev_realize(DEVICE(&s->soc), NULL, &error_abort);
> +
> + /* Register RAM */
> + memory_region_init_ram(main_mem, NULL, "microchip.icicle.kit.ram",
> + machine->ram_size, &error_fatal);
> + memory_region_add_subregion(system_memory,
> + memmap[MICROCHIP_PFSOC_DRAM].base, main_mem);
> +
> + /* Load the firmware */
> + riscv_find_and_load_firmware(machine, BIOS_FILENAME, RESET_VECTOR, NULL);
> +}
> +
> +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;
> + mc->default_ram_size = 1 * GiB;
> +}
> +
> +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(µchip_icicle_kit_machine_typeinfo);
> +}
> +
> +type_init(microchip_icicle_kit_machine_init_register_types)
> diff --git a/include/hw/riscv/microchip_pfsoc.h b/include/hw/riscv/microchip_pfsoc.h
> new file mode 100644
> index 0000000..1953ef1
> --- /dev/null
> +++ b/include/hw/riscv/microchip_pfsoc.h
> @@ -0,0 +1,88 @@
> +/*
> + * Microchip PolarFire SoC machine interface
> + *
> + * Copyright (c) 2020 Wind River Systems, Inc.
> + *
> + * Author:
> + * Bin Meng <bin.meng@windriver.com>
> + *
> + * 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/>.
> + */
> +
> +#ifndef HW_MICROCHIP_PFSOC_H
> +#define HW_MICROCHIP_PFSOC_H
> +
> +typedef struct MicrochipPFSoCState {
> + /*< private >*/
> + DeviceState parent_obj;
> +
> + /*< public >*/
> + CPUClusterState e_cluster;
> + CPUClusterState u_cluster;
> + RISCVHartArrayState e_cpus;
> + RISCVHartArrayState u_cpus;
> + DeviceState *plic;
> +} MicrochipPFSoCState;
> +
> +#define TYPE_MICROCHIP_PFSOC "microchip.pfsoc"
> +#define MICROCHIP_PFSOC(obj) \
> + OBJECT_CHECK(MicrochipPFSoCState, (obj), TYPE_MICROCHIP_PFSOC)
> +
> +typedef struct MicrochipIcicleKitState {
> + /*< private >*/
> + MachineState parent_obj;
> +
> + /*< public >*/
> + MicrochipPFSoCState soc;
> +} MicrochipIcicleKitState;
> +
> +#define TYPE_MICROCHIP_ICICLE_KIT_MACHINE \
> + MACHINE_TYPE_NAME("microchip-icicle-kit")
> +#define MICROCHIP_ICICLE_KIT_MACHINE(obj) \
> + OBJECT_CHECK(MicrochipIcicleKitState, (obj), \
> + TYPE_MICROCHIP_ICICLE_KIT_MACHINE)
> +
> +enum {
> + MICROCHIP_PFSOC_DEBUG,
> + MICROCHIP_PFSOC_E51_DTIM,
> + MICROCHIP_PFSOC_BUSERR_UNIT0,
> + MICROCHIP_PFSOC_BUSERR_UNIT1,
> + MICROCHIP_PFSOC_BUSERR_UNIT2,
> + MICROCHIP_PFSOC_BUSERR_UNIT3,
> + MICROCHIP_PFSOC_BUSERR_UNIT4,
> + MICROCHIP_PFSOC_CLINT,
> + MICROCHIP_PFSOC_L2CC,
> + MICROCHIP_PFSOC_L2LIM,
> + MICROCHIP_PFSOC_PLIC,
> + MICROCHIP_PFSOC_SYSREG,
> + MICROCHIP_PFSOC_MPUCFG,
> + MICROCHIP_PFSOC_ENVM_CFG,
> + MICROCHIP_PFSOC_ENVM_DATA,
> + MICROCHIP_PFSOC_IOSCB_CFG,
> + MICROCHIP_PFSOC_DRAM,
> +};
> +
> +#define MICROCHIP_PFSOC_MANAGEMENT_CPU_COUNT 1
> +#define MICROCHIP_PFSOC_COMPUTE_CPU_COUNT 4
> +
> +#define MICROCHIP_PFSOC_PLIC_HART_CONFIG "MS"
> +#define MICROCHIP_PFSOC_PLIC_NUM_SOURCES 185
> +#define MICROCHIP_PFSOC_PLIC_NUM_PRIORITIES 7
> +#define MICROCHIP_PFSOC_PLIC_PRIORITY_BASE 0x04
> +#define MICROCHIP_PFSOC_PLIC_PENDING_BASE 0x1000
> +#define MICROCHIP_PFSOC_PLIC_ENABLE_BASE 0x2000
> +#define MICROCHIP_PFSOC_PLIC_ENABLE_STRIDE 0x80
> +#define MICROCHIP_PFSOC_PLIC_CONTEXT_BASE 0x200000
> +#define MICROCHIP_PFSOC_PLIC_CONTEXT_STRIDE 0x1000
> +
> +#endif /* HW_MICROCHIP_PFSOC_H */
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
2020-08-17 19:28 ` Alistair Francis
@ 2020-08-17 19:53 ` Cyril.Jean
-1 siblings, 0 replies; 100+ messages in thread
From: via @ 2020-08-17 19:53 UTC (permalink / raw)
To: alistair23
Cc: bmeng.cn, anup, Alistair.Francis, kbastian, palmerdabbelt,
sagark, qemu-devel, qemu-riscv, peter.maydell, alistair,
qemu-block, jasowang, bin.meng, pbonzini, palmer, qemu-arm,
marcandre.lureau, edgar.iglesias, philmd
On 8/17/20 8:28 PM, Alistair Francis wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Mon, Aug 17, 2020 at 11:12 AM via <qemu-devel@nongnu.org> wrote:
>> Hi Anup,
>>
>> On 8/17/20 11:30 AM, Bin Meng wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> Hi Anup,
>>>
>>> On Sat, Aug 15, 2020 at 1:44 AM Anup Patel <anup@brainfault.org> wrote:
>>>> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> From: Bin Meng <bin.meng@windriver.com>
>>>>>
>>>>> This adds support for Microchip PolarFire SoC Icicle Kit board.
>>>>> 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.
>>>> Nice Work !!! This is very helpful.
>>> Thanks!
>>>
>>>> The Microchip HSS is quite convoluted. It has:
>>>> 1. DDR Init
>>>> 2. Boot device support
>>>> 3. SBI support using OpenSBI as library
>>>> 4. Simple TEE support
>>>>
>>>> I think point 1) and 2) above should be part of U-Boot SPL.
>>>> The point 3) can be OpenSBI FW_DYNAMIC.
>>>>
>>>> Lastly,for point 4), we are working on a new OpenSBI feature using
>>>> which we can run independent Secure OS and Non-Secure OS using
>>>> U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
>>>> PolarFire).
>>>>
>>>> Do you have plans for adding U-Boot SPL support for this board ??
>>> + Cyril Jean from Microchip
>>>
>>> I will have to leave this question to Cyril to comment.
>>>
>> I currently do not have a plan to support U-Boot SPL. The idea of the
>> HSS is to contain all the silicon specific initialization and
>> configuration code within the HSS before jumping to U-Boot S-mode. I
>> would rather keep all this within the HSS for the time being. I would
>> wait until we reach production silicon before attempting to move this to
>> U-Boot SPL as the HSS is likely to contain some opaque silicon related
>> changes for another while.
> That is unfortunate, a lot of work has gone into making the boot flow
> simple and easy to use.
>
> QEMU now includes OpenSBI by default to make it easy for users to boot
> Linux. The Icicle Kit board is now the most difficult QEMU board to
> boot Linux on. Not to mention it makes it hard to impossible to
> support it in standard tool flows such as meta-riscv.
>
> Alistair
If it is such a problem we can add a U-Boot SPL stage and the HSS can be
treated as standard SoC ROM code.
Cyril.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
@ 2020-08-17 19:53 ` Cyril.Jean
0 siblings, 0 replies; 100+ messages in thread
From: Cyril.Jean @ 2020-08-17 19:53 UTC (permalink / raw)
To: alistair23
Cc: bmeng.cn, anup, Alistair.Francis, kbastian, palmerdabbelt,
sagark, qemu-devel, qemu-riscv, peter.maydell, alistair,
qemu-block, jasowang, bin.meng, pbonzini, palmer, qemu-arm,
marcandre.lureau, edgar.iglesias, philmd
On 8/17/20 8:28 PM, Alistair Francis wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Mon, Aug 17, 2020 at 11:12 AM via <qemu-devel@nongnu.org> wrote:
>> Hi Anup,
>>
>> On 8/17/20 11:30 AM, Bin Meng wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> Hi Anup,
>>>
>>> On Sat, Aug 15, 2020 at 1:44 AM Anup Patel <anup@brainfault.org> wrote:
>>>> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> From: Bin Meng <bin.meng@windriver.com>
>>>>>
>>>>> This adds support for Microchip PolarFire SoC Icicle Kit board.
>>>>> 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.
>>>> Nice Work !!! This is very helpful.
>>> Thanks!
>>>
>>>> The Microchip HSS is quite convoluted. It has:
>>>> 1. DDR Init
>>>> 2. Boot device support
>>>> 3. SBI support using OpenSBI as library
>>>> 4. Simple TEE support
>>>>
>>>> I think point 1) and 2) above should be part of U-Boot SPL.
>>>> The point 3) can be OpenSBI FW_DYNAMIC.
>>>>
>>>> Lastly,for point 4), we are working on a new OpenSBI feature using
>>>> which we can run independent Secure OS and Non-Secure OS using
>>>> U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
>>>> PolarFire).
>>>>
>>>> Do you have plans for adding U-Boot SPL support for this board ??
>>> + Cyril Jean from Microchip
>>>
>>> I will have to leave this question to Cyril to comment.
>>>
>> I currently do not have a plan to support U-Boot SPL. The idea of the
>> HSS is to contain all the silicon specific initialization and
>> configuration code within the HSS before jumping to U-Boot S-mode. I
>> would rather keep all this within the HSS for the time being. I would
>> wait until we reach production silicon before attempting to move this to
>> U-Boot SPL as the HSS is likely to contain some opaque silicon related
>> changes for another while.
> That is unfortunate, a lot of work has gone into making the boot flow
> simple and easy to use.
>
> QEMU now includes OpenSBI by default to make it easy for users to boot
> Linux. The Icicle Kit board is now the most difficult QEMU board to
> boot Linux on. Not to mention it makes it hard to impossible to
> support it in standard tool flows such as meta-riscv.
>
> Alistair
If it is such a problem we can add a U-Boot SPL stage and the HSS can be
treated as standard SoC ROM code.
Cyril.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 05/18] hw/char: Add Microchip PolarFire SoC MMUART emulation
2020-08-14 16:40 ` Bin Meng
@ 2020-08-17 20:51 ` Alistair Francis
-1 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-17 20:51 UTC (permalink / raw)
To: Bin Meng
Cc: Bin Meng, open list:RISC-V, Sagar Karandikar, Bastian Koppelmann,
Palmer Dabbelt, qemu-devel@nongnu.org Developers,
Alistair Francis, Paolo Bonzini, Marc-André Lureau
On Fri, Aug 14, 2020 at 9:45 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> Microchip PolarFire SoC MMUART is ns16550 compatible, with some
> additional registers. Create a simple MMUART model built on top
> of the existing ns16550 model.
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
> ---
>
> MAINTAINERS | 2 +
> hw/char/Kconfig | 3 ++
> hw/char/Makefile.objs | 1 +
> hw/char/mchp_pfsoc_mmuart.c | 82 +++++++++++++++++++++++++++++++++++++
> include/hw/char/mchp_pfsoc_mmuart.h | 61 +++++++++++++++++++++++++++
> 5 files changed, 149 insertions(+)
> create mode 100644 hw/char/mchp_pfsoc_mmuart.c
> create mode 100644 include/hw/char/mchp_pfsoc_mmuart.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8716cb6..e51edac 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1319,7 +1319,9 @@ M: Bin Meng <bin.meng@windriver.com>
> L: qemu-riscv@nongnu.org
> S: Supported
> F: hw/riscv/microchip_pfsoc.c
> +F: hw/char/mchp_pfsoc_mmuart.c
> F: include/hw/riscv/microchip_pfsoc.h
> +F: include/hw/char/mchp_pfsoc_mmuart.h
>
> RX Machines
> -----------
> diff --git a/hw/char/Kconfig b/hw/char/Kconfig
> index b7e0e4d..1d64555 100644
> --- a/hw/char/Kconfig
> +++ b/hw/char/Kconfig
> @@ -52,3 +52,6 @@ config RENESAS_SCI
>
> config AVR_USART
> bool
> +
> +config MCHP_PFSOC_MMUART
> + bool
> diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs
> index bf177ac..f705845 100644
> --- a/hw/char/Makefile.objs
> +++ b/hw/char/Makefile.objs
> @@ -33,6 +33,7 @@ common-obj-$(CONFIG_LM32) += lm32_juart.o
> common-obj-$(CONFIG_LM32) += lm32_uart.o
> common-obj-$(CONFIG_MILKYMIST) += milkymist-uart.o
> common-obj-$(CONFIG_SCLPCONSOLE) += sclpconsole.o sclpconsole-lm.o
> +common-obj-$(CONFIG_MCHP_PFSOC_MMUART) += mchp_pfsoc_mmuart.o
>
> obj-$(CONFIG_VIRTIO) += virtio-serial-bus.o
> obj-$(CONFIG_PSERIES) += spapr_vty.o
> diff --git a/hw/char/mchp_pfsoc_mmuart.c b/hw/char/mchp_pfsoc_mmuart.c
> new file mode 100644
> index 0000000..9984acc
> --- /dev/null
> +++ b/hw/char/mchp_pfsoc_mmuart.c
> @@ -0,0 +1,82 @@
> +/*
> + * Microchip PolarFire SoC MMUART emulation
> + *
> + * Copyright (c) 2020 Wind River Systems, Inc.
> + *
> + * Author:
> + * Bin Meng <bin.meng@windriver.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 or
> + * (at your option) version 3 of the License.
> + *
> + * This program is distributed in the hope that 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/log.h"
> +#include "chardev/char.h"
> +#include "exec/address-spaces.h"
> +#include "hw/char/mchp_pfsoc_mmuart.h"
> +
> +static uint64_t mchp_pfsoc_mmuart_read(void *opaque, hwaddr addr, unsigned size)
> +{
> + MchpPfSoCMMUartState *s = opaque;
> +
> + if ((addr % sizeof(uint32_t)) || (addr >= 0x34)) {
You can specify impl.min_access_size and impl.max_access_size as part
of MemoryRegionOps so the allignment check isn't required here.
> + qemu_log_mask(LOG_GUEST_ERROR, "%s: read: addr=0x%" HWADDR_PRIx "\n",
> + __func__, addr);
> + return 0;
> + }
> +
> + return s->reg[addr / sizeof(uint32_t)];
> +}
> +
> +static void mchp_pfsoc_mmuart_write(void *opaque, hwaddr addr,
> + uint64_t value, unsigned size)
> +{
> + MchpPfSoCMMUartState *s = opaque;
> + uint32_t val32 = (uint32_t)value;
> +
> + if ((addr % sizeof(uint32_t)) || (addr >= 0x34)) {
Same comment here about allignment.
Alistair
> + qemu_log_mask(LOG_GUEST_ERROR, "%s: bad write: addr=0x%" HWADDR_PRIx
> + " v=0x%x\n", __func__, addr, val32);
> + return;
> + }
> +
> + s->reg[addr / sizeof(uint32_t)] = val32;
> +}
> +
> +static const MemoryRegionOps mchp_pfsoc_mmuart_ops = {
> + .read = mchp_pfsoc_mmuart_read,
> + .write = mchp_pfsoc_mmuart_write,
> + .endianness = DEVICE_LITTLE_ENDIAN,
> +};
> +
> +MchpPfSoCMMUartState *mchp_pfsoc_mmuart_create(MemoryRegion *sysmem,
> + hwaddr base, qemu_irq irq, Chardev *chr)
> +{
> + MchpPfSoCMMUartState *s;
> +
> + s = g_new0(MchpPfSoCMMUartState, 1);
> +
> + memory_region_init_io(&s->iomem, NULL, &mchp_pfsoc_mmuart_ops, s,
> + "mchp.pfsoc.mmuart", 0x1000);
> +
> + s->base = base;
> + s->irq = irq;
> +
> + s->serial = serial_mm_init(sysmem, base, 2, irq, 399193, chr,
> + DEVICE_LITTLE_ENDIAN);
> +
> + memory_region_add_subregion(sysmem, base + 0x20, &s->iomem);
> +
> + return s;
> +}
> diff --git a/include/hw/char/mchp_pfsoc_mmuart.h b/include/hw/char/mchp_pfsoc_mmuart.h
> new file mode 100644
> index 0000000..f619902
> --- /dev/null
> +++ b/include/hw/char/mchp_pfsoc_mmuart.h
> @@ -0,0 +1,61 @@
> +/*
> + * Microchip PolarFire SoC MMUART emulation
> + *
> + * Copyright (c) 2020 Wind River Systems, Inc.
> + *
> + * Author:
> + * Bin Meng <bin.meng@windriver.com>
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to deal
> + * in the Software without restriction, including without limitation the rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> + * THE SOFTWARE.
> + */
> +
> +#ifndef HW_MCHP_PFSOC_MMUART_H
> +#define HW_MCHP_PFSOC_MMUART_H
> +
> +#include "hw/char/serial.h"
> +
> +#define MCHP_PFSOC_MMUART_REG_SIZE 52
> +
> +typedef struct MchpPfSoCMMUartState {
> + MemoryRegion iomem;
> + hwaddr base;
> + qemu_irq irq;
> +
> + SerialMM *serial;
> +
> + uint32_t reg[MCHP_PFSOC_MMUART_REG_SIZE / sizeof(uint32_t)];
> +} MchpPfSoCMMUartState;
> +
> +/**
> + * mchp_pfsoc_mmuart_create - Create a Microchip PolarFire SoC MMUART
> + *
> + * This is a helper routine for board to create a MMUART device that is
> + * compatible with Microchip PolarFire SoC.
> + *
> + * @sysmem: system memory region to map
> + * @base: base address of the MMUART registers
> + * @irq: IRQ number of the MMUART device
> + * @chr: character device to associate to
> + *
> + * @return: a pointer to the device specific control structure
> + */
> +MchpPfSoCMMUartState *mchp_pfsoc_mmuart_create(MemoryRegion *sysmem,
> + hwaddr base, qemu_irq irq, Chardev *chr);
> +
> +#endif /* HW_MCHP_PFSOC_MMUART_H */
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 05/18] hw/char: Add Microchip PolarFire SoC MMUART emulation
@ 2020-08-17 20:51 ` Alistair Francis
0 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-17 20:51 UTC (permalink / raw)
To: Bin Meng
Cc: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel@nongnu.org Developers,
open list:RISC-V, Marc-André Lureau, Bin Meng,
Paolo Bonzini
On Fri, Aug 14, 2020 at 9:45 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> Microchip PolarFire SoC MMUART is ns16550 compatible, with some
> additional registers. Create a simple MMUART model built on top
> of the existing ns16550 model.
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
> ---
>
> MAINTAINERS | 2 +
> hw/char/Kconfig | 3 ++
> hw/char/Makefile.objs | 1 +
> hw/char/mchp_pfsoc_mmuart.c | 82 +++++++++++++++++++++++++++++++++++++
> include/hw/char/mchp_pfsoc_mmuart.h | 61 +++++++++++++++++++++++++++
> 5 files changed, 149 insertions(+)
> create mode 100644 hw/char/mchp_pfsoc_mmuart.c
> create mode 100644 include/hw/char/mchp_pfsoc_mmuart.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8716cb6..e51edac 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1319,7 +1319,9 @@ M: Bin Meng <bin.meng@windriver.com>
> L: qemu-riscv@nongnu.org
> S: Supported
> F: hw/riscv/microchip_pfsoc.c
> +F: hw/char/mchp_pfsoc_mmuart.c
> F: include/hw/riscv/microchip_pfsoc.h
> +F: include/hw/char/mchp_pfsoc_mmuart.h
>
> RX Machines
> -----------
> diff --git a/hw/char/Kconfig b/hw/char/Kconfig
> index b7e0e4d..1d64555 100644
> --- a/hw/char/Kconfig
> +++ b/hw/char/Kconfig
> @@ -52,3 +52,6 @@ config RENESAS_SCI
>
> config AVR_USART
> bool
> +
> +config MCHP_PFSOC_MMUART
> + bool
> diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs
> index bf177ac..f705845 100644
> --- a/hw/char/Makefile.objs
> +++ b/hw/char/Makefile.objs
> @@ -33,6 +33,7 @@ common-obj-$(CONFIG_LM32) += lm32_juart.o
> common-obj-$(CONFIG_LM32) += lm32_uart.o
> common-obj-$(CONFIG_MILKYMIST) += milkymist-uart.o
> common-obj-$(CONFIG_SCLPCONSOLE) += sclpconsole.o sclpconsole-lm.o
> +common-obj-$(CONFIG_MCHP_PFSOC_MMUART) += mchp_pfsoc_mmuart.o
>
> obj-$(CONFIG_VIRTIO) += virtio-serial-bus.o
> obj-$(CONFIG_PSERIES) += spapr_vty.o
> diff --git a/hw/char/mchp_pfsoc_mmuart.c b/hw/char/mchp_pfsoc_mmuart.c
> new file mode 100644
> index 0000000..9984acc
> --- /dev/null
> +++ b/hw/char/mchp_pfsoc_mmuart.c
> @@ -0,0 +1,82 @@
> +/*
> + * Microchip PolarFire SoC MMUART emulation
> + *
> + * Copyright (c) 2020 Wind River Systems, Inc.
> + *
> + * Author:
> + * Bin Meng <bin.meng@windriver.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 or
> + * (at your option) version 3 of the License.
> + *
> + * This program is distributed in the hope that 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/log.h"
> +#include "chardev/char.h"
> +#include "exec/address-spaces.h"
> +#include "hw/char/mchp_pfsoc_mmuart.h"
> +
> +static uint64_t mchp_pfsoc_mmuart_read(void *opaque, hwaddr addr, unsigned size)
> +{
> + MchpPfSoCMMUartState *s = opaque;
> +
> + if ((addr % sizeof(uint32_t)) || (addr >= 0x34)) {
You can specify impl.min_access_size and impl.max_access_size as part
of MemoryRegionOps so the allignment check isn't required here.
> + qemu_log_mask(LOG_GUEST_ERROR, "%s: read: addr=0x%" HWADDR_PRIx "\n",
> + __func__, addr);
> + return 0;
> + }
> +
> + return s->reg[addr / sizeof(uint32_t)];
> +}
> +
> +static void mchp_pfsoc_mmuart_write(void *opaque, hwaddr addr,
> + uint64_t value, unsigned size)
> +{
> + MchpPfSoCMMUartState *s = opaque;
> + uint32_t val32 = (uint32_t)value;
> +
> + if ((addr % sizeof(uint32_t)) || (addr >= 0x34)) {
Same comment here about allignment.
Alistair
> + qemu_log_mask(LOG_GUEST_ERROR, "%s: bad write: addr=0x%" HWADDR_PRIx
> + " v=0x%x\n", __func__, addr, val32);
> + return;
> + }
> +
> + s->reg[addr / sizeof(uint32_t)] = val32;
> +}
> +
> +static const MemoryRegionOps mchp_pfsoc_mmuart_ops = {
> + .read = mchp_pfsoc_mmuart_read,
> + .write = mchp_pfsoc_mmuart_write,
> + .endianness = DEVICE_LITTLE_ENDIAN,
> +};
> +
> +MchpPfSoCMMUartState *mchp_pfsoc_mmuart_create(MemoryRegion *sysmem,
> + hwaddr base, qemu_irq irq, Chardev *chr)
> +{
> + MchpPfSoCMMUartState *s;
> +
> + s = g_new0(MchpPfSoCMMUartState, 1);
> +
> + memory_region_init_io(&s->iomem, NULL, &mchp_pfsoc_mmuart_ops, s,
> + "mchp.pfsoc.mmuart", 0x1000);
> +
> + s->base = base;
> + s->irq = irq;
> +
> + s->serial = serial_mm_init(sysmem, base, 2, irq, 399193, chr,
> + DEVICE_LITTLE_ENDIAN);
> +
> + memory_region_add_subregion(sysmem, base + 0x20, &s->iomem);
> +
> + return s;
> +}
> diff --git a/include/hw/char/mchp_pfsoc_mmuart.h b/include/hw/char/mchp_pfsoc_mmuart.h
> new file mode 100644
> index 0000000..f619902
> --- /dev/null
> +++ b/include/hw/char/mchp_pfsoc_mmuart.h
> @@ -0,0 +1,61 @@
> +/*
> + * Microchip PolarFire SoC MMUART emulation
> + *
> + * Copyright (c) 2020 Wind River Systems, Inc.
> + *
> + * Author:
> + * Bin Meng <bin.meng@windriver.com>
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to deal
> + * in the Software without restriction, including without limitation the rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> + * THE SOFTWARE.
> + */
> +
> +#ifndef HW_MCHP_PFSOC_MMUART_H
> +#define HW_MCHP_PFSOC_MMUART_H
> +
> +#include "hw/char/serial.h"
> +
> +#define MCHP_PFSOC_MMUART_REG_SIZE 52
> +
> +typedef struct MchpPfSoCMMUartState {
> + MemoryRegion iomem;
> + hwaddr base;
> + qemu_irq irq;
> +
> + SerialMM *serial;
> +
> + uint32_t reg[MCHP_PFSOC_MMUART_REG_SIZE / sizeof(uint32_t)];
> +} MchpPfSoCMMUartState;
> +
> +/**
> + * mchp_pfsoc_mmuart_create - Create a Microchip PolarFire SoC MMUART
> + *
> + * This is a helper routine for board to create a MMUART device that is
> + * compatible with Microchip PolarFire SoC.
> + *
> + * @sysmem: system memory region to map
> + * @base: base address of the MMUART registers
> + * @irq: IRQ number of the MMUART device
> + * @chr: character device to associate to
> + *
> + * @return: a pointer to the device specific control structure
> + */
> +MchpPfSoCMMUartState *mchp_pfsoc_mmuart_create(MemoryRegion *sysmem,
> + hwaddr base, qemu_irq irq, Chardev *chr);
> +
> +#endif /* HW_MCHP_PFSOC_MMUART_H */
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 06/18] hw/riscv: microchip_pfsoc: Connect 5 MMUARTs
2020-08-14 16:40 ` [PATCH 06/18] hw/riscv: microchip_pfsoc: Connect 5 MMUARTs Bin Meng
@ 2020-08-17 21:06 ` Alistair Francis
0 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-17 21:06 UTC (permalink / raw)
To: Bin Meng
Cc: Bin Meng, open list:RISC-V, Sagar Karandikar, Bastian Koppelmann,
Palmer Dabbelt, qemu-devel@nongnu.org Developers,
Alistair Francis, Palmer Dabbelt
On Fri, Aug 14, 2020 at 9:49 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> 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>
Alistair
> ---
>
> hw/riscv/Kconfig | 1 +
> hw/riscv/microchip_pfsoc.c | 30 ++++++++++++++++++++++++++++++
> include/hw/riscv/microchip_pfsoc.h | 20 ++++++++++++++++++++
> 3 files changed, 51 insertions(+)
>
> diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
> index 3292fae..ceb7c16 100644
> --- a/hw/riscv/Kconfig
> +++ b/hw/riscv/Kconfig
> @@ -54,3 +54,4 @@ config MICROCHIP_PFSOC
> select HART
> select SIFIVE
> select UNIMP
> + select MCHP_PFSOC_MMUART
> diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
> index 20a642c..f6b375c 100644
> --- a/hw/riscv/microchip_pfsoc.c
> +++ b/hw/riscv/microchip_pfsoc.c
> @@ -11,6 +11,7 @@
> * 0) CLINT (Core Level Interruptor)
> * 1) PLIC (Platform Level Interrupt Controller)
> * 2) eNVM (Embedded Non-Volatile Memory)
> + * 3) MMUARTs (Multi-Mode UART)
> *
> * This board currently generates devicetree dynamically that indicates at least
> * two harts and up to five harts.
> @@ -38,6 +39,7 @@
> #include "hw/irq.h"
> #include "hw/loader.h"
> #include "hw/sysbus.h"
> +#include "chardev/char.h"
> #include "hw/cpu/cluster.h"
> #include "target/riscv/cpu.h"
> #include "hw/misc/unimp.h"
> @@ -46,6 +48,7 @@
> #include "hw/riscv/sifive_clint.h"
> #include "hw/riscv/sifive_plic.h"
> #include "hw/riscv/microchip_pfsoc.h"
> +#include "sysemu/sysemu.h"
>
> /*
> * The BIOS image used by this machine is called Hart Software Services (HSS).
> @@ -69,8 +72,13 @@ static const struct MemmapEntry {
> [MICROCHIP_PFSOC_L2CC] = { 0x2010000, 0x1000 },
> [MICROCHIP_PFSOC_L2LIM] = { 0x8000000, 0x2000000 },
> [MICROCHIP_PFSOC_PLIC] = { 0xc000000, 0x4000000 },
> + [MICROCHIP_PFSOC_MMUART0] = { 0x20000000, 0x1000 },
> [MICROCHIP_PFSOC_SYSREG] = { 0x20002000, 0x2000 },
> [MICROCHIP_PFSOC_MPUCFG] = { 0x20005000, 0x1000 },
> + [MICROCHIP_PFSOC_MMUART1] = { 0x20100000, 0x1000 },
> + [MICROCHIP_PFSOC_MMUART2] = { 0x20102000, 0x1000 },
> + [MICROCHIP_PFSOC_MMUART3] = { 0x20104000, 0x1000 },
> + [MICROCHIP_PFSOC_MMUART4] = { 0x20106000, 0x1000 },
> [MICROCHIP_PFSOC_ENVM_CFG] = { 0x20200000, 0x1000 },
> [MICROCHIP_PFSOC_ENVM_DATA] = { 0x20220000, 0x20000 },
> [MICROCHIP_PFSOC_IOSCB_CFG] = { 0x37080000, 0x1000 },
> @@ -215,6 +223,28 @@ static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
> memmap[MICROCHIP_PFSOC_MPUCFG].base,
> memmap[MICROCHIP_PFSOC_MPUCFG].size);
>
> + /* 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));
> +
> /* eNVM */
> memory_region_init_rom(envm_data, OBJECT(dev), "microchip.pfsoc.envm.data",
> memmap[MICROCHIP_PFSOC_ENVM_DATA].size,
> diff --git a/include/hw/riscv/microchip_pfsoc.h b/include/hw/riscv/microchip_pfsoc.h
> index 1953ef1..a5efa1d 100644
> --- a/include/hw/riscv/microchip_pfsoc.h
> +++ b/include/hw/riscv/microchip_pfsoc.h
> @@ -22,6 +22,8 @@
> #ifndef HW_MICROCHIP_PFSOC_H
> #define HW_MICROCHIP_PFSOC_H
>
> +#include "hw/char/mchp_pfsoc_mmuart.h"
> +
> typedef struct MicrochipPFSoCState {
> /*< private >*/
> DeviceState parent_obj;
> @@ -32,6 +34,11 @@ typedef struct MicrochipPFSoCState {
> RISCVHartArrayState e_cpus;
> RISCVHartArrayState u_cpus;
> DeviceState *plic;
> + MchpPfSoCMMUartState *serial0;
> + MchpPfSoCMMUartState *serial1;
> + MchpPfSoCMMUartState *serial2;
> + MchpPfSoCMMUartState *serial3;
> + MchpPfSoCMMUartState *serial4;
> } MicrochipPFSoCState;
>
> #define TYPE_MICROCHIP_PFSOC "microchip.pfsoc"
> @@ -64,14 +71,27 @@ enum {
> MICROCHIP_PFSOC_L2CC,
> MICROCHIP_PFSOC_L2LIM,
> MICROCHIP_PFSOC_PLIC,
> + MICROCHIP_PFSOC_MMUART0,
> MICROCHIP_PFSOC_SYSREG,
> MICROCHIP_PFSOC_MPUCFG,
> + MICROCHIP_PFSOC_MMUART1,
> + MICROCHIP_PFSOC_MMUART2,
> + MICROCHIP_PFSOC_MMUART3,
> + MICROCHIP_PFSOC_MMUART4,
> MICROCHIP_PFSOC_ENVM_CFG,
> MICROCHIP_PFSOC_ENVM_DATA,
> MICROCHIP_PFSOC_IOSCB_CFG,
> MICROCHIP_PFSOC_DRAM,
> };
>
> +enum {
> + MICROCHIP_PFSOC_MMUART0_IRQ = 90,
> + MICROCHIP_PFSOC_MMUART1_IRQ = 91,
> + MICROCHIP_PFSOC_MMUART2_IRQ = 92,
> + MICROCHIP_PFSOC_MMUART3_IRQ = 93,
> + MICROCHIP_PFSOC_MMUART4_IRQ = 94,
> +};
> +
> #define MICROCHIP_PFSOC_MANAGEMENT_CPU_COUNT 1
> #define MICROCHIP_PFSOC_COMPUTE_CPU_COUNT 4
>
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 06/18] hw/riscv: microchip_pfsoc: Connect 5 MMUARTs
@ 2020-08-17 21:06 ` Alistair Francis
0 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-17 21:06 UTC (permalink / raw)
To: Bin Meng
Cc: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel@nongnu.org Developers,
open list:RISC-V, Bin Meng, Palmer Dabbelt
On Fri, Aug 14, 2020 at 9:49 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> 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>
Alistair
> ---
>
> hw/riscv/Kconfig | 1 +
> hw/riscv/microchip_pfsoc.c | 30 ++++++++++++++++++++++++++++++
> include/hw/riscv/microchip_pfsoc.h | 20 ++++++++++++++++++++
> 3 files changed, 51 insertions(+)
>
> diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
> index 3292fae..ceb7c16 100644
> --- a/hw/riscv/Kconfig
> +++ b/hw/riscv/Kconfig
> @@ -54,3 +54,4 @@ config MICROCHIP_PFSOC
> select HART
> select SIFIVE
> select UNIMP
> + select MCHP_PFSOC_MMUART
> diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
> index 20a642c..f6b375c 100644
> --- a/hw/riscv/microchip_pfsoc.c
> +++ b/hw/riscv/microchip_pfsoc.c
> @@ -11,6 +11,7 @@
> * 0) CLINT (Core Level Interruptor)
> * 1) PLIC (Platform Level Interrupt Controller)
> * 2) eNVM (Embedded Non-Volatile Memory)
> + * 3) MMUARTs (Multi-Mode UART)
> *
> * This board currently generates devicetree dynamically that indicates at least
> * two harts and up to five harts.
> @@ -38,6 +39,7 @@
> #include "hw/irq.h"
> #include "hw/loader.h"
> #include "hw/sysbus.h"
> +#include "chardev/char.h"
> #include "hw/cpu/cluster.h"
> #include "target/riscv/cpu.h"
> #include "hw/misc/unimp.h"
> @@ -46,6 +48,7 @@
> #include "hw/riscv/sifive_clint.h"
> #include "hw/riscv/sifive_plic.h"
> #include "hw/riscv/microchip_pfsoc.h"
> +#include "sysemu/sysemu.h"
>
> /*
> * The BIOS image used by this machine is called Hart Software Services (HSS).
> @@ -69,8 +72,13 @@ static const struct MemmapEntry {
> [MICROCHIP_PFSOC_L2CC] = { 0x2010000, 0x1000 },
> [MICROCHIP_PFSOC_L2LIM] = { 0x8000000, 0x2000000 },
> [MICROCHIP_PFSOC_PLIC] = { 0xc000000, 0x4000000 },
> + [MICROCHIP_PFSOC_MMUART0] = { 0x20000000, 0x1000 },
> [MICROCHIP_PFSOC_SYSREG] = { 0x20002000, 0x2000 },
> [MICROCHIP_PFSOC_MPUCFG] = { 0x20005000, 0x1000 },
> + [MICROCHIP_PFSOC_MMUART1] = { 0x20100000, 0x1000 },
> + [MICROCHIP_PFSOC_MMUART2] = { 0x20102000, 0x1000 },
> + [MICROCHIP_PFSOC_MMUART3] = { 0x20104000, 0x1000 },
> + [MICROCHIP_PFSOC_MMUART4] = { 0x20106000, 0x1000 },
> [MICROCHIP_PFSOC_ENVM_CFG] = { 0x20200000, 0x1000 },
> [MICROCHIP_PFSOC_ENVM_DATA] = { 0x20220000, 0x20000 },
> [MICROCHIP_PFSOC_IOSCB_CFG] = { 0x37080000, 0x1000 },
> @@ -215,6 +223,28 @@ static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
> memmap[MICROCHIP_PFSOC_MPUCFG].base,
> memmap[MICROCHIP_PFSOC_MPUCFG].size);
>
> + /* 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));
> +
> /* eNVM */
> memory_region_init_rom(envm_data, OBJECT(dev), "microchip.pfsoc.envm.data",
> memmap[MICROCHIP_PFSOC_ENVM_DATA].size,
> diff --git a/include/hw/riscv/microchip_pfsoc.h b/include/hw/riscv/microchip_pfsoc.h
> index 1953ef1..a5efa1d 100644
> --- a/include/hw/riscv/microchip_pfsoc.h
> +++ b/include/hw/riscv/microchip_pfsoc.h
> @@ -22,6 +22,8 @@
> #ifndef HW_MICROCHIP_PFSOC_H
> #define HW_MICROCHIP_PFSOC_H
>
> +#include "hw/char/mchp_pfsoc_mmuart.h"
> +
> typedef struct MicrochipPFSoCState {
> /*< private >*/
> DeviceState parent_obj;
> @@ -32,6 +34,11 @@ typedef struct MicrochipPFSoCState {
> RISCVHartArrayState e_cpus;
> RISCVHartArrayState u_cpus;
> DeviceState *plic;
> + MchpPfSoCMMUartState *serial0;
> + MchpPfSoCMMUartState *serial1;
> + MchpPfSoCMMUartState *serial2;
> + MchpPfSoCMMUartState *serial3;
> + MchpPfSoCMMUartState *serial4;
> } MicrochipPFSoCState;
>
> #define TYPE_MICROCHIP_PFSOC "microchip.pfsoc"
> @@ -64,14 +71,27 @@ enum {
> MICROCHIP_PFSOC_L2CC,
> MICROCHIP_PFSOC_L2LIM,
> MICROCHIP_PFSOC_PLIC,
> + MICROCHIP_PFSOC_MMUART0,
> MICROCHIP_PFSOC_SYSREG,
> MICROCHIP_PFSOC_MPUCFG,
> + MICROCHIP_PFSOC_MMUART1,
> + MICROCHIP_PFSOC_MMUART2,
> + MICROCHIP_PFSOC_MMUART3,
> + MICROCHIP_PFSOC_MMUART4,
> MICROCHIP_PFSOC_ENVM_CFG,
> MICROCHIP_PFSOC_ENVM_DATA,
> MICROCHIP_PFSOC_IOSCB_CFG,
> MICROCHIP_PFSOC_DRAM,
> };
>
> +enum {
> + MICROCHIP_PFSOC_MMUART0_IRQ = 90,
> + MICROCHIP_PFSOC_MMUART1_IRQ = 91,
> + MICROCHIP_PFSOC_MMUART2_IRQ = 92,
> + MICROCHIP_PFSOC_MMUART3_IRQ = 93,
> + MICROCHIP_PFSOC_MMUART4_IRQ = 94,
> +};
> +
> #define MICROCHIP_PFSOC_MANAGEMENT_CPU_COUNT 1
> #define MICROCHIP_PFSOC_COMPUTE_CPU_COUNT 4
>
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
2020-08-17 19:53 ` Cyril.Jean
@ 2020-08-18 6:17 ` Anup Patel
-1 siblings, 0 replies; 100+ messages in thread
From: Anup Patel @ 2020-08-18 6:17 UTC (permalink / raw)
To: Cyril.Jean
Cc: Peter Maydell, Alistair Francis, open list:RISC-V, qemu-block,
Sagar Karandikar, Bin Meng, Bastian Koppelmann, Jason Wang,
Palmer Dabbelt, Edgar E. Iglesias, QEMU Developers,
Marc-André Lureau, qemu-arm, Alistair Francis,
Paolo Bonzini, Alistair Francis, Bin Meng,
Philippe Mathieu-Daudé,
Palmer Dabbelt
On Tue, Aug 18, 2020 at 1:23 AM <Cyril.Jean@microchip.com> wrote:
>
> On 8/17/20 8:28 PM, Alistair Francis wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > On Mon, Aug 17, 2020 at 11:12 AM via <qemu-devel@nongnu.org> wrote:
> >> Hi Anup,
> >>
> >> On 8/17/20 11:30 AM, Bin Meng wrote:
> >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>
> >>> Hi Anup,
> >>>
> >>> On Sat, Aug 15, 2020 at 1:44 AM Anup Patel <anup@brainfault.org> wrote:
> >>>> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >>>>> From: Bin Meng <bin.meng@windriver.com>
> >>>>>
> >>>>> This adds support for Microchip PolarFire SoC Icicle Kit board.
> >>>>> 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.
> >>>> Nice Work !!! This is very helpful.
> >>> Thanks!
> >>>
> >>>> The Microchip HSS is quite convoluted. It has:
> >>>> 1. DDR Init
> >>>> 2. Boot device support
> >>>> 3. SBI support using OpenSBI as library
> >>>> 4. Simple TEE support
> >>>>
> >>>> I think point 1) and 2) above should be part of U-Boot SPL.
> >>>> The point 3) can be OpenSBI FW_DYNAMIC.
> >>>>
> >>>> Lastly,for point 4), we are working on a new OpenSBI feature using
> >>>> which we can run independent Secure OS and Non-Secure OS using
> >>>> U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
> >>>> PolarFire).
> >>>>
> >>>> Do you have plans for adding U-Boot SPL support for this board ??
> >>> + Cyril Jean from Microchip
> >>>
> >>> I will have to leave this question to Cyril to comment.
> >>>
> >> I currently do not have a plan to support U-Boot SPL. The idea of the
> >> HSS is to contain all the silicon specific initialization and
> >> configuration code within the HSS before jumping to U-Boot S-mode. I
> >> would rather keep all this within the HSS for the time being. I would
> >> wait until we reach production silicon before attempting to move this to
> >> U-Boot SPL as the HSS is likely to contain some opaque silicon related
> >> changes for another while.
> > That is unfortunate, a lot of work has gone into making the boot flow
> > simple and easy to use.
> >
> > QEMU now includes OpenSBI by default to make it easy for users to boot
> > Linux. The Icicle Kit board is now the most difficult QEMU board to
> > boot Linux on. Not to mention it makes it hard to impossible to
> > support it in standard tool flows such as meta-riscv.
> >
> > Alistair
>
> If it is such a problem we can add a U-Boot SPL stage and the HSS can be
> treated as standard SoC ROM code.
It's not mandatory for U-Boot SPL to have stable DRAM calibration settings
from the start itself. The initial U-Boot SPL support for most
platforms (accross
architectures) usually include basic working DRAM calibration settings which
is later on updated with separate patches. Also, we don't need all U-Boot
drivers to be upstreamed in one-go as this can be done in phases.
The advantage we have with PolarFire SoC Icicle board is that we already
have a U-Boot S-mode. and we believe the OpenSBI generic platform will
work fine for PolarFire SoC Icicle board so the only thing missing right now
is the U-Boot SPL support for OpenSource boot-flow.
It will certainly accelerate open-source development if we have boot-flow
U-Boot_SPL => OpenSBI (FW_DYNAMIC) => U-Boot_S-mode working
on PolarFire SoC Icicle board. Initially, we just need DRAM, SD/eMMC,
and Serial port support for U-Boot SPL and U-Boot S-mode. Later on,
more patches can add ethernet and other booting device drivers to U-Boot.
Regarding security services of HSS, we are working on a OpenSBI
feature which will allow HSS security services to run as independent
binary in M-mode (not linked to OpenSBI) and OpenSBI FW_DYNAMIC
will be a separate binary acting as a secure monitor.
Regards,
Anup
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
@ 2020-08-18 6:17 ` Anup Patel
0 siblings, 0 replies; 100+ messages in thread
From: Anup Patel @ 2020-08-18 6:17 UTC (permalink / raw)
To: Cyril.Jean
Cc: Alistair Francis, Bin Meng, Alistair Francis, Bastian Koppelmann,
Palmer Dabbelt, Sagar Karandikar, QEMU Developers,
open list:RISC-V, Peter Maydell, Alistair Francis, qemu-block,
Jason Wang, Bin Meng, Paolo Bonzini, Palmer Dabbelt, qemu-arm,
Marc-André Lureau, Edgar E. Iglesias,
Philippe Mathieu-Daudé
On Tue, Aug 18, 2020 at 1:23 AM <Cyril.Jean@microchip.com> wrote:
>
> On 8/17/20 8:28 PM, Alistair Francis wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > On Mon, Aug 17, 2020 at 11:12 AM via <qemu-devel@nongnu.org> wrote:
> >> Hi Anup,
> >>
> >> On 8/17/20 11:30 AM, Bin Meng wrote:
> >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>
> >>> Hi Anup,
> >>>
> >>> On Sat, Aug 15, 2020 at 1:44 AM Anup Patel <anup@brainfault.org> wrote:
> >>>> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >>>>> From: Bin Meng <bin.meng@windriver.com>
> >>>>>
> >>>>> This adds support for Microchip PolarFire SoC Icicle Kit board.
> >>>>> 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.
> >>>> Nice Work !!! This is very helpful.
> >>> Thanks!
> >>>
> >>>> The Microchip HSS is quite convoluted. It has:
> >>>> 1. DDR Init
> >>>> 2. Boot device support
> >>>> 3. SBI support using OpenSBI as library
> >>>> 4. Simple TEE support
> >>>>
> >>>> I think point 1) and 2) above should be part of U-Boot SPL.
> >>>> The point 3) can be OpenSBI FW_DYNAMIC.
> >>>>
> >>>> Lastly,for point 4), we are working on a new OpenSBI feature using
> >>>> which we can run independent Secure OS and Non-Secure OS using
> >>>> U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
> >>>> PolarFire).
> >>>>
> >>>> Do you have plans for adding U-Boot SPL support for this board ??
> >>> + Cyril Jean from Microchip
> >>>
> >>> I will have to leave this question to Cyril to comment.
> >>>
> >> I currently do not have a plan to support U-Boot SPL. The idea of the
> >> HSS is to contain all the silicon specific initialization and
> >> configuration code within the HSS before jumping to U-Boot S-mode. I
> >> would rather keep all this within the HSS for the time being. I would
> >> wait until we reach production silicon before attempting to move this to
> >> U-Boot SPL as the HSS is likely to contain some opaque silicon related
> >> changes for another while.
> > That is unfortunate, a lot of work has gone into making the boot flow
> > simple and easy to use.
> >
> > QEMU now includes OpenSBI by default to make it easy for users to boot
> > Linux. The Icicle Kit board is now the most difficult QEMU board to
> > boot Linux on. Not to mention it makes it hard to impossible to
> > support it in standard tool flows such as meta-riscv.
> >
> > Alistair
>
> If it is such a problem we can add a U-Boot SPL stage and the HSS can be
> treated as standard SoC ROM code.
It's not mandatory for U-Boot SPL to have stable DRAM calibration settings
from the start itself. The initial U-Boot SPL support for most
platforms (accross
architectures) usually include basic working DRAM calibration settings which
is later on updated with separate patches. Also, we don't need all U-Boot
drivers to be upstreamed in one-go as this can be done in phases.
The advantage we have with PolarFire SoC Icicle board is that we already
have a U-Boot S-mode. and we believe the OpenSBI generic platform will
work fine for PolarFire SoC Icicle board so the only thing missing right now
is the U-Boot SPL support for OpenSource boot-flow.
It will certainly accelerate open-source development if we have boot-flow
U-Boot_SPL => OpenSBI (FW_DYNAMIC) => U-Boot_S-mode working
on PolarFire SoC Icicle board. Initially, we just need DRAM, SD/eMMC,
and Serial port support for U-Boot SPL and U-Boot S-mode. Later on,
more patches can add ethernet and other booting device drivers to U-Boot.
Regarding security services of HSS, we are working on a OpenSBI
feature which will allow HSS security services to run as independent
binary in M-mode (not linked to OpenSBI) and OpenSBI FW_DYNAMIC
will be a separate binary acting as a secure monitor.
Regards,
Anup
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
2020-08-18 6:17 ` Anup Patel
@ 2020-08-18 13:09 ` Cyril.Jean
-1 siblings, 0 replies; 100+ messages in thread
From: via @ 2020-08-18 13:09 UTC (permalink / raw)
To: anup
Cc: alistair23, bmeng.cn, Alistair.Francis, kbastian, palmerdabbelt,
sagark, qemu-devel, qemu-riscv, peter.maydell, alistair,
qemu-block, jasowang, bin.meng, pbonzini, palmer, qemu-arm,
marcandre.lureau, edgar.iglesias, philmd
On 8/18/20 7:17 AM, Anup Patel wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Tue, Aug 18, 2020 at 1:23 AM <Cyril.Jean@microchip.com> wrote:
>> On 8/17/20 8:28 PM, Alistair Francis wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> On Mon, Aug 17, 2020 at 11:12 AM via <qemu-devel@nongnu.org> wrote:
>>>> Hi Anup,
>>>>
>>>> On 8/17/20 11:30 AM, Bin Meng wrote:
>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>>>
>>>>> Hi Anup,
>>>>>
>>>>> On Sat, Aug 15, 2020 at 1:44 AM Anup Patel <anup@brainfault.org> wrote:
>>>>>> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>> From: Bin Meng <bin.meng@windriver.com>
>>>>>>>
>>>>>>> This adds support for Microchip PolarFire SoC Icicle Kit board.
>>>>>>> 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.
>>>>>> Nice Work !!! This is very helpful.
>>>>> Thanks!
>>>>>
>>>>>> The Microchip HSS is quite convoluted. It has:
>>>>>> 1. DDR Init
>>>>>> 2. Boot device support
>>>>>> 3. SBI support using OpenSBI as library
>>>>>> 4. Simple TEE support
>>>>>>
>>>>>> I think point 1) and 2) above should be part of U-Boot SPL.
>>>>>> The point 3) can be OpenSBI FW_DYNAMIC.
>>>>>>
>>>>>> Lastly,for point 4), we are working on a new OpenSBI feature using
>>>>>> which we can run independent Secure OS and Non-Secure OS using
>>>>>> U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
>>>>>> PolarFire).
>>>>>>
>>>>>> Do you have plans for adding U-Boot SPL support for this board ??
>>>>> + Cyril Jean from Microchip
>>>>>
>>>>> I will have to leave this question to Cyril to comment.
>>>>>
>>>> I currently do not have a plan to support U-Boot SPL. The idea of the
>>>> HSS is to contain all the silicon specific initialization and
>>>> configuration code within the HSS before jumping to U-Boot S-mode. I
>>>> would rather keep all this within the HSS for the time being. I would
>>>> wait until we reach production silicon before attempting to move this to
>>>> U-Boot SPL as the HSS is likely to contain some opaque silicon related
>>>> changes for another while.
>>> That is unfortunate, a lot of work has gone into making the boot flow
>>> simple and easy to use.
>>>
>>> QEMU now includes OpenSBI by default to make it easy for users to boot
>>> Linux. The Icicle Kit board is now the most difficult QEMU board to
>>> boot Linux on. Not to mention it makes it hard to impossible to
>>> support it in standard tool flows such as meta-riscv.
>>>
>>> Alistair
>> If it is such a problem we can add a U-Boot SPL stage and the HSS can be
>> treated as standard SoC ROM code.
> It's not mandatory for U-Boot SPL to have stable DRAM calibration settings
> from the start itself. The initial U-Boot SPL support for most
> platforms (accross
> architectures) usually include basic working DRAM calibration settings which
> is later on updated with separate patches. Also, we don't need all U-Boot
> drivers to be upstreamed in one-go as this can be done in phases.
>
> The advantage we have with PolarFire SoC Icicle board is that we already
> have a U-Boot S-mode. and we believe the OpenSBI generic platform will
> work fine for PolarFire SoC Icicle board so the only thing missing right now
> is the U-Boot SPL support for OpenSource boot-flow.
>
> It will certainly accelerate open-source development if we have boot-flow
> U-Boot_SPL => OpenSBI (FW_DYNAMIC) => U-Boot_S-mode working
> on PolarFire SoC Icicle board. Initially, we just need DRAM, SD/eMMC,
> and Serial port support for U-Boot SPL and U-Boot S-mode. Later on,
> more patches can add ethernet and other booting device drivers to U-Boot.
>
> Regarding security services of HSS, we are working on a OpenSBI
> feature which will allow HSS security services to run as independent
> binary in M-mode (not linked to OpenSBI) and OpenSBI FW_DYNAMIC
> will be a separate binary acting as a secure monitor.
>
> Regards,
> Anup
What I have in mind is that the external memory will be up and running
by the time we get to U-Boot SPL. In the case of PolarFire SoC the ROM
code equivalent brings up the DDR memory interface so we do not need to
worry about this as part of U-Boot.
Sounds to me the component that needs to be upstreamed next is the eMMC
support so that it can be used as part of U-Boot SPL. Correct?
Regards,
Cyril.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
@ 2020-08-18 13:09 ` Cyril.Jean
0 siblings, 0 replies; 100+ messages in thread
From: Cyril.Jean @ 2020-08-18 13:09 UTC (permalink / raw)
To: anup
Cc: alistair23, bmeng.cn, Alistair.Francis, kbastian, palmerdabbelt,
sagark, qemu-devel, qemu-riscv, peter.maydell, alistair,
qemu-block, jasowang, bin.meng, pbonzini, palmer, qemu-arm,
marcandre.lureau, edgar.iglesias, philmd
On 8/18/20 7:17 AM, Anup Patel wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Tue, Aug 18, 2020 at 1:23 AM <Cyril.Jean@microchip.com> wrote:
>> On 8/17/20 8:28 PM, Alistair Francis wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> On Mon, Aug 17, 2020 at 11:12 AM via <qemu-devel@nongnu.org> wrote:
>>>> Hi Anup,
>>>>
>>>> On 8/17/20 11:30 AM, Bin Meng wrote:
>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>>>
>>>>> Hi Anup,
>>>>>
>>>>> On Sat, Aug 15, 2020 at 1:44 AM Anup Patel <anup@brainfault.org> wrote:
>>>>>> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>> From: Bin Meng <bin.meng@windriver.com>
>>>>>>>
>>>>>>> This adds support for Microchip PolarFire SoC Icicle Kit board.
>>>>>>> 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.
>>>>>> Nice Work !!! This is very helpful.
>>>>> Thanks!
>>>>>
>>>>>> The Microchip HSS is quite convoluted. It has:
>>>>>> 1. DDR Init
>>>>>> 2. Boot device support
>>>>>> 3. SBI support using OpenSBI as library
>>>>>> 4. Simple TEE support
>>>>>>
>>>>>> I think point 1) and 2) above should be part of U-Boot SPL.
>>>>>> The point 3) can be OpenSBI FW_DYNAMIC.
>>>>>>
>>>>>> Lastly,for point 4), we are working on a new OpenSBI feature using
>>>>>> which we can run independent Secure OS and Non-Secure OS using
>>>>>> U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
>>>>>> PolarFire).
>>>>>>
>>>>>> Do you have plans for adding U-Boot SPL support for this board ??
>>>>> + Cyril Jean from Microchip
>>>>>
>>>>> I will have to leave this question to Cyril to comment.
>>>>>
>>>> I currently do not have a plan to support U-Boot SPL. The idea of the
>>>> HSS is to contain all the silicon specific initialization and
>>>> configuration code within the HSS before jumping to U-Boot S-mode. I
>>>> would rather keep all this within the HSS for the time being. I would
>>>> wait until we reach production silicon before attempting to move this to
>>>> U-Boot SPL as the HSS is likely to contain some opaque silicon related
>>>> changes for another while.
>>> That is unfortunate, a lot of work has gone into making the boot flow
>>> simple and easy to use.
>>>
>>> QEMU now includes OpenSBI by default to make it easy for users to boot
>>> Linux. The Icicle Kit board is now the most difficult QEMU board to
>>> boot Linux on. Not to mention it makes it hard to impossible to
>>> support it in standard tool flows such as meta-riscv.
>>>
>>> Alistair
>> If it is such a problem we can add a U-Boot SPL stage and the HSS can be
>> treated as standard SoC ROM code.
> It's not mandatory for U-Boot SPL to have stable DRAM calibration settings
> from the start itself. The initial U-Boot SPL support for most
> platforms (accross
> architectures) usually include basic working DRAM calibration settings which
> is later on updated with separate patches. Also, we don't need all U-Boot
> drivers to be upstreamed in one-go as this can be done in phases.
>
> The advantage we have with PolarFire SoC Icicle board is that we already
> have a U-Boot S-mode. and we believe the OpenSBI generic platform will
> work fine for PolarFire SoC Icicle board so the only thing missing right now
> is the U-Boot SPL support for OpenSource boot-flow.
>
> It will certainly accelerate open-source development if we have boot-flow
> U-Boot_SPL => OpenSBI (FW_DYNAMIC) => U-Boot_S-mode working
> on PolarFire SoC Icicle board. Initially, we just need DRAM, SD/eMMC,
> and Serial port support for U-Boot SPL and U-Boot S-mode. Later on,
> more patches can add ethernet and other booting device drivers to U-Boot.
>
> Regarding security services of HSS, we are working on a OpenSBI
> feature which will allow HSS security services to run as independent
> binary in M-mode (not linked to OpenSBI) and OpenSBI FW_DYNAMIC
> will be a separate binary acting as a secure monitor.
>
> Regards,
> Anup
What I have in mind is that the external memory will be up and running
by the time we get to U-Boot SPL. In the case of PolarFire SoC the ROM
code equivalent brings up the DDR memory interface so we do not need to
worry about this as part of U-Boot.
Sounds to me the component that needs to be upstreamed next is the eMMC
support so that it can be used as part of U-Boot SPL. Correct?
Regards,
Cyril.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
2020-08-18 13:09 ` Cyril.Jean
@ 2020-08-18 13:55 ` Anup Patel
-1 siblings, 0 replies; 100+ messages in thread
From: Anup Patel @ 2020-08-18 13:55 UTC (permalink / raw)
To: Cyril.Jean
Cc: Peter Maydell, Alistair Francis, open list:RISC-V, qemu-block,
Sagar Karandikar, Bin Meng, Bastian Koppelmann, Jason Wang,
Palmer Dabbelt, Edgar E. Iglesias, QEMU Developers,
Marc-André Lureau, qemu-arm, Alistair Francis,
Paolo Bonzini, Alistair Francis, Bin Meng,
Philippe Mathieu-Daudé,
Palmer Dabbelt
On Tue, Aug 18, 2020 at 6:39 PM <Cyril.Jean@microchip.com> wrote:
>
> On 8/18/20 7:17 AM, Anup Patel wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > On Tue, Aug 18, 2020 at 1:23 AM <Cyril.Jean@microchip.com> wrote:
> >> On 8/17/20 8:28 PM, Alistair Francis wrote:
> >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>
> >>> On Mon, Aug 17, 2020 at 11:12 AM via <qemu-devel@nongnu.org> wrote:
> >>>> Hi Anup,
> >>>>
> >>>> On 8/17/20 11:30 AM, Bin Meng wrote:
> >>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>>>
> >>>>> Hi Anup,
> >>>>>
> >>>>> On Sat, Aug 15, 2020 at 1:44 AM Anup Patel <anup@brainfault.org> wrote:
> >>>>>> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >>>>>>> From: Bin Meng <bin.meng@windriver.com>
> >>>>>>>
> >>>>>>> This adds support for Microchip PolarFire SoC Icicle Kit board.
> >>>>>>> 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.
> >>>>>> Nice Work !!! This is very helpful.
> >>>>> Thanks!
> >>>>>
> >>>>>> The Microchip HSS is quite convoluted. It has:
> >>>>>> 1. DDR Init
> >>>>>> 2. Boot device support
> >>>>>> 3. SBI support using OpenSBI as library
> >>>>>> 4. Simple TEE support
> >>>>>>
> >>>>>> I think point 1) and 2) above should be part of U-Boot SPL.
> >>>>>> The point 3) can be OpenSBI FW_DYNAMIC.
> >>>>>>
> >>>>>> Lastly,for point 4), we are working on a new OpenSBI feature using
> >>>>>> which we can run independent Secure OS and Non-Secure OS using
> >>>>>> U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
> >>>>>> PolarFire).
> >>>>>>
> >>>>>> Do you have plans for adding U-Boot SPL support for this board ??
> >>>>> + Cyril Jean from Microchip
> >>>>>
> >>>>> I will have to leave this question to Cyril to comment.
> >>>>>
> >>>> I currently do not have a plan to support U-Boot SPL. The idea of the
> >>>> HSS is to contain all the silicon specific initialization and
> >>>> configuration code within the HSS before jumping to U-Boot S-mode. I
> >>>> would rather keep all this within the HSS for the time being. I would
> >>>> wait until we reach production silicon before attempting to move this to
> >>>> U-Boot SPL as the HSS is likely to contain some opaque silicon related
> >>>> changes for another while.
> >>> That is unfortunate, a lot of work has gone into making the boot flow
> >>> simple and easy to use.
> >>>
> >>> QEMU now includes OpenSBI by default to make it easy for users to boot
> >>> Linux. The Icicle Kit board is now the most difficult QEMU board to
> >>> boot Linux on. Not to mention it makes it hard to impossible to
> >>> support it in standard tool flows such as meta-riscv.
> >>>
> >>> Alistair
> >> If it is such a problem we can add a U-Boot SPL stage and the HSS can be
> >> treated as standard SoC ROM code.
> > It's not mandatory for U-Boot SPL to have stable DRAM calibration settings
> > from the start itself. The initial U-Boot SPL support for most
> > platforms (accross
> > architectures) usually include basic working DRAM calibration settings which
> > is later on updated with separate patches. Also, we don't need all U-Boot
> > drivers to be upstreamed in one-go as this can be done in phases.
> >
> > The advantage we have with PolarFire SoC Icicle board is that we already
> > have a U-Boot S-mode. and we believe the OpenSBI generic platform will
> > work fine for PolarFire SoC Icicle board so the only thing missing right now
> > is the U-Boot SPL support for OpenSource boot-flow.
> >
> > It will certainly accelerate open-source development if we have boot-flow
> > U-Boot_SPL => OpenSBI (FW_DYNAMIC) => U-Boot_S-mode working
> > on PolarFire SoC Icicle board. Initially, we just need DRAM, SD/eMMC,
> > and Serial port support for U-Boot SPL and U-Boot S-mode. Later on,
> > more patches can add ethernet and other booting device drivers to U-Boot.
> >
> > Regarding security services of HSS, we are working on a OpenSBI
> > feature which will allow HSS security services to run as independent
> > binary in M-mode (not linked to OpenSBI) and OpenSBI FW_DYNAMIC
> > will be a separate binary acting as a secure monitor.
> >
> > Regards,
> > Anup
>
> What I have in mind is that the external memory will be up and running
> by the time we get to U-Boot SPL. In the case of PolarFire SoC the ROM
> code equivalent brings up the DDR memory interface so we do not need to
> worry about this as part of U-Boot.
Keeping DRAM configuration as part of a separate ROM booting stage prior
to the U-Boot SPL sounds good to me. This will lead to following boot-flow:
ROM/HSS (M-mode) => U-Boot SPL (M-mode) => OpenSBI (M-mode) => U-Boot S-mode
>
> Sounds to me the component that needs to be upstreamed next is the eMMC
> support so that it can be used as part of U-Boot SPL. Correct?
Maybe as a PHASE1 patch series for PolarFire U-Boot support can
target the following:
1. Minimal U-Boot board support for PolarFire IcIcle Board with
single defconfig to build both U-Boot SPL and U-Boot S-mode
2. Serial port driver (probably re-use existing driver)
3. SD and eMMC driver
Supporting SD booting is highly desirable for PHASE1. At least,
U-Boot SPL, OpenSBI, U-Boot S-mode, and Linux should come
as separate images from SD card. The ROM/HSS can reside and
boot from on-board flash/eMMC.
Above is my suggestion based on experience with SiFive Unleashed.
The general idea behind OpenSource boot-flow is to have each
booting stage as a separate binary so that users can selectively
upgrade a particular booting stage without re-compiling/re-flashing
other booting stages.
Various distros and yocto already support building most of the above
booting stages (U-Boot, OpenSBI, Linux, etc) so we can reuse a lot
of existing work. Eventually, I am confident we will endup moving
more stuff from ROM/HSS to U-Boot SPL for ease in maintenance.
Regards,
Anup
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
@ 2020-08-18 13:55 ` Anup Patel
0 siblings, 0 replies; 100+ messages in thread
From: Anup Patel @ 2020-08-18 13:55 UTC (permalink / raw)
To: Cyril.Jean
Cc: Alistair Francis, Bin Meng, Alistair Francis, Bastian Koppelmann,
Palmer Dabbelt, Sagar Karandikar, QEMU Developers,
open list:RISC-V, Peter Maydell, Alistair Francis, qemu-block,
Jason Wang, Bin Meng, Paolo Bonzini, Palmer Dabbelt, qemu-arm,
Marc-André Lureau, Edgar E. Iglesias,
Philippe Mathieu-Daudé
On Tue, Aug 18, 2020 at 6:39 PM <Cyril.Jean@microchip.com> wrote:
>
> On 8/18/20 7:17 AM, Anup Patel wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > On Tue, Aug 18, 2020 at 1:23 AM <Cyril.Jean@microchip.com> wrote:
> >> On 8/17/20 8:28 PM, Alistair Francis wrote:
> >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>
> >>> On Mon, Aug 17, 2020 at 11:12 AM via <qemu-devel@nongnu.org> wrote:
> >>>> Hi Anup,
> >>>>
> >>>> On 8/17/20 11:30 AM, Bin Meng wrote:
> >>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>>>
> >>>>> Hi Anup,
> >>>>>
> >>>>> On Sat, Aug 15, 2020 at 1:44 AM Anup Patel <anup@brainfault.org> wrote:
> >>>>>> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >>>>>>> From: Bin Meng <bin.meng@windriver.com>
> >>>>>>>
> >>>>>>> This adds support for Microchip PolarFire SoC Icicle Kit board.
> >>>>>>> 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.
> >>>>>> Nice Work !!! This is very helpful.
> >>>>> Thanks!
> >>>>>
> >>>>>> The Microchip HSS is quite convoluted. It has:
> >>>>>> 1. DDR Init
> >>>>>> 2. Boot device support
> >>>>>> 3. SBI support using OpenSBI as library
> >>>>>> 4. Simple TEE support
> >>>>>>
> >>>>>> I think point 1) and 2) above should be part of U-Boot SPL.
> >>>>>> The point 3) can be OpenSBI FW_DYNAMIC.
> >>>>>>
> >>>>>> Lastly,for point 4), we are working on a new OpenSBI feature using
> >>>>>> which we can run independent Secure OS and Non-Secure OS using
> >>>>>> U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
> >>>>>> PolarFire).
> >>>>>>
> >>>>>> Do you have plans for adding U-Boot SPL support for this board ??
> >>>>> + Cyril Jean from Microchip
> >>>>>
> >>>>> I will have to leave this question to Cyril to comment.
> >>>>>
> >>>> I currently do not have a plan to support U-Boot SPL. The idea of the
> >>>> HSS is to contain all the silicon specific initialization and
> >>>> configuration code within the HSS before jumping to U-Boot S-mode. I
> >>>> would rather keep all this within the HSS for the time being. I would
> >>>> wait until we reach production silicon before attempting to move this to
> >>>> U-Boot SPL as the HSS is likely to contain some opaque silicon related
> >>>> changes for another while.
> >>> That is unfortunate, a lot of work has gone into making the boot flow
> >>> simple and easy to use.
> >>>
> >>> QEMU now includes OpenSBI by default to make it easy for users to boot
> >>> Linux. The Icicle Kit board is now the most difficult QEMU board to
> >>> boot Linux on. Not to mention it makes it hard to impossible to
> >>> support it in standard tool flows such as meta-riscv.
> >>>
> >>> Alistair
> >> If it is such a problem we can add a U-Boot SPL stage and the HSS can be
> >> treated as standard SoC ROM code.
> > It's not mandatory for U-Boot SPL to have stable DRAM calibration settings
> > from the start itself. The initial U-Boot SPL support for most
> > platforms (accross
> > architectures) usually include basic working DRAM calibration settings which
> > is later on updated with separate patches. Also, we don't need all U-Boot
> > drivers to be upstreamed in one-go as this can be done in phases.
> >
> > The advantage we have with PolarFire SoC Icicle board is that we already
> > have a U-Boot S-mode. and we believe the OpenSBI generic platform will
> > work fine for PolarFire SoC Icicle board so the only thing missing right now
> > is the U-Boot SPL support for OpenSource boot-flow.
> >
> > It will certainly accelerate open-source development if we have boot-flow
> > U-Boot_SPL => OpenSBI (FW_DYNAMIC) => U-Boot_S-mode working
> > on PolarFire SoC Icicle board. Initially, we just need DRAM, SD/eMMC,
> > and Serial port support for U-Boot SPL and U-Boot S-mode. Later on,
> > more patches can add ethernet and other booting device drivers to U-Boot.
> >
> > Regarding security services of HSS, we are working on a OpenSBI
> > feature which will allow HSS security services to run as independent
> > binary in M-mode (not linked to OpenSBI) and OpenSBI FW_DYNAMIC
> > will be a separate binary acting as a secure monitor.
> >
> > Regards,
> > Anup
>
> What I have in mind is that the external memory will be up and running
> by the time we get to U-Boot SPL. In the case of PolarFire SoC the ROM
> code equivalent brings up the DDR memory interface so we do not need to
> worry about this as part of U-Boot.
Keeping DRAM configuration as part of a separate ROM booting stage prior
to the U-Boot SPL sounds good to me. This will lead to following boot-flow:
ROM/HSS (M-mode) => U-Boot SPL (M-mode) => OpenSBI (M-mode) => U-Boot S-mode
>
> Sounds to me the component that needs to be upstreamed next is the eMMC
> support so that it can be used as part of U-Boot SPL. Correct?
Maybe as a PHASE1 patch series for PolarFire U-Boot support can
target the following:
1. Minimal U-Boot board support for PolarFire IcIcle Board with
single defconfig to build both U-Boot SPL and U-Boot S-mode
2. Serial port driver (probably re-use existing driver)
3. SD and eMMC driver
Supporting SD booting is highly desirable for PHASE1. At least,
U-Boot SPL, OpenSBI, U-Boot S-mode, and Linux should come
as separate images from SD card. The ROM/HSS can reside and
boot from on-board flash/eMMC.
Above is my suggestion based on experience with SiFive Unleashed.
The general idea behind OpenSource boot-flow is to have each
booting stage as a separate binary so that users can selectively
upgrade a particular booting stage without re-compiling/re-flashing
other booting stages.
Various distros and yocto already support building most of the above
booting stages (U-Boot, OpenSBI, Linux, etc) so we can reuse a lot
of existing work. Eventually, I am confident we will endup moving
more stuff from ROM/HSS to U-Boot SPL for ease in maintenance.
Regards,
Anup
^ permalink raw reply [flat|nested] 100+ messages in thread
* RE: [PATCH 07/18] hw/sd: sd: Fix incorrect populated function switch status data structure
2020-08-15 7:58 ` Philippe Mathieu-Daudé
@ 2020-08-18 16:30 ` Sai Pavan Boddu
2020-08-21 10:09 ` Sai Pavan Boddu
0 siblings, 1 reply; 100+ messages in thread
From: Sai Pavan Boddu @ 2020-08-18 16:30 UTC (permalink / raw)
To: Philippe Mathieu-Daudé,
Bin Meng, Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv
Cc: Bin Meng, qemu-block
Thanks Philippe,
I would test this and get back.
Regards,
Sai Pavan
> -----Original Message-----
> From: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> On
> Behalf Of Philippe Mathieu-Daudé
> Sent: Saturday, August 15, 2020 1:29 PM
> To: Bin Meng <bmeng.cn@gmail.com>; Alistair Francis
> <Alistair.Francis@wdc.com>; Bastian Koppelmann <kbastian@mail.uni-
> paderborn.de>; Palmer Dabbelt <palmerdabbelt@google.com>; Sagar
> Karandikar <sagark@eecs.berkeley.edu>; qemu-devel@nongnu.org; qemu-
> riscv@nongnu.org; Sai Pavan Boddu <saipava@xilinx.com>
> Cc: Bin Meng <bin.meng@windriver.com>; qemu-block@nongnu.org
> Subject: Re: [PATCH 07/18] hw/sd: sd: Fix incorrect populated function switch
> status data structure
>
> +Sai Pavan
>
> On 8/14/20 6:40 PM, Bin Meng wrote:
> > From: Bin Meng <bin.meng@windriver.com>
> >
> > At present the function switch status data structure bit [399:376] are
> > wrongly pupulated. These 3 bytes encode function switch status for the
> > 6 function groups, with 4 bits per group, starting from function group
> > 6 at bit 399, then followed by function group 5 at bit 395, and so on.
> >
> > However the codes mistakenly fills in the function group 1 status at
> > bit 399. This fixes the code logic.
> >
>
> Fixes: a1bb27b1e9 ("SD card emulation (initial implementation)")
>
> > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > ---
> >
> > hw/sd/sd.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/sd/sd.c b/hw/sd/sd.c
> > index fad9cf1..51f5900 100644
> > --- a/hw/sd/sd.c
> > +++ b/hw/sd/sd.c
> > @@ -806,11 +806,15 @@ static void sd_function_switch(SDState *sd,
> uint32_t arg)
> > sd->data[11] = 0x43;
> > sd->data[12] = 0x80; /* Supported group 1 functions */
> > sd->data[13] = 0x03;
> > +
> > + sd->data[14] = 0;
> > + sd->data[15] = 0;
> > + sd->data[16] = 0;
>
> Pointless zero initialization.
>
> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>
> I'll wait until next week in case Sai Pavan wants to test this patch (I don't have
> access to the Xilinx images anymore) then I'll queue this via my sd-next tree.
>
> Regards,
>
> Phil.
>
> > for (i = 0; i < 6; i ++) {
> > new_func = (arg >> (i * 4)) & 0x0f;
> > if (mode && new_func != 0x0f)
> > sd->function_group[i] = new_func;
> > - sd->data[14 + (i >> 1)] = new_func << ((i * 4) & 4);
> > + sd->data[16 - (i >> 1)] |= new_func << ((i % 2) * 4);
> > }
> > memset(&sd->data[17], 0, 47);
> > stw_be_p(sd->data + 64, sd_crc16(sd->data, 64));
> >
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
2020-08-18 13:55 ` Anup Patel
@ 2020-08-19 1:34 ` Bin Meng
-1 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-19 1:34 UTC (permalink / raw)
To: Anup Patel
Cc: Peter Maydell, Alistair Francis, Cyril.Jean, open list:RISC-V,
Sagar Karandikar, Bin Meng, Bastian Koppelmann, Jason Wang,
Palmer Dabbelt, Edgar E. Iglesias, QEMU Developers,
Marc-André Lureau, qemu-arm, Alistair Francis,
Paolo Bonzini, Alistair Francis, qemu-block,
Philippe Mathieu-Daudé,
Palmer Dabbelt
On Tue, Aug 18, 2020 at 9:55 PM Anup Patel <anup@brainfault.org> wrote:
>
> On Tue, Aug 18, 2020 at 6:39 PM <Cyril.Jean@microchip.com> wrote:
> >
> > On 8/18/20 7:17 AM, Anup Patel wrote:
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > >
> > > On Tue, Aug 18, 2020 at 1:23 AM <Cyril.Jean@microchip.com> wrote:
> > >> On 8/17/20 8:28 PM, Alistair Francis wrote:
> > >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > >>>
> > >>> On Mon, Aug 17, 2020 at 11:12 AM via <qemu-devel@nongnu.org> wrote:
> > >>>> Hi Anup,
> > >>>>
> > >>>> On 8/17/20 11:30 AM, Bin Meng wrote:
> > >>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > >>>>>
> > >>>>> Hi Anup,
> > >>>>>
> > >>>>> On Sat, Aug 15, 2020 at 1:44 AM Anup Patel <anup@brainfault.org> wrote:
> > >>>>>> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >>>>>>> From: Bin Meng <bin.meng@windriver.com>
> > >>>>>>>
> > >>>>>>> This adds support for Microchip PolarFire SoC Icicle Kit board.
> > >>>>>>> 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.
> > >>>>>> Nice Work !!! This is very helpful.
> > >>>>> Thanks!
> > >>>>>
> > >>>>>> The Microchip HSS is quite convoluted. It has:
> > >>>>>> 1. DDR Init
> > >>>>>> 2. Boot device support
> > >>>>>> 3. SBI support using OpenSBI as library
> > >>>>>> 4. Simple TEE support
> > >>>>>>
> > >>>>>> I think point 1) and 2) above should be part of U-Boot SPL.
> > >>>>>> The point 3) can be OpenSBI FW_DYNAMIC.
> > >>>>>>
> > >>>>>> Lastly,for point 4), we are working on a new OpenSBI feature using
> > >>>>>> which we can run independent Secure OS and Non-Secure OS using
> > >>>>>> U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
> > >>>>>> PolarFire).
> > >>>>>>
> > >>>>>> Do you have plans for adding U-Boot SPL support for this board ??
> > >>>>> + Cyril Jean from Microchip
> > >>>>>
> > >>>>> I will have to leave this question to Cyril to comment.
> > >>>>>
> > >>>> I currently do not have a plan to support U-Boot SPL. The idea of the
> > >>>> HSS is to contain all the silicon specific initialization and
> > >>>> configuration code within the HSS before jumping to U-Boot S-mode. I
> > >>>> would rather keep all this within the HSS for the time being. I would
> > >>>> wait until we reach production silicon before attempting to move this to
> > >>>> U-Boot SPL as the HSS is likely to contain some opaque silicon related
> > >>>> changes for another while.
> > >>> That is unfortunate, a lot of work has gone into making the boot flow
> > >>> simple and easy to use.
> > >>>
> > >>> QEMU now includes OpenSBI by default to make it easy for users to boot
> > >>> Linux. The Icicle Kit board is now the most difficult QEMU board to
> > >>> boot Linux on. Not to mention it makes it hard to impossible to
> > >>> support it in standard tool flows such as meta-riscv.
> > >>>
> > >>> Alistair
> > >> If it is such a problem we can add a U-Boot SPL stage and the HSS can be
> > >> treated as standard SoC ROM code.
> > > It's not mandatory for U-Boot SPL to have stable DRAM calibration settings
> > > from the start itself. The initial U-Boot SPL support for most
> > > platforms (accross
> > > architectures) usually include basic working DRAM calibration settings which
> > > is later on updated with separate patches. Also, we don't need all U-Boot
> > > drivers to be upstreamed in one-go as this can be done in phases.
> > >
> > > The advantage we have with PolarFire SoC Icicle board is that we already
> > > have a U-Boot S-mode. and we believe the OpenSBI generic platform will
> > > work fine for PolarFire SoC Icicle board so the only thing missing right now
> > > is the U-Boot SPL support for OpenSource boot-flow.
> > >
> > > It will certainly accelerate open-source development if we have boot-flow
> > > U-Boot_SPL => OpenSBI (FW_DYNAMIC) => U-Boot_S-mode working
> > > on PolarFire SoC Icicle board. Initially, we just need DRAM, SD/eMMC,
> > > and Serial port support for U-Boot SPL and U-Boot S-mode. Later on,
> > > more patches can add ethernet and other booting device drivers to U-Boot.
> > >
> > > Regarding security services of HSS, we are working on a OpenSBI
> > > feature which will allow HSS security services to run as independent
> > > binary in M-mode (not linked to OpenSBI) and OpenSBI FW_DYNAMIC
> > > will be a separate binary acting as a secure monitor.
> > >
> > > Regards,
> > > Anup
> >
> > What I have in mind is that the external memory will be up and running
> > by the time we get to U-Boot SPL. In the case of PolarFire SoC the ROM
> > code equivalent brings up the DDR memory interface so we do not need to
> > worry about this as part of U-Boot.
>
> Keeping DRAM configuration as part of a separate ROM booting stage prior
> to the U-Boot SPL sounds good to me. This will lead to following boot-flow:
>
> ROM/HSS (M-mode) => U-Boot SPL (M-mode) => OpenSBI (M-mode) => U-Boot S-mode
If we want to keep the HSS, meaning that DDR memory is already
initialized, then there is no need to create an additional step of
U-Boot SPL phase, because there is no size limitation any more.
Right now, the boot workflow on PolarFire is:
HSS + OpenSBI (as a library) (M-mode) => U-Boot S-mode
It's just not the canonical way because of the HSS and OpenSBI as a library.
A canonical way should be:
U-Boot SPL (M-mode) => OpenSBI dynamic (M-mode) => U-Boot S-mode
So we should be aiming to replace HSS with U-Boot SPL.
>
> >
> > Sounds to me the component that needs to be upstreamed next is the eMMC
> > support so that it can be used as part of U-Boot SPL. Correct?
>
> Maybe as a PHASE1 patch series for PolarFire U-Boot support can
> target the following:
> 1. Minimal U-Boot board support for PolarFire IcIcle Board with
> single defconfig to build both U-Boot SPL and U-Boot S-mode
> 2. Serial port driver (probably re-use existing driver)
> 3. SD and eMMC driver
>
> Supporting SD booting is highly desirable for PHASE1. At least,
> U-Boot SPL, OpenSBI, U-Boot S-mode, and Linux should come
> as separate images from SD card. The ROM/HSS can reside and
> boot from on-board flash/eMMC.
>
> Above is my suggestion based on experience with SiFive Unleashed.
>
> The general idea behind OpenSource boot-flow is to have each
> booting stage as a separate binary so that users can selectively
> upgrade a particular booting stage without re-compiling/re-flashing
> other booting stages.
>
> Various distros and yocto already support building most of the above
> booting stages (U-Boot, OpenSBI, Linux, etc) so we can reuse a lot
> of existing work. Eventually, I am confident we will endup moving
> more stuff from ROM/HSS to U-Boot SPL for ease in maintenance.
Regards,
Bin
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
@ 2020-08-19 1:34 ` Bin Meng
0 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-19 1:34 UTC (permalink / raw)
To: Anup Patel
Cc: Cyril.Jean, Alistair Francis, Alistair Francis,
Bastian Koppelmann, Palmer Dabbelt, Sagar Karandikar,
QEMU Developers, open list:RISC-V, Peter Maydell,
Alistair Francis, qemu-block, Jason Wang, Bin Meng,
Paolo Bonzini, Palmer Dabbelt, qemu-arm, Marc-André Lureau,
Edgar E. Iglesias, Philippe Mathieu-Daudé
On Tue, Aug 18, 2020 at 9:55 PM Anup Patel <anup@brainfault.org> wrote:
>
> On Tue, Aug 18, 2020 at 6:39 PM <Cyril.Jean@microchip.com> wrote:
> >
> > On 8/18/20 7:17 AM, Anup Patel wrote:
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > >
> > > On Tue, Aug 18, 2020 at 1:23 AM <Cyril.Jean@microchip.com> wrote:
> > >> On 8/17/20 8:28 PM, Alistair Francis wrote:
> > >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > >>>
> > >>> On Mon, Aug 17, 2020 at 11:12 AM via <qemu-devel@nongnu.org> wrote:
> > >>>> Hi Anup,
> > >>>>
> > >>>> On 8/17/20 11:30 AM, Bin Meng wrote:
> > >>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > >>>>>
> > >>>>> Hi Anup,
> > >>>>>
> > >>>>> On Sat, Aug 15, 2020 at 1:44 AM Anup Patel <anup@brainfault.org> wrote:
> > >>>>>> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >>>>>>> From: Bin Meng <bin.meng@windriver.com>
> > >>>>>>>
> > >>>>>>> This adds support for Microchip PolarFire SoC Icicle Kit board.
> > >>>>>>> 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.
> > >>>>>> Nice Work !!! This is very helpful.
> > >>>>> Thanks!
> > >>>>>
> > >>>>>> The Microchip HSS is quite convoluted. It has:
> > >>>>>> 1. DDR Init
> > >>>>>> 2. Boot device support
> > >>>>>> 3. SBI support using OpenSBI as library
> > >>>>>> 4. Simple TEE support
> > >>>>>>
> > >>>>>> I think point 1) and 2) above should be part of U-Boot SPL.
> > >>>>>> The point 3) can be OpenSBI FW_DYNAMIC.
> > >>>>>>
> > >>>>>> Lastly,for point 4), we are working on a new OpenSBI feature using
> > >>>>>> which we can run independent Secure OS and Non-Secure OS using
> > >>>>>> U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
> > >>>>>> PolarFire).
> > >>>>>>
> > >>>>>> Do you have plans for adding U-Boot SPL support for this board ??
> > >>>>> + Cyril Jean from Microchip
> > >>>>>
> > >>>>> I will have to leave this question to Cyril to comment.
> > >>>>>
> > >>>> I currently do not have a plan to support U-Boot SPL. The idea of the
> > >>>> HSS is to contain all the silicon specific initialization and
> > >>>> configuration code within the HSS before jumping to U-Boot S-mode. I
> > >>>> would rather keep all this within the HSS for the time being. I would
> > >>>> wait until we reach production silicon before attempting to move this to
> > >>>> U-Boot SPL as the HSS is likely to contain some opaque silicon related
> > >>>> changes for another while.
> > >>> That is unfortunate, a lot of work has gone into making the boot flow
> > >>> simple and easy to use.
> > >>>
> > >>> QEMU now includes OpenSBI by default to make it easy for users to boot
> > >>> Linux. The Icicle Kit board is now the most difficult QEMU board to
> > >>> boot Linux on. Not to mention it makes it hard to impossible to
> > >>> support it in standard tool flows such as meta-riscv.
> > >>>
> > >>> Alistair
> > >> If it is such a problem we can add a U-Boot SPL stage and the HSS can be
> > >> treated as standard SoC ROM code.
> > > It's not mandatory for U-Boot SPL to have stable DRAM calibration settings
> > > from the start itself. The initial U-Boot SPL support for most
> > > platforms (accross
> > > architectures) usually include basic working DRAM calibration settings which
> > > is later on updated with separate patches. Also, we don't need all U-Boot
> > > drivers to be upstreamed in one-go as this can be done in phases.
> > >
> > > The advantage we have with PolarFire SoC Icicle board is that we already
> > > have a U-Boot S-mode. and we believe the OpenSBI generic platform will
> > > work fine for PolarFire SoC Icicle board so the only thing missing right now
> > > is the U-Boot SPL support for OpenSource boot-flow.
> > >
> > > It will certainly accelerate open-source development if we have boot-flow
> > > U-Boot_SPL => OpenSBI (FW_DYNAMIC) => U-Boot_S-mode working
> > > on PolarFire SoC Icicle board. Initially, we just need DRAM, SD/eMMC,
> > > and Serial port support for U-Boot SPL and U-Boot S-mode. Later on,
> > > more patches can add ethernet and other booting device drivers to U-Boot.
> > >
> > > Regarding security services of HSS, we are working on a OpenSBI
> > > feature which will allow HSS security services to run as independent
> > > binary in M-mode (not linked to OpenSBI) and OpenSBI FW_DYNAMIC
> > > will be a separate binary acting as a secure monitor.
> > >
> > > Regards,
> > > Anup
> >
> > What I have in mind is that the external memory will be up and running
> > by the time we get to U-Boot SPL. In the case of PolarFire SoC the ROM
> > code equivalent brings up the DDR memory interface so we do not need to
> > worry about this as part of U-Boot.
>
> Keeping DRAM configuration as part of a separate ROM booting stage prior
> to the U-Boot SPL sounds good to me. This will lead to following boot-flow:
>
> ROM/HSS (M-mode) => U-Boot SPL (M-mode) => OpenSBI (M-mode) => U-Boot S-mode
If we want to keep the HSS, meaning that DDR memory is already
initialized, then there is no need to create an additional step of
U-Boot SPL phase, because there is no size limitation any more.
Right now, the boot workflow on PolarFire is:
HSS + OpenSBI (as a library) (M-mode) => U-Boot S-mode
It's just not the canonical way because of the HSS and OpenSBI as a library.
A canonical way should be:
U-Boot SPL (M-mode) => OpenSBI dynamic (M-mode) => U-Boot S-mode
So we should be aiming to replace HSS with U-Boot SPL.
>
> >
> > Sounds to me the component that needs to be upstreamed next is the eMMC
> > support so that it can be used as part of U-Boot SPL. Correct?
>
> Maybe as a PHASE1 patch series for PolarFire U-Boot support can
> target the following:
> 1. Minimal U-Boot board support for PolarFire IcIcle Board with
> single defconfig to build both U-Boot SPL and U-Boot S-mode
> 2. Serial port driver (probably re-use existing driver)
> 3. SD and eMMC driver
>
> Supporting SD booting is highly desirable for PHASE1. At least,
> U-Boot SPL, OpenSBI, U-Boot S-mode, and Linux should come
> as separate images from SD card. The ROM/HSS can reside and
> boot from on-board flash/eMMC.
>
> Above is my suggestion based on experience with SiFive Unleashed.
>
> The general idea behind OpenSource boot-flow is to have each
> booting stage as a separate binary so that users can selectively
> upgrade a particular booting stage without re-compiling/re-flashing
> other booting stages.
>
> Various distros and yocto already support building most of the above
> booting stages (U-Boot, OpenSBI, Linux, etc) so we can reuse a lot
> of existing work. Eventually, I am confident we will endup moving
> more stuff from ROM/HSS to U-Boot SPL for ease in maintenance.
Regards,
Bin
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
2020-08-19 1:34 ` Bin Meng
@ 2020-08-19 10:13 ` Cyril.Jean
-1 siblings, 0 replies; 100+ messages in thread
From: via @ 2020-08-19 10:13 UTC (permalink / raw)
To: bmeng.cn, anup
Cc: alistair23, Alistair.Francis, kbastian, palmerdabbelt, sagark,
qemu-devel, qemu-riscv, peter.maydell, alistair, qemu-block,
jasowang, bin.meng, pbonzini, palmer, qemu-arm, marcandre.lureau,
edgar.iglesias, philmd
On 8/19/20 2:34 AM, Bin Meng wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Tue, Aug 18, 2020 at 9:55 PM Anup Patel <anup@brainfault.org> wrote:
>> On Tue, Aug 18, 2020 at 6:39 PM <Cyril.Jean@microchip.com> wrote:
>>> On 8/18/20 7:17 AM, Anup Patel wrote:
>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>>
>>>> On Tue, Aug 18, 2020 at 1:23 AM <Cyril.Jean@microchip.com> wrote:
>>>>> On 8/17/20 8:28 PM, Alistair Francis wrote:
>>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>>>>
>>>>>> On Mon, Aug 17, 2020 at 11:12 AM via <qemu-devel@nongnu.org> wrote:
>>>>>>> Hi Anup,
>>>>>>>
>>>>>>> On 8/17/20 11:30 AM, Bin Meng wrote:
>>>>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>>>>>>
>>>>>>>> Hi Anup,
>>>>>>>>
>>>>>>>> On Sat, Aug 15, 2020 at 1:44 AM Anup Patel <anup@brainfault.org> wrote:
>>>>>>>>> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>>> From: Bin Meng <bin.meng@windriver.com>
>>>>>>>>>>
>>>>>>>>>> This adds support for Microchip PolarFire SoC Icicle Kit board.
>>>>>>>>>> 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.
>>>>>>>>> Nice Work !!! This is very helpful.
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>>> The Microchip HSS is quite convoluted. It has:
>>>>>>>>> 1. DDR Init
>>>>>>>>> 2. Boot device support
>>>>>>>>> 3. SBI support using OpenSBI as library
>>>>>>>>> 4. Simple TEE support
>>>>>>>>>
>>>>>>>>> I think point 1) and 2) above should be part of U-Boot SPL.
>>>>>>>>> The point 3) can be OpenSBI FW_DYNAMIC.
>>>>>>>>>
>>>>>>>>> Lastly,for point 4), we are working on a new OpenSBI feature using
>>>>>>>>> which we can run independent Secure OS and Non-Secure OS using
>>>>>>>>> U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
>>>>>>>>> PolarFire).
>>>>>>>>>
>>>>>>>>> Do you have plans for adding U-Boot SPL support for this board ??
>>>>>>>> + Cyril Jean from Microchip
>>>>>>>>
>>>>>>>> I will have to leave this question to Cyril to comment.
>>>>>>>>
>>>>>>> I currently do not have a plan to support U-Boot SPL. The idea of the
>>>>>>> HSS is to contain all the silicon specific initialization and
>>>>>>> configuration code within the HSS before jumping to U-Boot S-mode. I
>>>>>>> would rather keep all this within the HSS for the time being. I would
>>>>>>> wait until we reach production silicon before attempting to move this to
>>>>>>> U-Boot SPL as the HSS is likely to contain some opaque silicon related
>>>>>>> changes for another while.
>>>>>> That is unfortunate, a lot of work has gone into making the boot flow
>>>>>> simple and easy to use.
>>>>>>
>>>>>> QEMU now includes OpenSBI by default to make it easy for users to boot
>>>>>> Linux. The Icicle Kit board is now the most difficult QEMU board to
>>>>>> boot Linux on. Not to mention it makes it hard to impossible to
>>>>>> support it in standard tool flows such as meta-riscv.
>>>>>>
>>>>>> Alistair
>>>>> If it is such a problem we can add a U-Boot SPL stage and the HSS can be
>>>>> treated as standard SoC ROM code.
>>>> It's not mandatory for U-Boot SPL to have stable DRAM calibration settings
>>>> from the start itself. The initial U-Boot SPL support for most
>>>> platforms (accross
>>>> architectures) usually include basic working DRAM calibration settings which
>>>> is later on updated with separate patches. Also, we don't need all U-Boot
>>>> drivers to be upstreamed in one-go as this can be done in phases.
>>>>
>>>> The advantage we have with PolarFire SoC Icicle board is that we already
>>>> have a U-Boot S-mode. and we believe the OpenSBI generic platform will
>>>> work fine for PolarFire SoC Icicle board so the only thing missing right now
>>>> is the U-Boot SPL support for OpenSource boot-flow.
>>>>
>>>> It will certainly accelerate open-source development if we have boot-flow
>>>> U-Boot_SPL => OpenSBI (FW_DYNAMIC) => U-Boot_S-mode working
>>>> on PolarFire SoC Icicle board. Initially, we just need DRAM, SD/eMMC,
>>>> and Serial port support for U-Boot SPL and U-Boot S-mode. Later on,
>>>> more patches can add ethernet and other booting device drivers to U-Boot.
>>>>
>>>> Regarding security services of HSS, we are working on a OpenSBI
>>>> feature which will allow HSS security services to run as independent
>>>> binary in M-mode (not linked to OpenSBI) and OpenSBI FW_DYNAMIC
>>>> will be a separate binary acting as a secure monitor.
>>>>
>>>> Regards,
>>>> Anup
>>> What I have in mind is that the external memory will be up and running
>>> by the time we get to U-Boot SPL. In the case of PolarFire SoC the ROM
>>> code equivalent brings up the DDR memory interface so we do not need to
>>> worry about this as part of U-Boot.
>> Keeping DRAM configuration as part of a separate ROM booting stage prior
>> to the U-Boot SPL sounds good to me. This will lead to following boot-flow:
>>
>> ROM/HSS (M-mode) => U-Boot SPL (M-mode) => OpenSBI (M-mode) => U-Boot S-mode
> If we want to keep the HSS, meaning that DDR memory is already
> initialized, then there is no need to create an additional step of
> U-Boot SPL phase, because there is no size limitation any more.
>
> Right now, the boot workflow on PolarFire is:
>
> HSS + OpenSBI (as a library) (M-mode) => U-Boot S-mode
>
> It's just not the canonical way because of the HSS and OpenSBI as a library.
>
> A canonical way should be:
>
> U-Boot SPL (M-mode) => OpenSBI dynamic (M-mode) => U-Boot S-mode
>
> So we should be aiming to replace HSS with U-Boot SPL.
>
>>> Sounds to me the component that needs to be upstreamed next is the eMMC
>>> support so that it can be used as part of U-Boot SPL. Correct?
>> Maybe as a PHASE1 patch series for PolarFire U-Boot support can
>> target the following:
>> 1. Minimal U-Boot board support for PolarFire IcIcle Board with
>> single defconfig to build both U-Boot SPL and U-Boot S-mode
>> 2. Serial port driver (probably re-use existing driver)
>> 3. SD and eMMC driver
>>
>> Supporting SD booting is highly desirable for PHASE1. At least,
>> U-Boot SPL, OpenSBI, U-Boot S-mode, and Linux should come
>> as separate images from SD card. The ROM/HSS can reside and
>> boot from on-board flash/eMMC.
>>
>> Above is my suggestion based on experience with SiFive Unleashed.
>>
>> The general idea behind OpenSource boot-flow is to have each
>> booting stage as a separate binary so that users can selectively
>> upgrade a particular booting stage without re-compiling/re-flashing
>> other booting stages.
>>
>> Various distros and yocto already support building most of the above
>> booting stages (U-Boot, OpenSBI, Linux, etc) so we can reuse a lot
>> of existing work. Eventually, I am confident we will endup moving
>> more stuff from ROM/HSS to U-Boot SPL for ease in maintenance.
> Regards,
> Bin
I am OK with supporting U-Boot SPL as a community boot flow but the HSS
is not going to disappear completely for many PolarFire SoC deployments.
We need to have the HSS running on the monitor core after the system has
booted for various reasons. Some of the current HSS functionalities can
be migrated at a later time.
The HSS was designed to easily enable and disable features through
Kconfig which should allow to assign features to different boot stages
depending on the overall system deployment. Keeping the HSS as ROM code
capable of starting various early boot stages in either M mode or S mode
allows us (Microchip engineering and non pure Linux users) to mix
different operating systems on the same platform and more easily debug
hardware bring-up.
What I am trying to get at is that we need to balance the QEMU ease of
use with the ability to bring-up and debug actual hardware. My preferred
approach is to keep all the hardware bring up in one place, the HSS, so
that you do not have to worry about obscure silicon idiosyncrasies once
you reach the open source boot flow. Silicon/board bring up
steps/features can be brought out of the HSS into the open source boot
stages once these steps are mature.
PolarFire SoC is the third family of SoC FPGA I have worked on. So I
have a fair idea of the amount of pain in front of me to bring the
entire device family to market :-) We decided early on in the
architecture of PolarFire SoC that we would make all code executing on
the RISC-V processors open source and user modifiable. This includes all
code typically hidden away in your typical SoC ROM code. This is why
PolarFire SoC has on-chip flash memory used to store the HSS and why the
HSS should be thought as including ROM code. The current Icicle Kit uses
engineering samples from the first device in the PolarFire SoC family.
So we are really at the beginning of the process of validating very
early boot steps on a significant number of devices. I do not want to
expose the open source community to the pain of bringing up a family of
devices because of the decision to open source all code. So I am asking
you to not rush in trying to migrate components from the HSS to a later
boot stage just yet. It can be done but based on experience I think that
now is not the right time yet.
Regards,
Cyril.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
@ 2020-08-19 10:13 ` Cyril.Jean
0 siblings, 0 replies; 100+ messages in thread
From: Cyril.Jean @ 2020-08-19 10:13 UTC (permalink / raw)
To: bmeng.cn, anup
Cc: alistair23, Alistair.Francis, kbastian, palmerdabbelt, sagark,
qemu-devel, qemu-riscv, peter.maydell, alistair, qemu-block,
jasowang, bin.meng, pbonzini, palmer, qemu-arm, marcandre.lureau,
edgar.iglesias, philmd
On 8/19/20 2:34 AM, Bin Meng wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Tue, Aug 18, 2020 at 9:55 PM Anup Patel <anup@brainfault.org> wrote:
>> On Tue, Aug 18, 2020 at 6:39 PM <Cyril.Jean@microchip.com> wrote:
>>> On 8/18/20 7:17 AM, Anup Patel wrote:
>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>>
>>>> On Tue, Aug 18, 2020 at 1:23 AM <Cyril.Jean@microchip.com> wrote:
>>>>> On 8/17/20 8:28 PM, Alistair Francis wrote:
>>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>>>>
>>>>>> On Mon, Aug 17, 2020 at 11:12 AM via <qemu-devel@nongnu.org> wrote:
>>>>>>> Hi Anup,
>>>>>>>
>>>>>>> On 8/17/20 11:30 AM, Bin Meng wrote:
>>>>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>>>>>>
>>>>>>>> Hi Anup,
>>>>>>>>
>>>>>>>> On Sat, Aug 15, 2020 at 1:44 AM Anup Patel <anup@brainfault.org> wrote:
>>>>>>>>> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>>> From: Bin Meng <bin.meng@windriver.com>
>>>>>>>>>>
>>>>>>>>>> This adds support for Microchip PolarFire SoC Icicle Kit board.
>>>>>>>>>> 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.
>>>>>>>>> Nice Work !!! This is very helpful.
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>>> The Microchip HSS is quite convoluted. It has:
>>>>>>>>> 1. DDR Init
>>>>>>>>> 2. Boot device support
>>>>>>>>> 3. SBI support using OpenSBI as library
>>>>>>>>> 4. Simple TEE support
>>>>>>>>>
>>>>>>>>> I think point 1) and 2) above should be part of U-Boot SPL.
>>>>>>>>> The point 3) can be OpenSBI FW_DYNAMIC.
>>>>>>>>>
>>>>>>>>> Lastly,for point 4), we are working on a new OpenSBI feature using
>>>>>>>>> which we can run independent Secure OS and Non-Secure OS using
>>>>>>>>> U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
>>>>>>>>> PolarFire).
>>>>>>>>>
>>>>>>>>> Do you have plans for adding U-Boot SPL support for this board ??
>>>>>>>> + Cyril Jean from Microchip
>>>>>>>>
>>>>>>>> I will have to leave this question to Cyril to comment.
>>>>>>>>
>>>>>>> I currently do not have a plan to support U-Boot SPL. The idea of the
>>>>>>> HSS is to contain all the silicon specific initialization and
>>>>>>> configuration code within the HSS before jumping to U-Boot S-mode. I
>>>>>>> would rather keep all this within the HSS for the time being. I would
>>>>>>> wait until we reach production silicon before attempting to move this to
>>>>>>> U-Boot SPL as the HSS is likely to contain some opaque silicon related
>>>>>>> changes for another while.
>>>>>> That is unfortunate, a lot of work has gone into making the boot flow
>>>>>> simple and easy to use.
>>>>>>
>>>>>> QEMU now includes OpenSBI by default to make it easy for users to boot
>>>>>> Linux. The Icicle Kit board is now the most difficult QEMU board to
>>>>>> boot Linux on. Not to mention it makes it hard to impossible to
>>>>>> support it in standard tool flows such as meta-riscv.
>>>>>>
>>>>>> Alistair
>>>>> If it is such a problem we can add a U-Boot SPL stage and the HSS can be
>>>>> treated as standard SoC ROM code.
>>>> It's not mandatory for U-Boot SPL to have stable DRAM calibration settings
>>>> from the start itself. The initial U-Boot SPL support for most
>>>> platforms (accross
>>>> architectures) usually include basic working DRAM calibration settings which
>>>> is later on updated with separate patches. Also, we don't need all U-Boot
>>>> drivers to be upstreamed in one-go as this can be done in phases.
>>>>
>>>> The advantage we have with PolarFire SoC Icicle board is that we already
>>>> have a U-Boot S-mode. and we believe the OpenSBI generic platform will
>>>> work fine for PolarFire SoC Icicle board so the only thing missing right now
>>>> is the U-Boot SPL support for OpenSource boot-flow.
>>>>
>>>> It will certainly accelerate open-source development if we have boot-flow
>>>> U-Boot_SPL => OpenSBI (FW_DYNAMIC) => U-Boot_S-mode working
>>>> on PolarFire SoC Icicle board. Initially, we just need DRAM, SD/eMMC,
>>>> and Serial port support for U-Boot SPL and U-Boot S-mode. Later on,
>>>> more patches can add ethernet and other booting device drivers to U-Boot.
>>>>
>>>> Regarding security services of HSS, we are working on a OpenSBI
>>>> feature which will allow HSS security services to run as independent
>>>> binary in M-mode (not linked to OpenSBI) and OpenSBI FW_DYNAMIC
>>>> will be a separate binary acting as a secure monitor.
>>>>
>>>> Regards,
>>>> Anup
>>> What I have in mind is that the external memory will be up and running
>>> by the time we get to U-Boot SPL. In the case of PolarFire SoC the ROM
>>> code equivalent brings up the DDR memory interface so we do not need to
>>> worry about this as part of U-Boot.
>> Keeping DRAM configuration as part of a separate ROM booting stage prior
>> to the U-Boot SPL sounds good to me. This will lead to following boot-flow:
>>
>> ROM/HSS (M-mode) => U-Boot SPL (M-mode) => OpenSBI (M-mode) => U-Boot S-mode
> If we want to keep the HSS, meaning that DDR memory is already
> initialized, then there is no need to create an additional step of
> U-Boot SPL phase, because there is no size limitation any more.
>
> Right now, the boot workflow on PolarFire is:
>
> HSS + OpenSBI (as a library) (M-mode) => U-Boot S-mode
>
> It's just not the canonical way because of the HSS and OpenSBI as a library.
>
> A canonical way should be:
>
> U-Boot SPL (M-mode) => OpenSBI dynamic (M-mode) => U-Boot S-mode
>
> So we should be aiming to replace HSS with U-Boot SPL.
>
>>> Sounds to me the component that needs to be upstreamed next is the eMMC
>>> support so that it can be used as part of U-Boot SPL. Correct?
>> Maybe as a PHASE1 patch series for PolarFire U-Boot support can
>> target the following:
>> 1. Minimal U-Boot board support for PolarFire IcIcle Board with
>> single defconfig to build both U-Boot SPL and U-Boot S-mode
>> 2. Serial port driver (probably re-use existing driver)
>> 3. SD and eMMC driver
>>
>> Supporting SD booting is highly desirable for PHASE1. At least,
>> U-Boot SPL, OpenSBI, U-Boot S-mode, and Linux should come
>> as separate images from SD card. The ROM/HSS can reside and
>> boot from on-board flash/eMMC.
>>
>> Above is my suggestion based on experience with SiFive Unleashed.
>>
>> The general idea behind OpenSource boot-flow is to have each
>> booting stage as a separate binary so that users can selectively
>> upgrade a particular booting stage without re-compiling/re-flashing
>> other booting stages.
>>
>> Various distros and yocto already support building most of the above
>> booting stages (U-Boot, OpenSBI, Linux, etc) so we can reuse a lot
>> of existing work. Eventually, I am confident we will endup moving
>> more stuff from ROM/HSS to U-Boot SPL for ease in maintenance.
> Regards,
> Bin
I am OK with supporting U-Boot SPL as a community boot flow but the HSS
is not going to disappear completely for many PolarFire SoC deployments.
We need to have the HSS running on the monitor core after the system has
booted for various reasons. Some of the current HSS functionalities can
be migrated at a later time.
The HSS was designed to easily enable and disable features through
Kconfig which should allow to assign features to different boot stages
depending on the overall system deployment. Keeping the HSS as ROM code
capable of starting various early boot stages in either M mode or S mode
allows us (Microchip engineering and non pure Linux users) to mix
different operating systems on the same platform and more easily debug
hardware bring-up.
What I am trying to get at is that we need to balance the QEMU ease of
use with the ability to bring-up and debug actual hardware. My preferred
approach is to keep all the hardware bring up in one place, the HSS, so
that you do not have to worry about obscure silicon idiosyncrasies once
you reach the open source boot flow. Silicon/board bring up
steps/features can be brought out of the HSS into the open source boot
stages once these steps are mature.
PolarFire SoC is the third family of SoC FPGA I have worked on. So I
have a fair idea of the amount of pain in front of me to bring the
entire device family to market :-) We decided early on in the
architecture of PolarFire SoC that we would make all code executing on
the RISC-V processors open source and user modifiable. This includes all
code typically hidden away in your typical SoC ROM code. This is why
PolarFire SoC has on-chip flash memory used to store the HSS and why the
HSS should be thought as including ROM code. The current Icicle Kit uses
engineering samples from the first device in the PolarFire SoC family.
So we are really at the beginning of the process of validating very
early boot steps on a significant number of devices. I do not want to
expose the open source community to the pain of bringing up a family of
devices because of the decision to open source all code. So I am asking
you to not rush in trying to migrate components from the HSS to a later
boot stage just yet. It can be done but based on experience I think that
now is not the right time yet.
Regards,
Cyril.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 07/18] hw/sd: sd: Fix incorrect populated function switch status data structure
2020-08-21 10:09 ` Sai Pavan Boddu
@ 2020-08-21 10:08 ` Bin Meng
-1 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-21 10:08 UTC (permalink / raw)
To: Sai Pavan Boddu
Cc: Bin Meng, qemu-riscv, qemu-block, Sagar Karandikar,
Bastian Koppelmann, Palmer Dabbelt, Philippe Mathieu-Daudé,
qemu-devel, saipava, Alistair Francis
Hi Sai,
On Fri, Aug 21, 2020 at 6:04 PM Sai Pavan Boddu
<sai.pavan.boddu@xilinx.com> wrote:
>
> Hi Philippe,
>
> First two patch of SD look good. Tested them over zynqmp and versal
> platforms.
>
Thanks for testing.
Can I add your Tested-by tag?
Regards,
Bin
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 07/18] hw/sd: sd: Fix incorrect populated function switch status data structure
@ 2020-08-21 10:08 ` Bin Meng
0 siblings, 0 replies; 100+ messages in thread
From: Bin Meng @ 2020-08-21 10:08 UTC (permalink / raw)
To: Sai Pavan Boddu
Cc: Philippe Mathieu-Daudé,
Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv, Bin Meng, qemu-block,
saipava
Hi Sai,
On Fri, Aug 21, 2020 at 6:04 PM Sai Pavan Boddu
<sai.pavan.boddu@xilinx.com> wrote:
>
> Hi Philippe,
>
> First two patch of SD look good. Tested them over zynqmp and versal
> platforms.
>
Thanks for testing.
Can I add your Tested-by tag?
Regards,
Bin
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 07/18] hw/sd: sd: Fix incorrect populated function switch status data structure
2020-08-18 16:30 ` Sai Pavan Boddu
@ 2020-08-21 10:09 ` Sai Pavan Boddu
0 siblings, 0 replies; 100+ messages in thread
From: Sai Pavan Boddu @ 2020-08-21 10:09 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Bin Meng, qemu-riscv, qemu-block, Sagar Karandikar,
Bastian Koppelmann, Palmer Dabbelt, Philippe Mathieu-Daudé,
qemu-devel, saipava, Alistair Francis, Bin Meng
Hi Philippe,
First two patch of SD look good. Tested them over zynqmp and versal
platforms.
Thanks,
Sai Pavan
On Tue, Aug 18, 2020 at 04:30:15PM +0000, Sai Pavan Boddu wrote:
> Thanks Philippe,
>
> I would test this and get back.
>
> Regards,
> Sai Pavan
>
> > -----Original Message-----
> > From: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> On
> > Behalf Of Philippe Mathieu-Daudé
> > Sent: Saturday, August 15, 2020 1:29 PM
> > To: Bin Meng <bmeng.cn@gmail.com>; Alistair Francis
> > <Alistair.Francis@wdc.com>; Bastian Koppelmann <kbastian@mail.uni-
> > paderborn.de>; Palmer Dabbelt <palmerdabbelt@google.com>; Sagar
> > Karandikar <sagark@eecs.berkeley.edu>; qemu-devel@nongnu.org; qemu-
> > riscv@nongnu.org; Sai Pavan Boddu <saipava@xilinx.com>
> > Cc: Bin Meng <bin.meng@windriver.com>; qemu-block@nongnu.org
> > Subject: Re: [PATCH 07/18] hw/sd: sd: Fix incorrect populated function switch
> > status data structure
> >
> > +Sai Pavan
> >
> > On 8/14/20 6:40 PM, Bin Meng wrote:
> > > From: Bin Meng <bin.meng@windriver.com>
> > >
> > > At present the function switch status data structure bit [399:376] are
> > > wrongly pupulated. These 3 bytes encode function switch status for the
> > > 6 function groups, with 4 bits per group, starting from function group
> > > 6 at bit 399, then followed by function group 5 at bit 395, and so on.
> > >
> > > However the codes mistakenly fills in the function group 1 status at
> > > bit 399. This fixes the code logic.
> > >
> >
> > Fixes: a1bb27b1e9 ("SD card emulation (initial implementation)")
> >
> > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > ---
> > >
> > > hw/sd/sd.c | 6 +++++-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/hw/sd/sd.c b/hw/sd/sd.c
> > > index fad9cf1..51f5900 100644
> > > --- a/hw/sd/sd.c
> > > +++ b/hw/sd/sd.c
> > > @@ -806,11 +806,15 @@ static void sd_function_switch(SDState *sd,
> > uint32_t arg)
> > > sd->data[11] = 0x43;
> > > sd->data[12] = 0x80; /* Supported group 1 functions */
> > > sd->data[13] = 0x03;
> > > +
> > > + sd->data[14] = 0;
> > > + sd->data[15] = 0;
> > > + sd->data[16] = 0;
> >
> > Pointless zero initialization.
> >
> > Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> >
> > I'll wait until next week in case Sai Pavan wants to test this patch (I don't have
> > access to the Xilinx images anymore) then I'll queue this via my sd-next tree.
> >
> > Regards,
> >
> > Phil.
> >
> > > for (i = 0; i < 6; i ++) {
> > > new_func = (arg >> (i * 4)) & 0x0f;
> > > if (mode && new_func != 0x0f)
> > > sd->function_group[i] = new_func;
> > > - sd->data[14 + (i >> 1)] = new_func << ((i * 4) & 4);
> > > + sd->data[16 - (i >> 1)] |= new_func << ((i % 2) * 4);
> > > }
> > > memset(&sd->data[17], 0, 47);
> > > stw_be_p(sd->data + 64, sd_crc16(sd->data, 64));
> > >
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 07/18] hw/sd: sd: Fix incorrect populated function switch status data structure
@ 2020-08-21 10:09 ` Sai Pavan Boddu
0 siblings, 0 replies; 100+ messages in thread
From: Sai Pavan Boddu @ 2020-08-21 10:09 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Philippe Mathieu-Daudé,
Bin Meng, Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv, Bin Meng, qemu-block,
saipava
Hi Philippe,
First two patch of SD look good. Tested them over zynqmp and versal
platforms.
Thanks,
Sai Pavan
On Tue, Aug 18, 2020 at 04:30:15PM +0000, Sai Pavan Boddu wrote:
> Thanks Philippe,
>
> I would test this and get back.
>
> Regards,
> Sai Pavan
>
> > -----Original Message-----
> > From: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> On
> > Behalf Of Philippe Mathieu-Daudé
> > Sent: Saturday, August 15, 2020 1:29 PM
> > To: Bin Meng <bmeng.cn@gmail.com>; Alistair Francis
> > <Alistair.Francis@wdc.com>; Bastian Koppelmann <kbastian@mail.uni-
> > paderborn.de>; Palmer Dabbelt <palmerdabbelt@google.com>; Sagar
> > Karandikar <sagark@eecs.berkeley.edu>; qemu-devel@nongnu.org; qemu-
> > riscv@nongnu.org; Sai Pavan Boddu <saipava@xilinx.com>
> > Cc: Bin Meng <bin.meng@windriver.com>; qemu-block@nongnu.org
> > Subject: Re: [PATCH 07/18] hw/sd: sd: Fix incorrect populated function switch
> > status data structure
> >
> > +Sai Pavan
> >
> > On 8/14/20 6:40 PM, Bin Meng wrote:
> > > From: Bin Meng <bin.meng@windriver.com>
> > >
> > > At present the function switch status data structure bit [399:376] are
> > > wrongly pupulated. These 3 bytes encode function switch status for the
> > > 6 function groups, with 4 bits per group, starting from function group
> > > 6 at bit 399, then followed by function group 5 at bit 395, and so on.
> > >
> > > However the codes mistakenly fills in the function group 1 status at
> > > bit 399. This fixes the code logic.
> > >
> >
> > Fixes: a1bb27b1e9 ("SD card emulation (initial implementation)")
> >
> > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > ---
> > >
> > > hw/sd/sd.c | 6 +++++-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/hw/sd/sd.c b/hw/sd/sd.c
> > > index fad9cf1..51f5900 100644
> > > --- a/hw/sd/sd.c
> > > +++ b/hw/sd/sd.c
> > > @@ -806,11 +806,15 @@ static void sd_function_switch(SDState *sd,
> > uint32_t arg)
> > > sd->data[11] = 0x43;
> > > sd->data[12] = 0x80; /* Supported group 1 functions */
> > > sd->data[13] = 0x03;
> > > +
> > > + sd->data[14] = 0;
> > > + sd->data[15] = 0;
> > > + sd->data[16] = 0;
> >
> > Pointless zero initialization.
> >
> > Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> >
> > I'll wait until next week in case Sai Pavan wants to test this patch (I don't have
> > access to the Xilinx images anymore) then I'll queue this via my sd-next tree.
> >
> > Regards,
> >
> > Phil.
> >
> > > for (i = 0; i < 6; i ++) {
> > > new_func = (arg >> (i * 4)) & 0x0f;
> > > if (mode && new_func != 0x0f)
> > > sd->function_group[i] = new_func;
> > > - sd->data[14 + (i >> 1)] = new_func << ((i * 4) & 4);
> > > + sd->data[16 - (i >> 1)] |= new_func << ((i % 2) * 4);
> > > }
> > > memset(&sd->data[17], 0, 47);
> > > stw_be_p(sd->data + 64, sd_crc16(sd->data, 64));
> > >
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
2020-08-19 10:13 ` Cyril.Jean
@ 2020-08-21 18:23 ` Alistair Francis
-1 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-21 18:23 UTC (permalink / raw)
To: Cyril.Jean
Cc: Bin Meng, open list:RISC-V, Anup Patel, Jason Wang,
Palmer Dabbelt, qemu-devel@nongnu.org Developers, Atish Patra,
Alistair Francis, Palmer Dabbelt, Bin Meng
On Wed, Aug 19, 2020 at 3:13 AM <Cyril.Jean@microchip.com> wrote:
>
> On 8/19/20 2:34 AM, Bin Meng wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > On Tue, Aug 18, 2020 at 9:55 PM Anup Patel <anup@brainfault.org> wrote:
> >> On Tue, Aug 18, 2020 at 6:39 PM <Cyril.Jean@microchip.com> wrote:
> >>> On 8/18/20 7:17 AM, Anup Patel wrote:
> >>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>>
> >>>> On Tue, Aug 18, 2020 at 1:23 AM <Cyril.Jean@microchip.com> wrote:
> >>>>> On 8/17/20 8:28 PM, Alistair Francis wrote:
> >>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>>>>
> >>>>>> On Mon, Aug 17, 2020 at 11:12 AM via <qemu-devel@nongnu.org> wrote:
> >>>>>>> Hi Anup,
> >>>>>>>
> >>>>>>> On 8/17/20 11:30 AM, Bin Meng wrote:
> >>>>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>>>>>>
> >>>>>>>> Hi Anup,
> >>>>>>>>
> >>>>>>>> On Sat, Aug 15, 2020 at 1:44 AM Anup Patel <anup@brainfault.org> wrote:
> >>>>>>>>> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >>>>>>>>>> From: Bin Meng <bin.meng@windriver.com>
> >>>>>>>>>>
> >>>>>>>>>> This adds support for Microchip PolarFire SoC Icicle Kit board.
> >>>>>>>>>> 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.
> >>>>>>>>> Nice Work !!! This is very helpful.
> >>>>>>>> Thanks!
> >>>>>>>>
> >>>>>>>>> The Microchip HSS is quite convoluted. It has:
> >>>>>>>>> 1. DDR Init
> >>>>>>>>> 2. Boot device support
> >>>>>>>>> 3. SBI support using OpenSBI as library
> >>>>>>>>> 4. Simple TEE support
> >>>>>>>>>
> >>>>>>>>> I think point 1) and 2) above should be part of U-Boot SPL.
> >>>>>>>>> The point 3) can be OpenSBI FW_DYNAMIC.
> >>>>>>>>>
> >>>>>>>>> Lastly,for point 4), we are working on a new OpenSBI feature using
> >>>>>>>>> which we can run independent Secure OS and Non-Secure OS using
> >>>>>>>>> U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
> >>>>>>>>> PolarFire).
> >>>>>>>>>
> >>>>>>>>> Do you have plans for adding U-Boot SPL support for this board ??
> >>>>>>>> + Cyril Jean from Microchip
> >>>>>>>>
> >>>>>>>> I will have to leave this question to Cyril to comment.
> >>>>>>>>
> >>>>>>> I currently do not have a plan to support U-Boot SPL. The idea of the
> >>>>>>> HSS is to contain all the silicon specific initialization and
> >>>>>>> configuration code within the HSS before jumping to U-Boot S-mode. I
> >>>>>>> would rather keep all this within the HSS for the time being. I would
> >>>>>>> wait until we reach production silicon before attempting to move this to
> >>>>>>> U-Boot SPL as the HSS is likely to contain some opaque silicon related
> >>>>>>> changes for another while.
> >>>>>> That is unfortunate, a lot of work has gone into making the boot flow
> >>>>>> simple and easy to use.
> >>>>>>
> >>>>>> QEMU now includes OpenSBI by default to make it easy for users to boot
> >>>>>> Linux. The Icicle Kit board is now the most difficult QEMU board to
> >>>>>> boot Linux on. Not to mention it makes it hard to impossible to
> >>>>>> support it in standard tool flows such as meta-riscv.
> >>>>>>
> >>>>>> Alistair
> >>>>> If it is such a problem we can add a U-Boot SPL stage and the HSS can be
> >>>>> treated as standard SoC ROM code.
> >>>> It's not mandatory for U-Boot SPL to have stable DRAM calibration settings
> >>>> from the start itself. The initial U-Boot SPL support for most
> >>>> platforms (accross
> >>>> architectures) usually include basic working DRAM calibration settings which
> >>>> is later on updated with separate patches. Also, we don't need all U-Boot
> >>>> drivers to be upstreamed in one-go as this can be done in phases.
> >>>>
> >>>> The advantage we have with PolarFire SoC Icicle board is that we already
> >>>> have a U-Boot S-mode. and we believe the OpenSBI generic platform will
> >>>> work fine for PolarFire SoC Icicle board so the only thing missing right now
> >>>> is the U-Boot SPL support for OpenSource boot-flow.
> >>>>
> >>>> It will certainly accelerate open-source development if we have boot-flow
> >>>> U-Boot_SPL => OpenSBI (FW_DYNAMIC) => U-Boot_S-mode working
> >>>> on PolarFire SoC Icicle board. Initially, we just need DRAM, SD/eMMC,
> >>>> and Serial port support for U-Boot SPL and U-Boot S-mode. Later on,
> >>>> more patches can add ethernet and other booting device drivers to U-Boot.
> >>>>
> >>>> Regarding security services of HSS, we are working on a OpenSBI
> >>>> feature which will allow HSS security services to run as independent
> >>>> binary in M-mode (not linked to OpenSBI) and OpenSBI FW_DYNAMIC
> >>>> will be a separate binary acting as a secure monitor.
> >>>>
> >>>> Regards,
> >>>> Anup
> >>> What I have in mind is that the external memory will be up and running
> >>> by the time we get to U-Boot SPL. In the case of PolarFire SoC the ROM
> >>> code equivalent brings up the DDR memory interface so we do not need to
> >>> worry about this as part of U-Boot.
> >> Keeping DRAM configuration as part of a separate ROM booting stage prior
> >> to the U-Boot SPL sounds good to me. This will lead to following boot-flow:
> >>
> >> ROM/HSS (M-mode) => U-Boot SPL (M-mode) => OpenSBI (M-mode) => U-Boot S-mode
> > If we want to keep the HSS, meaning that DDR memory is already
> > initialized, then there is no need to create an additional step of
> > U-Boot SPL phase, because there is no size limitation any more.
> >
> > Right now, the boot workflow on PolarFire is:
> >
> > HSS + OpenSBI (as a library) (M-mode) => U-Boot S-mode
> >
> > It's just not the canonical way because of the HSS and OpenSBI as a library.
> >
> > A canonical way should be:
> >
> > U-Boot SPL (M-mode) => OpenSBI dynamic (M-mode) => U-Boot S-mode
> >
> > So we should be aiming to replace HSS with U-Boot SPL.
> >
> >>> Sounds to me the component that needs to be upstreamed next is the eMMC
> >>> support so that it can be used as part of U-Boot SPL. Correct?
> >> Maybe as a PHASE1 patch series for PolarFire U-Boot support can
> >> target the following:
> >> 1. Minimal U-Boot board support for PolarFire IcIcle Board with
> >> single defconfig to build both U-Boot SPL and U-Boot S-mode
> >> 2. Serial port driver (probably re-use existing driver)
> >> 3. SD and eMMC driver
> >>
> >> Supporting SD booting is highly desirable for PHASE1. At least,
> >> U-Boot SPL, OpenSBI, U-Boot S-mode, and Linux should come
> >> as separate images from SD card. The ROM/HSS can reside and
> >> boot from on-board flash/eMMC.
> >>
> >> Above is my suggestion based on experience with SiFive Unleashed.
> >>
> >> The general idea behind OpenSource boot-flow is to have each
> >> booting stage as a separate binary so that users can selectively
> >> upgrade a particular booting stage without re-compiling/re-flashing
> >> other booting stages.
> >>
> >> Various distros and yocto already support building most of the above
> >> booting stages (U-Boot, OpenSBI, Linux, etc) so we can reuse a lot
> >> of existing work. Eventually, I am confident we will endup moving
> >> more stuff from ROM/HSS to U-Boot SPL for ease in maintenance.
> > Regards,
> > Bin
>
> I am OK with supporting U-Boot SPL as a community boot flow but the HSS
> is not going to disappear completely for many PolarFire SoC deployments.
> We need to have the HSS running on the monitor core after the system has
> booted for various reasons. Some of the current HSS functionalities can
> be migrated at a later time.
>
> The HSS was designed to easily enable and disable features through
> Kconfig which should allow to assign features to different boot stages
> depending on the overall system deployment. Keeping the HSS as ROM code
> capable of starting various early boot stages in either M mode or S mode
> allows us (Microchip engineering and non pure Linux users) to mix
> different operating systems on the same platform and more easily debug
> hardware bring-up.
Thanks for explaining this.
I have changed the CC list a bit to be a little more targeted.
>
> What I am trying to get at is that we need to balance the QEMU ease of
> use with the ability to bring-up and debug actual hardware. My preferred
Agreed. I don't think anyone has been saying that these changes should
be for QEMU only. All of the changes talked about apply to both the
QEMU model and the hardware.
> approach is to keep all the hardware bring up in one place, the HSS, so
> that you do not have to worry about obscure silicon idiosyncrasies once
> you reach the open source boot flow. Silicon/board bring up
That is a noble goal, but doesn't HSS currently pull in the OpenSBI
library, so it's doing more than just dealing with silicon bugs. As
well as that HSS is not supported by distros, so distros can't build
or ship it. For example OE won't build it in the meta-riscv layer,
meaning that the Icle board just isn't supported. This means the board
misses out on core work, for example it won't be able to utilise the
RISC-V AGL work that has started.
Also, how are users expected to update HSS as bugs and vulnerabilities
are found if it isn't shipped by distros?
> steps/features can be brought out of the HSS into the open source boot
> stages once these steps are mature.
>
> PolarFire SoC is the third family of SoC FPGA I have worked on. So I
> have a fair idea of the amount of pain in front of me to bring the
> entire device family to market :-) We decided early on in the
> architecture of PolarFire SoC that we would make all code executing on
> the RISC-V processors open source and user modifiable. This includes all
Awesome!!! That is so great to hear.
> code typically hidden away in your typical SoC ROM code. This is why
Again, this is just awesome!
> PolarFire SoC has on-chip flash memory used to store the HSS and why the
> HSS should be thought as including ROM code. The current Icicle Kit uses
If we could change it to be more like a traditional ROM in terms of
features then that would be really helpful. In that case we wouldn't
need it for QEMU and only use it for hardware. It would only handle
basic hardware boot up and then hand it over to U-Boot SPL/OpenSBI.
> engineering samples from the first device in the PolarFire SoC family.
> So we are really at the beginning of the process of validating very
> early boot steps on a significant number of devices. I do not want to
> expose the open source community to the pain of bringing up a family of
> devices because of the decision to open source all code. So I am asking
I understand what you mean. In saying that it is usually easiest to
start with the goal of upstreaming and then work towards that. That
way all of the architectures decisions are made in that context. Maybe
at first you have a fork while everything is in flux, but then it's
really helpful to have the work upstreamed.
I think we have all seen too many "open source" projects that just
fork everything, dump their code and never contribute back.
Unfortunately when that happens we end up with duplicate work and
frustrated engineers. As well as that the original project misses out
on all the advantages of open source as they aren't benefiting from
others work as well.
> you to not rush in trying to migrate components from the HSS to a later
> boot stage just yet. It can be done but based on experience I think that
> now is not the right time yet.
The open source focus is great to hear. I think we are all really glad
that MicroChip is doing this. It's a great first step, but it doesn't
end there.
Alistair
>
> Regards,
>
> Cyril.
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
@ 2020-08-21 18:23 ` Alistair Francis
0 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-21 18:23 UTC (permalink / raw)
To: Cyril.Jean
Cc: Bin Meng, Anup Patel, Alistair Francis, Palmer Dabbelt,
qemu-devel@nongnu.org Developers, open list:RISC-V, Jason Wang,
Bin Meng, Palmer Dabbelt, Atish Patra
On Wed, Aug 19, 2020 at 3:13 AM <Cyril.Jean@microchip.com> wrote:
>
> On 8/19/20 2:34 AM, Bin Meng wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > On Tue, Aug 18, 2020 at 9:55 PM Anup Patel <anup@brainfault.org> wrote:
> >> On Tue, Aug 18, 2020 at 6:39 PM <Cyril.Jean@microchip.com> wrote:
> >>> On 8/18/20 7:17 AM, Anup Patel wrote:
> >>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>>
> >>>> On Tue, Aug 18, 2020 at 1:23 AM <Cyril.Jean@microchip.com> wrote:
> >>>>> On 8/17/20 8:28 PM, Alistair Francis wrote:
> >>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>>>>
> >>>>>> On Mon, Aug 17, 2020 at 11:12 AM via <qemu-devel@nongnu.org> wrote:
> >>>>>>> Hi Anup,
> >>>>>>>
> >>>>>>> On 8/17/20 11:30 AM, Bin Meng wrote:
> >>>>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>>>>>>
> >>>>>>>> Hi Anup,
> >>>>>>>>
> >>>>>>>> On Sat, Aug 15, 2020 at 1:44 AM Anup Patel <anup@brainfault.org> wrote:
> >>>>>>>>> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >>>>>>>>>> From: Bin Meng <bin.meng@windriver.com>
> >>>>>>>>>>
> >>>>>>>>>> This adds support for Microchip PolarFire SoC Icicle Kit board.
> >>>>>>>>>> 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.
> >>>>>>>>> Nice Work !!! This is very helpful.
> >>>>>>>> Thanks!
> >>>>>>>>
> >>>>>>>>> The Microchip HSS is quite convoluted. It has:
> >>>>>>>>> 1. DDR Init
> >>>>>>>>> 2. Boot device support
> >>>>>>>>> 3. SBI support using OpenSBI as library
> >>>>>>>>> 4. Simple TEE support
> >>>>>>>>>
> >>>>>>>>> I think point 1) and 2) above should be part of U-Boot SPL.
> >>>>>>>>> The point 3) can be OpenSBI FW_DYNAMIC.
> >>>>>>>>>
> >>>>>>>>> Lastly,for point 4), we are working on a new OpenSBI feature using
> >>>>>>>>> which we can run independent Secure OS and Non-Secure OS using
> >>>>>>>>> U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
> >>>>>>>>> PolarFire).
> >>>>>>>>>
> >>>>>>>>> Do you have plans for adding U-Boot SPL support for this board ??
> >>>>>>>> + Cyril Jean from Microchip
> >>>>>>>>
> >>>>>>>> I will have to leave this question to Cyril to comment.
> >>>>>>>>
> >>>>>>> I currently do not have a plan to support U-Boot SPL. The idea of the
> >>>>>>> HSS is to contain all the silicon specific initialization and
> >>>>>>> configuration code within the HSS before jumping to U-Boot S-mode. I
> >>>>>>> would rather keep all this within the HSS for the time being. I would
> >>>>>>> wait until we reach production silicon before attempting to move this to
> >>>>>>> U-Boot SPL as the HSS is likely to contain some opaque silicon related
> >>>>>>> changes for another while.
> >>>>>> That is unfortunate, a lot of work has gone into making the boot flow
> >>>>>> simple and easy to use.
> >>>>>>
> >>>>>> QEMU now includes OpenSBI by default to make it easy for users to boot
> >>>>>> Linux. The Icicle Kit board is now the most difficult QEMU board to
> >>>>>> boot Linux on. Not to mention it makes it hard to impossible to
> >>>>>> support it in standard tool flows such as meta-riscv.
> >>>>>>
> >>>>>> Alistair
> >>>>> If it is such a problem we can add a U-Boot SPL stage and the HSS can be
> >>>>> treated as standard SoC ROM code.
> >>>> It's not mandatory for U-Boot SPL to have stable DRAM calibration settings
> >>>> from the start itself. The initial U-Boot SPL support for most
> >>>> platforms (accross
> >>>> architectures) usually include basic working DRAM calibration settings which
> >>>> is later on updated with separate patches. Also, we don't need all U-Boot
> >>>> drivers to be upstreamed in one-go as this can be done in phases.
> >>>>
> >>>> The advantage we have with PolarFire SoC Icicle board is that we already
> >>>> have a U-Boot S-mode. and we believe the OpenSBI generic platform will
> >>>> work fine for PolarFire SoC Icicle board so the only thing missing right now
> >>>> is the U-Boot SPL support for OpenSource boot-flow.
> >>>>
> >>>> It will certainly accelerate open-source development if we have boot-flow
> >>>> U-Boot_SPL => OpenSBI (FW_DYNAMIC) => U-Boot_S-mode working
> >>>> on PolarFire SoC Icicle board. Initially, we just need DRAM, SD/eMMC,
> >>>> and Serial port support for U-Boot SPL and U-Boot S-mode. Later on,
> >>>> more patches can add ethernet and other booting device drivers to U-Boot.
> >>>>
> >>>> Regarding security services of HSS, we are working on a OpenSBI
> >>>> feature which will allow HSS security services to run as independent
> >>>> binary in M-mode (not linked to OpenSBI) and OpenSBI FW_DYNAMIC
> >>>> will be a separate binary acting as a secure monitor.
> >>>>
> >>>> Regards,
> >>>> Anup
> >>> What I have in mind is that the external memory will be up and running
> >>> by the time we get to U-Boot SPL. In the case of PolarFire SoC the ROM
> >>> code equivalent brings up the DDR memory interface so we do not need to
> >>> worry about this as part of U-Boot.
> >> Keeping DRAM configuration as part of a separate ROM booting stage prior
> >> to the U-Boot SPL sounds good to me. This will lead to following boot-flow:
> >>
> >> ROM/HSS (M-mode) => U-Boot SPL (M-mode) => OpenSBI (M-mode) => U-Boot S-mode
> > If we want to keep the HSS, meaning that DDR memory is already
> > initialized, then there is no need to create an additional step of
> > U-Boot SPL phase, because there is no size limitation any more.
> >
> > Right now, the boot workflow on PolarFire is:
> >
> > HSS + OpenSBI (as a library) (M-mode) => U-Boot S-mode
> >
> > It's just not the canonical way because of the HSS and OpenSBI as a library.
> >
> > A canonical way should be:
> >
> > U-Boot SPL (M-mode) => OpenSBI dynamic (M-mode) => U-Boot S-mode
> >
> > So we should be aiming to replace HSS with U-Boot SPL.
> >
> >>> Sounds to me the component that needs to be upstreamed next is the eMMC
> >>> support so that it can be used as part of U-Boot SPL. Correct?
> >> Maybe as a PHASE1 patch series for PolarFire U-Boot support can
> >> target the following:
> >> 1. Minimal U-Boot board support for PolarFire IcIcle Board with
> >> single defconfig to build both U-Boot SPL and U-Boot S-mode
> >> 2. Serial port driver (probably re-use existing driver)
> >> 3. SD and eMMC driver
> >>
> >> Supporting SD booting is highly desirable for PHASE1. At least,
> >> U-Boot SPL, OpenSBI, U-Boot S-mode, and Linux should come
> >> as separate images from SD card. The ROM/HSS can reside and
> >> boot from on-board flash/eMMC.
> >>
> >> Above is my suggestion based on experience with SiFive Unleashed.
> >>
> >> The general idea behind OpenSource boot-flow is to have each
> >> booting stage as a separate binary so that users can selectively
> >> upgrade a particular booting stage without re-compiling/re-flashing
> >> other booting stages.
> >>
> >> Various distros and yocto already support building most of the above
> >> booting stages (U-Boot, OpenSBI, Linux, etc) so we can reuse a lot
> >> of existing work. Eventually, I am confident we will endup moving
> >> more stuff from ROM/HSS to U-Boot SPL for ease in maintenance.
> > Regards,
> > Bin
>
> I am OK with supporting U-Boot SPL as a community boot flow but the HSS
> is not going to disappear completely for many PolarFire SoC deployments.
> We need to have the HSS running on the monitor core after the system has
> booted for various reasons. Some of the current HSS functionalities can
> be migrated at a later time.
>
> The HSS was designed to easily enable and disable features through
> Kconfig which should allow to assign features to different boot stages
> depending on the overall system deployment. Keeping the HSS as ROM code
> capable of starting various early boot stages in either M mode or S mode
> allows us (Microchip engineering and non pure Linux users) to mix
> different operating systems on the same platform and more easily debug
> hardware bring-up.
Thanks for explaining this.
I have changed the CC list a bit to be a little more targeted.
>
> What I am trying to get at is that we need to balance the QEMU ease of
> use with the ability to bring-up and debug actual hardware. My preferred
Agreed. I don't think anyone has been saying that these changes should
be for QEMU only. All of the changes talked about apply to both the
QEMU model and the hardware.
> approach is to keep all the hardware bring up in one place, the HSS, so
> that you do not have to worry about obscure silicon idiosyncrasies once
> you reach the open source boot flow. Silicon/board bring up
That is a noble goal, but doesn't HSS currently pull in the OpenSBI
library, so it's doing more than just dealing with silicon bugs. As
well as that HSS is not supported by distros, so distros can't build
or ship it. For example OE won't build it in the meta-riscv layer,
meaning that the Icle board just isn't supported. This means the board
misses out on core work, for example it won't be able to utilise the
RISC-V AGL work that has started.
Also, how are users expected to update HSS as bugs and vulnerabilities
are found if it isn't shipped by distros?
> steps/features can be brought out of the HSS into the open source boot
> stages once these steps are mature.
>
> PolarFire SoC is the third family of SoC FPGA I have worked on. So I
> have a fair idea of the amount of pain in front of me to bring the
> entire device family to market :-) We decided early on in the
> architecture of PolarFire SoC that we would make all code executing on
> the RISC-V processors open source and user modifiable. This includes all
Awesome!!! That is so great to hear.
> code typically hidden away in your typical SoC ROM code. This is why
Again, this is just awesome!
> PolarFire SoC has on-chip flash memory used to store the HSS and why the
> HSS should be thought as including ROM code. The current Icicle Kit uses
If we could change it to be more like a traditional ROM in terms of
features then that would be really helpful. In that case we wouldn't
need it for QEMU and only use it for hardware. It would only handle
basic hardware boot up and then hand it over to U-Boot SPL/OpenSBI.
> engineering samples from the first device in the PolarFire SoC family.
> So we are really at the beginning of the process of validating very
> early boot steps on a significant number of devices. I do not want to
> expose the open source community to the pain of bringing up a family of
> devices because of the decision to open source all code. So I am asking
I understand what you mean. In saying that it is usually easiest to
start with the goal of upstreaming and then work towards that. That
way all of the architectures decisions are made in that context. Maybe
at first you have a fork while everything is in flux, but then it's
really helpful to have the work upstreamed.
I think we have all seen too many "open source" projects that just
fork everything, dump their code and never contribute back.
Unfortunately when that happens we end up with duplicate work and
frustrated engineers. As well as that the original project misses out
on all the advantages of open source as they aren't benefiting from
others work as well.
> you to not rush in trying to migrate components from the HSS to a later
> boot stage just yet. It can be done but based on experience I think that
> now is not the right time yet.
The open source focus is great to hear. I think we are all really glad
that MicroChip is doing this. It's a great first step, but it doesn't
end there.
Alistair
>
> Regards,
>
> Cyril.
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 15/18] hw/riscv: microchip_pfsoc: Connect 2 Cadence GEMs
2020-08-14 16:40 ` [PATCH 15/18] hw/riscv: microchip_pfsoc: Connect 2 Cadence GEMs Bin Meng
@ 2020-08-21 18:46 ` Alistair Francis
0 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-21 18:46 UTC (permalink / raw)
To: Bin Meng
Cc: Bin Meng, open list:RISC-V, Sagar Karandikar, Bastian Koppelmann,
Palmer Dabbelt, qemu-devel@nongnu.org Developers,
Alistair Francis, Palmer Dabbelt
On Fri, Aug 14, 2020 at 9:51 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> 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>
Alistair
> ---
>
> hw/riscv/microchip_pfsoc.c | 39 ++++++++++++++++++++++++++++++++++++++
> include/hw/riscv/microchip_pfsoc.h | 7 +++++++
> 2 files changed, 46 insertions(+)
>
> diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
> index 1c67cbc..625b511 100644
> --- a/hw/riscv/microchip_pfsoc.c
> +++ b/hw/riscv/microchip_pfsoc.c
> @@ -14,6 +14,7 @@
> * 3) MMUARTs (Multi-Mode UART)
> * 4) Cadence eMMC/SDHC controller and an SD card connected to it
> * 5) DMA (Direct Memory Access Controller)
> + * 6) GEM (Gigabit Ethernet MAC Controller)
> *
> * This board currently generates devicetree dynamically that indicates at least
> * two harts and up to five harts.
> @@ -59,6 +60,9 @@
> #define BIOS_FILENAME "hss.bin"
> #define RESET_VECTOR 0x20220000
>
> +/* GEM version */
> +#define GEM_REVISION 0x0107010c
> +
> static const struct MemmapEntry {
> hwaddr base;
> hwaddr size;
> @@ -83,6 +87,8 @@ static const struct MemmapEntry {
> [MICROCHIP_PFSOC_MMUART2] = { 0x20102000, 0x1000 },
> [MICROCHIP_PFSOC_MMUART3] = { 0x20104000, 0x1000 },
> [MICROCHIP_PFSOC_MMUART4] = { 0x20106000, 0x1000 },
> + [MICROCHIP_PFSOC_GEM0] = { 0x20110000, 0x2000 },
> + [MICROCHIP_PFSOC_GEM1] = { 0x20112000, 0x2000 },
> [MICROCHIP_PFSOC_ENVM_CFG] = { 0x20200000, 0x1000 },
> [MICROCHIP_PFSOC_ENVM_DATA] = { 0x20220000, 0x20000 },
> [MICROCHIP_PFSOC_IOSCB_CFG] = { 0x37080000, 0x1000 },
> @@ -119,6 +125,9 @@ static void microchip_pfsoc_soc_instance_init(Object *obj)
> object_initialize_child(obj, "dma-controller", &s->dma,
> TYPE_MCHP_PFSOC_DMA);
>
> + object_initialize_child(obj, "gem0", &s->gem0, TYPE_CADENCE_GEM);
> + object_initialize_child(obj, "gem1", &s->gem1, TYPE_CADENCE_GEM);
> +
> object_initialize_child(obj, "sd-controller", &s->sdhci,
> TYPE_CADENCE_SDHCI);
> object_initialize_child(OBJECT(&s->sdhci), "sd-controller.sdhci",
> @@ -136,6 +145,7 @@ static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
> MemoryRegion *envm_data = g_new(MemoryRegion, 1);
> char *plic_hart_config;
> size_t plic_hart_config_len;
> + NICInfo *nd;
> int i;
>
> sysbus_realize(SYS_BUS_DEVICE(&s->e_cpus), &error_abort);
> @@ -269,6 +279,35 @@ static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
> qdev_get_gpio_in(DEVICE(s->plic), MICROCHIP_PFSOC_MMUART4_IRQ),
> serial_hd(4));
>
> + /* GEMs */
> +
> + nd = &nd_table[0];
> + if (nd->used) {
> + qemu_check_nic_model(nd, TYPE_CADENCE_GEM);
> + qdev_set_nic_properties(DEVICE(&s->gem0), nd);
> + }
> + nd = &nd_table[1];
> + if (nd->used) {
> + qemu_check_nic_model(nd, TYPE_CADENCE_GEM);
> + qdev_set_nic_properties(DEVICE(&s->gem1), nd);
> + }
> +
> + 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));
> +
> /* eNVM */
> memory_region_init_rom(envm_data, OBJECT(dev), "microchip.pfsoc.envm.data",
> memmap[MICROCHIP_PFSOC_ENVM_DATA].size,
> diff --git a/include/hw/riscv/microchip_pfsoc.h b/include/hw/riscv/microchip_pfsoc.h
> index 7825935..60f994c 100644
> --- a/include/hw/riscv/microchip_pfsoc.h
> +++ b/include/hw/riscv/microchip_pfsoc.h
> @@ -24,6 +24,7 @@
>
> #include "hw/char/mchp_pfsoc_mmuart.h"
> #include "hw/dma/mchp_pfsoc_dma.h"
> +#include "hw/net/cadence_gem.h"
> #include "hw/sd/cadence_sdhci.h"
>
> typedef struct MicrochipPFSoCState {
> @@ -42,6 +43,8 @@ typedef struct MicrochipPFSoCState {
> MchpPfSoCMMUartState *serial3;
> MchpPfSoCMMUartState *serial4;
> MchpPfSoCDMAState dma;
> + CadenceGEMState gem0;
> + CadenceGEMState gem1;
> CadenceSDHCIState sdhci;
> } MicrochipPFSoCState;
>
> @@ -84,6 +87,8 @@ enum {
> MICROCHIP_PFSOC_MMUART2,
> MICROCHIP_PFSOC_MMUART3,
> MICROCHIP_PFSOC_MMUART4,
> + MICROCHIP_PFSOC_GEM0,
> + MICROCHIP_PFSOC_GEM1,
> MICROCHIP_PFSOC_ENVM_CFG,
> MICROCHIP_PFSOC_ENVM_DATA,
> MICROCHIP_PFSOC_IOSCB_CFG,
> @@ -91,6 +96,8 @@ enum {
> };
>
> enum {
> + MICROCHIP_PFSOC_GEM0_IRQ = 64,
> + MICROCHIP_PFSOC_GEM1_IRQ = 70,
> MICROCHIP_PFSOC_EMMC_SD_IRQ = 88,
> MICROCHIP_PFSOC_MMUART0_IRQ = 90,
> MICROCHIP_PFSOC_MMUART1_IRQ = 91,
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 15/18] hw/riscv: microchip_pfsoc: Connect 2 Cadence GEMs
@ 2020-08-21 18:46 ` Alistair Francis
0 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-21 18:46 UTC (permalink / raw)
To: Bin Meng
Cc: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel@nongnu.org Developers,
open list:RISC-V, Bin Meng, Palmer Dabbelt
On Fri, Aug 14, 2020 at 9:51 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> 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>
Alistair
> ---
>
> hw/riscv/microchip_pfsoc.c | 39 ++++++++++++++++++++++++++++++++++++++
> include/hw/riscv/microchip_pfsoc.h | 7 +++++++
> 2 files changed, 46 insertions(+)
>
> diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
> index 1c67cbc..625b511 100644
> --- a/hw/riscv/microchip_pfsoc.c
> +++ b/hw/riscv/microchip_pfsoc.c
> @@ -14,6 +14,7 @@
> * 3) MMUARTs (Multi-Mode UART)
> * 4) Cadence eMMC/SDHC controller and an SD card connected to it
> * 5) DMA (Direct Memory Access Controller)
> + * 6) GEM (Gigabit Ethernet MAC Controller)
> *
> * This board currently generates devicetree dynamically that indicates at least
> * two harts and up to five harts.
> @@ -59,6 +60,9 @@
> #define BIOS_FILENAME "hss.bin"
> #define RESET_VECTOR 0x20220000
>
> +/* GEM version */
> +#define GEM_REVISION 0x0107010c
> +
> static const struct MemmapEntry {
> hwaddr base;
> hwaddr size;
> @@ -83,6 +87,8 @@ static const struct MemmapEntry {
> [MICROCHIP_PFSOC_MMUART2] = { 0x20102000, 0x1000 },
> [MICROCHIP_PFSOC_MMUART3] = { 0x20104000, 0x1000 },
> [MICROCHIP_PFSOC_MMUART4] = { 0x20106000, 0x1000 },
> + [MICROCHIP_PFSOC_GEM0] = { 0x20110000, 0x2000 },
> + [MICROCHIP_PFSOC_GEM1] = { 0x20112000, 0x2000 },
> [MICROCHIP_PFSOC_ENVM_CFG] = { 0x20200000, 0x1000 },
> [MICROCHIP_PFSOC_ENVM_DATA] = { 0x20220000, 0x20000 },
> [MICROCHIP_PFSOC_IOSCB_CFG] = { 0x37080000, 0x1000 },
> @@ -119,6 +125,9 @@ static void microchip_pfsoc_soc_instance_init(Object *obj)
> object_initialize_child(obj, "dma-controller", &s->dma,
> TYPE_MCHP_PFSOC_DMA);
>
> + object_initialize_child(obj, "gem0", &s->gem0, TYPE_CADENCE_GEM);
> + object_initialize_child(obj, "gem1", &s->gem1, TYPE_CADENCE_GEM);
> +
> object_initialize_child(obj, "sd-controller", &s->sdhci,
> TYPE_CADENCE_SDHCI);
> object_initialize_child(OBJECT(&s->sdhci), "sd-controller.sdhci",
> @@ -136,6 +145,7 @@ static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
> MemoryRegion *envm_data = g_new(MemoryRegion, 1);
> char *plic_hart_config;
> size_t plic_hart_config_len;
> + NICInfo *nd;
> int i;
>
> sysbus_realize(SYS_BUS_DEVICE(&s->e_cpus), &error_abort);
> @@ -269,6 +279,35 @@ static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
> qdev_get_gpio_in(DEVICE(s->plic), MICROCHIP_PFSOC_MMUART4_IRQ),
> serial_hd(4));
>
> + /* GEMs */
> +
> + nd = &nd_table[0];
> + if (nd->used) {
> + qemu_check_nic_model(nd, TYPE_CADENCE_GEM);
> + qdev_set_nic_properties(DEVICE(&s->gem0), nd);
> + }
> + nd = &nd_table[1];
> + if (nd->used) {
> + qemu_check_nic_model(nd, TYPE_CADENCE_GEM);
> + qdev_set_nic_properties(DEVICE(&s->gem1), nd);
> + }
> +
> + 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));
> +
> /* eNVM */
> memory_region_init_rom(envm_data, OBJECT(dev), "microchip.pfsoc.envm.data",
> memmap[MICROCHIP_PFSOC_ENVM_DATA].size,
> diff --git a/include/hw/riscv/microchip_pfsoc.h b/include/hw/riscv/microchip_pfsoc.h
> index 7825935..60f994c 100644
> --- a/include/hw/riscv/microchip_pfsoc.h
> +++ b/include/hw/riscv/microchip_pfsoc.h
> @@ -24,6 +24,7 @@
>
> #include "hw/char/mchp_pfsoc_mmuart.h"
> #include "hw/dma/mchp_pfsoc_dma.h"
> +#include "hw/net/cadence_gem.h"
> #include "hw/sd/cadence_sdhci.h"
>
> typedef struct MicrochipPFSoCState {
> @@ -42,6 +43,8 @@ typedef struct MicrochipPFSoCState {
> MchpPfSoCMMUartState *serial3;
> MchpPfSoCMMUartState *serial4;
> MchpPfSoCDMAState dma;
> + CadenceGEMState gem0;
> + CadenceGEMState gem1;
> CadenceSDHCIState sdhci;
> } MicrochipPFSoCState;
>
> @@ -84,6 +87,8 @@ enum {
> MICROCHIP_PFSOC_MMUART2,
> MICROCHIP_PFSOC_MMUART3,
> MICROCHIP_PFSOC_MMUART4,
> + MICROCHIP_PFSOC_GEM0,
> + MICROCHIP_PFSOC_GEM1,
> MICROCHIP_PFSOC_ENVM_CFG,
> MICROCHIP_PFSOC_ENVM_DATA,
> MICROCHIP_PFSOC_IOSCB_CFG,
> @@ -91,6 +96,8 @@ enum {
> };
>
> enum {
> + MICROCHIP_PFSOC_GEM0_IRQ = 64,
> + MICROCHIP_PFSOC_GEM1_IRQ = 70,
> MICROCHIP_PFSOC_EMMC_SD_IRQ = 88,
> MICROCHIP_PFSOC_MMUART0_IRQ = 90,
> MICROCHIP_PFSOC_MMUART1_IRQ = 91,
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 16/18] hw/riscv: microchip_pfsoc: Hook GPIO controllers
2020-08-14 16:40 ` [PATCH 16/18] hw/riscv: microchip_pfsoc: Hook GPIO controllers Bin Meng
@ 2020-08-21 18:47 ` Alistair Francis
0 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-21 18:47 UTC (permalink / raw)
To: Bin Meng
Cc: Bin Meng, open list:RISC-V, Sagar Karandikar, Bastian Koppelmann,
Palmer Dabbelt, qemu-devel@nongnu.org Developers,
Alistair Francis, Palmer Dabbelt
On Fri, Aug 14, 2020 at 9:53 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> 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).
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Alistair
> ---
>
> hw/riscv/microchip_pfsoc.c | 14 ++++++++++++++
> include/hw/riscv/microchip_pfsoc.h | 3 +++
> 2 files changed, 17 insertions(+)
>
> diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
> index 625b511..139284a 100644
> --- a/hw/riscv/microchip_pfsoc.c
> +++ b/hw/riscv/microchip_pfsoc.c
> @@ -89,6 +89,9 @@ static const struct MemmapEntry {
> [MICROCHIP_PFSOC_MMUART4] = { 0x20106000, 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_ENVM_CFG] = { 0x20200000, 0x1000 },
> [MICROCHIP_PFSOC_ENVM_DATA] = { 0x20220000, 0x20000 },
> [MICROCHIP_PFSOC_IOSCB_CFG] = { 0x37080000, 0x1000 },
> @@ -308,6 +311,17 @@ static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
> sysbus_connect_irq(SYS_BUS_DEVICE(&s->gem1), 0,
> qdev_get_gpio_in(DEVICE(s->plic), MICROCHIP_PFSOC_GEM1_IRQ));
>
> + /* 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);
> +
> /* eNVM */
> memory_region_init_rom(envm_data, OBJECT(dev), "microchip.pfsoc.envm.data",
> memmap[MICROCHIP_PFSOC_ENVM_DATA].size,
> diff --git a/include/hw/riscv/microchip_pfsoc.h b/include/hw/riscv/microchip_pfsoc.h
> index 60f994c..993b17c 100644
> --- a/include/hw/riscv/microchip_pfsoc.h
> +++ b/include/hw/riscv/microchip_pfsoc.h
> @@ -89,6 +89,9 @@ enum {
> MICROCHIP_PFSOC_MMUART4,
> MICROCHIP_PFSOC_GEM0,
> MICROCHIP_PFSOC_GEM1,
> + MICROCHIP_PFSOC_GPIO0,
> + MICROCHIP_PFSOC_GPIO1,
> + MICROCHIP_PFSOC_GPIO2,
> MICROCHIP_PFSOC_ENVM_CFG,
> MICROCHIP_PFSOC_ENVM_DATA,
> MICROCHIP_PFSOC_IOSCB_CFG,
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 16/18] hw/riscv: microchip_pfsoc: Hook GPIO controllers
@ 2020-08-21 18:47 ` Alistair Francis
0 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-21 18:47 UTC (permalink / raw)
To: Bin Meng
Cc: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel@nongnu.org Developers,
open list:RISC-V, Bin Meng, Palmer Dabbelt
On Fri, Aug 14, 2020 at 9:53 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> 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).
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Alistair
> ---
>
> hw/riscv/microchip_pfsoc.c | 14 ++++++++++++++
> include/hw/riscv/microchip_pfsoc.h | 3 +++
> 2 files changed, 17 insertions(+)
>
> diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
> index 625b511..139284a 100644
> --- a/hw/riscv/microchip_pfsoc.c
> +++ b/hw/riscv/microchip_pfsoc.c
> @@ -89,6 +89,9 @@ static const struct MemmapEntry {
> [MICROCHIP_PFSOC_MMUART4] = { 0x20106000, 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_ENVM_CFG] = { 0x20200000, 0x1000 },
> [MICROCHIP_PFSOC_ENVM_DATA] = { 0x20220000, 0x20000 },
> [MICROCHIP_PFSOC_IOSCB_CFG] = { 0x37080000, 0x1000 },
> @@ -308,6 +311,17 @@ static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
> sysbus_connect_irq(SYS_BUS_DEVICE(&s->gem1), 0,
> qdev_get_gpio_in(DEVICE(s->plic), MICROCHIP_PFSOC_GEM1_IRQ));
>
> + /* 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);
> +
> /* eNVM */
> memory_region_init_rom(envm_data, OBJECT(dev), "microchip.pfsoc.envm.data",
> memmap[MICROCHIP_PFSOC_ENVM_DATA].size,
> diff --git a/include/hw/riscv/microchip_pfsoc.h b/include/hw/riscv/microchip_pfsoc.h
> index 60f994c..993b17c 100644
> --- a/include/hw/riscv/microchip_pfsoc.h
> +++ b/include/hw/riscv/microchip_pfsoc.h
> @@ -89,6 +89,9 @@ enum {
> MICROCHIP_PFSOC_MMUART4,
> MICROCHIP_PFSOC_GEM0,
> MICROCHIP_PFSOC_GEM1,
> + MICROCHIP_PFSOC_GPIO0,
> + MICROCHIP_PFSOC_GPIO1,
> + MICROCHIP_PFSOC_GPIO2,
> MICROCHIP_PFSOC_ENVM_CFG,
> MICROCHIP_PFSOC_ENVM_DATA,
> MICROCHIP_PFSOC_IOSCB_CFG,
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 18/18] hw/riscv: microchip_pfsoc: Document the software used for testing
2020-08-14 16:40 ` [PATCH 18/18] hw/riscv: microchip_pfsoc: Document the software used for testing Bin Meng
@ 2020-08-21 18:51 ` Alistair Francis
0 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-21 18:51 UTC (permalink / raw)
To: Bin Meng
Cc: Bin Meng, open list:RISC-V, Sagar Karandikar, Bastian Koppelmann,
Palmer Dabbelt, qemu-devel@nongnu.org Developers,
Alistair Francis, Palmer Dabbelt
On Fri, Aug 14, 2020 at 9:49 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> Add some useful comments to document the software used for testing.
> including how to patch HSS to bypass the DDR memory initialization,
> HSS and Yocto BSP build instructions, etc.
>
> To launch this machine for testing:
> $ qemu-system-riscv64 -M microchip-icicle-kit -smp 5 \
> -bios path/to/hss.bin -sd path/to/sdcard.img \
> -nic user,model=cadence_gem \
> -nic tap,ifname=tap,model=cadence_gem \
> -display none -serial stdio \
> -chardev socket,id=serial1,path=serial1.sock,server,wait \
> -serial chardev:serial1
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
>
> ---
>
> hw/riscv/microchip_pfsoc.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
> index e8b7f86..1575fef 100644
> --- a/hw/riscv/microchip_pfsoc.c
> +++ b/hw/riscv/microchip_pfsoc.c
> @@ -56,6 +56,27 @@
> /*
> * The BIOS image used by this machine is called Hart Software Services (HSS).
> * See https://github.com/polarfire-soc/hart-software-services
> + *
> + * As of now the DDR memory controller in the Microchip PolarFire SoC has not
> + * been modeled. Simply creating unimplemented devices does not make HSS happy.
> + * Emulating the DDR memory controller is tedious, so a patched HSS should be
> + * used as the BIOS for this machine.
> + *
> + * To patch HSS, open boards/icicle-kit-es/hss_board_init.c in the HSS source
> + * tree, find the boardInitFunctions[] array that contains the initialization
> + * routines for this board, and remove the line that contains 'HSS_DDRInit'.
> + *
> + * QEMU does not support eMMC hence the SD configuration shall be used in the
> + * HSS and Yocto BSP build. The eMMC configuration is not supported.
> + *
> + * Instructions to build HSS:
> + * $ cp boards/icicle-kit-es/def_config.sdcard .config
> + * $ make BOARD=icicle-kit-es
> + *
> + * For Yocto build, "MACHINE=icicle-kit-es-sd" should be specified, otherwise
> + * when booting Linux kernel the rootfs cannot be mounted. The generated image
> + * is something like: mpfs-dev-cli-icicle-kit-es-sd.rootfs.wic. Resize the file
> + * with 'qemu-image' to a power of 2 before passing to QEMU '-sd' command line.
Instead of adding comments in the code (where it's hard for users to
find and prone to getting out of date) can you drop this patch and
instead update the RISC-V QEMU wiki?
https://wiki.qemu.org/Documentation/Platforms/RISCV
Just add an Icicle section.
Alistair
> */
> #define BIOS_FILENAME "hss.bin"
> #define RESET_VECTOR 0x20220000
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 18/18] hw/riscv: microchip_pfsoc: Document the software used for testing
@ 2020-08-21 18:51 ` Alistair Francis
0 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-21 18:51 UTC (permalink / raw)
To: Bin Meng
Cc: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel@nongnu.org Developers,
open list:RISC-V, Bin Meng, Palmer Dabbelt
On Fri, Aug 14, 2020 at 9:49 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> Add some useful comments to document the software used for testing.
> including how to patch HSS to bypass the DDR memory initialization,
> HSS and Yocto BSP build instructions, etc.
>
> To launch this machine for testing:
> $ qemu-system-riscv64 -M microchip-icicle-kit -smp 5 \
> -bios path/to/hss.bin -sd path/to/sdcard.img \
> -nic user,model=cadence_gem \
> -nic tap,ifname=tap,model=cadence_gem \
> -display none -serial stdio \
> -chardev socket,id=serial1,path=serial1.sock,server,wait \
> -serial chardev:serial1
>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
>
> ---
>
> hw/riscv/microchip_pfsoc.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
> index e8b7f86..1575fef 100644
> --- a/hw/riscv/microchip_pfsoc.c
> +++ b/hw/riscv/microchip_pfsoc.c
> @@ -56,6 +56,27 @@
> /*
> * The BIOS image used by this machine is called Hart Software Services (HSS).
> * See https://github.com/polarfire-soc/hart-software-services
> + *
> + * As of now the DDR memory controller in the Microchip PolarFire SoC has not
> + * been modeled. Simply creating unimplemented devices does not make HSS happy.
> + * Emulating the DDR memory controller is tedious, so a patched HSS should be
> + * used as the BIOS for this machine.
> + *
> + * To patch HSS, open boards/icicle-kit-es/hss_board_init.c in the HSS source
> + * tree, find the boardInitFunctions[] array that contains the initialization
> + * routines for this board, and remove the line that contains 'HSS_DDRInit'.
> + *
> + * QEMU does not support eMMC hence the SD configuration shall be used in the
> + * HSS and Yocto BSP build. The eMMC configuration is not supported.
> + *
> + * Instructions to build HSS:
> + * $ cp boards/icicle-kit-es/def_config.sdcard .config
> + * $ make BOARD=icicle-kit-es
> + *
> + * For Yocto build, "MACHINE=icicle-kit-es-sd" should be specified, otherwise
> + * when booting Linux kernel the rootfs cannot be mounted. The generated image
> + * is something like: mpfs-dev-cli-icicle-kit-es-sd.rootfs.wic. Resize the file
> + * with 'qemu-image' to a power of 2 before passing to QEMU '-sd' command line.
Instead of adding comments in the code (where it's hard for users to
find and prone to getting out of date) can you drop this patch and
instead update the RISC-V QEMU wiki?
https://wiki.qemu.org/Documentation/Platforms/RISCV
Just add an Icicle section.
Alistair
> */
> #define BIOS_FILENAME "hss.bin"
> #define RESET_VECTOR 0x20220000
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* RE: [PATCH 07/18] hw/sd: sd: Fix incorrect populated function switch status data structure
2020-08-21 10:08 ` Bin Meng
@ 2020-08-24 4:13 ` Sai Pavan Boddu
-1 siblings, 0 replies; 100+ messages in thread
From: Sai Pavan Boddu @ 2020-08-24 4:13 UTC (permalink / raw)
To: Bin Meng
Cc: Bin Meng, qemu-riscv, qemu-block, Sagar Karandikar,
Bastian Koppelmann, Palmer Dabbelt, Philippe Mathieu-Daudé,
qemu-devel, Alistair Francis
Hi Bin,
> -----Original Message-----
> From: Bin Meng <bmeng.cn@gmail.com>
> Sent: Friday, August 21, 2020 3:38 PM
> To: Sai Pavan Boddu <saipava@xilinx.com>
> Cc: Philippe Mathieu-Daudé <f4bug@amsat.org>; Alistair Francis
> <Alistair.Francis@wdc.com>; Bastian Koppelmann <kbastian@mail.uni-
> paderborn.de>; Palmer Dabbelt <palmerdabbelt@google.com>; Sagar
> Karandikar <sagark@eecs.berkeley.edu>; qemu-devel@nongnu.org; qemu-
> riscv@nongnu.org; Bin Meng <bin.meng@windriver.com>; qemu-
> block@nongnu.org; Sai Pavan Boddu <saipava@xilinx.com>
> Subject: Re: [PATCH 07/18] hw/sd: sd: Fix incorrect populated function switch
> status data structure
>
> Hi Sai,
>
> On Fri, Aug 21, 2020 at 6:04 PM Sai Pavan Boddu
> <sai.pavan.boddu@xilinx.com> wrote:
> >
> > Hi Philippe,
> >
> > First two patch of SD look good. Tested them over zynqmp and versal
> > platforms.
> >
>
> Thanks for testing.
>
> Can I add your Tested-by tag?
[Sai Pavan Boddu] Sure. Thanks.
Regards,
Sai Pavan
>
> Regards,
> Bin
^ permalink raw reply [flat|nested] 100+ messages in thread
* RE: [PATCH 07/18] hw/sd: sd: Fix incorrect populated function switch status data structure
@ 2020-08-24 4:13 ` Sai Pavan Boddu
0 siblings, 0 replies; 100+ messages in thread
From: Sai Pavan Boddu @ 2020-08-24 4:13 UTC (permalink / raw)
To: Bin Meng
Cc: Philippe Mathieu-Daudé,
Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel, qemu-riscv, Bin Meng, qemu-block
Hi Bin,
> -----Original Message-----
> From: Bin Meng <bmeng.cn@gmail.com>
> Sent: Friday, August 21, 2020 3:38 PM
> To: Sai Pavan Boddu <saipava@xilinx.com>
> Cc: Philippe Mathieu-Daudé <f4bug@amsat.org>; Alistair Francis
> <Alistair.Francis@wdc.com>; Bastian Koppelmann <kbastian@mail.uni-
> paderborn.de>; Palmer Dabbelt <palmerdabbelt@google.com>; Sagar
> Karandikar <sagark@eecs.berkeley.edu>; qemu-devel@nongnu.org; qemu-
> riscv@nongnu.org; Bin Meng <bin.meng@windriver.com>; qemu-
> block@nongnu.org; Sai Pavan Boddu <saipava@xilinx.com>
> Subject: Re: [PATCH 07/18] hw/sd: sd: Fix incorrect populated function switch
> status data structure
>
> Hi Sai,
>
> On Fri, Aug 21, 2020 at 6:04 PM Sai Pavan Boddu
> <sai.pavan.boddu@xilinx.com> wrote:
> >
> > Hi Philippe,
> >
> > First two patch of SD look good. Tested them over zynqmp and versal
> > platforms.
> >
>
> Thanks for testing.
>
> Can I add your Tested-by tag?
[Sai Pavan Boddu] Sure. Thanks.
Regards,
Sai Pavan
>
> Regards,
> Bin
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 17/18] hw/riscv: clint: Avoid using hard-coded timebase frequency
2020-08-14 16:40 ` [PATCH 17/18] hw/riscv: clint: Avoid using hard-coded timebase frequency Bin Meng
@ 2020-08-25 18:33 ` Alistair Francis
0 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-25 18:33 UTC (permalink / raw)
To: Bin Meng
Cc: Bin Meng, open list:RISC-V, Sagar Karandikar, Bastian Koppelmann,
Palmer Dabbelt, qemu-devel@nongnu.org Developers,
Alistair Francis, Palmer Dabbelt
On Fri, Aug 14, 2020 at 9:54 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> 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>
Alistair
> ---
>
> hw/riscv/microchip_pfsoc.c | 6 +++++-
> hw/riscv/sifive_clint.c | 25 ++++++++++++++-----------
> hw/riscv/sifive_e.c | 3 ++-
> hw/riscv/sifive_u.c | 3 ++-
> hw/riscv/spike.c | 2 +-
> hw/riscv/virt.c | 3 ++-
> include/hw/riscv/sifive_clint.h | 3 ++-
> target/riscv/cpu.h | 6 ++++--
> target/riscv/cpu_helper.c | 4 +++-
> target/riscv/csr.c | 4 ++--
> 10 files changed, 37 insertions(+), 22 deletions(-)
>
> diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
> index 139284a..e8b7f86 100644
> --- a/hw/riscv/microchip_pfsoc.c
> +++ b/hw/riscv/microchip_pfsoc.c
> @@ -60,6 +60,9 @@
> #define BIOS_FILENAME "hss.bin"
> #define RESET_VECTOR 0x20220000
>
> +/* CLINT timebase frequency */
> +#define CLINT_TIMEBASE_FREQ 1000000
> +
> /* GEM version */
> #define GEM_REVISION 0x0107010c
>
> @@ -189,7 +192,8 @@ static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
> /* CLINT */
> sifive_clint_create(memmap[MICROCHIP_PFSOC_CLINT].base,
> memmap[MICROCHIP_PFSOC_CLINT].size, ms->smp.cpus,
> - SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE, false);
> + SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE,
> + CLINT_TIMEBASE_FREQ, false);
>
> /* L2 cache controller */
> create_unimplemented_device("microchip.pfsoc.l2cc",
> diff --git a/hw/riscv/sifive_clint.c b/hw/riscv/sifive_clint.c
> index 669c21a..a568568 100644
> --- a/hw/riscv/sifive_clint.c
> +++ b/hw/riscv/sifive_clint.c
> @@ -29,22 +29,23 @@
> #include "hw/riscv/sifive_clint.h"
> #include "qemu/timer.h"
>
> -static uint64_t cpu_riscv_read_rtc(void)
> +static uint64_t cpu_riscv_read_rtc(uint32_t timebase_freq)
> {
> return muldiv64(qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL),
> - SIFIVE_CLINT_TIMEBASE_FREQ, NANOSECONDS_PER_SECOND);
> + timebase_freq, NANOSECONDS_PER_SECOND);
> }
>
> /*
> * Called when timecmp is written to update the QEMU timer or immediately
> * trigger timer interrupt if mtimecmp <= current timer value.
> */
> -static void sifive_clint_write_timecmp(RISCVCPU *cpu, uint64_t value)
> +static void sifive_clint_write_timecmp(RISCVCPU *cpu, uint64_t value,
> + uint32_t timebase_freq)
> {
> uint64_t next;
> uint64_t diff;
>
> - uint64_t rtc_r = cpu_riscv_read_rtc();
> + uint64_t rtc_r = cpu_riscv_read_rtc(timebase_freq);
>
> cpu->env.timecmp = value;
> if (cpu->env.timecmp <= rtc_r) {
> @@ -59,7 +60,7 @@ static void sifive_clint_write_timecmp(RISCVCPU *cpu, uint64_t value)
> diff = cpu->env.timecmp - rtc_r;
> /* back to ns (note args switched in muldiv64) */
> next = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
> - muldiv64(diff, NANOSECONDS_PER_SECOND, SIFIVE_CLINT_TIMEBASE_FREQ);
> + muldiv64(diff, NANOSECONDS_PER_SECOND, timebase_freq);
> timer_mod(cpu->env.timer, next);
> }
>
> @@ -111,10 +112,10 @@ static uint64_t sifive_clint_read(void *opaque, hwaddr addr, unsigned size)
> }
> } else if (addr == clint->time_base) {
> /* time_lo */
> - return cpu_riscv_read_rtc() & 0xFFFFFFFF;
> + return cpu_riscv_read_rtc(clint->timebase_freq) & 0xFFFFFFFF;
> } else if (addr == clint->time_base + 4) {
> /* time_hi */
> - return (cpu_riscv_read_rtc() >> 32) & 0xFFFFFFFF;
> + return (cpu_riscv_read_rtc(clint->timebase_freq) >> 32) & 0xFFFFFFFF;
> }
>
> error_report("clint: invalid read: %08x", (uint32_t)addr);
> @@ -151,13 +152,13 @@ static void sifive_clint_write(void *opaque, hwaddr addr, uint64_t value,
> /* timecmp_lo */
> uint64_t timecmp_hi = env->timecmp >> 32;
> sifive_clint_write_timecmp(RISCV_CPU(cpu),
> - timecmp_hi << 32 | (value & 0xFFFFFFFF));
> + timecmp_hi << 32 | (value & 0xFFFFFFFF), clint->timebase_freq);
> return;
> } else if ((addr & 0x7) == 4) {
> /* timecmp_hi */
> uint64_t timecmp_lo = env->timecmp;
> sifive_clint_write_timecmp(RISCV_CPU(cpu),
> - value << 32 | (timecmp_lo & 0xFFFFFFFF));
> + value << 32 | (timecmp_lo & 0xFFFFFFFF), clint->timebase_freq);
> } else {
> error_report("clint: invalid timecmp write: %08x", (uint32_t)addr);
> }
> @@ -191,6 +192,7 @@ static Property sifive_clint_properties[] = {
> DEFINE_PROP_UINT32("timecmp-base", SiFiveCLINTState, timecmp_base, 0),
> DEFINE_PROP_UINT32("time-base", SiFiveCLINTState, time_base, 0),
> DEFINE_PROP_UINT32("aperture-size", SiFiveCLINTState, aperture_size, 0),
> + DEFINE_PROP_UINT32("timebase-freq", SiFiveCLINTState, timebase_freq, 0),
> DEFINE_PROP_END_OF_LIST(),
> };
>
> @@ -229,7 +231,7 @@ type_init(sifive_clint_register_types)
> */
> DeviceState *sifive_clint_create(hwaddr addr, hwaddr size, uint32_t num_harts,
> uint32_t sip_base, uint32_t timecmp_base, uint32_t time_base,
> - bool provide_rdtime)
> + uint32_t timebase_freq, bool provide_rdtime)
> {
> int i;
> for (i = 0; i < num_harts; i++) {
> @@ -239,7 +241,7 @@ DeviceState *sifive_clint_create(hwaddr addr, hwaddr size, uint32_t num_harts,
> continue;
> }
> if (provide_rdtime) {
> - riscv_cpu_set_rdtime_fn(env, cpu_riscv_read_rtc);
> + riscv_cpu_set_rdtime_fn(env, cpu_riscv_read_rtc, timebase_freq);
> }
> env->timer = timer_new_ns(QEMU_CLOCK_VIRTUAL,
> &sifive_clint_timer_cb, cpu);
> @@ -252,6 +254,7 @@ DeviceState *sifive_clint_create(hwaddr addr, hwaddr size, uint32_t num_harts,
> qdev_prop_set_uint32(dev, "timecmp-base", timecmp_base);
> qdev_prop_set_uint32(dev, "time-base", time_base);
> qdev_prop_set_uint32(dev, "aperture-size", size);
> + qdev_prop_set_uint32(dev, "timebase-freq", timebase_freq);
> sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), &error_fatal);
> sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, addr);
> return dev;
> diff --git a/hw/riscv/sifive_e.c b/hw/riscv/sifive_e.c
> index c84d407..e7f6460 100644
> --- a/hw/riscv/sifive_e.c
> +++ b/hw/riscv/sifive_e.c
> @@ -213,7 +213,8 @@ static void sifive_e_soc_realize(DeviceState *dev, Error **errp)
> memmap[SIFIVE_E_PLIC].size);
> sifive_clint_create(memmap[SIFIVE_E_CLINT].base,
> memmap[SIFIVE_E_CLINT].size, ms->smp.cpus,
> - SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE, false);
> + SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE,
> + SIFIVE_CLINT_TIMEBASE_FREQ, false);
> create_unimplemented_device("riscv.sifive.e.aon",
> memmap[SIFIVE_E_AON].base, memmap[SIFIVE_E_AON].size);
> sifive_e_prci_create(memmap[SIFIVE_E_PRCI].base);
> diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> index e256da2..5ec9fca 100644
> --- a/hw/riscv/sifive_u.c
> +++ b/hw/riscv/sifive_u.c
> @@ -706,7 +706,8 @@ static void sifive_u_soc_realize(DeviceState *dev, Error **errp)
> serial_hd(1), qdev_get_gpio_in(DEVICE(s->plic), SIFIVE_U_UART1_IRQ));
> sifive_clint_create(memmap[SIFIVE_U_CLINT].base,
> memmap[SIFIVE_U_CLINT].size, ms->smp.cpus,
> - SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE, false);
> + SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE,
> + SIFIVE_CLINT_TIMEBASE_FREQ, false);
>
> if (!sysbus_realize(SYS_BUS_DEVICE(&s->prci), errp)) {
> return;
> diff --git a/hw/riscv/spike.c b/hw/riscv/spike.c
> index 13958bd..ae8593a 100644
> --- a/hw/riscv/spike.c
> +++ b/hw/riscv/spike.c
> @@ -235,7 +235,7 @@ static void spike_board_init(MachineState *machine)
> /* Core Local Interruptor (timer and IPI) */
> sifive_clint_create(memmap[SPIKE_CLINT].base, memmap[SPIKE_CLINT].size,
> smp_cpus, SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE,
> - false);
> + SIFIVE_CLINT_TIMEBASE_FREQ, false);
> }
>
> static void spike_machine_init(MachineClass *mc)
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index 6e91cf1..af0d06a 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -572,7 +572,8 @@ static void virt_machine_init(MachineState *machine)
> memmap[VIRT_PLIC].size);
> sifive_clint_create(memmap[VIRT_CLINT].base,
> memmap[VIRT_CLINT].size, smp_cpus,
> - SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE, true);
> + SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE,
> + SIFIVE_CLINT_TIMEBASE_FREQ, true);
> sifive_test_create(memmap[VIRT_TEST].base);
>
> for (i = 0; i < VIRTIO_COUNT; i++) {
> diff --git a/include/hw/riscv/sifive_clint.h b/include/hw/riscv/sifive_clint.h
> index 4a720bf..eb8577a 100644
> --- a/include/hw/riscv/sifive_clint.h
> +++ b/include/hw/riscv/sifive_clint.h
> @@ -38,11 +38,12 @@ typedef struct SiFiveCLINTState {
> uint32_t timecmp_base;
> uint32_t time_base;
> uint32_t aperture_size;
> + uint32_t timebase_freq;
> } SiFiveCLINTState;
>
> DeviceState *sifive_clint_create(hwaddr addr, hwaddr size, uint32_t num_harts,
> uint32_t sip_base, uint32_t timecmp_base, uint32_t time_base,
> - bool provide_rdtime);
> + uint32_t timebase_freq, bool provide_rdtime);
>
> enum {
> SIFIVE_SIP_BASE = 0x0,
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index d34bcfa..02486c3 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -219,7 +219,8 @@ struct CPURISCVState {
> pmp_table_t pmp_state;
>
> /* machine specific rdtime callback */
> - uint64_t (*rdtime_fn)(void);
> + uint64_t (*rdtime_fn)(uint32_t);
> + uint32_t rdtime_fn_arg;
>
> /* True if in debugger mode. */
> bool debugger;
> @@ -347,7 +348,8 @@ void riscv_cpu_swap_hypervisor_regs(CPURISCVState *env);
> int riscv_cpu_claim_interrupts(RISCVCPU *cpu, uint32_t interrupts);
> uint32_t riscv_cpu_update_mip(RISCVCPU *cpu, uint32_t mask, uint32_t value);
> #define BOOL_TO_MASK(x) (-!!(x)) /* helper for riscv_cpu_update_mip value */
> -void riscv_cpu_set_rdtime_fn(CPURISCVState *env, uint64_t (*fn)(void));
> +void riscv_cpu_set_rdtime_fn(CPURISCVState *env, uint64_t (*fn)(uint32_t),
> + uint32_t arg);
> #endif
> void riscv_cpu_set_mode(CPURISCVState *env, target_ulong newpriv);
>
> diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
> index fd1d373..c82a521 100644
> --- a/target/riscv/cpu_helper.c
> +++ b/target/riscv/cpu_helper.c
> @@ -258,9 +258,11 @@ uint32_t riscv_cpu_update_mip(RISCVCPU *cpu, uint32_t mask, uint32_t value)
> return old;
> }
>
> -void riscv_cpu_set_rdtime_fn(CPURISCVState *env, uint64_t (*fn)(void))
> +void riscv_cpu_set_rdtime_fn(CPURISCVState *env, uint64_t (*fn)(uint32_t),
> + uint32_t arg)
> {
> env->rdtime_fn = fn;
> + env->rdtime_fn_arg = arg;
> }
>
> void riscv_cpu_set_mode(CPURISCVState *env, target_ulong newpriv)
> diff --git a/target/riscv/csr.c b/target/riscv/csr.c
> index 6a96a01..6cef1ac 100644
> --- a/target/riscv/csr.c
> +++ b/target/riscv/csr.c
> @@ -294,7 +294,7 @@ static int read_time(CPURISCVState *env, int csrno, target_ulong *val)
> return -1;
> }
>
> - *val = env->rdtime_fn() + delta;
> + *val = env->rdtime_fn(env->rdtime_fn_arg) + delta;
> return 0;
> }
>
> @@ -307,7 +307,7 @@ static int read_timeh(CPURISCVState *env, int csrno, target_ulong *val)
> return -1;
> }
>
> - *val = (env->rdtime_fn() + delta) >> 32;
> + *val = (env->rdtime_fn(env->rdtime_fn_arg) + delta) >> 32;
> return 0;
> }
> #endif
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH 17/18] hw/riscv: clint: Avoid using hard-coded timebase frequency
@ 2020-08-25 18:33 ` Alistair Francis
0 siblings, 0 replies; 100+ messages in thread
From: Alistair Francis @ 2020-08-25 18:33 UTC (permalink / raw)
To: Bin Meng
Cc: Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, qemu-devel@nongnu.org Developers,
open list:RISC-V, Bin Meng, Palmer Dabbelt
On Fri, Aug 14, 2020 at 9:54 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> 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>
Alistair
> ---
>
> hw/riscv/microchip_pfsoc.c | 6 +++++-
> hw/riscv/sifive_clint.c | 25 ++++++++++++++-----------
> hw/riscv/sifive_e.c | 3 ++-
> hw/riscv/sifive_u.c | 3 ++-
> hw/riscv/spike.c | 2 +-
> hw/riscv/virt.c | 3 ++-
> include/hw/riscv/sifive_clint.h | 3 ++-
> target/riscv/cpu.h | 6 ++++--
> target/riscv/cpu_helper.c | 4 +++-
> target/riscv/csr.c | 4 ++--
> 10 files changed, 37 insertions(+), 22 deletions(-)
>
> diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
> index 139284a..e8b7f86 100644
> --- a/hw/riscv/microchip_pfsoc.c
> +++ b/hw/riscv/microchip_pfsoc.c
> @@ -60,6 +60,9 @@
> #define BIOS_FILENAME "hss.bin"
> #define RESET_VECTOR 0x20220000
>
> +/* CLINT timebase frequency */
> +#define CLINT_TIMEBASE_FREQ 1000000
> +
> /* GEM version */
> #define GEM_REVISION 0x0107010c
>
> @@ -189,7 +192,8 @@ static void microchip_pfsoc_soc_realize(DeviceState *dev, Error **errp)
> /* CLINT */
> sifive_clint_create(memmap[MICROCHIP_PFSOC_CLINT].base,
> memmap[MICROCHIP_PFSOC_CLINT].size, ms->smp.cpus,
> - SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE, false);
> + SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE,
> + CLINT_TIMEBASE_FREQ, false);
>
> /* L2 cache controller */
> create_unimplemented_device("microchip.pfsoc.l2cc",
> diff --git a/hw/riscv/sifive_clint.c b/hw/riscv/sifive_clint.c
> index 669c21a..a568568 100644
> --- a/hw/riscv/sifive_clint.c
> +++ b/hw/riscv/sifive_clint.c
> @@ -29,22 +29,23 @@
> #include "hw/riscv/sifive_clint.h"
> #include "qemu/timer.h"
>
> -static uint64_t cpu_riscv_read_rtc(void)
> +static uint64_t cpu_riscv_read_rtc(uint32_t timebase_freq)
> {
> return muldiv64(qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL),
> - SIFIVE_CLINT_TIMEBASE_FREQ, NANOSECONDS_PER_SECOND);
> + timebase_freq, NANOSECONDS_PER_SECOND);
> }
>
> /*
> * Called when timecmp is written to update the QEMU timer or immediately
> * trigger timer interrupt if mtimecmp <= current timer value.
> */
> -static void sifive_clint_write_timecmp(RISCVCPU *cpu, uint64_t value)
> +static void sifive_clint_write_timecmp(RISCVCPU *cpu, uint64_t value,
> + uint32_t timebase_freq)
> {
> uint64_t next;
> uint64_t diff;
>
> - uint64_t rtc_r = cpu_riscv_read_rtc();
> + uint64_t rtc_r = cpu_riscv_read_rtc(timebase_freq);
>
> cpu->env.timecmp = value;
> if (cpu->env.timecmp <= rtc_r) {
> @@ -59,7 +60,7 @@ static void sifive_clint_write_timecmp(RISCVCPU *cpu, uint64_t value)
> diff = cpu->env.timecmp - rtc_r;
> /* back to ns (note args switched in muldiv64) */
> next = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
> - muldiv64(diff, NANOSECONDS_PER_SECOND, SIFIVE_CLINT_TIMEBASE_FREQ);
> + muldiv64(diff, NANOSECONDS_PER_SECOND, timebase_freq);
> timer_mod(cpu->env.timer, next);
> }
>
> @@ -111,10 +112,10 @@ static uint64_t sifive_clint_read(void *opaque, hwaddr addr, unsigned size)
> }
> } else if (addr == clint->time_base) {
> /* time_lo */
> - return cpu_riscv_read_rtc() & 0xFFFFFFFF;
> + return cpu_riscv_read_rtc(clint->timebase_freq) & 0xFFFFFFFF;
> } else if (addr == clint->time_base + 4) {
> /* time_hi */
> - return (cpu_riscv_read_rtc() >> 32) & 0xFFFFFFFF;
> + return (cpu_riscv_read_rtc(clint->timebase_freq) >> 32) & 0xFFFFFFFF;
> }
>
> error_report("clint: invalid read: %08x", (uint32_t)addr);
> @@ -151,13 +152,13 @@ static void sifive_clint_write(void *opaque, hwaddr addr, uint64_t value,
> /* timecmp_lo */
> uint64_t timecmp_hi = env->timecmp >> 32;
> sifive_clint_write_timecmp(RISCV_CPU(cpu),
> - timecmp_hi << 32 | (value & 0xFFFFFFFF));
> + timecmp_hi << 32 | (value & 0xFFFFFFFF), clint->timebase_freq);
> return;
> } else if ((addr & 0x7) == 4) {
> /* timecmp_hi */
> uint64_t timecmp_lo = env->timecmp;
> sifive_clint_write_timecmp(RISCV_CPU(cpu),
> - value << 32 | (timecmp_lo & 0xFFFFFFFF));
> + value << 32 | (timecmp_lo & 0xFFFFFFFF), clint->timebase_freq);
> } else {
> error_report("clint: invalid timecmp write: %08x", (uint32_t)addr);
> }
> @@ -191,6 +192,7 @@ static Property sifive_clint_properties[] = {
> DEFINE_PROP_UINT32("timecmp-base", SiFiveCLINTState, timecmp_base, 0),
> DEFINE_PROP_UINT32("time-base", SiFiveCLINTState, time_base, 0),
> DEFINE_PROP_UINT32("aperture-size", SiFiveCLINTState, aperture_size, 0),
> + DEFINE_PROP_UINT32("timebase-freq", SiFiveCLINTState, timebase_freq, 0),
> DEFINE_PROP_END_OF_LIST(),
> };
>
> @@ -229,7 +231,7 @@ type_init(sifive_clint_register_types)
> */
> DeviceState *sifive_clint_create(hwaddr addr, hwaddr size, uint32_t num_harts,
> uint32_t sip_base, uint32_t timecmp_base, uint32_t time_base,
> - bool provide_rdtime)
> + uint32_t timebase_freq, bool provide_rdtime)
> {
> int i;
> for (i = 0; i < num_harts; i++) {
> @@ -239,7 +241,7 @@ DeviceState *sifive_clint_create(hwaddr addr, hwaddr size, uint32_t num_harts,
> continue;
> }
> if (provide_rdtime) {
> - riscv_cpu_set_rdtime_fn(env, cpu_riscv_read_rtc);
> + riscv_cpu_set_rdtime_fn(env, cpu_riscv_read_rtc, timebase_freq);
> }
> env->timer = timer_new_ns(QEMU_CLOCK_VIRTUAL,
> &sifive_clint_timer_cb, cpu);
> @@ -252,6 +254,7 @@ DeviceState *sifive_clint_create(hwaddr addr, hwaddr size, uint32_t num_harts,
> qdev_prop_set_uint32(dev, "timecmp-base", timecmp_base);
> qdev_prop_set_uint32(dev, "time-base", time_base);
> qdev_prop_set_uint32(dev, "aperture-size", size);
> + qdev_prop_set_uint32(dev, "timebase-freq", timebase_freq);
> sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), &error_fatal);
> sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, addr);
> return dev;
> diff --git a/hw/riscv/sifive_e.c b/hw/riscv/sifive_e.c
> index c84d407..e7f6460 100644
> --- a/hw/riscv/sifive_e.c
> +++ b/hw/riscv/sifive_e.c
> @@ -213,7 +213,8 @@ static void sifive_e_soc_realize(DeviceState *dev, Error **errp)
> memmap[SIFIVE_E_PLIC].size);
> sifive_clint_create(memmap[SIFIVE_E_CLINT].base,
> memmap[SIFIVE_E_CLINT].size, ms->smp.cpus,
> - SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE, false);
> + SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE,
> + SIFIVE_CLINT_TIMEBASE_FREQ, false);
> create_unimplemented_device("riscv.sifive.e.aon",
> memmap[SIFIVE_E_AON].base, memmap[SIFIVE_E_AON].size);
> sifive_e_prci_create(memmap[SIFIVE_E_PRCI].base);
> diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> index e256da2..5ec9fca 100644
> --- a/hw/riscv/sifive_u.c
> +++ b/hw/riscv/sifive_u.c
> @@ -706,7 +706,8 @@ static void sifive_u_soc_realize(DeviceState *dev, Error **errp)
> serial_hd(1), qdev_get_gpio_in(DEVICE(s->plic), SIFIVE_U_UART1_IRQ));
> sifive_clint_create(memmap[SIFIVE_U_CLINT].base,
> memmap[SIFIVE_U_CLINT].size, ms->smp.cpus,
> - SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE, false);
> + SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE,
> + SIFIVE_CLINT_TIMEBASE_FREQ, false);
>
> if (!sysbus_realize(SYS_BUS_DEVICE(&s->prci), errp)) {
> return;
> diff --git a/hw/riscv/spike.c b/hw/riscv/spike.c
> index 13958bd..ae8593a 100644
> --- a/hw/riscv/spike.c
> +++ b/hw/riscv/spike.c
> @@ -235,7 +235,7 @@ static void spike_board_init(MachineState *machine)
> /* Core Local Interruptor (timer and IPI) */
> sifive_clint_create(memmap[SPIKE_CLINT].base, memmap[SPIKE_CLINT].size,
> smp_cpus, SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE,
> - false);
> + SIFIVE_CLINT_TIMEBASE_FREQ, false);
> }
>
> static void spike_machine_init(MachineClass *mc)
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index 6e91cf1..af0d06a 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -572,7 +572,8 @@ static void virt_machine_init(MachineState *machine)
> memmap[VIRT_PLIC].size);
> sifive_clint_create(memmap[VIRT_CLINT].base,
> memmap[VIRT_CLINT].size, smp_cpus,
> - SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE, true);
> + SIFIVE_SIP_BASE, SIFIVE_TIMECMP_BASE, SIFIVE_TIME_BASE,
> + SIFIVE_CLINT_TIMEBASE_FREQ, true);
> sifive_test_create(memmap[VIRT_TEST].base);
>
> for (i = 0; i < VIRTIO_COUNT; i++) {
> diff --git a/include/hw/riscv/sifive_clint.h b/include/hw/riscv/sifive_clint.h
> index 4a720bf..eb8577a 100644
> --- a/include/hw/riscv/sifive_clint.h
> +++ b/include/hw/riscv/sifive_clint.h
> @@ -38,11 +38,12 @@ typedef struct SiFiveCLINTState {
> uint32_t timecmp_base;
> uint32_t time_base;
> uint32_t aperture_size;
> + uint32_t timebase_freq;
> } SiFiveCLINTState;
>
> DeviceState *sifive_clint_create(hwaddr addr, hwaddr size, uint32_t num_harts,
> uint32_t sip_base, uint32_t timecmp_base, uint32_t time_base,
> - bool provide_rdtime);
> + uint32_t timebase_freq, bool provide_rdtime);
>
> enum {
> SIFIVE_SIP_BASE = 0x0,
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index d34bcfa..02486c3 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -219,7 +219,8 @@ struct CPURISCVState {
> pmp_table_t pmp_state;
>
> /* machine specific rdtime callback */
> - uint64_t (*rdtime_fn)(void);
> + uint64_t (*rdtime_fn)(uint32_t);
> + uint32_t rdtime_fn_arg;
>
> /* True if in debugger mode. */
> bool debugger;
> @@ -347,7 +348,8 @@ void riscv_cpu_swap_hypervisor_regs(CPURISCVState *env);
> int riscv_cpu_claim_interrupts(RISCVCPU *cpu, uint32_t interrupts);
> uint32_t riscv_cpu_update_mip(RISCVCPU *cpu, uint32_t mask, uint32_t value);
> #define BOOL_TO_MASK(x) (-!!(x)) /* helper for riscv_cpu_update_mip value */
> -void riscv_cpu_set_rdtime_fn(CPURISCVState *env, uint64_t (*fn)(void));
> +void riscv_cpu_set_rdtime_fn(CPURISCVState *env, uint64_t (*fn)(uint32_t),
> + uint32_t arg);
> #endif
> void riscv_cpu_set_mode(CPURISCVState *env, target_ulong newpriv);
>
> diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
> index fd1d373..c82a521 100644
> --- a/target/riscv/cpu_helper.c
> +++ b/target/riscv/cpu_helper.c
> @@ -258,9 +258,11 @@ uint32_t riscv_cpu_update_mip(RISCVCPU *cpu, uint32_t mask, uint32_t value)
> return old;
> }
>
> -void riscv_cpu_set_rdtime_fn(CPURISCVState *env, uint64_t (*fn)(void))
> +void riscv_cpu_set_rdtime_fn(CPURISCVState *env, uint64_t (*fn)(uint32_t),
> + uint32_t arg)
> {
> env->rdtime_fn = fn;
> + env->rdtime_fn_arg = arg;
> }
>
> void riscv_cpu_set_mode(CPURISCVState *env, target_ulong newpriv)
> diff --git a/target/riscv/csr.c b/target/riscv/csr.c
> index 6a96a01..6cef1ac 100644
> --- a/target/riscv/csr.c
> +++ b/target/riscv/csr.c
> @@ -294,7 +294,7 @@ static int read_time(CPURISCVState *env, int csrno, target_ulong *val)
> return -1;
> }
>
> - *val = env->rdtime_fn() + delta;
> + *val = env->rdtime_fn(env->rdtime_fn_arg) + delta;
> return 0;
> }
>
> @@ -307,7 +307,7 @@ static int read_timeh(CPURISCVState *env, int csrno, target_ulong *val)
> return -1;
> }
>
> - *val = (env->rdtime_fn() + delta) >> 32;
> + *val = (env->rdtime_fn(env->rdtime_fn_arg) + delta) >> 32;
> return 0;
> }
> #endif
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 100+ messages in thread
end of thread, other threads:[~2020-08-25 18:46 UTC | newest]
Thread overview: 100+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-14 16:40 [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support Bin Meng
2020-08-14 16:40 ` Bin Meng
2020-08-14 16:40 ` [PATCH 01/18] target/riscv: cpu: Add a new 'resetvec' property Bin Meng
2020-08-17 17:49 ` Alistair Francis
2020-08-17 17:49 ` Alistair Francis
2020-08-14 16:40 ` [PATCH 02/18] hw/riscv: hart: " Bin Meng
2020-08-17 17:49 ` Alistair Francis
2020-08-17 17:49 ` Alistair Francis
2020-08-14 16:40 ` [PATCH 03/18] target/riscv: cpu: Set reset vector based on the configured property value Bin Meng
2020-08-17 17:52 ` Alistair Francis
2020-08-17 17:52 ` Alistair Francis
2020-08-14 16:40 ` [PATCH 04/18] hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board Bin Meng
2020-08-17 19:39 ` Alistair Francis
2020-08-17 19:39 ` Alistair Francis
2020-08-14 16:40 ` [PATCH 05/18] hw/char: Add Microchip PolarFire SoC MMUART emulation Bin Meng
2020-08-14 16:40 ` Bin Meng
2020-08-17 20:51 ` Alistair Francis
2020-08-17 20:51 ` Alistair Francis
2020-08-14 16:40 ` [PATCH 06/18] hw/riscv: microchip_pfsoc: Connect 5 MMUARTs Bin Meng
2020-08-17 21:06 ` Alistair Francis
2020-08-17 21:06 ` Alistair Francis
2020-08-14 16:40 ` [PATCH 07/18] hw/sd: sd: Fix incorrect populated function switch status data structure Bin Meng
2020-08-15 7:58 ` Philippe Mathieu-Daudé
2020-08-18 16:30 ` Sai Pavan Boddu
2020-08-21 10:09 ` Sai Pavan Boddu
2020-08-21 10:09 ` Sai Pavan Boddu
2020-08-21 10:08 ` Bin Meng
2020-08-21 10:08 ` Bin Meng
2020-08-24 4:13 ` Sai Pavan Boddu
2020-08-24 4:13 ` Sai Pavan Boddu
2020-08-14 16:40 ` [PATCH 08/18] hw/sd: sd: Correctly set the high capacity bit Bin Meng
2020-08-15 8:38 ` Philippe Mathieu-Daudé
2020-08-16 8:54 ` Bin Meng
2020-08-16 8:54 ` Bin Meng
2020-08-14 16:40 ` [PATCH 09/18] hw/sd: sdhci: Make sdhci_poweron_reset() internal visible Bin Meng
2020-08-15 7:51 ` Philippe Mathieu-Daudé
2020-08-16 8:50 ` Bin Meng
2020-08-16 8:50 ` Bin Meng
2020-08-16 11:06 ` Philippe Mathieu-Daudé
2020-08-14 16:40 ` [PATCH 10/18] hw/sd: Add Cadence SDHCI emulation Bin Meng
2020-08-14 16:40 ` Bin Meng
2020-08-15 8:51 ` Philippe Mathieu-Daudé
2020-08-15 8:51 ` Philippe Mathieu-Daudé
2020-08-14 16:40 ` [PATCH 11/18] hw/riscv: microchip_pfsoc: Connect a Cadence SDHCI controller and an SD card Bin Meng
2020-08-15 8:55 ` Philippe Mathieu-Daudé
2020-08-14 16:40 ` [PATCH 12/18] hw/dma: Add Microchip PolarFire Soc DMA controller emulation Bin Meng
2020-08-14 16:40 ` [PATCH 13/18] hw/riscv: microchip_pfsoc: Connect a DMA controller Bin Meng
2020-08-15 9:00 ` Philippe Mathieu-Daudé
2020-08-16 8:57 ` Bin Meng
2020-08-16 8:57 ` Bin Meng
2020-08-16 11:08 ` Philippe Mathieu-Daudé
2020-08-14 16:40 ` [PATCH 14/18] hw/net: cadence_gem: Add a new 'phy-addr' property Bin Meng
2020-08-14 16:40 ` Bin Meng
2020-08-15 9:06 ` Philippe Mathieu-Daudé
2020-08-16 8:29 ` Bin Meng
2020-08-16 8:29 ` Bin Meng
2020-08-16 11:14 ` Philippe Mathieu-Daudé
2020-08-16 11:14 ` Philippe Mathieu-Daudé
2020-08-16 12:08 ` Nathan Rossi
2020-08-16 12:08 ` Nathan Rossi
2020-08-16 13:42 ` Bin Meng
2020-08-16 13:42 ` Bin Meng
2020-08-16 16:31 ` Philippe Mathieu-Daudé
2020-08-16 16:31 ` Philippe Mathieu-Daudé
2020-08-14 16:40 ` [PATCH 15/18] hw/riscv: microchip_pfsoc: Connect 2 Cadence GEMs Bin Meng
2020-08-21 18:46 ` Alistair Francis
2020-08-21 18:46 ` Alistair Francis
2020-08-14 16:40 ` [PATCH 16/18] hw/riscv: microchip_pfsoc: Hook GPIO controllers Bin Meng
2020-08-21 18:47 ` Alistair Francis
2020-08-21 18:47 ` Alistair Francis
2020-08-14 16:40 ` [PATCH 17/18] hw/riscv: clint: Avoid using hard-coded timebase frequency Bin Meng
2020-08-25 18:33 ` Alistair Francis
2020-08-25 18:33 ` Alistair Francis
2020-08-14 16:40 ` [PATCH 18/18] hw/riscv: microchip_pfsoc: Document the software used for testing Bin Meng
2020-08-21 18:51 ` Alistair Francis
2020-08-21 18:51 ` Alistair Francis
2020-08-14 17:44 ` [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support Anup Patel
2020-08-14 17:44 ` Anup Patel
2020-08-17 10:30 ` Bin Meng
2020-08-17 10:30 ` Bin Meng
2020-08-17 15:44 ` via
2020-08-17 15:44 ` Cyril.Jean
2020-08-17 19:28 ` Alistair Francis
2020-08-17 19:28 ` Alistair Francis
2020-08-17 19:53 ` via
2020-08-17 19:53 ` Cyril.Jean
2020-08-18 6:17 ` Anup Patel
2020-08-18 6:17 ` Anup Patel
2020-08-18 13:09 ` via
2020-08-18 13:09 ` Cyril.Jean
2020-08-18 13:55 ` Anup Patel
2020-08-18 13:55 ` Anup Patel
2020-08-19 1:34 ` Bin Meng
2020-08-19 1:34 ` Bin Meng
2020-08-19 10:13 ` via
2020-08-19 10:13 ` Cyril.Jean
2020-08-21 18:23 ` Alistair Francis
2020-08-21 18:23 ` Alistair Francis
2020-08-14 18:10 ` no-reply
2020-08-14 18:10 ` no-reply
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.