a828ba9d | 20-May-2023 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
hw/riscv/opentitan: Correct OpenTitanState parent type/size
OpenTitanState is the 'machine' (or 'board') state: it isn't a SysBus device, but inherits from the MachineState type. Correct the instanc
hw/riscv/opentitan: Correct OpenTitanState parent type/size
OpenTitanState is the 'machine' (or 'board') state: it isn't a SysBus device, but inherits from the MachineState type. Correct the instance size. Doing so we avoid leaking an OpenTitanState pointer in opentitan_machine_init().
Fixes: fe0fe4735e ("riscv: Initial commit of OpenTitan machine") Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230520054510.68822-6-philmd@linaro.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|
8696b74a | 20-May-2023 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
hw/riscv/opentitan: Explicit machine type definition
Expand the DEFINE_MACHINE() macro, converting the class_init() handler.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: A
hw/riscv/opentitan: Explicit machine type definition
Expand the DEFINE_MACHINE() macro, converting the class_init() handler.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230520054510.68822-5-philmd@linaro.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|
71302ff3 | 02-Mar-2023 |
Sunil V L <sunilvl@ventanamicro.com> |
hw/riscv/virt: Add memmap pointer to RiscVVirtState
memmap needs to be exported outside of virt.c so that modules like acpi can use it. Hence, add a pointer field in RiscVVirtState structure and ini
hw/riscv/virt: Add memmap pointer to RiscVVirtState
memmap needs to be exported outside of virt.c so that modules like acpi can use it. Hence, add a pointer field in RiscVVirtState structure and initialize it with the memorymap.
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230302091212.999767-4-sunilvl@ventanamicro.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
show more ...
|
168b8c29 | 02-Mar-2023 |
Sunil V L <sunilvl@ventanamicro.com> |
hw/riscv/virt: Add a switch to disable ACPI
ACPI will be enabled by default. Add a switch to turn off for testing and debug purposes.
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by
hw/riscv/virt: Add a switch to disable ACPI
ACPI will be enabled by default. Add a switch to turn off for testing and debug purposes.
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230302091212.999767-3-sunilvl@ventanamicro.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
show more ...
|
8b64475b | 06-Feb-2023 |
Daniel Henrique Barboza <dbarboza@ventanamicro.com> |
hw/riscv/boot.c: make riscv_load_initrd() static
The only remaining caller is riscv_load_kernel_and_initrd() which belongs to the same file.
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventana
hw/riscv/boot.c: make riscv_load_initrd() static
The only remaining caller is riscv_load_kernel_and_initrd() which belongs to the same file.
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: <20230206140022.2748401-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
show more ...
|
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 ...
|
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 ...
|
9c3ee7e8 | 11-Jan-2023 |
Daniel Henrique Barboza <dbarboza@ventanamicro.com> |
hw/riscv: use ms->fdt in riscv_socket_fdt_write_distance_matrix()
There's no need to use a MachineState pointer and a fdt pointer now that all RISC-V machines are using the FDT from the MachineState
hw/riscv: use ms->fdt in riscv_socket_fdt_write_distance_matrix()
There's no need to use a MachineState pointer and a fdt pointer now that all RISC-V machines are using the FDT from the MachineState.
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: <20230111170948.316276-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
show more ...
|