RE: [PATCH qemu v2] change the fdt_load_addr variable datatype to handle 64-bit DRAM address
Dear Daniel, Thanks for your comments. Incorporated the same and updated the patch set as v3. https://lists.gnu.org/archive/html/qemu-riscv/2023-06/msg00570.html Regards, Lakshmi -Original Message- From: Daniel Henrique Barboza Sent: Friday, June 23, 2023 12:16 AM To: Lakshmi Bai Raja Subramanian ; qemu-ri...@nongnu.org; Alistair Francis Cc: qemu-devel@nongnu.org Subject: Re: [PATCH qemu v2] change the fdt_load_addr variable datatype to handle 64-bit DRAM address (CC-ing Alistair) On 6/20/23 14:44, ~rlakshmibai wrote: > From: Lakshmi Bai Raja Subramanian > > > fdt_load_addr is getting overflowed when there is no DRAM at lower 32 bit > address space. > To support pure 64-bit DRAM address, fdt_load_addr variable's data > type is changed to uint64_t instead of uint32_t. It's worth mentioning that fdt_load_addr receives the result of riscv_compute_fdt_addr(), which is an uint64_t. > > Signed-off-by: Lakshmi Bai Raja Subramanian > > --- Reviewed-by: Daniel Henrique Barboza > hw/riscv/virt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c index > 95708d890e..c348529ac0 100644 > --- a/hw/riscv/virt.c > +++ b/hw/riscv/virt.c > @@ -1244,7 +1244,7 @@ static void virt_machine_done(Notifier *notifier, void > *data) > target_ulong start_addr = memmap[VIRT_DRAM].base; > target_ulong firmware_end_addr, kernel_start_addr; > const char *firmware_name = riscv_default_firmware_name(>soc[0]); > -uint32_t fdt_load_addr; > +uint64_t fdt_load_addr; > uint64_t kernel_entry = 0; > BlockBackend *pflash_blk0; >
Re: [PATCH qemu v2] change the fdt_load_addr variable datatype to handle 64-bit DRAM address
(CC-ing Alistair) On 6/20/23 14:44, ~rlakshmibai wrote: From: Lakshmi Bai Raja Subramanian fdt_load_addr is getting overflowed when there is no DRAM at lower 32 bit address space. To support pure 64-bit DRAM address, fdt_load_addr variable's data type is changed to uint64_t instead of uint32_t. It's worth mentioning that fdt_load_addr receives the result of riscv_compute_fdt_addr(), which is an uint64_t. Signed-off-by: Lakshmi Bai Raja Subramanian --- Reviewed-by: Daniel Henrique Barboza hw/riscv/virt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c index 95708d890e..c348529ac0 100644 --- a/hw/riscv/virt.c +++ b/hw/riscv/virt.c @@ -1244,7 +1244,7 @@ static void virt_machine_done(Notifier *notifier, void *data) target_ulong start_addr = memmap[VIRT_DRAM].base; target_ulong firmware_end_addr, kernel_start_addr; const char *firmware_name = riscv_default_firmware_name(>soc[0]); -uint32_t fdt_load_addr; +uint64_t fdt_load_addr; uint64_t kernel_entry = 0; BlockBackend *pflash_blk0;
[PATCH qemu v2] change the fdt_load_addr variable datatype to handle 64-bit DRAM address
From: Lakshmi Bai Raja Subramanian fdt_load_addr is getting overflowed when there is no DRAM at lower 32 bit address space. To support pure 64-bit DRAM address, fdt_load_addr variable's data type is changed to uint64_t instead of uint32_t. Signed-off-by: Lakshmi Bai Raja Subramanian --- hw/riscv/virt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c index 95708d890e..c348529ac0 100644 --- a/hw/riscv/virt.c +++ b/hw/riscv/virt.c @@ -1244,7 +1244,7 @@ static void virt_machine_done(Notifier *notifier, void *data) target_ulong start_addr = memmap[VIRT_DRAM].base; target_ulong firmware_end_addr, kernel_start_addr; const char *firmware_name = riscv_default_firmware_name(>soc[0]); -uint32_t fdt_load_addr; +uint64_t fdt_load_addr; uint64_t kernel_entry = 0; BlockBackend *pflash_blk0; -- 2.38.5
