Revision tags: v8.2.2, v7.2.10, v8.2.1, v8.1.5, v7.2.9, v8.1.4, v7.2.8, v8.2.0, v8.2.0-rc4, v8.2.0-rc3, v8.2.0-rc2, v8.2.0-rc1, v7.2.7, v8.1.3, v8.2.0-rc0 |
|
#
0a7549db |
| 23-Oct-2023 |
David Woodhouse <dwmw@amazon.co.uk> |
hw/riscv: use qemu_configure_nic_device()
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Thomas Huth <thuth@redhat.com>
|
Revision tags: v8.1.2, v8.1.1, v7.2.6, v8.0.5, v8.1.0, v8.1.0-rc4, v8.1.0-rc3, v7.2.5, v8.0.4, v8.1.0-rc2, v8.1.0-rc1, v8.1.0-rc0 |
|
#
42fe7499 |
| 14-Jul-2023 |
Michael Tokarev <mjt@tls.msk.ru> |
riscv: spelling fixes
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Acked-by: Alistair Francis <alistair.francis@wdc.com>
|
Revision tags: v8.1.2, v8.1.1, v7.2.6, v8.0.5, v8.1.0, v8.1.0-rc4, v8.1.0-rc3, v7.2.5, v8.0.4, v8.1.0-rc2, v8.1.0-rc1, v8.1.0-rc0 |
|
#
42fe7499 |
| 14-Jul-2023 |
Michael Tokarev <mjt@tls.msk.ru> |
riscv: spelling fixes
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Acked-by: Alistair Francis <alistair.francis@wdc.com>
|
Revision tags: v8.1.2, v8.1.1, v7.2.6, v8.0.5, v8.1.0, v8.1.0-rc4, v8.1.0-rc3, v7.2.5, v8.0.4, v8.1.0-rc2, v8.1.0-rc1, v8.1.0-rc0 |
|
#
42fe7499 |
| 14-Jul-2023 |
Michael Tokarev <mjt@tls.msk.ru> |
riscv: spelling fixes
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Acked-by: Alistair Francis <alistair.francis@wdc.com>
|
Revision tags: v8.0.3, v7.2.4, v8.0.2, v8.0.1, v7.2.3, v7.2.2, v8.0.0, v8.0.0-rc4, v8.0.0-rc3, v7.2.1, v8.0.0-rc2, v8.0.0-rc1, v8.0.0-rc0 |
|
#
487d73fc |
| 06-Feb-2023 |
Daniel Henrique Barboza <dbarboza@ventanamicro.com> |
hw/riscv/boot.c: consolidate all kernel init in riscv_load_kernel()
The microchip_icicle_kit, sifive_u, spike and virt boards are now doing the same steps when '-kernel' is used:
- execute load_ker
hw/riscv/boot.c: consolidate all kernel init in riscv_load_kernel()
The microchip_icicle_kit, sifive_u, spike and virt boards are now doing the same steps when '-kernel' is used:
- execute load_kernel() - load init_rd() - write kernel_cmdline
Let's fold everything inside riscv_load_kernel() to avoid code repetition. To not change the behavior of boards that aren't calling riscv_load_init(), add an 'load_initrd' flag to riscv_load_kernel() and allow these boards to opt out from initrd loading.
Cc: Palmer Dabbelt <palmer@dabbelt.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230206140022.2748401-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
show more ...
|
#
62c5bc34 |
| 06-Feb-2023 |
Daniel Henrique Barboza <dbarboza@ventanamicro.com> |
hw/riscv: handle 32 bit CPUs kernel_entry in riscv_load_kernel()
Next patch will move all calls to riscv_load_initrd() to riscv_load_kernel(). Machines that want to load initrd will be able to do vi
hw/riscv: handle 32 bit CPUs kernel_entry in riscv_load_kernel()
Next patch will move all calls to riscv_load_initrd() to riscv_load_kernel(). Machines that want to load initrd will be able to do via an extra flag to riscv_load_kernel().
This change will expose a sign-extend behavior that is happening in load_elf_ram_sym() when running 32 bit guests [1]. This is currently obscured by the fact that riscv_load_initrd() is using the return of riscv_load_kernel(), defined as target_ulong, and this return type will crop the higher 32 bits that would be padded with 1s by the sign extension when running in 32 bit targets. The changes to be done will force riscv_load_initrd() to use an uint64_t instead, exposing it to the padding when dealing with 32 bit CPUs.
There is a discussion about whether load_elf_ram_sym() should or should not sign extend the value returned by 'lowaddr'. What we can do is to prevent the behavior change that the next patch will end up doing. riscv_load_initrd() wasn't dealing with 64 bit kernel entries when running 32 bit CPUs, and we want to keep it that way.
One way of doing it is to use target_ulong in 'kernel_entry' in riscv_load_kernel() and rely on the fact that this var will not be sign extended for 32 bit targets. Another way is to explictly clear the higher 32 bits when running 32 bit CPUs for all possibilities of kernel_entry.
We opted for the later. This will allow us to be clear about the design choices made in the function, while also allowing us to add a small comment about what load_elf_ram_sym() is doing. With this change, the consolation patch can do its job without worrying about unintended behavioral changes.
[1] https://lists.gnu.org/archive/html/qemu-devel/2023-01/msg02281.html
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230206140022.2748401-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
show more ...
|
#
4b402886 |
| 01-Feb-2023 |
Daniel Henrique Barboza <dbarboza@ventanamicro.com> |
hw/riscv: change riscv_compute_fdt_addr() semantics
As it is now, riscv_compute_fdt_addr() is receiving a dram_base, a mem_size (which is defaulted to MachineState::ram_size in all boards) and the F
hw/riscv: change riscv_compute_fdt_addr() semantics
As it is now, riscv_compute_fdt_addr() is receiving a dram_base, a mem_size (which is defaulted to MachineState::ram_size in all boards) and the FDT pointer. And it makes a very important assumption: the DRAM interval dram_base + mem_size is contiguous. This is indeed the case for most boards that use a FDT.
The Icicle Kit board works with 2 distinct RAM banks that are separated by a gap. We have a lower bank with 1GiB size, a gap follows, then at 64GiB the high memory starts. MachineClass::default_ram_size for this board is set to 1.5Gb, and machine_init() is enforcing it as minimal RAM size, meaning that there we'll always have at least 512 MiB in the Hi RAM area.
Using riscv_compute_fdt_addr() in this board is weird because not only the board has sparse RAM, and it's calling it using the base address of the Lo RAM area, but it's also using a mem_size that we have guarantees that it will go up to the Hi RAM. All the function assumptions doesn't work for this board.
In fact, what makes the function works at all in this case is a coincidence. Commit 1a475d39ef54 introduced a 3GB boundary for the FDT, down from 4Gb, that is enforced if dram_base is lower than 3072 MiB. For the Icicle Kit board, memmap[MICROCHIP_PFSOC_DRAM_LO].base is 0x80000000 (2 Gb) and it has a 1Gb size, so it will fall in the conditions to put the FDT under a 3Gb address, which happens to be exactly at the end of DRAM_LO. If the base address of the Lo area started later than 3Gb this function would be unusable by the board. Changing any assumptions inside riscv_compute_fdt_addr() can also break it by accident as well.
Let's change riscv_compute_fdt_addr() semantics to be appropriate to the Icicle Kit board and for future boards that might have sparse RAM topologies to worry about:
- relieve the condition that the dram_base + mem_size area is contiguous, since this is already not the case today;
- receive an extra 'dram_size' size attribute that refers to a contiguous RAM block that the board wants the FDT to reside on.
Together with 'mem_size' and 'fdt', which are now now being consumed by a MachineState pointer, we're able to make clear assumptions based on the DRAM block and total mem_size available to ensure that the FDT will be put in a valid RAM address.
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230201171212.1219375-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|
#
bc2c0153 |
| 01-Feb-2023 |
Daniel Henrique Barboza <dbarboza@ventanamicro.com> |
hw/riscv: split fdt address calculation from fdt load
A common trend in other archs is to calculate the fdt address, which is usually straightforward, and then calling a function that loads the fdt/
hw/riscv: split fdt address calculation from fdt load
A common trend in other archs is to calculate the fdt address, which is usually straightforward, and then calling a function that loads the fdt/dtb by using that address.
riscv_load_fdt() is doing a bit too much in comparison. It's calculating the fdt address via an elaborated heuristic to put the FDT at the bottom of DRAM, and "bottom of DRAM" will vary across boards and configurations, then it's actually loading the fdt, and finally it's returning the fdt address used to the caller.
Reduce the existing complexity of riscv_load_fdt() by splitting its code into a new function, riscv_compute_fdt_addr(), that will take care of all fdt address logic. riscv_load_fdt() can then be a simple function that just loads a fdt at the given fdt address.
We're also taken the opportunity to clarify the intentions and assumptions made by these functions. riscv_load_fdt() is now receiving a hwaddr as fdt_addr because there is no restriction of having to load the fdt in higher addresses that doesn't fit in an uint32_t.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230201171212.1219375-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|
#
4b402886 |
| 01-Feb-2023 |
Daniel Henrique Barboza <dbarboza@ventanamicro.com> |
hw/riscv: change riscv_compute_fdt_addr() semantics
As it is now, riscv_compute_fdt_addr() is receiving a dram_base, a mem_size (which is defaulted to MachineState::ram_size in all boards) and the F
hw/riscv: change riscv_compute_fdt_addr() semantics
As it is now, riscv_compute_fdt_addr() is receiving a dram_base, a mem_size (which is defaulted to MachineState::ram_size in all boards) and the FDT pointer. And it makes a very important assumption: the DRAM interval dram_base + mem_size is contiguous. This is indeed the case for most boards that use a FDT.
The Icicle Kit board works with 2 distinct RAM banks that are separated by a gap. We have a lower bank with 1GiB size, a gap follows, then at 64GiB the high memory starts. MachineClass::default_ram_size for this board is set to 1.5Gb, and machine_init() is enforcing it as minimal RAM size, meaning that there we'll always have at least 512 MiB in the Hi RAM area.
Using riscv_compute_fdt_addr() in this board is weird because not only the board has sparse RAM, and it's calling it using the base address of the Lo RAM area, but it's also using a mem_size that we have guarantees that it will go up to the Hi RAM. All the function assumptions doesn't work for this board.
In fact, what makes the function works at all in this case is a coincidence. Commit 1a475d39ef54 introduced a 3GB boundary for the FDT, down from 4Gb, that is enforced if dram_base is lower than 3072 MiB. For the Icicle Kit board, memmap[MICROCHIP_PFSOC_DRAM_LO].base is 0x80000000 (2 Gb) and it has a 1Gb size, so it will fall in the conditions to put the FDT under a 3Gb address, which happens to be exactly at the end of DRAM_LO. If the base address of the Lo area started later than 3Gb this function would be unusable by the board. Changing any assumptions inside riscv_compute_fdt_addr() can also break it by accident as well.
Let's change riscv_compute_fdt_addr() semantics to be appropriate to the Icicle Kit board and for future boards that might have sparse RAM topologies to worry about:
- relieve the condition that the dram_base + mem_size area is contiguous, since this is already not the case today;
- receive an extra 'dram_size' size attribute that refers to a contiguous RAM block that the board wants the FDT to reside on.
Together with 'mem_size' and 'fdt', which are now now being consumed by a MachineState pointer, we're able to make clear assumptions based on the DRAM block and total mem_size available to ensure that the FDT will be put in a valid RAM address.
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230201171212.1219375-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|
#
bc2c0153 |
| 01-Feb-2023 |
Daniel Henrique Barboza <dbarboza@ventanamicro.com> |
hw/riscv: split fdt address calculation from fdt load
A common trend in other archs is to calculate the fdt address, which is usually straightforward, and then calling a function that loads the fdt/
hw/riscv: split fdt address calculation from fdt load
A common trend in other archs is to calculate the fdt address, which is usually straightforward, and then calling a function that loads the fdt/dtb by using that address.
riscv_load_fdt() is doing a bit too much in comparison. It's calculating the fdt address via an elaborated heuristic to put the FDT at the bottom of DRAM, and "bottom of DRAM" will vary across boards and configurations, then it's actually loading the fdt, and finally it's returning the fdt address used to the caller.
Reduce the existing complexity of riscv_load_fdt() by splitting its code into a new function, riscv_compute_fdt_addr(), that will take care of all fdt address logic. riscv_load_fdt() can then be a simple function that just loads a fdt at the given fdt address.
We're also taken the opportunity to clarify the intentions and assumptions made by these functions. riscv_load_fdt() is now receiving a hwaddr as fdt_addr because there is no restriction of having to load the fdt in higher addresses that doesn't fit in an uint32_t.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230201171212.1219375-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|
#
60c1f05e |
| 02-Jan-2023 |
Daniel Henrique Barboza <dbarboza@ventanamicro.com> |
hw/riscv/boot.c: use MachineState in riscv_load_kernel()
All callers are using kernel_filename as machine->kernel_filename.
This will also simplify the changes in riscv_load_kernel() that we're goi
hw/riscv/boot.c: use MachineState in riscv_load_kernel()
All callers are using kernel_filename as machine->kernel_filename.
This will also simplify the changes in riscv_load_kernel() that we're going to do next.
Cc: Palmer Dabbelt <palmer@dabbelt.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230102115241.25733-10-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|
#
1f991461 |
| 02-Jan-2023 |
Daniel Henrique Barboza <dbarboza@ventanamicro.com> |
hw/riscv/boot.c: use MachineState in riscv_load_initrd()
'filename', 'mem_size' and 'fdt' from riscv_load_initrd() can all be retrieved by the MachineState object for all callers.
Cc: Palmer Dabbel
hw/riscv/boot.c: use MachineState in riscv_load_initrd()
'filename', 'mem_size' and 'fdt' from riscv_load_initrd() can all be retrieved by the MachineState object for all callers.
Cc: Palmer Dabbelt <palmer@dabbelt.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230102115241.25733-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|
#
b9a65476 |
| 02-Jan-2023 |
Daniel Henrique Barboza <dbarboza@ventanamicro.com> |
hw/riscv: write initrd 'chosen' FDT inside riscv_load_initrd()
riscv_load_initrd() returns the initrd end addr while also writing a 'start' var to mark the addr start. These informations are being u
hw/riscv: write initrd 'chosen' FDT inside riscv_load_initrd()
riscv_load_initrd() returns the initrd end addr while also writing a 'start' var to mark the addr start. These informations are being used just to write the initrd FDT node. Every existing caller of riscv_load_initrd() is writing the FDT in the same manner.
We can simplify things by writing the FDT inside riscv_load_initrd(), sparing callers from having to manage start/end addrs to write the FDT themselves.
An 'if (fdt)' check is already inserted at the end of the function because we'll end up using it later on with other boards that doesn´t have a FDT.
Cc: Palmer Dabbelt <palmer@dabbelt.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230102115241.25733-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|
#
60c1f05e |
| 02-Jan-2023 |
Daniel Henrique Barboza <dbarboza@ventanamicro.com> |
hw/riscv/boot.c: use MachineState in riscv_load_kernel()
All callers are using kernel_filename as machine->kernel_filename.
This will also simplify the changes in riscv_load_kernel() that we're goi
hw/riscv/boot.c: use MachineState in riscv_load_kernel()
All callers are using kernel_filename as machine->kernel_filename.
This will also simplify the changes in riscv_load_kernel() that we're going to do next.
Cc: Palmer Dabbelt <palmer@dabbelt.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230102115241.25733-10-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|
#
1f991461 |
| 02-Jan-2023 |
Daniel Henrique Barboza <dbarboza@ventanamicro.com> |
hw/riscv/boot.c: use MachineState in riscv_load_initrd()
'filename', 'mem_size' and 'fdt' from riscv_load_initrd() can all be retrieved by the MachineState object for all callers.
Cc: Palmer Dabbel
hw/riscv/boot.c: use MachineState in riscv_load_initrd()
'filename', 'mem_size' and 'fdt' from riscv_load_initrd() can all be retrieved by the MachineState object for all callers.
Cc: Palmer Dabbelt <palmer@dabbelt.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230102115241.25733-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|
#
b9a65476 |
| 02-Jan-2023 |
Daniel Henrique Barboza <dbarboza@ventanamicro.com> |
hw/riscv: write initrd 'chosen' FDT inside riscv_load_initrd()
riscv_load_initrd() returns the initrd end addr while also writing a 'start' var to mark the addr start. These informations are being u
hw/riscv: write initrd 'chosen' FDT inside riscv_load_initrd()
riscv_load_initrd() returns the initrd end addr while also writing a 'start' var to mark the addr start. These informations are being used just to write the initrd FDT node. Every existing caller of riscv_load_initrd() is writing the FDT in the same manner.
We can simplify things by writing the FDT inside riscv_load_initrd(), sparing callers from having to manage start/end addrs to write the FDT themselves.
An 'if (fdt)' check is already inserted at the end of the function because we'll end up using it later on with other boards that doesn´t have a FDT.
Cc: Palmer Dabbelt <palmer@dabbelt.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230102115241.25733-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|
Revision tags: v7.2.0, v7.2.0-rc4, v7.2.0-rc3, v7.2.0-rc2 |
|
#
592f0a94 |
| 17-Nov-2022 |
Conor Dooley <conor.dooley@microchip.com> |
hw/{misc, riscv}: pfsoc: add system controller as unimplemented
The system controller on PolarFire SoC is access via a mailbox. The control registers for this mailbox lie in the "IOSCB" region & the
hw/{misc, riscv}: pfsoc: add system controller as unimplemented
The system controller on PolarFire SoC is access via a mailbox. The control registers for this mailbox lie in the "IOSCB" region & the interrupt is cleared via write to the "SYSREG" region. It also has a QSPI controller, usually connected to a flash chip, that is used for storing FPGA bitstreams and used for In-Application Programming (IAP).
Linux has an implementation of the system controller, through which the hwrng is accessed, leading to load/store access faults.
Add the QSPI as unimplemented and a very basic (effectively unimplemented) version of the system controller's mailbox. Rather than purely marking the regions as unimplemented, service the mailbox requests by reporting failures and raising the interrupt so a guest can better handle the lack of support.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20221117225518.4102575-4-conor@kernel.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|
#
8d32e374 |
| 17-Nov-2022 |
Conor Dooley <conor.dooley@microchip.com> |
hw/riscv: pfsoc: add missing FICs as unimplemented
The Fabric Interconnect Controllers provide interfaces between the FPGA fabric and the core complex. There are 5 FICs on PolarFire SoC, numbered 0
hw/riscv: pfsoc: add missing FICs as unimplemented
The Fabric Interconnect Controllers provide interfaces between the FPGA fabric and the core complex. There are 5 FICs on PolarFire SoC, numbered 0 through 4. FIC2 is an AXI4 slave interface from the FPGA fabric and does not show up on the MSS memory map. FIC4 is dedicated to the User Crypto Processor and does not show up on the MSS memory map either.
FIC 0, 1 & 3 do show up in the MSS memory map and neither FICs 0 or 1 are represented in QEMU, leading to load access violations while booting Linux for Icicle if PCIe is enabled as the root port is connected via either FIC 0 or 1.
Acked-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Message-Id: <20221117225518.4102575-3-conor@kernel.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|
Revision tags: v7.2.0, v7.2.0-rc4, v7.2.0-rc3, v7.2.0-rc2 |
|
#
592f0a94 |
| 17-Nov-2022 |
Conor Dooley <conor.dooley@microchip.com> |
hw/{misc, riscv}: pfsoc: add system controller as unimplemented
The system controller on PolarFire SoC is access via a mailbox. The control registers for this mailbox lie in the "IOSCB" region & the
hw/{misc, riscv}: pfsoc: add system controller as unimplemented
The system controller on PolarFire SoC is access via a mailbox. The control registers for this mailbox lie in the "IOSCB" region & the interrupt is cleared via write to the "SYSREG" region. It also has a QSPI controller, usually connected to a flash chip, that is used for storing FPGA bitstreams and used for In-Application Programming (IAP).
Linux has an implementation of the system controller, through which the hwrng is accessed, leading to load/store access faults.
Add the QSPI as unimplemented and a very basic (effectively unimplemented) version of the system controller's mailbox. Rather than purely marking the regions as unimplemented, service the mailbox requests by reporting failures and raising the interrupt so a guest can better handle the lack of support.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20221117225518.4102575-4-conor@kernel.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|
#
8d32e374 |
| 17-Nov-2022 |
Conor Dooley <conor.dooley@microchip.com> |
hw/riscv: pfsoc: add missing FICs as unimplemented
The Fabric Interconnect Controllers provide interfaces between the FPGA fabric and the core complex. There are 5 FICs on PolarFire SoC, numbered 0
hw/riscv: pfsoc: add missing FICs as unimplemented
The Fabric Interconnect Controllers provide interfaces between the FPGA fabric and the core complex. There are 5 FICs on PolarFire SoC, numbered 0 through 4. FIC2 is an AXI4 slave interface from the FPGA fabric and does not show up on the MSS memory map. FIC4 is dedicated to the User Crypto Processor and does not show up on the MSS memory map either.
FIC 0, 1 & 3 do show up in the MSS memory map and neither FICs 0 or 1 are represented in QEMU, leading to load access violations while booting Linux for Icicle if PCIe is enabled as the root port is connected via either FIC 0 or 1.
Acked-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Message-Id: <20221117225518.4102575-3-conor@kernel.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|
Revision tags: v7.2.0, v7.2.0-rc4, v7.2.0-rc3, v7.2.0-rc2 |
|
#
592f0a94 |
| 17-Nov-2022 |
Conor Dooley <conor.dooley@microchip.com> |
hw/{misc, riscv}: pfsoc: add system controller as unimplemented
The system controller on PolarFire SoC is access via a mailbox. The control registers for this mailbox lie in the "IOSCB" region & the
hw/{misc, riscv}: pfsoc: add system controller as unimplemented
The system controller on PolarFire SoC is access via a mailbox. The control registers for this mailbox lie in the "IOSCB" region & the interrupt is cleared via write to the "SYSREG" region. It also has a QSPI controller, usually connected to a flash chip, that is used for storing FPGA bitstreams and used for In-Application Programming (IAP).
Linux has an implementation of the system controller, through which the hwrng is accessed, leading to load/store access faults.
Add the QSPI as unimplemented and a very basic (effectively unimplemented) version of the system controller's mailbox. Rather than purely marking the regions as unimplemented, service the mailbox requests by reporting failures and raising the interrupt so a guest can better handle the lack of support.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20221117225518.4102575-4-conor@kernel.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|
#
8d32e374 |
| 17-Nov-2022 |
Conor Dooley <conor.dooley@microchip.com> |
hw/riscv: pfsoc: add missing FICs as unimplemented
The Fabric Interconnect Controllers provide interfaces between the FPGA fabric and the core complex. There are 5 FICs on PolarFire SoC, numbered 0
hw/riscv: pfsoc: add missing FICs as unimplemented
The Fabric Interconnect Controllers provide interfaces between the FPGA fabric and the core complex. There are 5 FICs on PolarFire SoC, numbered 0 through 4. FIC2 is an AXI4 slave interface from the FPGA fabric and does not show up on the MSS memory map. FIC4 is dedicated to the User Crypto Processor and does not show up on the MSS memory map either.
FIC 0, 1 & 3 do show up in the MSS memory map and neither FICs 0 or 1 are represented in QEMU, leading to load access violations while booting Linux for Icicle if PCIe is enabled as the root port is connected via either FIC 0 or 1.
Acked-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Message-Id: <20221117225518.4102575-3-conor@kernel.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|
Revision tags: v7.2.0-rc1, v7.2.0-rc0, v7.1.0, v7.1.0-rc4, v7.1.0-rc3 |
|
#
25da6e31 |
| 13-Aug-2022 |
Conor Dooley <conor.dooley@microchip.com> |
hw/riscv: microchip_pfsoc: fix kernel panics due to missing peripherals
Booting using "Direct Kernel Boot" for PolarFire SoC & skipping u-boot entirely is probably not advisable, but it does at leas
hw/riscv: microchip_pfsoc: fix kernel panics due to missing peripherals
Booting using "Direct Kernel Boot" for PolarFire SoC & skipping u-boot entirely is probably not advisable, but it does at least show signs of life. Recent Linux kernel versions make use of peripherals that are missing definitions in QEMU and lead to kernel panics. These issues almost certain rear their head for other methods of booting, but I was unable to figure out a suitable HSS version that is recent enough to support these peripherals & works with QEMU.
With these peripherals added, booting a kernel with the following hangs hangs waiting for the system controller's hwrng, but the kernel no longer panics. With the Linux driver for hwrng disabled, it boots to console.
qemu-system-riscv64 -M microchip-icicle-kit \ -m 2G -smp 5 \ -kernel $(vmlinux_bin) \ -dtb $(dtb)\ -initrd $(initramfs) \ -display none -serial null \ -serial stdio
More peripherals are added than strictly required to fix the panics in the hopes of avoiding a replication of this problem in the future. Some of the peripherals which are in the device tree for recent kernels are implemented in the FPGA fabric. The eMMC/SD mux, which exists as an unimplemented device is replaced by a wider entry. This updated entry covers both the mux & the remainder of the FPGA fabric connected to the MSS using Fabric Interrconnect (FIC) 3.
Link: https://github.com/polarfire-soc/icicle-kit-reference-design#fabric-memory-map Link: https://ww1.microchip.com/downloads/aemDocuments/documents/FPGA/ProductDocuments/SupportingCollateral/V1_4_Register_Map.zip Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20220813135127.2971754-1-mail@conchuod.ie> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|
Revision tags: v7.1.0-rc2, v7.1.0-rc1 |
|
#
6934f15b |
| 28-Jul-2022 |
Daniel Henrique Barboza <danielhb413@gmail.com> |
hw/riscv: remove 'fdt' param from riscv_setup_rom_reset_vec()
The 'fdt' param is not being used in riscv_setup_rom_reset_vec(). Simplify the API by removing it. While we're at it, remove the redunda
hw/riscv: remove 'fdt' param from riscv_setup_rom_reset_vec()
The 'fdt' param is not being used in riscv_setup_rom_reset_vec(). Simplify the API by removing it. While we're at it, remove the redundant 'return' statement at the end of function.
Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Alistair Francis <alistair.francis@wdc.com> Cc: Bin Meng <bin.meng@windriver.com> Cc: Vijai Kumar K <vijai@behindbytes.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20220728181926.2123771-1-danielhb413@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|
Revision tags: v7.2.0-rc1, v7.2.0-rc0, v7.1.0, v7.1.0-rc4, v7.1.0-rc3 |
|
#
25da6e31 |
| 13-Aug-2022 |
Conor Dooley <conor.dooley@microchip.com> |
hw/riscv: microchip_pfsoc: fix kernel panics due to missing peripherals
Booting using "Direct Kernel Boot" for PolarFire SoC & skipping u-boot entirely is probably not advisable, but it does at leas
hw/riscv: microchip_pfsoc: fix kernel panics due to missing peripherals
Booting using "Direct Kernel Boot" for PolarFire SoC & skipping u-boot entirely is probably not advisable, but it does at least show signs of life. Recent Linux kernel versions make use of peripherals that are missing definitions in QEMU and lead to kernel panics. These issues almost certain rear their head for other methods of booting, but I was unable to figure out a suitable HSS version that is recent enough to support these peripherals & works with QEMU.
With these peripherals added, booting a kernel with the following hangs hangs waiting for the system controller's hwrng, but the kernel no longer panics. With the Linux driver for hwrng disabled, it boots to console.
qemu-system-riscv64 -M microchip-icicle-kit \ -m 2G -smp 5 \ -kernel $(vmlinux_bin) \ -dtb $(dtb)\ -initrd $(initramfs) \ -display none -serial null \ -serial stdio
More peripherals are added than strictly required to fix the panics in the hopes of avoiding a replication of this problem in the future. Some of the peripherals which are in the device tree for recent kernels are implemented in the FPGA fabric. The eMMC/SD mux, which exists as an unimplemented device is replaced by a wider entry. This updated entry covers both the mux & the remainder of the FPGA fabric connected to the MSS using Fabric Interrconnect (FIC) 3.
Link: https://github.com/polarfire-soc/icicle-kit-reference-design#fabric-memory-map Link: https://ww1.microchip.com/downloads/aemDocuments/documents/FPGA/ProductDocuments/SupportingCollateral/V1_4_Register_Map.zip Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20220813135127.2971754-1-mail@conchuod.ie> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|