All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
To: qemu-devel@nongnu.org
Cc: qemu-riscv@nongnu.org, alistair.francis@wdc.com,
	Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Subject: [PATCH v4 0/3] riscv_load_fdt() semantics change
Date: Thu, 26 Jan 2023 10:52:16 -0300	[thread overview]
Message-ID: <20230126135219.1054658-1-dbarboza@ventanamicro.com> (raw)

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



             reply	other threads:[~2023-01-26 13:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-26 13:52 Daniel Henrique Barboza [this message]
2023-01-26 13:52 ` [PATCH v4 1/3] hw/riscv/boot.c: calculate fdt size after fdt_pack() Daniel Henrique Barboza
2023-01-29  2:20   ` Bin Meng
2023-01-29  3:06     ` Bin Meng
2023-01-26 13:52 ` [PATCH v4 2/3] hw/riscv: split fdt address calculation from fdt load Daniel Henrique Barboza
2023-01-29  5:16   ` Bin Meng
2023-01-26 13:52 ` [PATCH v4 3/3] hw/riscv: change riscv_compute_fdt_addr() semantics Daniel Henrique Barboza
2023-01-29  5:45   ` Bin Meng
2023-01-30 17:16     ` Daniel Henrique Barboza
2023-01-30 18:02       ` Daniel Henrique Barboza
2023-01-31  1:00       ` Bin Meng
2023-01-31  9:57         ` Daniel Henrique Barboza
2023-01-31 12:11           ` Bin Meng
2023-01-26 18:40 ` [PATCH v4 0/3] riscv_load_fdt() semantics change Conor Dooley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230126135219.1054658-1-dbarboza@ventanamicro.com \
    --to=dbarboza@ventanamicro.com \
    --cc=alistair.francis@wdc.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.