[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 2/3] hw/riscv: split fdt address calculation from fdt load
From: |
Bin Meng |
Subject: |
Re: [PATCH v4 2/3] hw/riscv: split fdt address calculation from fdt load |
Date: |
Sun, 29 Jan 2023 13:16:55 +0800 |
On Thu, Jan 26, 2023 at 9:53 PM Daniel Henrique Barboza
<dbarboza@ventanamicro.com> wrote:
>
> 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>
> ---
> hw/riscv/boot.c | 33 +++++++++++++++++++++++++--------
> hw/riscv/microchip_pfsoc.c | 6 ++++--
> hw/riscv/sifive_u.c | 7 ++++---
> hw/riscv/spike.c | 6 +++---
> hw/riscv/virt.c | 7 ++++---
> include/hw/riscv/boot.h | 4 +++-
> 6 files changed, 43 insertions(+), 20 deletions(-)
>
> diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c
> index a563b7482a..a6f7b8ae8e 100644
> --- a/hw/riscv/boot.c
> +++ b/hw/riscv/boot.c
> @@ -283,9 +283,21 @@ out:
> return kernel_entry;
> }
>
> -uint64_t riscv_load_fdt(hwaddr dram_base, uint64_t mem_size, void *fdt)
> +/*
> + * The FDT should be put at the farthest point possible to
> + * avoid overwriting it with the kernel/initrd.
> + *
> + * This function makes an assumption that the DRAM is
> + * contiguous. It also cares about 32-bit systems and
> + * will limit fdt_addr to be addressable by them even for
> + * 64-bit CPUs.
> + *
> + * The FDT is fdt_packed() during the calculation.
> + */
> +uint32_t riscv_compute_fdt_addr(hwaddr dram_base, uint64_t mem_size,
> + void *fdt)
The original code returns a uint64_t for fdt_addr but now this is uint32_t?
> {
> - uint64_t temp, fdt_addr;
> + uint64_t temp;
> hwaddr dram_end = dram_base + mem_size;
> int ret = fdt_pack(fdt);
> int fdtsize;
> @@ -306,11 +318,18 @@ uint64_t riscv_load_fdt(hwaddr dram_base, uint64_t
> mem_size, void *fdt)
> * end of dram or 3GB whichever is lesser.
> */
> temp = (dram_base < 3072 * MiB) ? MIN(dram_end, 3072 * MiB) : dram_end;
> - fdt_addr = QEMU_ALIGN_DOWN(temp - fdtsize, 2 * MiB);
>
> - ret = fdt_pack(fdt);
> - /* Should only fail if we've built a corrupted tree */
> - g_assert(ret == 0);
> + return QEMU_ALIGN_DOWN(temp - fdtsize, 2 * MiB);
> +}
> +
> +/*
> + * 'fdt_addr' is received as hwaddr because boards might put
> + * the FDT beyond 32-bit addressing boundary.
> + */
> +void riscv_load_fdt(hwaddr fdt_addr, void *fdt)
> +{
> + uint32_t fdtsize = fdt_totalsize(fdt);
> +
> /* copy in the device tree */
> qemu_fdt_dumpdtb(fdt, fdtsize);
>
> @@ -318,8 +337,6 @@ uint64_t riscv_load_fdt(hwaddr dram_base, uint64_t
> mem_size, void *fdt)
> &address_space_memory);
> qemu_register_reset_nosnapshotload(qemu_fdt_randomize_seeds,
> rom_ptr_for_as(&address_space_memory, fdt_addr,
> fdtsize));
> -
> - return fdt_addr;
> }
>
> void riscv_rom_copy_firmware_info(MachineState *machine, hwaddr rom_base,
> diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
> index b7e171b605..a30203db85 100644
> --- a/hw/riscv/microchip_pfsoc.c
> +++ b/hw/riscv/microchip_pfsoc.c
> @@ -633,8 +633,10 @@ static void
> microchip_icicle_kit_machine_init(MachineState *machine)
> kernel_start_addr, true, NULL);
>
> /* Compute the fdt load address in dram */
> - fdt_load_addr = riscv_load_fdt(memmap[MICROCHIP_PFSOC_DRAM_LO].base,
> - machine->ram_size, machine->fdt);
> + fdt_load_addr =
> riscv_compute_fdt_addr(memmap[MICROCHIP_PFSOC_DRAM_LO].base,
> + machine->ram_size,
> machine->fdt);
> + riscv_load_fdt(fdt_load_addr, machine->fdt);
> +
> /* Load the reset vector */
> riscv_setup_rom_reset_vec(machine, &s->soc.u_cpus,
> firmware_load_addr,
> memmap[MICROCHIP_PFSOC_ENVM_DATA].base,
> diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> index b0b3e6f03a..6bbdbe5fb7 100644
> --- a/hw/riscv/sifive_u.c
> +++ b/hw/riscv/sifive_u.c
> @@ -608,9 +608,10 @@ static void sifive_u_machine_init(MachineState *machine)
> kernel_entry = 0;
> }
>
> - /* Compute the fdt load address in dram */
> - fdt_load_addr = riscv_load_fdt(memmap[SIFIVE_U_DEV_DRAM].base,
> - machine->ram_size, machine->fdt);
> + fdt_load_addr = riscv_compute_fdt_addr(memmap[SIFIVE_U_DEV_DRAM].base,
> + machine->ram_size, machine->fdt);
> + riscv_load_fdt(fdt_load_addr, machine->fdt);
> +
> if (!riscv_is_32bit(&s->soc.u_cpus)) {
> start_addr_hi32 = (uint64_t)start_addr >> 32;
> }
> diff --git a/hw/riscv/spike.c b/hw/riscv/spike.c
> index 483581e05f..ceebe34c5f 100644
> --- a/hw/riscv/spike.c
> +++ b/hw/riscv/spike.c
> @@ -316,9 +316,9 @@ static void spike_board_init(MachineState *machine)
> kernel_entry = 0;
> }
>
> - /* Compute the fdt load address in dram */
> - fdt_load_addr = riscv_load_fdt(memmap[SPIKE_DRAM].base,
> - machine->ram_size, machine->fdt);
> + fdt_load_addr = riscv_compute_fdt_addr(memmap[SPIKE_DRAM].base,
> + machine->ram_size, machine->fdt);
> + riscv_load_fdt(fdt_load_addr, machine->fdt);
>
> /* load the reset vector */
> riscv_setup_rom_reset_vec(machine, &s->soc[0], memmap[SPIKE_DRAM].base,
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index 48326406fd..43fca597f0 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -1292,9 +1292,10 @@ static void virt_machine_done(Notifier *notifier, void
> *data)
> start_addr = virt_memmap[VIRT_FLASH].base;
> }
>
> - /* Compute the fdt load address in dram */
> - fdt_load_addr = riscv_load_fdt(memmap[VIRT_DRAM].base,
> - machine->ram_size, machine->fdt);
> + fdt_load_addr = riscv_compute_fdt_addr(memmap[VIRT_DRAM].base,
> + machine->ram_size, machine->fdt);
> + riscv_load_fdt(fdt_load_addr, machine->fdt);
> +
> /* load the reset vector */
> riscv_setup_rom_reset_vec(machine, &s->soc[0], start_addr,
> virt_memmap[VIRT_MROM].base,
> diff --git a/include/hw/riscv/boot.h b/include/hw/riscv/boot.h
> index bc9faed397..7babd669c7 100644
> --- a/include/hw/riscv/boot.h
> +++ b/include/hw/riscv/boot.h
> @@ -48,7 +48,9 @@ target_ulong riscv_load_kernel(MachineState *machine,
> target_ulong firmware_end_addr,
> bool load_initrd,
> symbol_fn_t sym_cb);
> -uint64_t riscv_load_fdt(hwaddr dram_start, uint64_t dram_size, void *fdt);
> +uint32_t riscv_compute_fdt_addr(hwaddr dram_start, uint64_t dram_size,
> + void *fdt);
> +void riscv_load_fdt(hwaddr fdt_addr, void *fdt);
> void riscv_setup_rom_reset_vec(MachineState *machine, RISCVHartArrayState
> *harts,
> hwaddr saddr,
> hwaddr rom_base, hwaddr rom_size,
> --
Regards,
Bin
- [PATCH v4 0/3] riscv_load_fdt() semantics change, Daniel Henrique Barboza, 2023/01/26
- [PATCH v4 1/3] hw/riscv/boot.c: calculate fdt size after fdt_pack(), Daniel Henrique Barboza, 2023/01/26
- [PATCH v4 2/3] hw/riscv: split fdt address calculation from fdt load, Daniel Henrique Barboza, 2023/01/26
- Re: [PATCH v4 2/3] hw/riscv: split fdt address calculation from fdt load,
Bin Meng <=
- [PATCH v4 3/3] hw/riscv: change riscv_compute_fdt_addr() semantics, Daniel Henrique Barboza, 2023/01/26
- Re: [PATCH v4 3/3] hw/riscv: change riscv_compute_fdt_addr() semantics, Bin Meng, 2023/01/29
- Re: [PATCH v4 3/3] hw/riscv: change riscv_compute_fdt_addr() semantics, Daniel Henrique Barboza, 2023/01/30
- Re: [PATCH v4 3/3] hw/riscv: change riscv_compute_fdt_addr() semantics, Daniel Henrique Barboza, 2023/01/30
- Re: [PATCH v4 3/3] hw/riscv: change riscv_compute_fdt_addr() semantics, Bin Meng, 2023/01/30
- Re: [PATCH v4 3/3] hw/riscv: change riscv_compute_fdt_addr() semantics, Daniel Henrique Barboza, 2023/01/31
- Re: [PATCH v4 3/3] hw/riscv: change riscv_compute_fdt_addr() semantics, Bin Meng, 2023/01/31
Re: [PATCH v4 0/3] riscv_load_fdt() semantics change, Conor Dooley, 2023/01/26