Re: [v2 PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
On Thu, Jan 7, 2021 at 1:11 AM Atish Patra wrote:
>
> Currently, we place the DTB at 2MB from 4GB or end of DRAM which ever is
> lesser. However, Linux kernel can address only 1GB of memory for RV32.
> Thus, it can not map anything beyond 3GB (assuming 2GB is the starting
> address).
> As a result, it can not process DT and panic if opensbi dynamic firmware
> is used. While at it, place the DTB further away to avoid in memory placement
> issues in future.
>
> Fix this by placing the DTB at 16MB from 3GB or end of DRAM whichever is
> lower.
>
> Fixes: 66b1205bc5ab ("RISC-V: Copy the fdt in dram instead of ROM")
>
> Reviewed-by: Bin Meng
> Tested-by: Bin Meng
> Signed-off-by: Atish Patra
Thanks!
Applied to riscv-to-apply.next
Alistair
> ---
> Changes from v2->v1
> 1. Added the fixes tag and updated aligned down address to 16MB.
> ---
> hw/riscv/boot.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c
> index d62f3dc7581e..2ed23c7e9849 100644
> --- a/hw/riscv/boot.c
> +++ b/hw/riscv/boot.c
> @@ -202,11 +202,11 @@ uint32_t riscv_load_fdt(hwaddr dram_base, uint64_t
> mem_size, void *fdt)
> /*
> * We should put fdt as far as possible to avoid kernel/initrd
> overwriting
> * its content. But it should be addressable by 32 bit system as well.
> - * Thus, put it at an aligned address that less than fdt size from end of
> - * dram or 4GB whichever is lesser.
> + * Thus, put it at an 16MB aligned address that less than fdt size from
> the
> + * end of dram or 3GB whichever is lesser.
> */
> -temp = MIN(dram_end, 4096 * MiB);
> -fdt_addr = QEMU_ALIGN_DOWN(temp - fdtsize, 2 * MiB);
> +temp = MIN(dram_end, 3072 * MiB);
> +fdt_addr = QEMU_ALIGN_DOWN(temp - fdtsize, 16 * MiB);
>
> fdt_pack(fdt);
> /* copy in the device tree */
> --
> 2.25.1
>
>
[v2 PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
Currently, we place the DTB at 2MB from 4GB or end of DRAM which ever is
lesser. However, Linux kernel can address only 1GB of memory for RV32.
Thus, it can not map anything beyond 3GB (assuming 2GB is the starting address).
As a result, it can not process DT and panic if opensbi dynamic firmware
is used. While at it, place the DTB further away to avoid in memory placement
issues in future.
Fix this by placing the DTB at 16MB from 3GB or end of DRAM whichever is lower.
Fixes: 66b1205bc5ab ("RISC-V: Copy the fdt in dram instead of ROM")
Reviewed-by: Bin Meng
Tested-by: Bin Meng
Signed-off-by: Atish Patra
---
Changes from v2->v1
1. Added the fixes tag and updated aligned down address to 16MB.
---
hw/riscv/boot.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c
index d62f3dc7581e..2ed23c7e9849 100644
--- a/hw/riscv/boot.c
+++ b/hw/riscv/boot.c
@@ -202,11 +202,11 @@ uint32_t riscv_load_fdt(hwaddr dram_base, uint64_t
mem_size, void *fdt)
/*
* We should put fdt as far as possible to avoid kernel/initrd overwriting
* its content. But it should be addressable by 32 bit system as well.
- * Thus, put it at an aligned address that less than fdt size from end of
- * dram or 4GB whichever is lesser.
+ * Thus, put it at an 16MB aligned address that less than fdt size from the
+ * end of dram or 3GB whichever is lesser.
*/
-temp = MIN(dram_end, 4096 * MiB);
-fdt_addr = QEMU_ALIGN_DOWN(temp - fdtsize, 2 * MiB);
+temp = MIN(dram_end, 3072 * MiB);
+fdt_addr = QEMU_ALIGN_DOWN(temp - fdtsize, 16 * MiB);
fdt_pack(fdt);
/* copy in the device tree */
--
2.25.1
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
On Wed, 2021-01-06 at 08:04 +0800, Bin Meng wrote:
> Hi Atish,
>
> On Wed, Jan 6, 2021 at 7:44 AM Atish Patra
> wrote:
> >
> > On Tue, 2021-01-05 at 11:11 +0800, Bin Meng wrote:
> > > On Fri, Dec 18, 2020 at 5:48 AM Atish Patra
> > > wrote:
> > > >
> > > > Currently, we place the DTB at 2MB from 4GB or end of DRAM
> > > > which
> > > > ever is
> > > > lesser. However, Linux kernel can address only 1GB of memory
> > > > for
> > > > RV32.
> > > > Thus, it can not map anything beyond 3GB (assuming 2GB is the
> > > > starting address).
> > > > As a result, it can not process DT and panic if opensbi dynamic
> > > > firmware
> > > > is used.
> > > >
> > > > Fix this by placing the DTB at 2MB from 3GB or end of DRAM
> > > > whichever is lower.
> > > >
> > >
> > > Fixes: 66b1205bc5ab ("RISC-V: Copy the fdt in dram instead of
> > > ROM")
> > >
> >
> > Just to clarify, it is not a bug in the original patch. This bug
> > appeared in recent kernel because kernel(from v5.10) doesn't use
> > fixmap
> > for DT processing anymore. Thus, the DT has to be placed at
> > location
> > that can be addressed by kernel.
>
> Thanks for the clarification.
>
> >
> > I will add the fixes tag.
> >
>
> Did you get a chance to trace to another possible kernel bug?
>
Yeah. Let me explain. Apologies for long explanation in advance :)
5.10 kernel + memblock_enforce_memory_limit patch actually boots but
crashes after a point with 2GB of memory. You did not see any boot logs
as you were not using earlycon argument.
The issue was masked by the a kernel patch [3] that got merged in 5.11-
rc1. The patch[3] also throws a warning on RV32 because of a another
bug[1].
The real issue with 2GB memory in RV32 is that Linux kernel treats any
pointers within last 4K byte of addressable memory as error [2].
In the absence of the patch[3], kernel unflattens the DT towards the
end of the memory. These memory regions are absolutely fine and
addressable. I even verified the memory region in qemu and can print
the DT strings using gdb. However, kernel thinks as error by mistake
because of [2].
The kernel patch[3] masked off the 2GB problem because it tried to
allocate bunch of memblocks and failed. That lead memblock to allocate
memory for unflattend DT at a different place which helped.
I have a fix solve the bug introduced by that patch[3] and can
reproduce the 2GB problem with 5.11-rc2 as well with the kernel fix.
The simple solution is here to place the DTB at an address farther away
from the end of 3GB. Kernel puts some other data structure towards the
end of the addressable memory but never accesses those last 4K bytes of
memory. Thus we don't see a problem anymore. This problem manifests
only when you have a virtual address within 4K of addressable memory.
It is only possible with RV32 and 2GB combination.
fdt_addr = QEMU_ALIGN_DOWN(temp - fdtsize, X * MiB);
where X must be > 4.
I tested with 8/16/32 MB aligned address and it works fine every time.
I think the safest option should be 32MB offset.
Kernel should also be fixed so that memblock allocation code should not
allocate anything within last 4K of addressable memory.
[1]
http://lists.infradead.org/pipermail/linux-riscv/2021-January/004086.html
[2]
https://github.com/torvalds/linux/blob/master/include/linux/err.h#L22
[3] 0f522592ab9f RISC-V: Add kernel image sections to the resource tree
> Regards,
> Bin
--
Regards,
Atish
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
Hi Atish,
On Wed, Jan 6, 2021 at 7:44 AM Atish Patra wrote:
>
> On Tue, 2021-01-05 at 11:11 +0800, Bin Meng wrote:
> > On Fri, Dec 18, 2020 at 5:48 AM Atish Patra
> > wrote:
> > >
> > > Currently, we place the DTB at 2MB from 4GB or end of DRAM which
> > > ever is
> > > lesser. However, Linux kernel can address only 1GB of memory for
> > > RV32.
> > > Thus, it can not map anything beyond 3GB (assuming 2GB is the
> > > starting address).
> > > As a result, it can not process DT and panic if opensbi dynamic
> > > firmware
> > > is used.
> > >
> > > Fix this by placing the DTB at 2MB from 3GB or end of DRAM
> > > whichever is lower.
> > >
> >
> > Fixes: 66b1205bc5ab ("RISC-V: Copy the fdt in dram instead of ROM")
> >
>
> Just to clarify, it is not a bug in the original patch. This bug
> appeared in recent kernel because kernel(from v5.10) doesn't use fixmap
> for DT processing anymore. Thus, the DT has to be placed at location
> that can be addressed by kernel.
Thanks for the clarification.
>
> I will add the fixes tag.
>
Did you get a chance to trace to another possible kernel bug?
Regards,
Bin
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
On Tue, 2021-01-05 at 11:11 +0800, Bin Meng wrote:
> On Fri, Dec 18, 2020 at 5:48 AM Atish Patra
> wrote:
> >
> > Currently, we place the DTB at 2MB from 4GB or end of DRAM which
> > ever is
> > lesser. However, Linux kernel can address only 1GB of memory for
> > RV32.
> > Thus, it can not map anything beyond 3GB (assuming 2GB is the
> > starting address).
> > As a result, it can not process DT and panic if opensbi dynamic
> > firmware
> > is used.
> >
> > Fix this by placing the DTB at 2MB from 3GB or end of DRAM
> > whichever is lower.
> >
>
> Fixes: 66b1205bc5ab ("RISC-V: Copy the fdt in dram instead of ROM")
>
Just to clarify, it is not a bug in the original patch. This bug
appeared in recent kernel because kernel(from v5.10) doesn't use fixmap
for DT processing anymore. Thus, the DT has to be placed at location
that can be addressed by kernel.
I will add the fixes tag.
> > Signed-off-by: Atish Patra
> > ---
> > hw/riscv/boot.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
>
> Reviewed-by: Bin Meng
> Tested-by: Bin Meng
Thanks.
--
Regards,
Atish
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
On Mon, Jan 4, 2021 at 7:11 PM Bin Meng wrote:
>
> On Fri, Dec 18, 2020 at 5:48 AM Atish Patra wrote:
> >
> > Currently, we place the DTB at 2MB from 4GB or end of DRAM which ever is
> > lesser. However, Linux kernel can address only 1GB of memory for RV32.
> > Thus, it can not map anything beyond 3GB (assuming 2GB is the starting
> > address).
> > As a result, it can not process DT and panic if opensbi dynamic firmware
> > is used.
> >
> > Fix this by placing the DTB at 2MB from 3GB or end of DRAM whichever is
> > lower.
> >
>
> Fixes: 66b1205bc5ab ("RISC-V: Copy the fdt in dram instead of ROM")
>
> > Signed-off-by: Atish Patra
> > ---
> > hw/riscv/boot.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
>
> Reviewed-by: Bin Meng
> Tested-by: Bin Meng
Thanks!
Applied to riscv-to-apply.next
Alistair
>
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
On Fri, Dec 18, 2020 at 5:48 AM Atish Patra wrote:
>
> Currently, we place the DTB at 2MB from 4GB or end of DRAM which ever is
> lesser. However, Linux kernel can address only 1GB of memory for RV32.
> Thus, it can not map anything beyond 3GB (assuming 2GB is the starting
> address).
> As a result, it can not process DT and panic if opensbi dynamic firmware
> is used.
>
> Fix this by placing the DTB at 2MB from 3GB or end of DRAM whichever is lower.
>
Fixes: 66b1205bc5ab ("RISC-V: Copy the fdt in dram instead of ROM")
> Signed-off-by: Atish Patra
> ---
> hw/riscv/boot.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Bin Meng
Tested-by: Bin Meng
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
Hi Atish, On Tue, Jan 5, 2021 at 4:24 AM Atish Patra wrote: > > On Tue, 2020-12-29 at 12:49 +0800, Bin Meng wrote: > > Hi Atish, > > > > On Wed, Dec 23, 2020 at 9:20 AM Bin Meng wrote: > > > > > > Hi Atish, > > > > > > On Wed, Dec 23, 2020 at 3:59 AM Atish Patra > > > wrote: > > > > > > > > On Tue, 2020-12-22 at 13:35 +0800, Bin Meng wrote: > > > > > Hi Atish, > > > > > > > > > > On Sat, Dec 19, 2020 at 3:46 AM Atish Patra < > > > > > atish.pa...@wdc.com> > > > > > wrote: > > > > > > > > > > > > On Fri, 2020-12-18 at 16:42 +0800, Bin Meng wrote: > > > > > > > Hi Atish, > > > > > > > > > > > > > > On Fri, Dec 18, 2020 at 4:00 PM Atish Patra < > > > > > > > atish.pa...@wdc.com> > > > > > > > wrote: > > > > > > > > > > > > > > > > On Fri, 2020-12-18 at 15:33 +0800, Bin Meng wrote: > > > > > > > > > Hi Atish, > > > > > > > > > > > > > > > > > > On Fri, Dec 18, 2020 at 3:27 PM Atish Patra < > > > > > > > > > atish.pa...@wdc.com> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Fri, 2020-12-18 at 15:21 +0800, Bin Meng wrote: > > > > > > > > > > > Hi Atish, > > > > > > > > > > > > > > > > > > > > > > On Fri, Dec 18, 2020 at 5:48 AM Atish Patra > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Currently, we place the DTB at 2MB from 4GB or > > > > > > > > > > > > end of > > > > > > > > > > > > DRAM > > > > > > > > > > > > which > > > > > > > > > > > > ever is > > > > > > > > > > > > lesser. However, Linux kernel can address only > > > > > > > > > > > > 1GB of > > > > > > > > > > > > memory > > > > > > > > > > > > for > > > > > > > > > > > > RV32. > > > > > > > > > > > > Thus, it can not map anything beyond 3GB > > > > > > > > > > > > (assuming 2GB > > > > > > > > > > > > is > > > > > > > > > > > > the > > > > > > > > > > > > starting address). > > > > > > > > > > > > As a result, it can not process DT and panic if > > > > > > > > > > > > opensbi > > > > > > > > > > > > dynamic > > > > > > > > > > > > firmware > > > > > > > > > > > > is used. > > > > > > > > > > > > > > > > > > > > > > > > Fix this by placing the DTB at 2MB from 3GB or > > > > > > > > > > > > end of > > > > > > > > > > > > DRAM > > > > > > > > > > > > whichever is lower. > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Atish Patra > > > > > > > > > > > > --- > > > > > > > > > > > > hw/riscv/boot.c | 4 ++-- > > > > > > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > With this patch, 32-bit sifive_u still does not > > > > > > > > > > > boot > > > > > > > > > > > kernel > > > > > > > > > > > with > > > > > > > > > > > the > > > > > > > > > > > following patch applied on 5.10: > > > > > > > > > > > > > > > > > > > > > > https://patchwork.kernel.org/project/linux-riscv/patch/20201217074855.1948743-1-atish.pa...@wdc.com/ > > > > > > > > > > > > > > > > > > > > > > Command I used: > > > > > > > > > > > $ qemu-system-riscv32 -nographic -M sifive_u -m 1G > > > > > > > > > > > -smp 5 > > > > > > > > > > > - > > > > > > > > > > > kernel > > > > > > > > > > > arch/riscv/boot/Image > > > > > > > > > > > > > > > > > > > > > > 32-bit virt cannot boot the same kernel image with > > > > > > > > > > > memory > > > > > > > > > > > set > > > > > > > > > > > to > > > > > > > > > > > 2G > > > > > > > > > > > either: > > > > > > > > > > > $ qemu-system-riscv32 -nographic -M virt -m 2G -smp > > > > > > > > > > > 4 - > > > > > > > > > > > kernel > > > > > > > > > > > arch/riscv/boot/Image > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Bin, > > > > > > > > > > As mentioned in the email on the linux mailing list, > > > > > > > > > > this > > > > > > > > > > patch > > > > > > > > > > only > > > > > > > > > > solves 2GB problem. sifive_u problem is solved by > > > > > > > > > > Alistair's > > > > > > > > > > patch[1]. > > > > > > > > > > > > > > > > > > > > He is planning to send the PR soon. The issue with > > > > > > > > > > sifive_u > > > > > > > > > > boot > > > > > > > > > > was it > > > > > > > > > > was failing the 32 bit test earlier resulting a 2MB > > > > > > > > > > aligned > > > > > > > > > > address > > > > > > > > > > instead of 4MB. > > > > > > > > > > > > > > > > > > Ah, I see. However my testing shows that virt with 2G > > > > > > > > > still > > > > > > > > > does > > > > > > > > > not > > > > > > > > > boot with this patch. > > > > > > > > > > > > > > > > > > > > > > > > > Strange. I verified again with following combination with > > > > > > > > -bios > > > > > > > > and > > > > > > > > without bios parameter. > > > > > > > > > > > > > > > > 1. virt 32/64 with 1GB/2GB memory > > > > > > > > 2. sifive_u 32/64 bit with 1GB/2GB memory (Alistair's > > > > > > > > patch > > > > > > > > included) > > > > > > > > > > > > > > > > Can you share the boot log along with the head commit of > > > > > > > > Qemu > > > > > > > > and > > > > > > > > commandline ? I am using 5.10 kernel
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
On Tue, 2020-12-29 at 12:49 +0800, Bin Meng wrote: > Hi Atish, > > On Wed, Dec 23, 2020 at 9:20 AM Bin Meng wrote: > > > > Hi Atish, > > > > On Wed, Dec 23, 2020 at 3:59 AM Atish Patra > > wrote: > > > > > > On Tue, 2020-12-22 at 13:35 +0800, Bin Meng wrote: > > > > Hi Atish, > > > > > > > > On Sat, Dec 19, 2020 at 3:46 AM Atish Patra < > > > > atish.pa...@wdc.com> > > > > wrote: > > > > > > > > > > On Fri, 2020-12-18 at 16:42 +0800, Bin Meng wrote: > > > > > > Hi Atish, > > > > > > > > > > > > On Fri, Dec 18, 2020 at 4:00 PM Atish Patra < > > > > > > atish.pa...@wdc.com> > > > > > > wrote: > > > > > > > > > > > > > > On Fri, 2020-12-18 at 15:33 +0800, Bin Meng wrote: > > > > > > > > Hi Atish, > > > > > > > > > > > > > > > > On Fri, Dec 18, 2020 at 3:27 PM Atish Patra < > > > > > > > > atish.pa...@wdc.com> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Fri, 2020-12-18 at 15:21 +0800, Bin Meng wrote: > > > > > > > > > > Hi Atish, > > > > > > > > > > > > > > > > > > > > On Fri, Dec 18, 2020 at 5:48 AM Atish Patra > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Currently, we place the DTB at 2MB from 4GB or > > > > > > > > > > > end of > > > > > > > > > > > DRAM > > > > > > > > > > > which > > > > > > > > > > > ever is > > > > > > > > > > > lesser. However, Linux kernel can address only > > > > > > > > > > > 1GB of > > > > > > > > > > > memory > > > > > > > > > > > for > > > > > > > > > > > RV32. > > > > > > > > > > > Thus, it can not map anything beyond 3GB > > > > > > > > > > > (assuming 2GB > > > > > > > > > > > is > > > > > > > > > > > the > > > > > > > > > > > starting address). > > > > > > > > > > > As a result, it can not process DT and panic if > > > > > > > > > > > opensbi > > > > > > > > > > > dynamic > > > > > > > > > > > firmware > > > > > > > > > > > is used. > > > > > > > > > > > > > > > > > > > > > > Fix this by placing the DTB at 2MB from 3GB or > > > > > > > > > > > end of > > > > > > > > > > > DRAM > > > > > > > > > > > whichever is lower. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Atish Patra > > > > > > > > > > > --- > > > > > > > > > > > hw/riscv/boot.c | 4 ++-- > > > > > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > With this patch, 32-bit sifive_u still does not > > > > > > > > > > boot > > > > > > > > > > kernel > > > > > > > > > > with > > > > > > > > > > the > > > > > > > > > > following patch applied on 5.10: > > > > > > > > > > > > > > > > > > > > https://patchwork.kernel.org/project/linux-riscv/patch/20201217074855.1948743-1-atish.pa...@wdc.com/ > > > > > > > > > > > > > > > > > > > > Command I used: > > > > > > > > > > $ qemu-system-riscv32 -nographic -M sifive_u -m 1G > > > > > > > > > > -smp 5 > > > > > > > > > > - > > > > > > > > > > kernel > > > > > > > > > > arch/riscv/boot/Image > > > > > > > > > > > > > > > > > > > > 32-bit virt cannot boot the same kernel image with > > > > > > > > > > memory > > > > > > > > > > set > > > > > > > > > > to > > > > > > > > > > 2G > > > > > > > > > > either: > > > > > > > > > > $ qemu-system-riscv32 -nographic -M virt -m 2G -smp > > > > > > > > > > 4 - > > > > > > > > > > kernel > > > > > > > > > > arch/riscv/boot/Image > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Bin, > > > > > > > > > As mentioned in the email on the linux mailing list, > > > > > > > > > this > > > > > > > > > patch > > > > > > > > > only > > > > > > > > > solves 2GB problem. sifive_u problem is solved by > > > > > > > > > Alistair's > > > > > > > > > patch[1]. > > > > > > > > > > > > > > > > > > He is planning to send the PR soon. The issue with > > > > > > > > > sifive_u > > > > > > > > > boot > > > > > > > > > was it > > > > > > > > > was failing the 32 bit test earlier resulting a 2MB > > > > > > > > > aligned > > > > > > > > > address > > > > > > > > > instead of 4MB. > > > > > > > > > > > > > > > > Ah, I see. However my testing shows that virt with 2G > > > > > > > > still > > > > > > > > does > > > > > > > > not > > > > > > > > boot with this patch. > > > > > > > > > > > > > > > > > > > > > > Strange. I verified again with following combination with > > > > > > > -bios > > > > > > > and > > > > > > > without bios parameter. > > > > > > > > > > > > > > 1. virt 32/64 with 1GB/2GB memory > > > > > > > 2. sifive_u 32/64 bit with 1GB/2GB memory (Alistair's > > > > > > > patch > > > > > > > included) > > > > > > > > > > > > > > Can you share the boot log along with the head commit of > > > > > > > Qemu > > > > > > > and > > > > > > > commandline ? I am using 5.10 kernel with my kernel fix. > > > > > > > > > > > > > > > > > > > I was using Alistair's QEMU repo for testing and 5.10 > > > > > > kernel with > > > > > > your > > > > > > kernel fix: > > > > > > > > > > > > $ git checkout -b testing pull-riscv-to-apply-20201217-1 > > > > > > $ apply this patch > > > > > > $ mkdir
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
Hi Atish, On Wed, Dec 23, 2020 at 9:20 AM Bin Meng wrote: > > Hi Atish, > > On Wed, Dec 23, 2020 at 3:59 AM Atish Patra wrote: > > > > On Tue, 2020-12-22 at 13:35 +0800, Bin Meng wrote: > > > Hi Atish, > > > > > > On Sat, Dec 19, 2020 at 3:46 AM Atish Patra > > > wrote: > > > > > > > > On Fri, 2020-12-18 at 16:42 +0800, Bin Meng wrote: > > > > > Hi Atish, > > > > > > > > > > On Fri, Dec 18, 2020 at 4:00 PM Atish Patra > > > > > wrote: > > > > > > > > > > > > On Fri, 2020-12-18 at 15:33 +0800, Bin Meng wrote: > > > > > > > Hi Atish, > > > > > > > > > > > > > > On Fri, Dec 18, 2020 at 3:27 PM Atish Patra < > > > > > > > atish.pa...@wdc.com> > > > > > > > wrote: > > > > > > > > > > > > > > > > On Fri, 2020-12-18 at 15:21 +0800, Bin Meng wrote: > > > > > > > > > Hi Atish, > > > > > > > > > > > > > > > > > > On Fri, Dec 18, 2020 at 5:48 AM Atish Patra > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Currently, we place the DTB at 2MB from 4GB or end of > > > > > > > > > > DRAM > > > > > > > > > > which > > > > > > > > > > ever is > > > > > > > > > > lesser. However, Linux kernel can address only 1GB of > > > > > > > > > > memory > > > > > > > > > > for > > > > > > > > > > RV32. > > > > > > > > > > Thus, it can not map anything beyond 3GB (assuming 2GB > > > > > > > > > > is > > > > > > > > > > the > > > > > > > > > > starting address). > > > > > > > > > > As a result, it can not process DT and panic if opensbi > > > > > > > > > > dynamic > > > > > > > > > > firmware > > > > > > > > > > is used. > > > > > > > > > > > > > > > > > > > > Fix this by placing the DTB at 2MB from 3GB or end of > > > > > > > > > > DRAM > > > > > > > > > > whichever is lower. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Atish Patra > > > > > > > > > > --- > > > > > > > > > > hw/riscv/boot.c | 4 ++-- > > > > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > > > > > > > > > > > > > With this patch, 32-bit sifive_u still does not boot > > > > > > > > > kernel > > > > > > > > > with > > > > > > > > > the > > > > > > > > > following patch applied on 5.10: > > > > > > > > > > > > > > > > > > https://patchwork.kernel.org/project/linux-riscv/patch/20201217074855.1948743-1-atish.pa...@wdc.com/ > > > > > > > > > > > > > > > > > > Command I used: > > > > > > > > > $ qemu-system-riscv32 -nographic -M sifive_u -m 1G -smp 5 > > > > > > > > > - > > > > > > > > > kernel > > > > > > > > > arch/riscv/boot/Image > > > > > > > > > > > > > > > > > > 32-bit virt cannot boot the same kernel image with memory > > > > > > > > > set > > > > > > > > > to > > > > > > > > > 2G > > > > > > > > > either: > > > > > > > > > $ qemu-system-riscv32 -nographic -M virt -m 2G -smp 4 - > > > > > > > > > kernel > > > > > > > > > arch/riscv/boot/Image > > > > > > > > > > > > > > > > > > > > > > > > > Hi Bin, > > > > > > > > As mentioned in the email on the linux mailing list, this > > > > > > > > patch > > > > > > > > only > > > > > > > > solves 2GB problem. sifive_u problem is solved by > > > > > > > > Alistair's > > > > > > > > patch[1]. > > > > > > > > > > > > > > > > He is planning to send the PR soon. The issue with sifive_u > > > > > > > > boot > > > > > > > > was it > > > > > > > > was failing the 32 bit test earlier resulting a 2MB aligned > > > > > > > > address > > > > > > > > instead of 4MB. > > > > > > > > > > > > > > Ah, I see. However my testing shows that virt with 2G still > > > > > > > does > > > > > > > not > > > > > > > boot with this patch. > > > > > > > > > > > > > > > > > > > Strange. I verified again with following combination with -bios > > > > > > and > > > > > > without bios parameter. > > > > > > > > > > > > 1. virt 32/64 with 1GB/2GB memory > > > > > > 2. sifive_u 32/64 bit with 1GB/2GB memory (Alistair's patch > > > > > > included) > > > > > > > > > > > > Can you share the boot log along with the head commit of Qemu > > > > > > and > > > > > > commandline ? I am using 5.10 kernel with my kernel fix. > > > > > > > > > > > > > > > > I was using Alistair's QEMU repo for testing and 5.10 kernel with > > > > > your > > > > > kernel fix: > > > > > > > > > > $ git checkout -b testing pull-riscv-to-apply-20201217-1 > > > > > $ apply this patch > > > > > $ mkdir build;cd build;../configure > > > > > --target-list=riscv64-softmmu,riscv32-softmmu;make -j > > > > > > > > > > $ ./qemu-system-riscv32 -nographic -M virt -m 2G -smp 4 -kernel > > > > > ~/work/git/linux/arch/riscv/boot/Image > > > > > > > > > > OpenSBI v0.8 > > > > >_ _ > > > > > / __ \ / | _ \_ _| > > > > > | | | |_ __ ___ _ __ | (___ | |_) || | > > > > > | | | | '_ \ / _ \ '_ \ \___ \| _ < | | > > > > > | |__| | |_) | __/ | | |) | |_) || |_ > > > > > \/| .__/ \___|_| |_|_/|/_| > > > > > | | > > > > > |_| > > > > > > > > > > Platform Name : riscv-virtio,qemu > > > > > Platform Features
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
Hi Atish, On Wed, Dec 23, 2020 at 3:59 AM Atish Patra wrote: > > On Tue, 2020-12-22 at 13:35 +0800, Bin Meng wrote: > > Hi Atish, > > > > On Sat, Dec 19, 2020 at 3:46 AM Atish Patra > > wrote: > > > > > > On Fri, 2020-12-18 at 16:42 +0800, Bin Meng wrote: > > > > Hi Atish, > > > > > > > > On Fri, Dec 18, 2020 at 4:00 PM Atish Patra > > > > wrote: > > > > > > > > > > On Fri, 2020-12-18 at 15:33 +0800, Bin Meng wrote: > > > > > > Hi Atish, > > > > > > > > > > > > On Fri, Dec 18, 2020 at 3:27 PM Atish Patra < > > > > > > atish.pa...@wdc.com> > > > > > > wrote: > > > > > > > > > > > > > > On Fri, 2020-12-18 at 15:21 +0800, Bin Meng wrote: > > > > > > > > Hi Atish, > > > > > > > > > > > > > > > > On Fri, Dec 18, 2020 at 5:48 AM Atish Patra > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Currently, we place the DTB at 2MB from 4GB or end of > > > > > > > > > DRAM > > > > > > > > > which > > > > > > > > > ever is > > > > > > > > > lesser. However, Linux kernel can address only 1GB of > > > > > > > > > memory > > > > > > > > > for > > > > > > > > > RV32. > > > > > > > > > Thus, it can not map anything beyond 3GB (assuming 2GB > > > > > > > > > is > > > > > > > > > the > > > > > > > > > starting address). > > > > > > > > > As a result, it can not process DT and panic if opensbi > > > > > > > > > dynamic > > > > > > > > > firmware > > > > > > > > > is used. > > > > > > > > > > > > > > > > > > Fix this by placing the DTB at 2MB from 3GB or end of > > > > > > > > > DRAM > > > > > > > > > whichever is lower. > > > > > > > > > > > > > > > > > > Signed-off-by: Atish Patra > > > > > > > > > --- > > > > > > > > > hw/riscv/boot.c | 4 ++-- > > > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > > > > > > > > > > With this patch, 32-bit sifive_u still does not boot > > > > > > > > kernel > > > > > > > > with > > > > > > > > the > > > > > > > > following patch applied on 5.10: > > > > > > > > > > > > > > > > https://patchwork.kernel.org/project/linux-riscv/patch/20201217074855.1948743-1-atish.pa...@wdc.com/ > > > > > > > > > > > > > > > > Command I used: > > > > > > > > $ qemu-system-riscv32 -nographic -M sifive_u -m 1G -smp 5 > > > > > > > > - > > > > > > > > kernel > > > > > > > > arch/riscv/boot/Image > > > > > > > > > > > > > > > > 32-bit virt cannot boot the same kernel image with memory > > > > > > > > set > > > > > > > > to > > > > > > > > 2G > > > > > > > > either: > > > > > > > > $ qemu-system-riscv32 -nographic -M virt -m 2G -smp 4 - > > > > > > > > kernel > > > > > > > > arch/riscv/boot/Image > > > > > > > > > > > > > > > > > > > > > > Hi Bin, > > > > > > > As mentioned in the email on the linux mailing list, this > > > > > > > patch > > > > > > > only > > > > > > > solves 2GB problem. sifive_u problem is solved by > > > > > > > Alistair's > > > > > > > patch[1]. > > > > > > > > > > > > > > He is planning to send the PR soon. The issue with sifive_u > > > > > > > boot > > > > > > > was it > > > > > > > was failing the 32 bit test earlier resulting a 2MB aligned > > > > > > > address > > > > > > > instead of 4MB. > > > > > > > > > > > > Ah, I see. However my testing shows that virt with 2G still > > > > > > does > > > > > > not > > > > > > boot with this patch. > > > > > > > > > > > > > > > > Strange. I verified again with following combination with -bios > > > > > and > > > > > without bios parameter. > > > > > > > > > > 1. virt 32/64 with 1GB/2GB memory > > > > > 2. sifive_u 32/64 bit with 1GB/2GB memory (Alistair's patch > > > > > included) > > > > > > > > > > Can you share the boot log along with the head commit of Qemu > > > > > and > > > > > commandline ? I am using 5.10 kernel with my kernel fix. > > > > > > > > > > > > > I was using Alistair's QEMU repo for testing and 5.10 kernel with > > > > your > > > > kernel fix: > > > > > > > > $ git checkout -b testing pull-riscv-to-apply-20201217-1 > > > > $ apply this patch > > > > $ mkdir build;cd build;../configure > > > > --target-list=riscv64-softmmu,riscv32-softmmu;make -j > > > > > > > > $ ./qemu-system-riscv32 -nographic -M virt -m 2G -smp 4 -kernel > > > > ~/work/git/linux/arch/riscv/boot/Image > > > > > > > > OpenSBI v0.8 > > > >_ _ > > > > / __ \ / | _ \_ _| > > > > | | | |_ __ ___ _ __ | (___ | |_) || | > > > > | | | | '_ \ / _ \ '_ \ \___ \| _ < | | > > > > | |__| | |_) | __/ | | |) | |_) || |_ > > > > \/| .__/ \___|_| |_|_/|/_| > > > > | | > > > > |_| > > > > > > > > Platform Name : riscv-virtio,qemu > > > > Platform Features : timer,mfdeleg > > > > Platform HART Count : 4 > > > > Boot HART ID: 3 > > > > Boot HART ISA : rv32imafdcsu > > > > BOOT HART Features : pmp,scounteren,mcounteren,time > > > > BOOT HART PMP Count : 16 > > > > Firmware Base : 0x8000 > > > > Firmware Size : 104 KB > > > > Runtime SBI Version : 0.2 > > > > >
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
On Tue, 2020-12-22 at 13:35 +0800, Bin Meng wrote: > Hi Atish, > > On Sat, Dec 19, 2020 at 3:46 AM Atish Patra > wrote: > > > > On Fri, 2020-12-18 at 16:42 +0800, Bin Meng wrote: > > > Hi Atish, > > > > > > On Fri, Dec 18, 2020 at 4:00 PM Atish Patra > > > wrote: > > > > > > > > On Fri, 2020-12-18 at 15:33 +0800, Bin Meng wrote: > > > > > Hi Atish, > > > > > > > > > > On Fri, Dec 18, 2020 at 3:27 PM Atish Patra < > > > > > atish.pa...@wdc.com> > > > > > wrote: > > > > > > > > > > > > On Fri, 2020-12-18 at 15:21 +0800, Bin Meng wrote: > > > > > > > Hi Atish, > > > > > > > > > > > > > > On Fri, Dec 18, 2020 at 5:48 AM Atish Patra > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > Currently, we place the DTB at 2MB from 4GB or end of > > > > > > > > DRAM > > > > > > > > which > > > > > > > > ever is > > > > > > > > lesser. However, Linux kernel can address only 1GB of > > > > > > > > memory > > > > > > > > for > > > > > > > > RV32. > > > > > > > > Thus, it can not map anything beyond 3GB (assuming 2GB > > > > > > > > is > > > > > > > > the > > > > > > > > starting address). > > > > > > > > As a result, it can not process DT and panic if opensbi > > > > > > > > dynamic > > > > > > > > firmware > > > > > > > > is used. > > > > > > > > > > > > > > > > Fix this by placing the DTB at 2MB from 3GB or end of > > > > > > > > DRAM > > > > > > > > whichever is lower. > > > > > > > > > > > > > > > > Signed-off-by: Atish Patra > > > > > > > > --- > > > > > > > > hw/riscv/boot.c | 4 ++-- > > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > > > > > > > With this patch, 32-bit sifive_u still does not boot > > > > > > > kernel > > > > > > > with > > > > > > > the > > > > > > > following patch applied on 5.10: > > > > > > > > > > > > > > https://patchwork.kernel.org/project/linux-riscv/patch/20201217074855.1948743-1-atish.pa...@wdc.com/ > > > > > > > > > > > > > > Command I used: > > > > > > > $ qemu-system-riscv32 -nographic -M sifive_u -m 1G -smp 5 > > > > > > > - > > > > > > > kernel > > > > > > > arch/riscv/boot/Image > > > > > > > > > > > > > > 32-bit virt cannot boot the same kernel image with memory > > > > > > > set > > > > > > > to > > > > > > > 2G > > > > > > > either: > > > > > > > $ qemu-system-riscv32 -nographic -M virt -m 2G -smp 4 - > > > > > > > kernel > > > > > > > arch/riscv/boot/Image > > > > > > > > > > > > > > > > > > > Hi Bin, > > > > > > As mentioned in the email on the linux mailing list, this > > > > > > patch > > > > > > only > > > > > > solves 2GB problem. sifive_u problem is solved by > > > > > > Alistair's > > > > > > patch[1]. > > > > > > > > > > > > He is planning to send the PR soon. The issue with sifive_u > > > > > > boot > > > > > > was it > > > > > > was failing the 32 bit test earlier resulting a 2MB aligned > > > > > > address > > > > > > instead of 4MB. > > > > > > > > > > Ah, I see. However my testing shows that virt with 2G still > > > > > does > > > > > not > > > > > boot with this patch. > > > > > > > > > > > > > Strange. I verified again with following combination with -bios > > > > and > > > > without bios parameter. > > > > > > > > 1. virt 32/64 with 1GB/2GB memory > > > > 2. sifive_u 32/64 bit with 1GB/2GB memory (Alistair's patch > > > > included) > > > > > > > > Can you share the boot log along with the head commit of Qemu > > > > and > > > > commandline ? I am using 5.10 kernel with my kernel fix. > > > > > > > > > > I was using Alistair's QEMU repo for testing and 5.10 kernel with > > > your > > > kernel fix: > > > > > > $ git checkout -b testing pull-riscv-to-apply-20201217-1 > > > $ apply this patch > > > $ mkdir build;cd build;../configure > > > --target-list=riscv64-softmmu,riscv32-softmmu;make -j > > > > > > $ ./qemu-system-riscv32 -nographic -M virt -m 2G -smp 4 -kernel > > > ~/work/git/linux/arch/riscv/boot/Image > > > > > > OpenSBI v0.8 > > > _ _ > > > / __ \ / | _ \_ _| > > > | | | |_ __ ___ _ __ | (___ | |_) || | > > > | | | | '_ \ / _ \ '_ \ \___ \| _ < | | > > > | |__| | |_) | __/ | | |) | |_) || |_ > > > \/| .__/ \___|_| |_|_/|/_| > > > | | > > > |_| > > > > > > Platform Name : riscv-virtio,qemu > > > Platform Features : timer,mfdeleg > > > Platform HART Count : 4 > > > Boot HART ID : 3 > > > Boot HART ISA : rv32imafdcsu > > > BOOT HART Features : pmp,scounteren,mcounteren,time > > > BOOT HART PMP Count : 16 > > > Firmware Base : 0x8000 > > > Firmware Size : 104 KB > > > Runtime SBI Version : 0.2 > > > > > > MIDELEG : 0x0222 > > > MEDELEG : 0xb109 > > > PMP0 : 0x8000-0x8001 (A) > > > PMP1 : 0x-0x (A,R,W,X) > > > > > > > > > $ ./qemu-system-riscv32 -nographic -M sifive_u -m 2G -smp 5 - > > > kernel > > > ~/work/git/linux/arch/riscv/boot/Image > > > > > > OpenSBI v0.8 > > >
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
Hi Atish, On Sat, Dec 19, 2020 at 3:46 AM Atish Patra wrote: > > On Fri, 2020-12-18 at 16:42 +0800, Bin Meng wrote: > > Hi Atish, > > > > On Fri, Dec 18, 2020 at 4:00 PM Atish Patra > > wrote: > > > > > > On Fri, 2020-12-18 at 15:33 +0800, Bin Meng wrote: > > > > Hi Atish, > > > > > > > > On Fri, Dec 18, 2020 at 3:27 PM Atish Patra > > > > wrote: > > > > > > > > > > On Fri, 2020-12-18 at 15:21 +0800, Bin Meng wrote: > > > > > > Hi Atish, > > > > > > > > > > > > On Fri, Dec 18, 2020 at 5:48 AM Atish Patra > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > Currently, we place the DTB at 2MB from 4GB or end of DRAM > > > > > > > which > > > > > > > ever is > > > > > > > lesser. However, Linux kernel can address only 1GB of > > > > > > > memory > > > > > > > for > > > > > > > RV32. > > > > > > > Thus, it can not map anything beyond 3GB (assuming 2GB is > > > > > > > the > > > > > > > starting address). > > > > > > > As a result, it can not process DT and panic if opensbi > > > > > > > dynamic > > > > > > > firmware > > > > > > > is used. > > > > > > > > > > > > > > Fix this by placing the DTB at 2MB from 3GB or end of DRAM > > > > > > > whichever is lower. > > > > > > > > > > > > > > Signed-off-by: Atish Patra > > > > > > > --- > > > > > > > hw/riscv/boot.c | 4 ++-- > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > > > > With this patch, 32-bit sifive_u still does not boot kernel > > > > > > with > > > > > > the > > > > > > following patch applied on 5.10: > > > > > > https://patchwork.kernel.org/project/linux-riscv/patch/20201217074855.1948743-1-atish.pa...@wdc.com/ > > > > > > > > > > > > Command I used: > > > > > > $ qemu-system-riscv32 -nographic -M sifive_u -m 1G -smp 5 - > > > > > > kernel > > > > > > arch/riscv/boot/Image > > > > > > > > > > > > 32-bit virt cannot boot the same kernel image with memory set > > > > > > to > > > > > > 2G > > > > > > either: > > > > > > $ qemu-system-riscv32 -nographic -M virt -m 2G -smp 4 -kernel > > > > > > arch/riscv/boot/Image > > > > > > > > > > > > > > > > Hi Bin, > > > > > As mentioned in the email on the linux mailing list, this patch > > > > > only > > > > > solves 2GB problem. sifive_u problem is solved by Alistair's > > > > > patch[1]. > > > > > > > > > > He is planning to send the PR soon. The issue with sifive_u > > > > > boot > > > > > was it > > > > > was failing the 32 bit test earlier resulting a 2MB aligned > > > > > address > > > > > instead of 4MB. > > > > > > > > Ah, I see. However my testing shows that virt with 2G still does > > > > not > > > > boot with this patch. > > > > > > > > > > Strange. I verified again with following combination with -bios and > > > without bios parameter. > > > > > > 1. virt 32/64 with 1GB/2GB memory > > > 2. sifive_u 32/64 bit with 1GB/2GB memory (Alistair's patch > > > included) > > > > > > Can you share the boot log along with the head commit of Qemu and > > > commandline ? I am using 5.10 kernel with my kernel fix. > > > > > > > I was using Alistair's QEMU repo for testing and 5.10 kernel with > > your > > kernel fix: > > > > $ git checkout -b testing pull-riscv-to-apply-20201217-1 > > $ apply this patch > > $ mkdir build;cd build;../configure > > --target-list=riscv64-softmmu,riscv32-softmmu;make -j > > > > $ ./qemu-system-riscv32 -nographic -M virt -m 2G -smp 4 -kernel > > ~/work/git/linux/arch/riscv/boot/Image > > > > OpenSBI v0.8 > >_ _ > > / __ \ / | _ \_ _| > > | | | |_ __ ___ _ __ | (___ | |_) || | > > | | | | '_ \ / _ \ '_ \ \___ \| _ < | | > > | |__| | |_) | __/ | | |) | |_) || |_ > > \/| .__/ \___|_| |_|_/|/_| > > | | > > |_| > > > > Platform Name : riscv-virtio,qemu > > Platform Features : timer,mfdeleg > > Platform HART Count : 4 > > Boot HART ID: 3 > > Boot HART ISA : rv32imafdcsu > > BOOT HART Features : pmp,scounteren,mcounteren,time > > BOOT HART PMP Count : 16 > > Firmware Base : 0x8000 > > Firmware Size : 104 KB > > Runtime SBI Version : 0.2 > > > > MIDELEG : 0x0222 > > MEDELEG : 0xb109 > > PMP0: 0x8000-0x8001 (A) > > PMP1: 0x-0x (A,R,W,X) > > > > > > $ ./qemu-system-riscv32 -nographic -M sifive_u -m 2G -smp 5 -kernel > > ~/work/git/linux/arch/riscv/boot/Image > > > > OpenSBI v0.8 > >_ _ > > / __ \ / | _ \_ _| > > | | | |_ __ ___ _ __ | (___ | |_) || | > > | | | | '_ \ / _ \ '_ \ \___ \| _ < | | > > | |__| | |_) | __/ | | |) | |_) || |_ > > \/| .__/ \___|_| |_|_/|/_| > > | | > > |_| > > > > Platform Name : SiFive HiFive Unleashed A00 > > Platform Features : timer,mfdeleg > > Platform HART Count : 5 > > Boot HART ID: 4 > > Boot HART ISA : rv32imafdcsu > > BOOT HART Features : pmp,scounteren,mcounteren > > BOOT HART PMP
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
On Fri, 2020-12-18 at 16:42 +0800, Bin Meng wrote: > Hi Atish, > > On Fri, Dec 18, 2020 at 4:00 PM Atish Patra > wrote: > > > > On Fri, 2020-12-18 at 15:33 +0800, Bin Meng wrote: > > > Hi Atish, > > > > > > On Fri, Dec 18, 2020 at 3:27 PM Atish Patra > > > wrote: > > > > > > > > On Fri, 2020-12-18 at 15:21 +0800, Bin Meng wrote: > > > > > Hi Atish, > > > > > > > > > > On Fri, Dec 18, 2020 at 5:48 AM Atish Patra > > > > > > > > > > wrote: > > > > > > > > > > > > Currently, we place the DTB at 2MB from 4GB or end of DRAM > > > > > > which > > > > > > ever is > > > > > > lesser. However, Linux kernel can address only 1GB of > > > > > > memory > > > > > > for > > > > > > RV32. > > > > > > Thus, it can not map anything beyond 3GB (assuming 2GB is > > > > > > the > > > > > > starting address). > > > > > > As a result, it can not process DT and panic if opensbi > > > > > > dynamic > > > > > > firmware > > > > > > is used. > > > > > > > > > > > > Fix this by placing the DTB at 2MB from 3GB or end of DRAM > > > > > > whichever is lower. > > > > > > > > > > > > Signed-off-by: Atish Patra > > > > > > --- > > > > > > hw/riscv/boot.c | 4 ++-- > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > With this patch, 32-bit sifive_u still does not boot kernel > > > > > with > > > > > the > > > > > following patch applied on 5.10: > > > > > https://patchwork.kernel.org/project/linux-riscv/patch/20201217074855.1948743-1-atish.pa...@wdc.com/ > > > > > > > > > > Command I used: > > > > > $ qemu-system-riscv32 -nographic -M sifive_u -m 1G -smp 5 - > > > > > kernel > > > > > arch/riscv/boot/Image > > > > > > > > > > 32-bit virt cannot boot the same kernel image with memory set > > > > > to > > > > > 2G > > > > > either: > > > > > $ qemu-system-riscv32 -nographic -M virt -m 2G -smp 4 -kernel > > > > > arch/riscv/boot/Image > > > > > > > > > > > > > Hi Bin, > > > > As mentioned in the email on the linux mailing list, this patch > > > > only > > > > solves 2GB problem. sifive_u problem is solved by Alistair's > > > > patch[1]. > > > > > > > > He is planning to send the PR soon. The issue with sifive_u > > > > boot > > > > was it > > > > was failing the 32 bit test earlier resulting a 2MB aligned > > > > address > > > > instead of 4MB. > > > > > > Ah, I see. However my testing shows that virt with 2G still does > > > not > > > boot with this patch. > > > > > > > Strange. I verified again with following combination with -bios and > > without bios parameter. > > > > 1. virt 32/64 with 1GB/2GB memory > > 2. sifive_u 32/64 bit with 1GB/2GB memory (Alistair's patch > > included) > > > > Can you share the boot log along with the head commit of Qemu and > > commandline ? I am using 5.10 kernel with my kernel fix. > > > > I was using Alistair's QEMU repo for testing and 5.10 kernel with > your > kernel fix: > > $ git checkout -b testing pull-riscv-to-apply-20201217-1 > $ apply this patch > $ mkdir build;cd build;../configure > --target-list=riscv64-softmmu,riscv32-softmmu;make -j > > $ ./qemu-system-riscv32 -nographic -M virt -m 2G -smp 4 -kernel > ~/work/git/linux/arch/riscv/boot/Image > > OpenSBI v0.8 > _ _ > / __ \ / | _ \_ _| > | | | |_ __ ___ _ __ | (___ | |_) || | > | | | | '_ \ / _ \ '_ \ \___ \| _ < | | > | |__| | |_) | __/ | | |) | |_) || |_ > \/| .__/ \___|_| |_|_/|/_| > | | > |_| > > Platform Name : riscv-virtio,qemu > Platform Features : timer,mfdeleg > Platform HART Count : 4 > Boot HART ID : 3 > Boot HART ISA : rv32imafdcsu > BOOT HART Features : pmp,scounteren,mcounteren,time > BOOT HART PMP Count : 16 > Firmware Base : 0x8000 > Firmware Size : 104 KB > Runtime SBI Version : 0.2 > > MIDELEG : 0x0222 > MEDELEG : 0xb109 > PMP0 : 0x8000-0x8001 (A) > PMP1 : 0x-0x (A,R,W,X) > > > $ ./qemu-system-riscv32 -nographic -M sifive_u -m 2G -smp 5 -kernel > ~/work/git/linux/arch/riscv/boot/Image > > OpenSBI v0.8 > _ _ > / __ \ / | _ \_ _| > | | | |_ __ ___ _ __ | (___ | |_) || | > | | | | '_ \ / _ \ '_ \ \___ \| _ < | | > | |__| | |_) | __/ | | |) | |_) || |_ > \/| .__/ \___|_| |_|_/|/_| > | | > |_| > > Platform Name : SiFive HiFive Unleashed A00 > Platform Features : timer,mfdeleg > Platform HART Count : 5 > Boot HART ID : 4 > Boot HART ISA : rv32imafdcsu > BOOT HART Features : pmp,scounteren,mcounteren > BOOT HART PMP Count : 16 > Firmware Base : 0x8000 > Firmware Size : 112 KB > Runtime SBI Version : 0.2 > > MIDELEG : 0x0222 > MEDELEG : 0xb109 > PMP0 : 0x8000-0x8001 (A) > PMP1 : 0x-0x (A,R,W,X) > > > The following is sifive_u with 1G: > > $ ./qemu-system-riscv32 -nographic -M sifive_u -m
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
Hi Atish, On Fri, Dec 18, 2020 at 4:00 PM Atish Patra wrote: > > On Fri, 2020-12-18 at 15:33 +0800, Bin Meng wrote: > > Hi Atish, > > > > On Fri, Dec 18, 2020 at 3:27 PM Atish Patra > > wrote: > > > > > > On Fri, 2020-12-18 at 15:21 +0800, Bin Meng wrote: > > > > Hi Atish, > > > > > > > > On Fri, Dec 18, 2020 at 5:48 AM Atish Patra > > > > wrote: > > > > > > > > > > Currently, we place the DTB at 2MB from 4GB or end of DRAM > > > > > which > > > > > ever is > > > > > lesser. However, Linux kernel can address only 1GB of memory > > > > > for > > > > > RV32. > > > > > Thus, it can not map anything beyond 3GB (assuming 2GB is the > > > > > starting address). > > > > > As a result, it can not process DT and panic if opensbi dynamic > > > > > firmware > > > > > is used. > > > > > > > > > > Fix this by placing the DTB at 2MB from 3GB or end of DRAM > > > > > whichever is lower. > > > > > > > > > > Signed-off-by: Atish Patra > > > > > --- > > > > > hw/riscv/boot.c | 4 ++-- > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > > > > With this patch, 32-bit sifive_u still does not boot kernel with > > > > the > > > > following patch applied on 5.10: > > > > https://patchwork.kernel.org/project/linux-riscv/patch/20201217074855.1948743-1-atish.pa...@wdc.com/ > > > > > > > > Command I used: > > > > $ qemu-system-riscv32 -nographic -M sifive_u -m 1G -smp 5 -kernel > > > > arch/riscv/boot/Image > > > > > > > > 32-bit virt cannot boot the same kernel image with memory set to > > > > 2G > > > > either: > > > > $ qemu-system-riscv32 -nographic -M virt -m 2G -smp 4 -kernel > > > > arch/riscv/boot/Image > > > > > > > > > > Hi Bin, > > > As mentioned in the email on the linux mailing list, this patch > > > only > > > solves 2GB problem. sifive_u problem is solved by Alistair's > > > patch[1]. > > > > > > He is planning to send the PR soon. The issue with sifive_u boot > > > was it > > > was failing the 32 bit test earlier resulting a 2MB aligned address > > > instead of 4MB. > > > > Ah, I see. However my testing shows that virt with 2G still does not > > boot with this patch. > > > > Strange. I verified again with following combination with -bios and > without bios parameter. > > 1. virt 32/64 with 1GB/2GB memory > 2. sifive_u 32/64 bit with 1GB/2GB memory (Alistair's patch included) > > Can you share the boot log along with the head commit of Qemu and > commandline ? I am using 5.10 kernel with my kernel fix. > I was using Alistair's QEMU repo for testing and 5.10 kernel with your kernel fix: $ git checkout -b testing pull-riscv-to-apply-20201217-1 $ apply this patch $ mkdir build;cd build;../configure --target-list=riscv64-softmmu,riscv32-softmmu;make -j $ ./qemu-system-riscv32 -nographic -M virt -m 2G -smp 4 -kernel ~/work/git/linux/arch/riscv/boot/Image OpenSBI v0.8 _ _ / __ \ / | _ \_ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ \___ \| _ < | | | |__| | |_) | __/ | | |) | |_) || |_ \/| .__/ \___|_| |_|_/|/_| | | |_| Platform Name : riscv-virtio,qemu Platform Features : timer,mfdeleg Platform HART Count : 4 Boot HART ID: 3 Boot HART ISA : rv32imafdcsu BOOT HART Features : pmp,scounteren,mcounteren,time BOOT HART PMP Count : 16 Firmware Base : 0x8000 Firmware Size : 104 KB Runtime SBI Version : 0.2 MIDELEG : 0x0222 MEDELEG : 0xb109 PMP0: 0x8000-0x8001 (A) PMP1: 0x-0x (A,R,W,X) $ ./qemu-system-riscv32 -nographic -M sifive_u -m 2G -smp 5 -kernel ~/work/git/linux/arch/riscv/boot/Image OpenSBI v0.8 _ _ / __ \ / | _ \_ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ \___ \| _ < | | | |__| | |_) | __/ | | |) | |_) || |_ \/| .__/ \___|_| |_|_/|/_| | | |_| Platform Name : SiFive HiFive Unleashed A00 Platform Features : timer,mfdeleg Platform HART Count : 5 Boot HART ID: 4 Boot HART ISA : rv32imafdcsu BOOT HART Features : pmp,scounteren,mcounteren BOOT HART PMP Count : 16 Firmware Base : 0x8000 Firmware Size : 112 KB Runtime SBI Version : 0.2 MIDELEG : 0x0222 MEDELEG : 0xb109 PMP0: 0x8000-0x8001 (A) PMP1: 0x-0x (A,R,W,X) The following is sifive_u with 1G: $ ./qemu-system-riscv32 -nographic -M sifive_u -m 1G -smp 5 -kernel ~/work/git/linux/arch/riscv/boot/Image OpenSBI v0.8 _ _ / __ \ / | _ \_ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ \___ \| _ < | | | |__| | |_) | __/ | | |) | |_) || |_ \/| .__/ \___|_| |_|_/|/_| | | |_| Platform Name : SiFive HiFive Unleashed A00 Platform Features : timer,mfdeleg Platform HART Count : 5 Boot
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
On Fri, 2020-12-18 at 15:33 +0800, Bin Meng wrote: > Hi Atish, > > On Fri, Dec 18, 2020 at 3:27 PM Atish Patra > wrote: > > > > On Fri, 2020-12-18 at 15:21 +0800, Bin Meng wrote: > > > Hi Atish, > > > > > > On Fri, Dec 18, 2020 at 5:48 AM Atish Patra > > > wrote: > > > > > > > > Currently, we place the DTB at 2MB from 4GB or end of DRAM > > > > which > > > > ever is > > > > lesser. However, Linux kernel can address only 1GB of memory > > > > for > > > > RV32. > > > > Thus, it can not map anything beyond 3GB (assuming 2GB is the > > > > starting address). > > > > As a result, it can not process DT and panic if opensbi dynamic > > > > firmware > > > > is used. > > > > > > > > Fix this by placing the DTB at 2MB from 3GB or end of DRAM > > > > whichever is lower. > > > > > > > > Signed-off-by: Atish Patra > > > > --- > > > > hw/riscv/boot.c | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > With this patch, 32-bit sifive_u still does not boot kernel with > > > the > > > following patch applied on 5.10: > > > https://patchwork.kernel.org/project/linux-riscv/patch/20201217074855.1948743-1-atish.pa...@wdc.com/ > > > > > > Command I used: > > > $ qemu-system-riscv32 -nographic -M sifive_u -m 1G -smp 5 -kernel > > > arch/riscv/boot/Image > > > > > > 32-bit virt cannot boot the same kernel image with memory set to > > > 2G > > > either: > > > $ qemu-system-riscv32 -nographic -M virt -m 2G -smp 4 -kernel > > > arch/riscv/boot/Image > > > > > > > Hi Bin, > > As mentioned in the email on the linux mailing list, this patch > > only > > solves 2GB problem. sifive_u problem is solved by Alistair's > > patch[1]. > > > > He is planning to send the PR soon. The issue with sifive_u boot > > was it > > was failing the 32 bit test earlier resulting a 2MB aligned address > > instead of 4MB. > > Ah, I see. However my testing shows that virt with 2G still does not > boot with this patch. > Strange. I verified again with following combination with -bios and without bios parameter. 1. virt 32/64 with 1GB/2GB memory 2. sifive_u 32/64 bit with 1GB/2GB memory (Alistair's patch included) Can you share the boot log along with the head commit of Qemu and commandline ? I am using 5.10 kernel with my kernel fix. > > > > [1] > > https://www.mail-archive.com/qemu-devel@nongnu.org/msg767886.html > > > > Regards, > Bin -- Regards, Atish
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
Hi Atish, On Fri, Dec 18, 2020 at 3:27 PM Atish Patra wrote: > > On Fri, 2020-12-18 at 15:21 +0800, Bin Meng wrote: > > Hi Atish, > > > > On Fri, Dec 18, 2020 at 5:48 AM Atish Patra > > wrote: > > > > > > Currently, we place the DTB at 2MB from 4GB or end of DRAM which > > > ever is > > > lesser. However, Linux kernel can address only 1GB of memory for > > > RV32. > > > Thus, it can not map anything beyond 3GB (assuming 2GB is the > > > starting address). > > > As a result, it can not process DT and panic if opensbi dynamic > > > firmware > > > is used. > > > > > > Fix this by placing the DTB at 2MB from 3GB or end of DRAM > > > whichever is lower. > > > > > > Signed-off-by: Atish Patra > > > --- > > > hw/riscv/boot.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > With this patch, 32-bit sifive_u still does not boot kernel with the > > following patch applied on 5.10: > > https://patchwork.kernel.org/project/linux-riscv/patch/20201217074855.1948743-1-atish.pa...@wdc.com/ > > > > Command I used: > > $ qemu-system-riscv32 -nographic -M sifive_u -m 1G -smp 5 -kernel > > arch/riscv/boot/Image > > > > 32-bit virt cannot boot the same kernel image with memory set to 2G > > either: > > $ qemu-system-riscv32 -nographic -M virt -m 2G -smp 4 -kernel > > arch/riscv/boot/Image > > > > Hi Bin, > As mentioned in the email on the linux mailing list, this patch only > solves 2GB problem. sifive_u problem is solved by Alistair's patch[1]. > > He is planning to send the PR soon. The issue with sifive_u boot was it > was failing the 32 bit test earlier resulting a 2MB aligned address > instead of 4MB. Ah, I see. However my testing shows that virt with 2G still does not boot with this patch. > > [1] https://www.mail-archive.com/qemu-devel@nongnu.org/msg767886.html > Regards, Bin
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
On Fri, 2020-12-18 at 15:21 +0800, Bin Meng wrote: > Hi Atish, > > On Fri, Dec 18, 2020 at 5:48 AM Atish Patra > wrote: > > > > Currently, we place the DTB at 2MB from 4GB or end of DRAM which > > ever is > > lesser. However, Linux kernel can address only 1GB of memory for > > RV32. > > Thus, it can not map anything beyond 3GB (assuming 2GB is the > > starting address). > > As a result, it can not process DT and panic if opensbi dynamic > > firmware > > is used. > > > > Fix this by placing the DTB at 2MB from 3GB or end of DRAM > > whichever is lower. > > > > Signed-off-by: Atish Patra > > --- > > hw/riscv/boot.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > With this patch, 32-bit sifive_u still does not boot kernel with the > following patch applied on 5.10: > https://patchwork.kernel.org/project/linux-riscv/patch/20201217074855.1948743-1-atish.pa...@wdc.com/ > > Command I used: > $ qemu-system-riscv32 -nographic -M sifive_u -m 1G -smp 5 -kernel > arch/riscv/boot/Image > > 32-bit virt cannot boot the same kernel image with memory set to 2G > either: > $ qemu-system-riscv32 -nographic -M virt -m 2G -smp 4 -kernel > arch/riscv/boot/Image > Hi Bin, As mentioned in the email on the linux mailing list, this patch only solves 2GB problem. sifive_u problem is solved by Alistair's patch[1]. He is planning to send the PR soon. The issue with sifive_u boot was it was failing the 32 bit test earlier resulting a 2MB aligned address instead of 4MB. [1] https://www.mail-archive.com/qemu-devel@nongnu.org/msg767886.html > Regards, > Bin -- Regards, Atish
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
Hi Atish, On Fri, Dec 18, 2020 at 5:48 AM Atish Patra wrote: > > Currently, we place the DTB at 2MB from 4GB or end of DRAM which ever is > lesser. However, Linux kernel can address only 1GB of memory for RV32. > Thus, it can not map anything beyond 3GB (assuming 2GB is the starting > address). > As a result, it can not process DT and panic if opensbi dynamic firmware > is used. > > Fix this by placing the DTB at 2MB from 3GB or end of DRAM whichever is lower. > > Signed-off-by: Atish Patra > --- > hw/riscv/boot.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > With this patch, 32-bit sifive_u still does not boot kernel with the following patch applied on 5.10: https://patchwork.kernel.org/project/linux-riscv/patch/20201217074855.1948743-1-atish.pa...@wdc.com/ Command I used: $ qemu-system-riscv32 -nographic -M sifive_u -m 1G -smp 5 -kernel arch/riscv/boot/Image 32-bit virt cannot boot the same kernel image with memory set to 2G either: $ qemu-system-riscv32 -nographic -M virt -m 2G -smp 4 -kernel arch/riscv/boot/Image Regards, Bin
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
On Thu, 17 Dec 2020 14:35:10 PST (-0800), Atish Patra wrote: On Thu, 2020-12-17 at 14:31 -0800, Palmer Dabbelt wrote: On Thu, 17 Dec 2020 13:48:26 PST (-0800), Atish Patra wrote: > Currently, we place the DTB at 2MB from 4GB or end of DRAM which > ever is > lesser. However, Linux kernel can address only 1GB of memory for > RV32. > Thus, it can not map anything beyond 3GB (assuming 2GB is the > starting address). > As a result, it can not process DT and panic if opensbi dynamic > firmware > is used. > > Fix this by placing the DTB at 2MB from 3GB or end of DRAM > whichever is lower. > > Signed-off-by: Atish Patra > --- > hw/riscv/boot.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c > index d62f3dc7581e..9e77b22e4d56 100644 > --- a/hw/riscv/boot.c > +++ b/hw/riscv/boot.c > @@ -203,9 +203,9 @@ uint32_t riscv_load_fdt(hwaddr dram_base, > uint64_t mem_size, void *fdt) > * We should put fdt as far as possible to avoid kernel/initrd > overwriting > * its content. But it should be addressable by 32 bit system > as well. > * Thus, put it at an aligned address that less than fdt size > from end of > - * dram or 4GB whichever is lesser. > + * dram or 3GB whichever is lesser. > */ > - temp = MIN(dram_end, 4096 * MiB); > + temp = MIN(dram_end, 3072 * MiB); > fdt_addr = QEMU_ALIGN_DOWN(temp - fdtsize, 2 * MiB); > > fdt_pack(fdt); Presumably this was the cause of that 32-bit boot issue? This fixes the fw_dynamic case if you use more than 1GB of memory. The other issue was with the kernel. I sent the kernel fix yesterday. https://patchwork.kernel.org/project/linux-riscv/patch/20201217074855.1948743-1-atish.pa...@wdc.com/ Can you include the kernel fix in your next PR ? Not the one I'm writing up right now, as I want to get the new stuff up earlier in the merge window this time around. I'm planning on sending fixes during the merge window, though, as we have a few. We have tomorrow off, so I should be able to get through all the email and send it either over the weekend or early next week.
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
On Thu, 2020-12-17 at 14:31 -0800, Palmer Dabbelt wrote: > On Thu, 17 Dec 2020 13:48:26 PST (-0800), Atish Patra wrote: > > Currently, we place the DTB at 2MB from 4GB or end of DRAM which > > ever is > > lesser. However, Linux kernel can address only 1GB of memory for > > RV32. > > Thus, it can not map anything beyond 3GB (assuming 2GB is the > > starting address). > > As a result, it can not process DT and panic if opensbi dynamic > > firmware > > is used. > > > > Fix this by placing the DTB at 2MB from 3GB or end of DRAM > > whichever is lower. > > > > Signed-off-by: Atish Patra > > --- > > hw/riscv/boot.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c > > index d62f3dc7581e..9e77b22e4d56 100644 > > --- a/hw/riscv/boot.c > > +++ b/hw/riscv/boot.c > > @@ -203,9 +203,9 @@ uint32_t riscv_load_fdt(hwaddr dram_base, > > uint64_t mem_size, void *fdt) > > * We should put fdt as far as possible to avoid kernel/initrd > > overwriting > > * its content. But it should be addressable by 32 bit system > > as well. > > * Thus, put it at an aligned address that less than fdt size > > from end of > > - * dram or 4GB whichever is lesser. > > + * dram or 3GB whichever is lesser. > > */ > > - temp = MIN(dram_end, 4096 * MiB); > > + temp = MIN(dram_end, 3072 * MiB); > > fdt_addr = QEMU_ALIGN_DOWN(temp - fdtsize, 2 * MiB); > > > > fdt_pack(fdt); > > Presumably this was the cause of that 32-bit boot issue? This fixes the fw_dynamic case if you use more than 1GB of memory. The other issue was with the kernel. I sent the kernel fix yesterday. https://patchwork.kernel.org/project/linux-riscv/patch/20201217074855.1948743-1-atish.pa...@wdc.com/ Can you include the kernel fix in your next PR ? -- Regards, Atish
Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
On Thu, 17 Dec 2020 13:48:26 PST (-0800), Atish Patra wrote: Currently, we place the DTB at 2MB from 4GB or end of DRAM which ever is lesser. However, Linux kernel can address only 1GB of memory for RV32. Thus, it can not map anything beyond 3GB (assuming 2GB is the starting address). As a result, it can not process DT and panic if opensbi dynamic firmware is used. Fix this by placing the DTB at 2MB from 3GB or end of DRAM whichever is lower. Signed-off-by: Atish Patra --- hw/riscv/boot.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c index d62f3dc7581e..9e77b22e4d56 100644 --- a/hw/riscv/boot.c +++ b/hw/riscv/boot.c @@ -203,9 +203,9 @@ uint32_t riscv_load_fdt(hwaddr dram_base, uint64_t mem_size, void *fdt) * We should put fdt as far as possible to avoid kernel/initrd overwriting * its content. But it should be addressable by 32 bit system as well. * Thus, put it at an aligned address that less than fdt size from end of - * dram or 4GB whichever is lesser. + * dram or 3GB whichever is lesser. */ -temp = MIN(dram_end, 4096 * MiB); +temp = MIN(dram_end, 3072 * MiB); fdt_addr = QEMU_ALIGN_DOWN(temp - fdtsize, 2 * MiB); fdt_pack(fdt); Presumably this was the cause of that 32-bit boot issue?
[PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
Currently, we place the DTB at 2MB from 4GB or end of DRAM which ever is lesser. However, Linux kernel can address only 1GB of memory for RV32. Thus, it can not map anything beyond 3GB (assuming 2GB is the starting address). As a result, it can not process DT and panic if opensbi dynamic firmware is used. Fix this by placing the DTB at 2MB from 3GB or end of DRAM whichever is lower. Signed-off-by: Atish Patra --- hw/riscv/boot.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c index d62f3dc7581e..9e77b22e4d56 100644 --- a/hw/riscv/boot.c +++ b/hw/riscv/boot.c @@ -203,9 +203,9 @@ uint32_t riscv_load_fdt(hwaddr dram_base, uint64_t mem_size, void *fdt) * We should put fdt as far as possible to avoid kernel/initrd overwriting * its content. But it should be addressable by 32 bit system as well. * Thus, put it at an aligned address that less than fdt size from end of - * dram or 4GB whichever is lesser. + * dram or 3GB whichever is lesser. */ -temp = MIN(dram_end, 4096 * MiB); +temp = MIN(dram_end, 3072 * MiB); fdt_addr = QEMU_ALIGN_DOWN(temp - fdtsize, 2 * MiB); fdt_pack(fdt); -- 2.25.1
