Hi,

After discussions in the previous version, where we ended up discovering
the details of why the current riscv_load_fdt() works with the Microchip
Icicle Kit board almost by accident, I decided to change how
riscv_compute_fdt_addr() (the FDT address calculation from
riscv_load_fdt()) operates. 

Instead of relying on premises that the Icicle Kit board can't hold
right from start, since dram_base + mem_size will never be contained in
a contiguous RAM area, change the FDT address calculation to also
receive the bondaries of the DRAM block that the board guarantees that
it's not sparse. With this extra information we're able to make a more
consistent FDT address calculation that will cover all existing cases we
have today.


Changes from v3:
- patch 3:
  - function to handle Icicle Kit FDT separately: discarded
  - change riscv_compute_fdt_addr() to clearly handle cases like the
    Icicle Kit board where not all RAM is contiguous
- v3 link: https://lists.gnu.org/archive/html/qemu-devel/2023-01/msg04464.html

Daniel Henrique Barboza (3):
  hw/riscv/boot.c: calculate fdt size after fdt_pack()
  hw/riscv: split fdt address calculation from fdt load
  hw/riscv: change riscv_compute_fdt_addr() semantics

 hw/riscv/boot.c            | 56 +++++++++++++++++++++++++++++++-------
 hw/riscv/microchip_pfsoc.c |  7 +++--
 hw/riscv/sifive_u.c        |  8 ++++--
 hw/riscv/spike.c           |  7 +++--
 hw/riscv/virt.c            |  8 ++++--
 include/hw/riscv/boot.h    |  4 ++-
 6 files changed, 68 insertions(+), 22 deletions(-)

-- 
2.39.1

On Thu, Jan 26, 2023 at 10:52:16AM -0300, Daniel Henrique Barboza wrote:
> Hi,
> 
> After discussions in the previous version, where we ended up discovering
> the details of why the current riscv_load_fdt() works with the Microchip
> Icicle Kit board almost by accident, I decided to change how
> riscv_compute_fdt_addr() (the FDT address calculation from
> riscv_load_fdt()) operates. 
> 
> Instead of relying on premises that the Icicle Kit board can't hold
> right from start, since dram_base + mem_size will never be contained in
> a contiguous RAM area, change the FDT address calculation to also
> receive the bondaries of the DRAM block that the board guarantees that
> it's not sparse. With this extra information we're able to make a more
> consistent FDT address calculation that will cover all existing cases we
> have today.

The "test" case that fail before, is now back passing again. Thanks
Daniel!

Tested-by: Conor Dooley <conor.dooley@microchip.com>