* [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2020-12-17 21:48 ` Atish Patra
0 siblings, 0 replies; 42+ messages in thread
From: Atish Patra @ 2020-12-17 21:48 UTC (permalink / raw)
To: qemu-devel, qemu-riscv
Cc: Sagar Karandikar, Bastian Koppelmann, Anup Patel, Atish Patra,
Alistair Francis, Palmer Dabbelt, Bin Meng
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 <atish.patra@wdc.com>
---
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
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2020-12-17 21:48 ` Atish Patra
0 siblings, 0 replies; 42+ messages in thread
From: Atish Patra @ 2020-12-17 21:48 UTC (permalink / raw)
To: qemu-devel, qemu-riscv
Cc: Atish Patra, Alistair Francis, Bastian Koppelmann,
Palmer Dabbelt, Sagar Karandikar, Anup Patel, Bin Meng
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 <atish.patra@wdc.com>
---
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
^ permalink raw reply related [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
2020-12-17 21:48 ` Atish Patra
@ 2020-12-17 22:31 ` Palmer Dabbelt
-1 siblings, 0 replies; 42+ messages in thread
From: Palmer Dabbelt @ 2020-12-17 22:31 UTC (permalink / raw)
To: Atish Patra
Cc: qemu-riscv, sagark, Bastian Koppelmann, Anup Patel, qemu-devel,
Atish Patra, Alistair Francis, bmeng.cn
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 <atish.patra@wdc.com>
> ---
> 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?
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2020-12-17 22:31 ` Palmer Dabbelt
0 siblings, 0 replies; 42+ messages in thread
From: Palmer Dabbelt @ 2020-12-17 22:31 UTC (permalink / raw)
To: Atish Patra
Cc: qemu-devel, qemu-riscv, Atish Patra, Alistair Francis,
Bastian Koppelmann, sagark, Anup Patel, bmeng.cn
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 <atish.patra@wdc.com>
> ---
> 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?
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
2020-12-17 22:31 ` Palmer Dabbelt
@ 2020-12-17 22:35 ` Atish Patra
-1 siblings, 0 replies; 42+ messages in thread
From: Atish Patra @ 2020-12-17 22:35 UTC (permalink / raw)
To: palmer
Cc: qemu-riscv, sagark, kbastian, Anup Patel, qemu-devel,
Alistair Francis, bmeng.cn
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 <atish.patra@wdc.com>
> > ---
> > 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.patra@wdc.com/
Can you include the kernel fix in your next PR ?
--
Regards,
Atish
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2020-12-17 22:35 ` Atish Patra
0 siblings, 0 replies; 42+ messages in thread
From: Atish Patra @ 2020-12-17 22:35 UTC (permalink / raw)
To: palmer
Cc: qemu-riscv, kbastian, Alistair Francis, sagark, qemu-devel,
Anup Patel, bmeng.cn
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 <atish.patra@wdc.com>
> > ---
> > 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.patra@wdc.com/
Can you include the kernel fix in your next PR ?
--
Regards,
Atish
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
2020-12-17 22:35 ` Atish Patra
@ 2020-12-17 22:39 ` Palmer Dabbelt
-1 siblings, 0 replies; 42+ messages in thread
From: Palmer Dabbelt @ 2020-12-17 22:39 UTC (permalink / raw)
To: Atish Patra
Cc: qemu-riscv, sagark, Bastian Koppelmann, Anup Patel, qemu-devel,
Alistair Francis, bmeng.cn
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 <atish.patra@wdc.com>
>> > ---
>> > 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.patra@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.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2020-12-17 22:39 ` Palmer Dabbelt
0 siblings, 0 replies; 42+ messages in thread
From: Palmer Dabbelt @ 2020-12-17 22:39 UTC (permalink / raw)
To: Atish Patra
Cc: qemu-riscv, Bastian Koppelmann, Alistair Francis, sagark,
qemu-devel, Anup Patel, bmeng.cn
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 <atish.patra@wdc.com>
>> > ---
>> > 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.patra@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.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
2020-12-17 21:48 ` Atish Patra
@ 2020-12-18 7:21 ` Bin Meng
-1 siblings, 0 replies; 42+ messages in thread
From: Bin Meng @ 2020-12-18 7:21 UTC (permalink / raw)
To: Atish Patra
Cc: open list:RISC-V, Sagar Karandikar, Bastian Koppelmann,
Anup Patel, qemu-devel@nongnu.org Developers, Alistair Francis,
Palmer Dabbelt
Hi Atish,
On Fri, Dec 18, 2020 at 5:48 AM Atish Patra <atish.patra@wdc.com> 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 <atish.patra@wdc.com>
> ---
> 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.patra@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
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2020-12-18 7:21 ` Bin Meng
0 siblings, 0 replies; 42+ messages in thread
From: Bin Meng @ 2020-12-18 7:21 UTC (permalink / raw)
To: Atish Patra
Cc: qemu-devel@nongnu.org Developers, open list:RISC-V,
Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, Anup Patel
Hi Atish,
On Fri, Dec 18, 2020 at 5:48 AM Atish Patra <atish.patra@wdc.com> 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 <atish.patra@wdc.com>
> ---
> 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.patra@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
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
2020-12-18 7:21 ` Bin Meng
@ 2020-12-18 7:27 ` Atish Patra
-1 siblings, 0 replies; 42+ messages in thread
From: Atish Patra @ 2020-12-18 7:27 UTC (permalink / raw)
To: bmeng.cn
Cc: qemu-riscv, sagark, kbastian, Anup Patel, qemu-devel,
Alistair Francis, palmer
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 <atish.patra@wdc.com>
> 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 <atish.patra@wdc.com>
> > ---
> > 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.patra@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
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2020-12-18 7:27 ` Atish Patra
0 siblings, 0 replies; 42+ messages in thread
From: Atish Patra @ 2020-12-18 7:27 UTC (permalink / raw)
To: bmeng.cn
Cc: Anup Patel, qemu-riscv, kbastian, Alistair Francis, palmer,
qemu-devel, sagark
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 <atish.patra@wdc.com>
> 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 <atish.patra@wdc.com>
> > ---
> > 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.patra@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
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
2020-12-18 7:27 ` Atish Patra
@ 2020-12-18 7:33 ` Bin Meng
-1 siblings, 0 replies; 42+ messages in thread
From: Bin Meng @ 2020-12-18 7:33 UTC (permalink / raw)
To: Atish Patra
Cc: qemu-riscv, sagark, kbastian, Anup Patel, qemu-devel,
Alistair Francis, palmer
Hi Atish,
On Fri, Dec 18, 2020 at 3:27 PM Atish Patra <Atish.Patra@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 <atish.patra@wdc.com>
> > 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 <atish.patra@wdc.com>
> > > ---
> > > 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.patra@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
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2020-12-18 7:33 ` Bin Meng
0 siblings, 0 replies; 42+ messages in thread
From: Bin Meng @ 2020-12-18 7:33 UTC (permalink / raw)
To: Atish Patra
Cc: Anup Patel, qemu-riscv, kbastian, Alistair Francis, palmer,
qemu-devel, sagark
Hi Atish,
On Fri, Dec 18, 2020 at 3:27 PM Atish Patra <Atish.Patra@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 <atish.patra@wdc.com>
> > 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 <atish.patra@wdc.com>
> > > ---
> > > 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.patra@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
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
2020-12-18 7:33 ` Bin Meng
@ 2020-12-18 8:00 ` Atish Patra
-1 siblings, 0 replies; 42+ messages in thread
From: Atish Patra @ 2020-12-18 8:00 UTC (permalink / raw)
To: bmeng.cn
Cc: qemu-riscv, sagark, kbastian, Anup Patel, qemu-devel,
Alistair Francis, palmer
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.Patra@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 <atish.patra@wdc.com>
> > > 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 <atish.patra@wdc.com>
> > > > ---
> > > > 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.patra@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
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2020-12-18 8:00 ` Atish Patra
0 siblings, 0 replies; 42+ messages in thread
From: Atish Patra @ 2020-12-18 8:00 UTC (permalink / raw)
To: bmeng.cn
Cc: sagark, qemu-riscv, kbastian, Alistair Francis, palmer,
Anup Patel, qemu-devel
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.Patra@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 <atish.patra@wdc.com>
> > > 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 <atish.patra@wdc.com>
> > > > ---
> > > > 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.patra@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
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
2020-12-18 8:00 ` Atish Patra
@ 2020-12-18 8:42 ` Bin Meng
-1 siblings, 0 replies; 42+ messages in thread
From: Bin Meng @ 2020-12-18 8:42 UTC (permalink / raw)
To: Atish Patra
Cc: qemu-riscv, sagark, kbastian, Anup Patel, qemu-devel,
Alistair Francis, palmer
Hi Atish,
On Fri, Dec 18, 2020 at 4:00 PM Atish Patra <Atish.Patra@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.Patra@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 <atish.patra@wdc.com>
> > > > 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 <atish.patra@wdc.com>
> > > > > ---
> > > > > 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.patra@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 : 0x80000000
Firmware Size : 104 KB
Runtime SBI Version : 0.2
MIDELEG : 0x00000222
MEDELEG : 0x0000b109
PMP0 : 0x80000000-0x8001ffff (A)
PMP1 : 0x00000000-0xffffffff (A,R,W,X)
<hangs here>
$ ./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 : 0x80000000
Firmware Size : 112 KB
Runtime SBI Version : 0.2
MIDELEG : 0x00000222
MEDELEG : 0x0000b109
PMP0 : 0x80000000-0x8001ffff (A)
PMP1 : 0x00000000-0xffffffff (A,R,W,X)
<hangs here>
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 HART ID : 3
Boot HART ISA : rv32imafdcsu
BOOT HART Features : pmp,scounteren,mcounteren
BOOT HART PMP Count : 16
Firmware Base : 0x80000000
Firmware Size : 112 KB
Runtime SBI Version : 0.2
MIDELEG : 0x00000222
MEDELEG : 0x0000b109
PMP0 : 0x80000000-0x8001ffff (A)
PMP1 : 0x00000000-0xffffffff (A,R,W,X)
[ 0.000000] Linux version 5.10.0-00001-gbf0dad61896d
(bmeng@pek-vx-bsp2) (riscv64-linux-gcc (GCC) 8.1.0, GNU ld (GNU
Binutils) 2.30) #1 SMP Thu Dec 17 16:48:13 CST 2020
[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80400000
[ 0.000000] efi: UEFI not found.
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000080400000-0x00000000bfffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000080400000-0x00000000bfffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000080400000-0x00000000bfffffff]
[ 0.000000] SBI specification v0.2 detected
[ 0.000000] SBI implementation ID=0x1 Version=0x8
[ 0.000000] SBI v0.2 TIME extension detected
[ 0.000000] SBI v0.2 IPI extension detected
[ 0.000000] SBI v0.2 RFENCE extension detected
[ 0.000000] SBI v0.2 HSM extension detected
[ 0.000000] CPU with hartid=0 is not available
[ 0.000000] CPU with hartid=0 is not available
Regards,
Bin
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2020-12-18 8:42 ` Bin Meng
0 siblings, 0 replies; 42+ messages in thread
From: Bin Meng @ 2020-12-18 8:42 UTC (permalink / raw)
To: Atish Patra
Cc: sagark, qemu-riscv, kbastian, Alistair Francis, palmer,
Anup Patel, qemu-devel
Hi Atish,
On Fri, Dec 18, 2020 at 4:00 PM Atish Patra <Atish.Patra@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.Patra@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 <atish.patra@wdc.com>
> > > > 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 <atish.patra@wdc.com>
> > > > > ---
> > > > > 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.patra@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 : 0x80000000
Firmware Size : 104 KB
Runtime SBI Version : 0.2
MIDELEG : 0x00000222
MEDELEG : 0x0000b109
PMP0 : 0x80000000-0x8001ffff (A)
PMP1 : 0x00000000-0xffffffff (A,R,W,X)
<hangs here>
$ ./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 : 0x80000000
Firmware Size : 112 KB
Runtime SBI Version : 0.2
MIDELEG : 0x00000222
MEDELEG : 0x0000b109
PMP0 : 0x80000000-0x8001ffff (A)
PMP1 : 0x00000000-0xffffffff (A,R,W,X)
<hangs here>
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 HART ID : 3
Boot HART ISA : rv32imafdcsu
BOOT HART Features : pmp,scounteren,mcounteren
BOOT HART PMP Count : 16
Firmware Base : 0x80000000
Firmware Size : 112 KB
Runtime SBI Version : 0.2
MIDELEG : 0x00000222
MEDELEG : 0x0000b109
PMP0 : 0x80000000-0x8001ffff (A)
PMP1 : 0x00000000-0xffffffff (A,R,W,X)
[ 0.000000] Linux version 5.10.0-00001-gbf0dad61896d
(bmeng@pek-vx-bsp2) (riscv64-linux-gcc (GCC) 8.1.0, GNU ld (GNU
Binutils) 2.30) #1 SMP Thu Dec 17 16:48:13 CST 2020
[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80400000
[ 0.000000] efi: UEFI not found.
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000080400000-0x00000000bfffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000080400000-0x00000000bfffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000080400000-0x00000000bfffffff]
[ 0.000000] SBI specification v0.2 detected
[ 0.000000] SBI implementation ID=0x1 Version=0x8
[ 0.000000] SBI v0.2 TIME extension detected
[ 0.000000] SBI v0.2 IPI extension detected
[ 0.000000] SBI v0.2 RFENCE extension detected
[ 0.000000] SBI v0.2 HSM extension detected
[ 0.000000] CPU with hartid=0 is not available
[ 0.000000] CPU with hartid=0 is not available
Regards,
Bin
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
2020-12-18 8:42 ` Bin Meng
@ 2020-12-18 19:46 ` Atish Patra
-1 siblings, 0 replies; 42+ messages in thread
From: Atish Patra @ 2020-12-18 19:46 UTC (permalink / raw)
To: bmeng.cn
Cc: qemu-riscv, sagark, kbastian, Anup Patel, qemu-devel,
Alistair Francis, palmer
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.Patra@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.Patra@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
> > > > > <atish.patra@wdc.com>
> > > > > 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 <atish.patra@wdc.com>
> > > > > > ---
> > > > > > 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.patra@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 : 0x80000000
> Firmware Size : 104 KB
> Runtime SBI Version : 0.2
>
> MIDELEG : 0x00000222
> MEDELEG : 0x0000b109
> PMP0 : 0x80000000-0x8001ffff (A)
> PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> <hangs here>
>
> $ ./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 : 0x80000000
> Firmware Size : 112 KB
> Runtime SBI Version : 0.2
>
> MIDELEG : 0x00000222
> MEDELEG : 0x0000b109
> PMP0 : 0x80000000-0x8001ffff (A)
> PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> <hangs here>
>
> 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 HART ID : 3
> Boot HART ISA : rv32imafdcsu
> BOOT HART Features : pmp,scounteren,mcounteren
> BOOT HART PMP Count : 16
> Firmware Base : 0x80000000
> Firmware Size : 112 KB
> Runtime SBI Version : 0.2
>
> MIDELEG : 0x00000222
> MEDELEG : 0x0000b109
> PMP0 : 0x80000000-0x8001ffff (A)
> PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> [ 0.000000] Linux version 5.10.0-00001-gbf0dad61896d
> (bmeng@pek-vx-bsp2) (riscv64-linux-gcc (GCC) 8.1.0, GNU ld (GNU
> Binutils) 2.30) #1 SMP Thu Dec 17 16:48:13 CST 2020
> [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80400000
> [ 0.000000] efi: UEFI not found.
> [ 0.000000] Zone ranges:
> [ 0.000000] Normal [mem 0x0000000080400000-0x00000000bfffffff]
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 0: [mem 0x0000000080400000-
> 0x00000000bfffffff]
> [ 0.000000] Initmem setup node 0 [mem 0x0000000080400000-
> 0x00000000bfffffff]
> [ 0.000000] SBI specification v0.2 detected
> [ 0.000000] SBI implementation ID=0x1 Version=0x8
> [ 0.000000] SBI v0.2 TIME extension detected
> [ 0.000000] SBI v0.2 IPI extension detected
> [ 0.000000] SBI v0.2 RFENCE extension detected
> [ 0.000000] SBI v0.2 HSM extension detected
> [ 0.000000] CPU with hartid=0 is not available
> [ 0.000000] CPU with hartid=0 is not available
>
> Regards,
> Bin
May be you forgot to apply this patch for 2GB case on top of Alistair's
tree? I don't see any issues with exact same setup.
Qemu git log
------
851966c92cf5 (HEAD) RISC-V: Place DTB at 3GB boundary instead of 4GB
d31e970a01e7 (tag: pull-riscv-to-apply-20201217-1, alistair/riscv-to-
apply.next, alistair/riscv-to-apply.for-upstream) riscv/opentitan:
Update the OpenTitan memory layout
3ed2b8ac2dac hw/riscv: Use the CPU to determine if 32-bit
094b072c6819 target/riscv: cpu: Set XLEN independently from target
-------
Virt machine boot with 2GB memory
---------------------------------
$ ./qemu-system-riscv32 -nographic -M virt -m 2G -smp 4 -kernel
~/workspace/linux/arch/riscv/boot/Image
OpenSBI v0.8
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
Platform Name : riscv-virtio,qemu
Platform Features : timer,mfdeleg
Platform HART Count : 4
Boot HART ID : 0
Boot HART ISA : rv32imafdcsu
BOOT HART Features : pmp,scounteren,mcounteren,time
BOOT HART PMP Count : 16
Firmware Base : 0x80000000
Firmware Size : 104 KB
Runtime SBI Version : 0.2
MIDELEG : 0x00000222
MEDELEG : 0x0000b109
PMP0 : 0x80000000-0x8001ffff (A)
PMP1 : 0x00000000-0xffffffff (A,R,W,X)
[ 0.000000] Linux version 5.10.0-00022-ge20097fb37e2-dirty
(atish@jedi-01) (riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0, GNU ld
(GNU Binutils) 2.35) #548 SMP PREEMPT Fri Dec 18 10:45:11 PST 2020
[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80400000
[ 0.000000] efi: UEFI not found.
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000080400000-0x00000000c03fffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000080400000-0x00000000c03fffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000080400000-
0x00000000c03fffff]
[ 0.000000] On node 0 totalpages: 262144
[ 0.000000] Normal zone: 2048 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 262144 pages, LIFO batch:63
---------------------------------
sifive_u boot with 2GB memory
---------------------------------
$ ./qemu-system-riscv32 -nographic -M sifive_u -m 2G -smp 5 -kernel
~/workspace/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 : 3
Boot HART ISA : rv32imafdcsu
BOOT HART Features : pmp,scounteren,mcounteren
BOOT HART PMP Count : 16
Firmware Base : 0x80000000
Firmware Size : 112 KB
Runtime SBI Version : 0.2
MIDELEG : 0x00000222
MEDELEG : 0x0000b109
PMP0 : 0x80000000-0x8001ffff (A)
PMP1 : 0x00000000-0xffffffff (A,R,W,X)
[ 0.000000] Linux version 5.10.0-00022-ge20097fb37e2-dirty
(atish@jedi-01) (riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0, GNU ld
(GNU Binutils) 2.35) #548 SMP PREEMPT Fri Dec 18 10:45:11 PST 2020
[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80400000
[ 0.000000] efi: UEFI not found.
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000080400000-0x00000000c03fffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000080400000-0x00000000c03fffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000080400000-
0x00000000c03fffff]
---------------------------------
--
Regards,
Atish
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2020-12-18 19:46 ` Atish Patra
0 siblings, 0 replies; 42+ messages in thread
From: Atish Patra @ 2020-12-18 19:46 UTC (permalink / raw)
To: bmeng.cn
Cc: qemu-riscv, kbastian, sagark, Alistair Francis, Anup Patel,
qemu-devel, palmer
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.Patra@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.Patra@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
> > > > > <atish.patra@wdc.com>
> > > > > 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 <atish.patra@wdc.com>
> > > > > > ---
> > > > > > 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.patra@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 : 0x80000000
> Firmware Size : 104 KB
> Runtime SBI Version : 0.2
>
> MIDELEG : 0x00000222
> MEDELEG : 0x0000b109
> PMP0 : 0x80000000-0x8001ffff (A)
> PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> <hangs here>
>
> $ ./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 : 0x80000000
> Firmware Size : 112 KB
> Runtime SBI Version : 0.2
>
> MIDELEG : 0x00000222
> MEDELEG : 0x0000b109
> PMP0 : 0x80000000-0x8001ffff (A)
> PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> <hangs here>
>
> 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 HART ID : 3
> Boot HART ISA : rv32imafdcsu
> BOOT HART Features : pmp,scounteren,mcounteren
> BOOT HART PMP Count : 16
> Firmware Base : 0x80000000
> Firmware Size : 112 KB
> Runtime SBI Version : 0.2
>
> MIDELEG : 0x00000222
> MEDELEG : 0x0000b109
> PMP0 : 0x80000000-0x8001ffff (A)
> PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> [ 0.000000] Linux version 5.10.0-00001-gbf0dad61896d
> (bmeng@pek-vx-bsp2) (riscv64-linux-gcc (GCC) 8.1.0, GNU ld (GNU
> Binutils) 2.30) #1 SMP Thu Dec 17 16:48:13 CST 2020
> [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80400000
> [ 0.000000] efi: UEFI not found.
> [ 0.000000] Zone ranges:
> [ 0.000000] Normal [mem 0x0000000080400000-0x00000000bfffffff]
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 0: [mem 0x0000000080400000-
> 0x00000000bfffffff]
> [ 0.000000] Initmem setup node 0 [mem 0x0000000080400000-
> 0x00000000bfffffff]
> [ 0.000000] SBI specification v0.2 detected
> [ 0.000000] SBI implementation ID=0x1 Version=0x8
> [ 0.000000] SBI v0.2 TIME extension detected
> [ 0.000000] SBI v0.2 IPI extension detected
> [ 0.000000] SBI v0.2 RFENCE extension detected
> [ 0.000000] SBI v0.2 HSM extension detected
> [ 0.000000] CPU with hartid=0 is not available
> [ 0.000000] CPU with hartid=0 is not available
>
> Regards,
> Bin
May be you forgot to apply this patch for 2GB case on top of Alistair's
tree? I don't see any issues with exact same setup.
Qemu git log
------
851966c92cf5 (HEAD) RISC-V: Place DTB at 3GB boundary instead of 4GB
d31e970a01e7 (tag: pull-riscv-to-apply-20201217-1, alistair/riscv-to-
apply.next, alistair/riscv-to-apply.for-upstream) riscv/opentitan:
Update the OpenTitan memory layout
3ed2b8ac2dac hw/riscv: Use the CPU to determine if 32-bit
094b072c6819 target/riscv: cpu: Set XLEN independently from target
-------
Virt machine boot with 2GB memory
---------------------------------
$ ./qemu-system-riscv32 -nographic -M virt -m 2G -smp 4 -kernel
~/workspace/linux/arch/riscv/boot/Image
OpenSBI v0.8
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
Platform Name : riscv-virtio,qemu
Platform Features : timer,mfdeleg
Platform HART Count : 4
Boot HART ID : 0
Boot HART ISA : rv32imafdcsu
BOOT HART Features : pmp,scounteren,mcounteren,time
BOOT HART PMP Count : 16
Firmware Base : 0x80000000
Firmware Size : 104 KB
Runtime SBI Version : 0.2
MIDELEG : 0x00000222
MEDELEG : 0x0000b109
PMP0 : 0x80000000-0x8001ffff (A)
PMP1 : 0x00000000-0xffffffff (A,R,W,X)
[ 0.000000] Linux version 5.10.0-00022-ge20097fb37e2-dirty
(atish@jedi-01) (riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0, GNU ld
(GNU Binutils) 2.35) #548 SMP PREEMPT Fri Dec 18 10:45:11 PST 2020
[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80400000
[ 0.000000] efi: UEFI not found.
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000080400000-0x00000000c03fffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000080400000-0x00000000c03fffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000080400000-
0x00000000c03fffff]
[ 0.000000] On node 0 totalpages: 262144
[ 0.000000] Normal zone: 2048 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 262144 pages, LIFO batch:63
---------------------------------
sifive_u boot with 2GB memory
---------------------------------
$ ./qemu-system-riscv32 -nographic -M sifive_u -m 2G -smp 5 -kernel
~/workspace/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 : 3
Boot HART ISA : rv32imafdcsu
BOOT HART Features : pmp,scounteren,mcounteren
BOOT HART PMP Count : 16
Firmware Base : 0x80000000
Firmware Size : 112 KB
Runtime SBI Version : 0.2
MIDELEG : 0x00000222
MEDELEG : 0x0000b109
PMP0 : 0x80000000-0x8001ffff (A)
PMP1 : 0x00000000-0xffffffff (A,R,W,X)
[ 0.000000] Linux version 5.10.0-00022-ge20097fb37e2-dirty
(atish@jedi-01) (riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0, GNU ld
(GNU Binutils) 2.35) #548 SMP PREEMPT Fri Dec 18 10:45:11 PST 2020
[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80400000
[ 0.000000] efi: UEFI not found.
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000080400000-0x00000000c03fffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000080400000-0x00000000c03fffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000080400000-
0x00000000c03fffff]
---------------------------------
--
Regards,
Atish
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
2020-12-18 19:46 ` Atish Patra
@ 2020-12-22 5:35 ` Bin Meng
-1 siblings, 0 replies; 42+ messages in thread
From: Bin Meng @ 2020-12-22 5:35 UTC (permalink / raw)
To: Atish Patra
Cc: qemu-riscv, sagark, kbastian, Anup Patel, qemu-devel,
Alistair Francis, palmer
Hi Atish,
On Sat, Dec 19, 2020 at 3:46 AM Atish Patra <Atish.Patra@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.Patra@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.Patra@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
> > > > > > <atish.patra@wdc.com>
> > > > > > 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 <atish.patra@wdc.com>
> > > > > > > ---
> > > > > > > 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.patra@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 : 0x80000000
> > Firmware Size : 104 KB
> > Runtime SBI Version : 0.2
> >
> > MIDELEG : 0x00000222
> > MEDELEG : 0x0000b109
> > PMP0 : 0x80000000-0x8001ffff (A)
> > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > <hangs here>
> >
> > $ ./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 : 0x80000000
> > Firmware Size : 112 KB
> > Runtime SBI Version : 0.2
> >
> > MIDELEG : 0x00000222
> > MEDELEG : 0x0000b109
> > PMP0 : 0x80000000-0x8001ffff (A)
> > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > <hangs here>
> >
> > 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 HART ID : 3
> > Boot HART ISA : rv32imafdcsu
> > BOOT HART Features : pmp,scounteren,mcounteren
> > BOOT HART PMP Count : 16
> > Firmware Base : 0x80000000
> > Firmware Size : 112 KB
> > Runtime SBI Version : 0.2
> >
> > MIDELEG : 0x00000222
> > MEDELEG : 0x0000b109
> > PMP0 : 0x80000000-0x8001ffff (A)
> > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > [ 0.000000] Linux version 5.10.0-00001-gbf0dad61896d
> > (bmeng@pek-vx-bsp2) (riscv64-linux-gcc (GCC) 8.1.0, GNU ld (GNU
> > Binutils) 2.30) #1 SMP Thu Dec 17 16:48:13 CST 2020
> > [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80400000
> > [ 0.000000] efi: UEFI not found.
> > [ 0.000000] Zone ranges:
> > [ 0.000000] Normal [mem 0x0000000080400000-0x00000000bfffffff]
> > [ 0.000000] Movable zone start for each node
> > [ 0.000000] Early memory node ranges
> > [ 0.000000] node 0: [mem 0x0000000080400000-
> > 0x00000000bfffffff]
> > [ 0.000000] Initmem setup node 0 [mem 0x0000000080400000-
> > 0x00000000bfffffff]
> > [ 0.000000] SBI specification v0.2 detected
> > [ 0.000000] SBI implementation ID=0x1 Version=0x8
> > [ 0.000000] SBI v0.2 TIME extension detected
> > [ 0.000000] SBI v0.2 IPI extension detected
> > [ 0.000000] SBI v0.2 RFENCE extension detected
> > [ 0.000000] SBI v0.2 HSM extension detected
> > [ 0.000000] CPU with hartid=0 is not available
> > [ 0.000000] CPU with hartid=0 is not available
> >
> > Regards,
> > Bin
>
> May be you forgot to apply this patch for 2GB case on top of Alistair's
> tree? I don't see any issues with exact same setup.
That's really weird. I have:
$ git log --oneline
3ced2fb RISC-V: Place DTB at 3GB boundary instead of 4GB
d31e970 riscv/opentitan: Update the OpenTitan memory layout
3ed2b8a hw/riscv: Use the CPU to determine if 32-bit
094b072 target/riscv: cpu: Set XLEN independently from target
8987cdc4 target/riscv: csr: Remove compile time XLEN checks
I just rebuilt the QEMU binaries but still have the same result. 2G
does not boot on either 'virt' or 'sifive_u'.
$ ./qemu-system-riscv32 -version
QEMU emulator version 5.2.50 (v5.2.0-551-g3ced2fb)
Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
Maybe it's toolchain related? I am using kernel.org toolchain
riscv64-linux-gcc (GCC) 8.1.0. I see you were using
riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0.
>
> Qemu git log
> ------
> 851966c92cf5 (HEAD) RISC-V: Place DTB at 3GB boundary instead of 4GB
> d31e970a01e7 (tag: pull-riscv-to-apply-20201217-1, alistair/riscv-to-
> apply.next, alistair/riscv-to-apply.for-upstream) riscv/opentitan:
> Update the OpenTitan memory layout
> 3ed2b8ac2dac hw/riscv: Use the CPU to determine if 32-bit
> 094b072c6819 target/riscv: cpu: Set XLEN independently from target
> -------
Regards,
Bin
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2020-12-22 5:35 ` Bin Meng
0 siblings, 0 replies; 42+ messages in thread
From: Bin Meng @ 2020-12-22 5:35 UTC (permalink / raw)
To: Atish Patra
Cc: qemu-riscv, kbastian, sagark, Alistair Francis, Anup Patel,
qemu-devel, palmer
Hi Atish,
On Sat, Dec 19, 2020 at 3:46 AM Atish Patra <Atish.Patra@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.Patra@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.Patra@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
> > > > > > <atish.patra@wdc.com>
> > > > > > 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 <atish.patra@wdc.com>
> > > > > > > ---
> > > > > > > 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.patra@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 : 0x80000000
> > Firmware Size : 104 KB
> > Runtime SBI Version : 0.2
> >
> > MIDELEG : 0x00000222
> > MEDELEG : 0x0000b109
> > PMP0 : 0x80000000-0x8001ffff (A)
> > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > <hangs here>
> >
> > $ ./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 : 0x80000000
> > Firmware Size : 112 KB
> > Runtime SBI Version : 0.2
> >
> > MIDELEG : 0x00000222
> > MEDELEG : 0x0000b109
> > PMP0 : 0x80000000-0x8001ffff (A)
> > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > <hangs here>
> >
> > 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 HART ID : 3
> > Boot HART ISA : rv32imafdcsu
> > BOOT HART Features : pmp,scounteren,mcounteren
> > BOOT HART PMP Count : 16
> > Firmware Base : 0x80000000
> > Firmware Size : 112 KB
> > Runtime SBI Version : 0.2
> >
> > MIDELEG : 0x00000222
> > MEDELEG : 0x0000b109
> > PMP0 : 0x80000000-0x8001ffff (A)
> > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > [ 0.000000] Linux version 5.10.0-00001-gbf0dad61896d
> > (bmeng@pek-vx-bsp2) (riscv64-linux-gcc (GCC) 8.1.0, GNU ld (GNU
> > Binutils) 2.30) #1 SMP Thu Dec 17 16:48:13 CST 2020
> > [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80400000
> > [ 0.000000] efi: UEFI not found.
> > [ 0.000000] Zone ranges:
> > [ 0.000000] Normal [mem 0x0000000080400000-0x00000000bfffffff]
> > [ 0.000000] Movable zone start for each node
> > [ 0.000000] Early memory node ranges
> > [ 0.000000] node 0: [mem 0x0000000080400000-
> > 0x00000000bfffffff]
> > [ 0.000000] Initmem setup node 0 [mem 0x0000000080400000-
> > 0x00000000bfffffff]
> > [ 0.000000] SBI specification v0.2 detected
> > [ 0.000000] SBI implementation ID=0x1 Version=0x8
> > [ 0.000000] SBI v0.2 TIME extension detected
> > [ 0.000000] SBI v0.2 IPI extension detected
> > [ 0.000000] SBI v0.2 RFENCE extension detected
> > [ 0.000000] SBI v0.2 HSM extension detected
> > [ 0.000000] CPU with hartid=0 is not available
> > [ 0.000000] CPU with hartid=0 is not available
> >
> > Regards,
> > Bin
>
> May be you forgot to apply this patch for 2GB case on top of Alistair's
> tree? I don't see any issues with exact same setup.
That's really weird. I have:
$ git log --oneline
3ced2fb RISC-V: Place DTB at 3GB boundary instead of 4GB
d31e970 riscv/opentitan: Update the OpenTitan memory layout
3ed2b8a hw/riscv: Use the CPU to determine if 32-bit
094b072 target/riscv: cpu: Set XLEN independently from target
8987cdc4 target/riscv: csr: Remove compile time XLEN checks
I just rebuilt the QEMU binaries but still have the same result. 2G
does not boot on either 'virt' or 'sifive_u'.
$ ./qemu-system-riscv32 -version
QEMU emulator version 5.2.50 (v5.2.0-551-g3ced2fb)
Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
Maybe it's toolchain related? I am using kernel.org toolchain
riscv64-linux-gcc (GCC) 8.1.0. I see you were using
riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0.
>
> Qemu git log
> ------
> 851966c92cf5 (HEAD) RISC-V: Place DTB at 3GB boundary instead of 4GB
> d31e970a01e7 (tag: pull-riscv-to-apply-20201217-1, alistair/riscv-to-
> apply.next, alistair/riscv-to-apply.for-upstream) riscv/opentitan:
> Update the OpenTitan memory layout
> 3ed2b8ac2dac hw/riscv: Use the CPU to determine if 32-bit
> 094b072c6819 target/riscv: cpu: Set XLEN independently from target
> -------
Regards,
Bin
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
2020-12-22 5:35 ` Bin Meng
@ 2020-12-22 19:59 ` Atish Patra
-1 siblings, 0 replies; 42+ messages in thread
From: Atish Patra @ 2020-12-22 19:59 UTC (permalink / raw)
To: bmeng.cn
Cc: qemu-riscv, sagark, kbastian, Anup Patel, qemu-devel,
Alistair Francis, palmer
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.Patra@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.Patra@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.Patra@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
> > > > > > > <atish.patra@wdc.com>
> > > > > > > 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 <atish.patra@wdc.com>
> > > > > > > > ---
> > > > > > > > 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.patra@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 : 0x80000000
> > > Firmware Size : 104 KB
> > > Runtime SBI Version : 0.2
> > >
> > > MIDELEG : 0x00000222
> > > MEDELEG : 0x0000b109
> > > PMP0 : 0x80000000-0x8001ffff (A)
> > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > <hangs here>
> > >
> > > $ ./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 : 0x80000000
> > > Firmware Size : 112 KB
> > > Runtime SBI Version : 0.2
> > >
> > > MIDELEG : 0x00000222
> > > MEDELEG : 0x0000b109
> > > PMP0 : 0x80000000-0x8001ffff (A)
> > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > <hangs here>
> > >
> > > 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 HART ID : 3
> > > Boot HART ISA : rv32imafdcsu
> > > BOOT HART Features : pmp,scounteren,mcounteren
> > > BOOT HART PMP Count : 16
> > > Firmware Base : 0x80000000
> > > Firmware Size : 112 KB
> > > Runtime SBI Version : 0.2
> > >
> > > MIDELEG : 0x00000222
> > > MEDELEG : 0x0000b109
> > > PMP0 : 0x80000000-0x8001ffff (A)
> > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > [ 0.000000] Linux version 5.10.0-00001-gbf0dad61896d
> > > (bmeng@pek-vx-bsp2) (riscv64-linux-gcc (GCC) 8.1.0, GNU ld (GNU
> > > Binutils) 2.30) #1 SMP Thu Dec 17 16:48:13 CST 2020
> > > [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 -
> > > 0x80400000
> > > [ 0.000000] efi: UEFI not found.
> > > [ 0.000000] Zone ranges:
> > > [ 0.000000] Normal [mem 0x0000000080400000-
> > > 0x00000000bfffffff]
> > > [ 0.000000] Movable zone start for each node
> > > [ 0.000000] Early memory node ranges
> > > [ 0.000000] node 0: [mem 0x0000000080400000-
> > > 0x00000000bfffffff]
> > > [ 0.000000] Initmem setup node 0 [mem 0x0000000080400000-
> > > 0x00000000bfffffff]
> > > [ 0.000000] SBI specification v0.2 detected
> > > [ 0.000000] SBI implementation ID=0x1 Version=0x8
> > > [ 0.000000] SBI v0.2 TIME extension detected
> > > [ 0.000000] SBI v0.2 IPI extension detected
> > > [ 0.000000] SBI v0.2 RFENCE extension detected
> > > [ 0.000000] SBI v0.2 HSM extension detected
> > > [ 0.000000] CPU with hartid=0 is not available
> > > [ 0.000000] CPU with hartid=0 is not available
> > >
> > > Regards,
> > > Bin
> >
> > May be you forgot to apply this patch for 2GB case on top of
> > Alistair's
> > tree? I don't see any issues with exact same setup.
>
> That's really weird. I have:
>
> $ git log --oneline
> 3ced2fb RISC-V: Place DTB at 3GB boundary instead of 4GB
> d31e970 riscv/opentitan: Update the OpenTitan memory layout
> 3ed2b8a hw/riscv: Use the CPU to determine if 32-bit
> 094b072 target/riscv: cpu: Set XLEN independently from target
> 8987cdc4 target/riscv: csr: Remove compile time XLEN checks
>
> I just rebuilt the QEMU binaries but still have the same result. 2G
> does not boot on either 'virt' or 'sifive_u'.
>
> $ ./qemu-system-riscv32 -version
> QEMU emulator version 5.2.50 (v5.2.0-551-g3ced2fb)
> Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project
> developers
>
> Maybe it's toolchain related? I am using kernel.org toolchain
> riscv64-linux-gcc (GCC) 8.1.0. I see you were using
> riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0.
>
Strange. If it is a toolchain related issue, the cause might be
completely different. Can you give it a try to with updated toolchain ?
The pre-built toolchain available in bootlin[1] is 10.2.0.
[1] https://toolchains.bootlin.com/
Can I download pre-built gcc 8.1.0 toolchain from somewhere ?
>
> >
> > Qemu git log
> > ------
> > 851966c92cf5 (HEAD) RISC-V: Place DTB at 3GB boundary instead of
> > 4GB
> > d31e970a01e7 (tag: pull-riscv-to-apply-20201217-1, alistair/riscv-
> > to-
> > apply.next, alistair/riscv-to-apply.for-upstream) riscv/opentitan:
> > Update the OpenTitan memory layout
> > 3ed2b8ac2dac hw/riscv: Use the CPU to determine if 32-bit
> > 094b072c6819 target/riscv: cpu: Set XLEN independently from target
> > -------
>
> Regards,
> Bin
--
Regards,
Atish
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2020-12-22 19:59 ` Atish Patra
0 siblings, 0 replies; 42+ messages in thread
From: Atish Patra @ 2020-12-22 19:59 UTC (permalink / raw)
To: bmeng.cn
Cc: qemu-riscv, kbastian, sagark, Alistair Francis, Anup Patel,
qemu-devel, palmer
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.Patra@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.Patra@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.Patra@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
> > > > > > > <atish.patra@wdc.com>
> > > > > > > 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 <atish.patra@wdc.com>
> > > > > > > > ---
> > > > > > > > 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.patra@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 : 0x80000000
> > > Firmware Size : 104 KB
> > > Runtime SBI Version : 0.2
> > >
> > > MIDELEG : 0x00000222
> > > MEDELEG : 0x0000b109
> > > PMP0 : 0x80000000-0x8001ffff (A)
> > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > <hangs here>
> > >
> > > $ ./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 : 0x80000000
> > > Firmware Size : 112 KB
> > > Runtime SBI Version : 0.2
> > >
> > > MIDELEG : 0x00000222
> > > MEDELEG : 0x0000b109
> > > PMP0 : 0x80000000-0x8001ffff (A)
> > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > <hangs here>
> > >
> > > 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 HART ID : 3
> > > Boot HART ISA : rv32imafdcsu
> > > BOOT HART Features : pmp,scounteren,mcounteren
> > > BOOT HART PMP Count : 16
> > > Firmware Base : 0x80000000
> > > Firmware Size : 112 KB
> > > Runtime SBI Version : 0.2
> > >
> > > MIDELEG : 0x00000222
> > > MEDELEG : 0x0000b109
> > > PMP0 : 0x80000000-0x8001ffff (A)
> > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > [ 0.000000] Linux version 5.10.0-00001-gbf0dad61896d
> > > (bmeng@pek-vx-bsp2) (riscv64-linux-gcc (GCC) 8.1.0, GNU ld (GNU
> > > Binutils) 2.30) #1 SMP Thu Dec 17 16:48:13 CST 2020
> > > [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 -
> > > 0x80400000
> > > [ 0.000000] efi: UEFI not found.
> > > [ 0.000000] Zone ranges:
> > > [ 0.000000] Normal [mem 0x0000000080400000-
> > > 0x00000000bfffffff]
> > > [ 0.000000] Movable zone start for each node
> > > [ 0.000000] Early memory node ranges
> > > [ 0.000000] node 0: [mem 0x0000000080400000-
> > > 0x00000000bfffffff]
> > > [ 0.000000] Initmem setup node 0 [mem 0x0000000080400000-
> > > 0x00000000bfffffff]
> > > [ 0.000000] SBI specification v0.2 detected
> > > [ 0.000000] SBI implementation ID=0x1 Version=0x8
> > > [ 0.000000] SBI v0.2 TIME extension detected
> > > [ 0.000000] SBI v0.2 IPI extension detected
> > > [ 0.000000] SBI v0.2 RFENCE extension detected
> > > [ 0.000000] SBI v0.2 HSM extension detected
> > > [ 0.000000] CPU with hartid=0 is not available
> > > [ 0.000000] CPU with hartid=0 is not available
> > >
> > > Regards,
> > > Bin
> >
> > May be you forgot to apply this patch for 2GB case on top of
> > Alistair's
> > tree? I don't see any issues with exact same setup.
>
> That's really weird. I have:
>
> $ git log --oneline
> 3ced2fb RISC-V: Place DTB at 3GB boundary instead of 4GB
> d31e970 riscv/opentitan: Update the OpenTitan memory layout
> 3ed2b8a hw/riscv: Use the CPU to determine if 32-bit
> 094b072 target/riscv: cpu: Set XLEN independently from target
> 8987cdc4 target/riscv: csr: Remove compile time XLEN checks
>
> I just rebuilt the QEMU binaries but still have the same result. 2G
> does not boot on either 'virt' or 'sifive_u'.
>
> $ ./qemu-system-riscv32 -version
> QEMU emulator version 5.2.50 (v5.2.0-551-g3ced2fb)
> Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project
> developers
>
> Maybe it's toolchain related? I am using kernel.org toolchain
> riscv64-linux-gcc (GCC) 8.1.0. I see you were using
> riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0.
>
Strange. If it is a toolchain related issue, the cause might be
completely different. Can you give it a try to with updated toolchain ?
The pre-built toolchain available in bootlin[1] is 10.2.0.
[1] https://toolchains.bootlin.com/
Can I download pre-built gcc 8.1.0 toolchain from somewhere ?
>
> >
> > Qemu git log
> > ------
> > 851966c92cf5 (HEAD) RISC-V: Place DTB at 3GB boundary instead of
> > 4GB
> > d31e970a01e7 (tag: pull-riscv-to-apply-20201217-1, alistair/riscv-
> > to-
> > apply.next, alistair/riscv-to-apply.for-upstream) riscv/opentitan:
> > Update the OpenTitan memory layout
> > 3ed2b8ac2dac hw/riscv: Use the CPU to determine if 32-bit
> > 094b072c6819 target/riscv: cpu: Set XLEN independently from target
> > -------
>
> Regards,
> Bin
--
Regards,
Atish
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
2020-12-22 19:59 ` Atish Patra
@ 2020-12-23 1:20 ` Bin Meng
-1 siblings, 0 replies; 42+ messages in thread
From: Bin Meng @ 2020-12-23 1:20 UTC (permalink / raw)
To: Atish Patra
Cc: qemu-riscv, sagark, kbastian, Anup Patel, qemu-devel,
Alistair Francis, palmer
Hi Atish,
On Wed, Dec 23, 2020 at 3:59 AM Atish Patra <Atish.Patra@wdc.com> 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.Patra@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.Patra@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.Patra@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
> > > > > > > > <atish.patra@wdc.com>
> > > > > > > > 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 <atish.patra@wdc.com>
> > > > > > > > > ---
> > > > > > > > > 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.patra@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 : 0x80000000
> > > > Firmware Size : 104 KB
> > > > Runtime SBI Version : 0.2
> > > >
> > > > MIDELEG : 0x00000222
> > > > MEDELEG : 0x0000b109
> > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > <hangs here>
> > > >
> > > > $ ./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 : 0x80000000
> > > > Firmware Size : 112 KB
> > > > Runtime SBI Version : 0.2
> > > >
> > > > MIDELEG : 0x00000222
> > > > MEDELEG : 0x0000b109
> > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > <hangs here>
> > > >
> > > > 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 HART ID : 3
> > > > Boot HART ISA : rv32imafdcsu
> > > > BOOT HART Features : pmp,scounteren,mcounteren
> > > > BOOT HART PMP Count : 16
> > > > Firmware Base : 0x80000000
> > > > Firmware Size : 112 KB
> > > > Runtime SBI Version : 0.2
> > > >
> > > > MIDELEG : 0x00000222
> > > > MEDELEG : 0x0000b109
> > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > [ 0.000000] Linux version 5.10.0-00001-gbf0dad61896d
> > > > (bmeng@pek-vx-bsp2) (riscv64-linux-gcc (GCC) 8.1.0, GNU ld (GNU
> > > > Binutils) 2.30) #1 SMP Thu Dec 17 16:48:13 CST 2020
> > > > [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 -
> > > > 0x80400000
> > > > [ 0.000000] efi: UEFI not found.
> > > > [ 0.000000] Zone ranges:
> > > > [ 0.000000] Normal [mem 0x0000000080400000-
> > > > 0x00000000bfffffff]
> > > > [ 0.000000] Movable zone start for each node
> > > > [ 0.000000] Early memory node ranges
> > > > [ 0.000000] node 0: [mem 0x0000000080400000-
> > > > 0x00000000bfffffff]
> > > > [ 0.000000] Initmem setup node 0 [mem 0x0000000080400000-
> > > > 0x00000000bfffffff]
> > > > [ 0.000000] SBI specification v0.2 detected
> > > > [ 0.000000] SBI implementation ID=0x1 Version=0x8
> > > > [ 0.000000] SBI v0.2 TIME extension detected
> > > > [ 0.000000] SBI v0.2 IPI extension detected
> > > > [ 0.000000] SBI v0.2 RFENCE extension detected
> > > > [ 0.000000] SBI v0.2 HSM extension detected
> > > > [ 0.000000] CPU with hartid=0 is not available
> > > > [ 0.000000] CPU with hartid=0 is not available
> > > >
> > > > Regards,
> > > > Bin
> > >
> > > May be you forgot to apply this patch for 2GB case on top of
> > > Alistair's
> > > tree? I don't see any issues with exact same setup.
> >
> > That's really weird. I have:
> >
> > $ git log --oneline
> > 3ced2fb RISC-V: Place DTB at 3GB boundary instead of 4GB
> > d31e970 riscv/opentitan: Update the OpenTitan memory layout
> > 3ed2b8a hw/riscv: Use the CPU to determine if 32-bit
> > 094b072 target/riscv: cpu: Set XLEN independently from target
> > 8987cdc4 target/riscv: csr: Remove compile time XLEN checks
> >
> > I just rebuilt the QEMU binaries but still have the same result. 2G
> > does not boot on either 'virt' or 'sifive_u'.
> >
> > $ ./qemu-system-riscv32 -version
> > QEMU emulator version 5.2.50 (v5.2.0-551-g3ced2fb)
> > Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project
> > developers
> >
> > Maybe it's toolchain related? I am using kernel.org toolchain
> > riscv64-linux-gcc (GCC) 8.1.0. I see you were using
> > riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0.
> >
>
> Strange. If it is a toolchain related issue, the cause might be
> completely different. Can you give it a try to with updated toolchain ?
> The pre-built toolchain available in bootlin[1] is 10.2.0.
>
> [1] https://toolchains.bootlin.com/
I will give it a try.
>
> Can I download pre-built gcc 8.1.0 toolchain from somewhere ?
Yes, you can download it from
http://cdn.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc-8.1.0-nolibc-riscv64-linux.tar.xz
Regards,
Bin
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2020-12-23 1:20 ` Bin Meng
0 siblings, 0 replies; 42+ messages in thread
From: Bin Meng @ 2020-12-23 1:20 UTC (permalink / raw)
To: Atish Patra
Cc: qemu-riscv, kbastian, sagark, Alistair Francis, Anup Patel,
qemu-devel, palmer
Hi Atish,
On Wed, Dec 23, 2020 at 3:59 AM Atish Patra <Atish.Patra@wdc.com> 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.Patra@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.Patra@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.Patra@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
> > > > > > > > <atish.patra@wdc.com>
> > > > > > > > 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 <atish.patra@wdc.com>
> > > > > > > > > ---
> > > > > > > > > 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.patra@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 : 0x80000000
> > > > Firmware Size : 104 KB
> > > > Runtime SBI Version : 0.2
> > > >
> > > > MIDELEG : 0x00000222
> > > > MEDELEG : 0x0000b109
> > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > <hangs here>
> > > >
> > > > $ ./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 : 0x80000000
> > > > Firmware Size : 112 KB
> > > > Runtime SBI Version : 0.2
> > > >
> > > > MIDELEG : 0x00000222
> > > > MEDELEG : 0x0000b109
> > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > <hangs here>
> > > >
> > > > 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 HART ID : 3
> > > > Boot HART ISA : rv32imafdcsu
> > > > BOOT HART Features : pmp,scounteren,mcounteren
> > > > BOOT HART PMP Count : 16
> > > > Firmware Base : 0x80000000
> > > > Firmware Size : 112 KB
> > > > Runtime SBI Version : 0.2
> > > >
> > > > MIDELEG : 0x00000222
> > > > MEDELEG : 0x0000b109
> > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > [ 0.000000] Linux version 5.10.0-00001-gbf0dad61896d
> > > > (bmeng@pek-vx-bsp2) (riscv64-linux-gcc (GCC) 8.1.0, GNU ld (GNU
> > > > Binutils) 2.30) #1 SMP Thu Dec 17 16:48:13 CST 2020
> > > > [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 -
> > > > 0x80400000
> > > > [ 0.000000] efi: UEFI not found.
> > > > [ 0.000000] Zone ranges:
> > > > [ 0.000000] Normal [mem 0x0000000080400000-
> > > > 0x00000000bfffffff]
> > > > [ 0.000000] Movable zone start for each node
> > > > [ 0.000000] Early memory node ranges
> > > > [ 0.000000] node 0: [mem 0x0000000080400000-
> > > > 0x00000000bfffffff]
> > > > [ 0.000000] Initmem setup node 0 [mem 0x0000000080400000-
> > > > 0x00000000bfffffff]
> > > > [ 0.000000] SBI specification v0.2 detected
> > > > [ 0.000000] SBI implementation ID=0x1 Version=0x8
> > > > [ 0.000000] SBI v0.2 TIME extension detected
> > > > [ 0.000000] SBI v0.2 IPI extension detected
> > > > [ 0.000000] SBI v0.2 RFENCE extension detected
> > > > [ 0.000000] SBI v0.2 HSM extension detected
> > > > [ 0.000000] CPU with hartid=0 is not available
> > > > [ 0.000000] CPU with hartid=0 is not available
> > > >
> > > > Regards,
> > > > Bin
> > >
> > > May be you forgot to apply this patch for 2GB case on top of
> > > Alistair's
> > > tree? I don't see any issues with exact same setup.
> >
> > That's really weird. I have:
> >
> > $ git log --oneline
> > 3ced2fb RISC-V: Place DTB at 3GB boundary instead of 4GB
> > d31e970 riscv/opentitan: Update the OpenTitan memory layout
> > 3ed2b8a hw/riscv: Use the CPU to determine if 32-bit
> > 094b072 target/riscv: cpu: Set XLEN independently from target
> > 8987cdc4 target/riscv: csr: Remove compile time XLEN checks
> >
> > I just rebuilt the QEMU binaries but still have the same result. 2G
> > does not boot on either 'virt' or 'sifive_u'.
> >
> > $ ./qemu-system-riscv32 -version
> > QEMU emulator version 5.2.50 (v5.2.0-551-g3ced2fb)
> > Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project
> > developers
> >
> > Maybe it's toolchain related? I am using kernel.org toolchain
> > riscv64-linux-gcc (GCC) 8.1.0. I see you were using
> > riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0.
> >
>
> Strange. If it is a toolchain related issue, the cause might be
> completely different. Can you give it a try to with updated toolchain ?
> The pre-built toolchain available in bootlin[1] is 10.2.0.
>
> [1] https://toolchains.bootlin.com/
I will give it a try.
>
> Can I download pre-built gcc 8.1.0 toolchain from somewhere ?
Yes, you can download it from
http://cdn.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc-8.1.0-nolibc-riscv64-linux.tar.xz
Regards,
Bin
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
2020-12-23 1:20 ` Bin Meng
@ 2020-12-29 4:49 ` Bin Meng
-1 siblings, 0 replies; 42+ messages in thread
From: Bin Meng @ 2020-12-29 4:49 UTC (permalink / raw)
To: Atish Patra
Cc: qemu-riscv, sagark, kbastian, Anup Patel, qemu-devel,
Alistair Francis, palmer
Hi Atish,
On Wed, Dec 23, 2020 at 9:20 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Atish,
>
> On Wed, Dec 23, 2020 at 3:59 AM Atish Patra <Atish.Patra@wdc.com> 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.Patra@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.Patra@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.Patra@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
> > > > > > > > > <atish.patra@wdc.com>
> > > > > > > > > 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 <atish.patra@wdc.com>
> > > > > > > > > > ---
> > > > > > > > > > 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.patra@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 : 0x80000000
> > > > > Firmware Size : 104 KB
> > > > > Runtime SBI Version : 0.2
> > > > >
> > > > > MIDELEG : 0x00000222
> > > > > MEDELEG : 0x0000b109
> > > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > > <hangs here>
> > > > >
> > > > > $ ./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 : 0x80000000
> > > > > Firmware Size : 112 KB
> > > > > Runtime SBI Version : 0.2
> > > > >
> > > > > MIDELEG : 0x00000222
> > > > > MEDELEG : 0x0000b109
> > > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > > <hangs here>
> > > > >
> > > > > 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 HART ID : 3
> > > > > Boot HART ISA : rv32imafdcsu
> > > > > BOOT HART Features : pmp,scounteren,mcounteren
> > > > > BOOT HART PMP Count : 16
> > > > > Firmware Base : 0x80000000
> > > > > Firmware Size : 112 KB
> > > > > Runtime SBI Version : 0.2
> > > > >
> > > > > MIDELEG : 0x00000222
> > > > > MEDELEG : 0x0000b109
> > > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > > [ 0.000000] Linux version 5.10.0-00001-gbf0dad61896d
> > > > > (bmeng@pek-vx-bsp2) (riscv64-linux-gcc (GCC) 8.1.0, GNU ld (GNU
> > > > > Binutils) 2.30) #1 SMP Thu Dec 17 16:48:13 CST 2020
> > > > > [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 -
> > > > > 0x80400000
> > > > > [ 0.000000] efi: UEFI not found.
> > > > > [ 0.000000] Zone ranges:
> > > > > [ 0.000000] Normal [mem 0x0000000080400000-
> > > > > 0x00000000bfffffff]
> > > > > [ 0.000000] Movable zone start for each node
> > > > > [ 0.000000] Early memory node ranges
> > > > > [ 0.000000] node 0: [mem 0x0000000080400000-
> > > > > 0x00000000bfffffff]
> > > > > [ 0.000000] Initmem setup node 0 [mem 0x0000000080400000-
> > > > > 0x00000000bfffffff]
> > > > > [ 0.000000] SBI specification v0.2 detected
> > > > > [ 0.000000] SBI implementation ID=0x1 Version=0x8
> > > > > [ 0.000000] SBI v0.2 TIME extension detected
> > > > > [ 0.000000] SBI v0.2 IPI extension detected
> > > > > [ 0.000000] SBI v0.2 RFENCE extension detected
> > > > > [ 0.000000] SBI v0.2 HSM extension detected
> > > > > [ 0.000000] CPU with hartid=0 is not available
> > > > > [ 0.000000] CPU with hartid=0 is not available
> > > > >
> > > > > Regards,
> > > > > Bin
> > > >
> > > > May be you forgot to apply this patch for 2GB case on top of
> > > > Alistair's
> > > > tree? I don't see any issues with exact same setup.
> > >
> > > That's really weird. I have:
> > >
> > > $ git log --oneline
> > > 3ced2fb RISC-V: Place DTB at 3GB boundary instead of 4GB
> > > d31e970 riscv/opentitan: Update the OpenTitan memory layout
> > > 3ed2b8a hw/riscv: Use the CPU to determine if 32-bit
> > > 094b072 target/riscv: cpu: Set XLEN independently from target
> > > 8987cdc4 target/riscv: csr: Remove compile time XLEN checks
> > >
> > > I just rebuilt the QEMU binaries but still have the same result. 2G
> > > does not boot on either 'virt' or 'sifive_u'.
> > >
> > > $ ./qemu-system-riscv32 -version
> > > QEMU emulator version 5.2.50 (v5.2.0-551-g3ced2fb)
> > > Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project
> > > developers
> > >
> > > Maybe it's toolchain related? I am using kernel.org toolchain
> > > riscv64-linux-gcc (GCC) 8.1.0. I see you were using
> > > riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0.
> > >
> >
> > Strange. If it is a toolchain related issue, the cause might be
> > completely different. Can you give it a try to with updated toolchain ?
> > The pre-built toolchain available in bootlin[1] is 10.2.0.
> >
> > [1] https://toolchains.bootlin.com/
>
> I will give it a try.
I used the bootlin pre-built 10.2.0 toolchain to build the Linux
kernel. Still, 2GB does not boot on QEMU.
I looked at your kernel log again, and found:
[ 0.000000] Linux version 5.10.0-00022-ge20097fb37e2-dirty
It seems you have 22 commits on top of 5.10.
I only have one commit "RISC-V: Fix usage of
memblock_enforce_memory_limit" on top of 5.10.
Could you please check?
>
> >
> > Can I download pre-built gcc 8.1.0 toolchain from somewhere ?
>
> Yes, you can download it from
> http://cdn.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc-8.1.0-nolibc-riscv64-linux.tar.xz
Regards,
Bin
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2020-12-29 4:49 ` Bin Meng
0 siblings, 0 replies; 42+ messages in thread
From: Bin Meng @ 2020-12-29 4:49 UTC (permalink / raw)
To: Atish Patra
Cc: qemu-riscv, kbastian, sagark, Alistair Francis, Anup Patel,
qemu-devel, palmer
Hi Atish,
On Wed, Dec 23, 2020 at 9:20 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Atish,
>
> On Wed, Dec 23, 2020 at 3:59 AM Atish Patra <Atish.Patra@wdc.com> 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.Patra@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.Patra@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.Patra@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
> > > > > > > > > <atish.patra@wdc.com>
> > > > > > > > > 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 <atish.patra@wdc.com>
> > > > > > > > > > ---
> > > > > > > > > > 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.patra@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 : 0x80000000
> > > > > Firmware Size : 104 KB
> > > > > Runtime SBI Version : 0.2
> > > > >
> > > > > MIDELEG : 0x00000222
> > > > > MEDELEG : 0x0000b109
> > > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > > <hangs here>
> > > > >
> > > > > $ ./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 : 0x80000000
> > > > > Firmware Size : 112 KB
> > > > > Runtime SBI Version : 0.2
> > > > >
> > > > > MIDELEG : 0x00000222
> > > > > MEDELEG : 0x0000b109
> > > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > > <hangs here>
> > > > >
> > > > > 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 HART ID : 3
> > > > > Boot HART ISA : rv32imafdcsu
> > > > > BOOT HART Features : pmp,scounteren,mcounteren
> > > > > BOOT HART PMP Count : 16
> > > > > Firmware Base : 0x80000000
> > > > > Firmware Size : 112 KB
> > > > > Runtime SBI Version : 0.2
> > > > >
> > > > > MIDELEG : 0x00000222
> > > > > MEDELEG : 0x0000b109
> > > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > > [ 0.000000] Linux version 5.10.0-00001-gbf0dad61896d
> > > > > (bmeng@pek-vx-bsp2) (riscv64-linux-gcc (GCC) 8.1.0, GNU ld (GNU
> > > > > Binutils) 2.30) #1 SMP Thu Dec 17 16:48:13 CST 2020
> > > > > [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 -
> > > > > 0x80400000
> > > > > [ 0.000000] efi: UEFI not found.
> > > > > [ 0.000000] Zone ranges:
> > > > > [ 0.000000] Normal [mem 0x0000000080400000-
> > > > > 0x00000000bfffffff]
> > > > > [ 0.000000] Movable zone start for each node
> > > > > [ 0.000000] Early memory node ranges
> > > > > [ 0.000000] node 0: [mem 0x0000000080400000-
> > > > > 0x00000000bfffffff]
> > > > > [ 0.000000] Initmem setup node 0 [mem 0x0000000080400000-
> > > > > 0x00000000bfffffff]
> > > > > [ 0.000000] SBI specification v0.2 detected
> > > > > [ 0.000000] SBI implementation ID=0x1 Version=0x8
> > > > > [ 0.000000] SBI v0.2 TIME extension detected
> > > > > [ 0.000000] SBI v0.2 IPI extension detected
> > > > > [ 0.000000] SBI v0.2 RFENCE extension detected
> > > > > [ 0.000000] SBI v0.2 HSM extension detected
> > > > > [ 0.000000] CPU with hartid=0 is not available
> > > > > [ 0.000000] CPU with hartid=0 is not available
> > > > >
> > > > > Regards,
> > > > > Bin
> > > >
> > > > May be you forgot to apply this patch for 2GB case on top of
> > > > Alistair's
> > > > tree? I don't see any issues with exact same setup.
> > >
> > > That's really weird. I have:
> > >
> > > $ git log --oneline
> > > 3ced2fb RISC-V: Place DTB at 3GB boundary instead of 4GB
> > > d31e970 riscv/opentitan: Update the OpenTitan memory layout
> > > 3ed2b8a hw/riscv: Use the CPU to determine if 32-bit
> > > 094b072 target/riscv: cpu: Set XLEN independently from target
> > > 8987cdc4 target/riscv: csr: Remove compile time XLEN checks
> > >
> > > I just rebuilt the QEMU binaries but still have the same result. 2G
> > > does not boot on either 'virt' or 'sifive_u'.
> > >
> > > $ ./qemu-system-riscv32 -version
> > > QEMU emulator version 5.2.50 (v5.2.0-551-g3ced2fb)
> > > Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project
> > > developers
> > >
> > > Maybe it's toolchain related? I am using kernel.org toolchain
> > > riscv64-linux-gcc (GCC) 8.1.0. I see you were using
> > > riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0.
> > >
> >
> > Strange. If it is a toolchain related issue, the cause might be
> > completely different. Can you give it a try to with updated toolchain ?
> > The pre-built toolchain available in bootlin[1] is 10.2.0.
> >
> > [1] https://toolchains.bootlin.com/
>
> I will give it a try.
I used the bootlin pre-built 10.2.0 toolchain to build the Linux
kernel. Still, 2GB does not boot on QEMU.
I looked at your kernel log again, and found:
[ 0.000000] Linux version 5.10.0-00022-ge20097fb37e2-dirty
It seems you have 22 commits on top of 5.10.
I only have one commit "RISC-V: Fix usage of
memblock_enforce_memory_limit" on top of 5.10.
Could you please check?
>
> >
> > Can I download pre-built gcc 8.1.0 toolchain from somewhere ?
>
> Yes, you can download it from
> http://cdn.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc-8.1.0-nolibc-riscv64-linux.tar.xz
Regards,
Bin
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
2020-12-29 4:49 ` Bin Meng
@ 2021-01-04 20:24 ` Atish Patra
-1 siblings, 0 replies; 42+ messages in thread
From: Atish Patra @ 2021-01-04 20:24 UTC (permalink / raw)
To: bmeng.cn
Cc: qemu-riscv, sagark, kbastian, Anup Patel, qemu-devel,
Alistair Francis, palmer
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 <bmeng.cn@gmail.com> wrote:
> >
> > Hi Atish,
> >
> > On Wed, Dec 23, 2020 at 3:59 AM Atish Patra <Atish.Patra@wdc.com>
> > 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.Patra@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.Patra@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.Patra@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
> > > > > > > > > > <atish.patra@wdc.com>
> > > > > > > > > > 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 <atish.patra@wdc.com>
> > > > > > > > > > > ---
> > > > > > > > > > > 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.patra@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 : 0x80000000
> > > > > > Firmware Size : 104 KB
> > > > > > Runtime SBI Version : 0.2
> > > > > >
> > > > > > MIDELEG : 0x00000222
> > > > > > MEDELEG : 0x0000b109
> > > > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > > > <hangs here>
> > > > > >
> > > > > > $ ./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 : 0x80000000
> > > > > > Firmware Size : 112 KB
> > > > > > Runtime SBI Version : 0.2
> > > > > >
> > > > > > MIDELEG : 0x00000222
> > > > > > MEDELEG : 0x0000b109
> > > > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > > > <hangs here>
> > > > > >
> > > > > > 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 HART ID : 3
> > > > > > Boot HART ISA : rv32imafdcsu
> > > > > > BOOT HART Features : pmp,scounteren,mcounteren
> > > > > > BOOT HART PMP Count : 16
> > > > > > Firmware Base : 0x80000000
> > > > > > Firmware Size : 112 KB
> > > > > > Runtime SBI Version : 0.2
> > > > > >
> > > > > > MIDELEG : 0x00000222
> > > > > > MEDELEG : 0x0000b109
> > > > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > > > [ 0.000000] Linux version 5.10.0-00001-gbf0dad61896d
> > > > > > (bmeng@pek-vx-bsp2) (riscv64-linux-gcc (GCC) 8.1.0, GNU ld
> > > > > > (GNU
> > > > > > Binutils) 2.30) #1 SMP Thu Dec 17 16:48:13 CST 2020
> > > > > > [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 -
> > > > > > 0x80400000
> > > > > > [ 0.000000] efi: UEFI not found.
> > > > > > [ 0.000000] Zone ranges:
> > > > > > [ 0.000000] Normal [mem 0x0000000080400000-
> > > > > > 0x00000000bfffffff]
> > > > > > [ 0.000000] Movable zone start for each node
> > > > > > [ 0.000000] Early memory node ranges
> > > > > > [ 0.000000] node 0: [mem 0x0000000080400000-
> > > > > > 0x00000000bfffffff]
> > > > > > [ 0.000000] Initmem setup node 0 [mem
> > > > > > 0x0000000080400000-
> > > > > > 0x00000000bfffffff]
> > > > > > [ 0.000000] SBI specification v0.2 detected
> > > > > > [ 0.000000] SBI implementation ID=0x1 Version=0x8
> > > > > > [ 0.000000] SBI v0.2 TIME extension detected
> > > > > > [ 0.000000] SBI v0.2 IPI extension detected
> > > > > > [ 0.000000] SBI v0.2 RFENCE extension detected
> > > > > > [ 0.000000] SBI v0.2 HSM extension detected
> > > > > > [ 0.000000] CPU with hartid=0 is not available
> > > > > > [ 0.000000] CPU with hartid=0 is not available
> > > > > >
> > > > > > Regards,
> > > > > > Bin
> > > > >
> > > > > May be you forgot to apply this patch for 2GB case on top of
> > > > > Alistair's
> > > > > tree? I don't see any issues with exact same setup.
> > > >
> > > > That's really weird. I have:
> > > >
> > > > $ git log --oneline
> > > > 3ced2fb RISC-V: Place DTB at 3GB boundary instead of 4GB
> > > > d31e970 riscv/opentitan: Update the OpenTitan memory layout
> > > > 3ed2b8a hw/riscv: Use the CPU to determine if 32-bit
> > > > 094b072 target/riscv: cpu: Set XLEN independently from target
> > > > 8987cdc4 target/riscv: csr: Remove compile time XLEN checks
> > > >
> > > > I just rebuilt the QEMU binaries but still have the same
> > > > result. 2G
> > > > does not boot on either 'virt' or 'sifive_u'.
> > > >
> > > > $ ./qemu-system-riscv32 -version
> > > > QEMU emulator version 5.2.50 (v5.2.0-551-g3ced2fb)
> > > > Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project
> > > > developers
> > > >
> > > > Maybe it's toolchain related? I am using kernel.org toolchain
> > > > riscv64-linux-gcc (GCC) 8.1.0. I see you were using
> > > > riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0.
> > > >
> > >
> > > Strange. If it is a toolchain related issue, the cause might be
> > > completely different. Can you give it a try to with updated
> > > toolchain ?
> > > The pre-built toolchain available in bootlin[1] is 10.2.0.
> > >
> > > [1] https://toolchains.bootlin.com/
> >
> > I will give it a try.
>
> I used the bootlin pre-built 10.2.0 toolchain to build the Linux
> kernel. Still, 2GB does not boot on QEMU.
>
> I looked at your kernel log again, and found:
>
> [ 0.000000] Linux version 5.10.0-00022-ge20097fb37e2-dirty
>
> It seems you have 22 commits on top of 5.10.
>
> I only have one commit "RISC-V: Fix usage of
> memblock_enforce_memory_limit" on top of 5.10.
>
> Could you please check?
>
Sorry for the late reply. I was on vacation. I was using for-next
branch on top of 5.10. I just tested with 5.11-rc2 and everything seems
to be fine. Can you check with 5.11-rc2 ?
Apologies for the any confusion caused.
> >
> > >
> > > Can I download pre-built gcc 8.1.0 toolchain from somewhere ?
> >
> > Yes, you can download it from
> > http://cdn.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc-8.1.0-nolibc-riscv64-linux.tar.xz
>
> Regards,
> Bin
--
Regards,
Atish
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2021-01-04 20:24 ` Atish Patra
0 siblings, 0 replies; 42+ messages in thread
From: Atish Patra @ 2021-01-04 20:24 UTC (permalink / raw)
To: bmeng.cn
Cc: qemu-riscv, kbastian, sagark, Alistair Francis, Anup Patel,
qemu-devel, palmer
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 <bmeng.cn@gmail.com> wrote:
> >
> > Hi Atish,
> >
> > On Wed, Dec 23, 2020 at 3:59 AM Atish Patra <Atish.Patra@wdc.com>
> > 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.Patra@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.Patra@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.Patra@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
> > > > > > > > > > <atish.patra@wdc.com>
> > > > > > > > > > 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 <atish.patra@wdc.com>
> > > > > > > > > > > ---
> > > > > > > > > > > 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.patra@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 : 0x80000000
> > > > > > Firmware Size : 104 KB
> > > > > > Runtime SBI Version : 0.2
> > > > > >
> > > > > > MIDELEG : 0x00000222
> > > > > > MEDELEG : 0x0000b109
> > > > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > > > <hangs here>
> > > > > >
> > > > > > $ ./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 : 0x80000000
> > > > > > Firmware Size : 112 KB
> > > > > > Runtime SBI Version : 0.2
> > > > > >
> > > > > > MIDELEG : 0x00000222
> > > > > > MEDELEG : 0x0000b109
> > > > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > > > <hangs here>
> > > > > >
> > > > > > 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 HART ID : 3
> > > > > > Boot HART ISA : rv32imafdcsu
> > > > > > BOOT HART Features : pmp,scounteren,mcounteren
> > > > > > BOOT HART PMP Count : 16
> > > > > > Firmware Base : 0x80000000
> > > > > > Firmware Size : 112 KB
> > > > > > Runtime SBI Version : 0.2
> > > > > >
> > > > > > MIDELEG : 0x00000222
> > > > > > MEDELEG : 0x0000b109
> > > > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > > > [ 0.000000] Linux version 5.10.0-00001-gbf0dad61896d
> > > > > > (bmeng@pek-vx-bsp2) (riscv64-linux-gcc (GCC) 8.1.0, GNU ld
> > > > > > (GNU
> > > > > > Binutils) 2.30) #1 SMP Thu Dec 17 16:48:13 CST 2020
> > > > > > [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 -
> > > > > > 0x80400000
> > > > > > [ 0.000000] efi: UEFI not found.
> > > > > > [ 0.000000] Zone ranges:
> > > > > > [ 0.000000] Normal [mem 0x0000000080400000-
> > > > > > 0x00000000bfffffff]
> > > > > > [ 0.000000] Movable zone start for each node
> > > > > > [ 0.000000] Early memory node ranges
> > > > > > [ 0.000000] node 0: [mem 0x0000000080400000-
> > > > > > 0x00000000bfffffff]
> > > > > > [ 0.000000] Initmem setup node 0 [mem
> > > > > > 0x0000000080400000-
> > > > > > 0x00000000bfffffff]
> > > > > > [ 0.000000] SBI specification v0.2 detected
> > > > > > [ 0.000000] SBI implementation ID=0x1 Version=0x8
> > > > > > [ 0.000000] SBI v0.2 TIME extension detected
> > > > > > [ 0.000000] SBI v0.2 IPI extension detected
> > > > > > [ 0.000000] SBI v0.2 RFENCE extension detected
> > > > > > [ 0.000000] SBI v0.2 HSM extension detected
> > > > > > [ 0.000000] CPU with hartid=0 is not available
> > > > > > [ 0.000000] CPU with hartid=0 is not available
> > > > > >
> > > > > > Regards,
> > > > > > Bin
> > > > >
> > > > > May be you forgot to apply this patch for 2GB case on top of
> > > > > Alistair's
> > > > > tree? I don't see any issues with exact same setup.
> > > >
> > > > That's really weird. I have:
> > > >
> > > > $ git log --oneline
> > > > 3ced2fb RISC-V: Place DTB at 3GB boundary instead of 4GB
> > > > d31e970 riscv/opentitan: Update the OpenTitan memory layout
> > > > 3ed2b8a hw/riscv: Use the CPU to determine if 32-bit
> > > > 094b072 target/riscv: cpu: Set XLEN independently from target
> > > > 8987cdc4 target/riscv: csr: Remove compile time XLEN checks
> > > >
> > > > I just rebuilt the QEMU binaries but still have the same
> > > > result. 2G
> > > > does not boot on either 'virt' or 'sifive_u'.
> > > >
> > > > $ ./qemu-system-riscv32 -version
> > > > QEMU emulator version 5.2.50 (v5.2.0-551-g3ced2fb)
> > > > Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project
> > > > developers
> > > >
> > > > Maybe it's toolchain related? I am using kernel.org toolchain
> > > > riscv64-linux-gcc (GCC) 8.1.0. I see you were using
> > > > riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0.
> > > >
> > >
> > > Strange. If it is a toolchain related issue, the cause might be
> > > completely different. Can you give it a try to with updated
> > > toolchain ?
> > > The pre-built toolchain available in bootlin[1] is 10.2.0.
> > >
> > > [1] https://toolchains.bootlin.com/
> >
> > I will give it a try.
>
> I used the bootlin pre-built 10.2.0 toolchain to build the Linux
> kernel. Still, 2GB does not boot on QEMU.
>
> I looked at your kernel log again, and found:
>
> [ 0.000000] Linux version 5.10.0-00022-ge20097fb37e2-dirty
>
> It seems you have 22 commits on top of 5.10.
>
> I only have one commit "RISC-V: Fix usage of
> memblock_enforce_memory_limit" on top of 5.10.
>
> Could you please check?
>
Sorry for the late reply. I was on vacation. I was using for-next
branch on top of 5.10. I just tested with 5.11-rc2 and everything seems
to be fine. Can you check with 5.11-rc2 ?
Apologies for the any confusion caused.
> >
> > >
> > > Can I download pre-built gcc 8.1.0 toolchain from somewhere ?
> >
> > Yes, you can download it from
> > http://cdn.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc-8.1.0-nolibc-riscv64-linux.tar.xz
>
> Regards,
> Bin
--
Regards,
Atish
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
2021-01-04 20:24 ` Atish Patra
@ 2021-01-05 3:06 ` Bin Meng
-1 siblings, 0 replies; 42+ messages in thread
From: Bin Meng @ 2021-01-05 3:06 UTC (permalink / raw)
To: Atish Patra
Cc: qemu-riscv, sagark, kbastian, Anup Patel, qemu-devel,
Alistair Francis, palmer
Hi Atish,
On Tue, Jan 5, 2021 at 4:24 AM Atish Patra <Atish.Patra@wdc.com> 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 <bmeng.cn@gmail.com> wrote:
> > >
> > > Hi Atish,
> > >
> > > On Wed, Dec 23, 2020 at 3:59 AM Atish Patra <Atish.Patra@wdc.com>
> > > 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.Patra@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.Patra@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.Patra@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
> > > > > > > > > > > <atish.patra@wdc.com>
> > > > > > > > > > > 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 <atish.patra@wdc.com>
> > > > > > > > > > > > ---
> > > > > > > > > > > > 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.patra@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 : 0x80000000
> > > > > > > Firmware Size : 104 KB
> > > > > > > Runtime SBI Version : 0.2
> > > > > > >
> > > > > > > MIDELEG : 0x00000222
> > > > > > > MEDELEG : 0x0000b109
> > > > > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > > > > <hangs here>
> > > > > > >
> > > > > > > $ ./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 : 0x80000000
> > > > > > > Firmware Size : 112 KB
> > > > > > > Runtime SBI Version : 0.2
> > > > > > >
> > > > > > > MIDELEG : 0x00000222
> > > > > > > MEDELEG : 0x0000b109
> > > > > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > > > > <hangs here>
> > > > > > >
> > > > > > > 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 HART ID : 3
> > > > > > > Boot HART ISA : rv32imafdcsu
> > > > > > > BOOT HART Features : pmp,scounteren,mcounteren
> > > > > > > BOOT HART PMP Count : 16
> > > > > > > Firmware Base : 0x80000000
> > > > > > > Firmware Size : 112 KB
> > > > > > > Runtime SBI Version : 0.2
> > > > > > >
> > > > > > > MIDELEG : 0x00000222
> > > > > > > MEDELEG : 0x0000b109
> > > > > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > > > > [ 0.000000] Linux version 5.10.0-00001-gbf0dad61896d
> > > > > > > (bmeng@pek-vx-bsp2) (riscv64-linux-gcc (GCC) 8.1.0, GNU ld
> > > > > > > (GNU
> > > > > > > Binutils) 2.30) #1 SMP Thu Dec 17 16:48:13 CST 2020
> > > > > > > [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 -
> > > > > > > 0x80400000
> > > > > > > [ 0.000000] efi: UEFI not found.
> > > > > > > [ 0.000000] Zone ranges:
> > > > > > > [ 0.000000] Normal [mem 0x0000000080400000-
> > > > > > > 0x00000000bfffffff]
> > > > > > > [ 0.000000] Movable zone start for each node
> > > > > > > [ 0.000000] Early memory node ranges
> > > > > > > [ 0.000000] node 0: [mem 0x0000000080400000-
> > > > > > > 0x00000000bfffffff]
> > > > > > > [ 0.000000] Initmem setup node 0 [mem
> > > > > > > 0x0000000080400000-
> > > > > > > 0x00000000bfffffff]
> > > > > > > [ 0.000000] SBI specification v0.2 detected
> > > > > > > [ 0.000000] SBI implementation ID=0x1 Version=0x8
> > > > > > > [ 0.000000] SBI v0.2 TIME extension detected
> > > > > > > [ 0.000000] SBI v0.2 IPI extension detected
> > > > > > > [ 0.000000] SBI v0.2 RFENCE extension detected
> > > > > > > [ 0.000000] SBI v0.2 HSM extension detected
> > > > > > > [ 0.000000] CPU with hartid=0 is not available
> > > > > > > [ 0.000000] CPU with hartid=0 is not available
> > > > > > >
> > > > > > > Regards,
> > > > > > > Bin
> > > > > >
> > > > > > May be you forgot to apply this patch for 2GB case on top of
> > > > > > Alistair's
> > > > > > tree? I don't see any issues with exact same setup.
> > > > >
> > > > > That's really weird. I have:
> > > > >
> > > > > $ git log --oneline
> > > > > 3ced2fb RISC-V: Place DTB at 3GB boundary instead of 4GB
> > > > > d31e970 riscv/opentitan: Update the OpenTitan memory layout
> > > > > 3ed2b8a hw/riscv: Use the CPU to determine if 32-bit
> > > > > 094b072 target/riscv: cpu: Set XLEN independently from target
> > > > > 8987cdc4 target/riscv: csr: Remove compile time XLEN checks
> > > > >
> > > > > I just rebuilt the QEMU binaries but still have the same
> > > > > result. 2G
> > > > > does not boot on either 'virt' or 'sifive_u'.
> > > > >
> > > > > $ ./qemu-system-riscv32 -version
> > > > > QEMU emulator version 5.2.50 (v5.2.0-551-g3ced2fb)
> > > > > Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project
> > > > > developers
> > > > >
> > > > > Maybe it's toolchain related? I am using kernel.org toolchain
> > > > > riscv64-linux-gcc (GCC) 8.1.0. I see you were using
> > > > > riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0.
> > > > >
> > > >
> > > > Strange. If it is a toolchain related issue, the cause might be
> > > > completely different. Can you give it a try to with updated
> > > > toolchain ?
> > > > The pre-built toolchain available in bootlin[1] is 10.2.0.
> > > >
> > > > [1] https://toolchains.bootlin.com/
> > >
> > > I will give it a try.
> >
> > I used the bootlin pre-built 10.2.0 toolchain to build the Linux
> > kernel. Still, 2GB does not boot on QEMU.
> >
> > I looked at your kernel log again, and found:
> >
> > [ 0.000000] Linux version 5.10.0-00022-ge20097fb37e2-dirty
> >
> > It seems you have 22 commits on top of 5.10.
> >
> > I only have one commit "RISC-V: Fix usage of
> > memblock_enforce_memory_limit" on top of 5.10.
> >
> > Could you please check?
> >
>
> Sorry for the late reply. I was on vacation. I was using for-next
> branch on top of 5.10. I just tested with 5.11-rc2 and everything seems
> to be fine. Can you check with 5.11-rc2 ?
I just tested v5.11-rc2 and "-m 2G" boots now.
> Apologies for the any confusion caused.
>
So it looks there are multiple kernel breakages on 32-bit support.
Could you identify which kernel commit "fixed" things in your "Linux
version 5.10.0-00022-ge20097fb37e2-dirty" build since there are only
22 commits on top of 5.10?
Regards,
Bin
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2021-01-05 3:06 ` Bin Meng
0 siblings, 0 replies; 42+ messages in thread
From: Bin Meng @ 2021-01-05 3:06 UTC (permalink / raw)
To: Atish Patra
Cc: qemu-riscv, kbastian, sagark, Alistair Francis, Anup Patel,
qemu-devel, palmer
Hi Atish,
On Tue, Jan 5, 2021 at 4:24 AM Atish Patra <Atish.Patra@wdc.com> 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 <bmeng.cn@gmail.com> wrote:
> > >
> > > Hi Atish,
> > >
> > > On Wed, Dec 23, 2020 at 3:59 AM Atish Patra <Atish.Patra@wdc.com>
> > > 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.Patra@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.Patra@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.Patra@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
> > > > > > > > > > > <atish.patra@wdc.com>
> > > > > > > > > > > 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 <atish.patra@wdc.com>
> > > > > > > > > > > > ---
> > > > > > > > > > > > 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.patra@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 : 0x80000000
> > > > > > > Firmware Size : 104 KB
> > > > > > > Runtime SBI Version : 0.2
> > > > > > >
> > > > > > > MIDELEG : 0x00000222
> > > > > > > MEDELEG : 0x0000b109
> > > > > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > > > > <hangs here>
> > > > > > >
> > > > > > > $ ./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 : 0x80000000
> > > > > > > Firmware Size : 112 KB
> > > > > > > Runtime SBI Version : 0.2
> > > > > > >
> > > > > > > MIDELEG : 0x00000222
> > > > > > > MEDELEG : 0x0000b109
> > > > > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > > > > <hangs here>
> > > > > > >
> > > > > > > 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 HART ID : 3
> > > > > > > Boot HART ISA : rv32imafdcsu
> > > > > > > BOOT HART Features : pmp,scounteren,mcounteren
> > > > > > > BOOT HART PMP Count : 16
> > > > > > > Firmware Base : 0x80000000
> > > > > > > Firmware Size : 112 KB
> > > > > > > Runtime SBI Version : 0.2
> > > > > > >
> > > > > > > MIDELEG : 0x00000222
> > > > > > > MEDELEG : 0x0000b109
> > > > > > > PMP0 : 0x80000000-0x8001ffff (A)
> > > > > > > PMP1 : 0x00000000-0xffffffff (A,R,W,X)
> > > > > > > [ 0.000000] Linux version 5.10.0-00001-gbf0dad61896d
> > > > > > > (bmeng@pek-vx-bsp2) (riscv64-linux-gcc (GCC) 8.1.0, GNU ld
> > > > > > > (GNU
> > > > > > > Binutils) 2.30) #1 SMP Thu Dec 17 16:48:13 CST 2020
> > > > > > > [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 -
> > > > > > > 0x80400000
> > > > > > > [ 0.000000] efi: UEFI not found.
> > > > > > > [ 0.000000] Zone ranges:
> > > > > > > [ 0.000000] Normal [mem 0x0000000080400000-
> > > > > > > 0x00000000bfffffff]
> > > > > > > [ 0.000000] Movable zone start for each node
> > > > > > > [ 0.000000] Early memory node ranges
> > > > > > > [ 0.000000] node 0: [mem 0x0000000080400000-
> > > > > > > 0x00000000bfffffff]
> > > > > > > [ 0.000000] Initmem setup node 0 [mem
> > > > > > > 0x0000000080400000-
> > > > > > > 0x00000000bfffffff]
> > > > > > > [ 0.000000] SBI specification v0.2 detected
> > > > > > > [ 0.000000] SBI implementation ID=0x1 Version=0x8
> > > > > > > [ 0.000000] SBI v0.2 TIME extension detected
> > > > > > > [ 0.000000] SBI v0.2 IPI extension detected
> > > > > > > [ 0.000000] SBI v0.2 RFENCE extension detected
> > > > > > > [ 0.000000] SBI v0.2 HSM extension detected
> > > > > > > [ 0.000000] CPU with hartid=0 is not available
> > > > > > > [ 0.000000] CPU with hartid=0 is not available
> > > > > > >
> > > > > > > Regards,
> > > > > > > Bin
> > > > > >
> > > > > > May be you forgot to apply this patch for 2GB case on top of
> > > > > > Alistair's
> > > > > > tree? I don't see any issues with exact same setup.
> > > > >
> > > > > That's really weird. I have:
> > > > >
> > > > > $ git log --oneline
> > > > > 3ced2fb RISC-V: Place DTB at 3GB boundary instead of 4GB
> > > > > d31e970 riscv/opentitan: Update the OpenTitan memory layout
> > > > > 3ed2b8a hw/riscv: Use the CPU to determine if 32-bit
> > > > > 094b072 target/riscv: cpu: Set XLEN independently from target
> > > > > 8987cdc4 target/riscv: csr: Remove compile time XLEN checks
> > > > >
> > > > > I just rebuilt the QEMU binaries but still have the same
> > > > > result. 2G
> > > > > does not boot on either 'virt' or 'sifive_u'.
> > > > >
> > > > > $ ./qemu-system-riscv32 -version
> > > > > QEMU emulator version 5.2.50 (v5.2.0-551-g3ced2fb)
> > > > > Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project
> > > > > developers
> > > > >
> > > > > Maybe it's toolchain related? I am using kernel.org toolchain
> > > > > riscv64-linux-gcc (GCC) 8.1.0. I see you were using
> > > > > riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0.
> > > > >
> > > >
> > > > Strange. If it is a toolchain related issue, the cause might be
> > > > completely different. Can you give it a try to with updated
> > > > toolchain ?
> > > > The pre-built toolchain available in bootlin[1] is 10.2.0.
> > > >
> > > > [1] https://toolchains.bootlin.com/
> > >
> > > I will give it a try.
> >
> > I used the bootlin pre-built 10.2.0 toolchain to build the Linux
> > kernel. Still, 2GB does not boot on QEMU.
> >
> > I looked at your kernel log again, and found:
> >
> > [ 0.000000] Linux version 5.10.0-00022-ge20097fb37e2-dirty
> >
> > It seems you have 22 commits on top of 5.10.
> >
> > I only have one commit "RISC-V: Fix usage of
> > memblock_enforce_memory_limit" on top of 5.10.
> >
> > Could you please check?
> >
>
> Sorry for the late reply. I was on vacation. I was using for-next
> branch on top of 5.10. I just tested with 5.11-rc2 and everything seems
> to be fine. Can you check with 5.11-rc2 ?
I just tested v5.11-rc2 and "-m 2G" boots now.
> Apologies for the any confusion caused.
>
So it looks there are multiple kernel breakages on 32-bit support.
Could you identify which kernel commit "fixed" things in your "Linux
version 5.10.0-00022-ge20097fb37e2-dirty" build since there are only
22 commits on top of 5.10?
Regards,
Bin
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
2020-12-17 21:48 ` Atish Patra
@ 2021-01-05 3:11 ` Bin Meng
-1 siblings, 0 replies; 42+ messages in thread
From: Bin Meng @ 2021-01-05 3:11 UTC (permalink / raw)
To: Atish Patra
Cc: open list:RISC-V, Sagar Karandikar, Bastian Koppelmann,
Anup Patel, qemu-devel@nongnu.org Developers, Alistair Francis,
Palmer Dabbelt
On Fri, Dec 18, 2020 at 5:48 AM Atish Patra <atish.patra@wdc.com> 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 <atish.patra@wdc.com>
> ---
> hw/riscv/boot.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Bin Meng <bin.meng@windriver.com>
Tested-by: Bin Meng <bin.meng@windriver.com>
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2021-01-05 3:11 ` Bin Meng
0 siblings, 0 replies; 42+ messages in thread
From: Bin Meng @ 2021-01-05 3:11 UTC (permalink / raw)
To: Atish Patra
Cc: qemu-devel@nongnu.org Developers, open list:RISC-V,
Alistair Francis, Bastian Koppelmann, Palmer Dabbelt,
Sagar Karandikar, Anup Patel
On Fri, Dec 18, 2020 at 5:48 AM Atish Patra <atish.patra@wdc.com> 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 <atish.patra@wdc.com>
> ---
> hw/riscv/boot.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Bin Meng <bin.meng@windriver.com>
Tested-by: Bin Meng <bin.meng@windriver.com>
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
2021-01-05 3:11 ` Bin Meng
@ 2021-01-05 21:02 ` Alistair Francis
-1 siblings, 0 replies; 42+ messages in thread
From: Alistair Francis @ 2021-01-05 21:02 UTC (permalink / raw)
To: Bin Meng
Cc: open list:RISC-V, Sagar Karandikar, Bastian Koppelmann,
Anup Patel, qemu-devel@nongnu.org Developers, Atish Patra,
Alistair Francis, Palmer Dabbelt
On Mon, Jan 4, 2021 at 7:11 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> On Fri, Dec 18, 2020 at 5:48 AM Atish Patra <atish.patra@wdc.com> 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 <atish.patra@wdc.com>
> > ---
> > hw/riscv/boot.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
>
> Reviewed-by: Bin Meng <bin.meng@windriver.com>
> Tested-by: Bin Meng <bin.meng@windriver.com>
Thanks!
Applied to riscv-to-apply.next
Alistair
>
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2021-01-05 21:02 ` Alistair Francis
0 siblings, 0 replies; 42+ messages in thread
From: Alistair Francis @ 2021-01-05 21:02 UTC (permalink / raw)
To: Bin Meng
Cc: Atish Patra, open list:RISC-V, Sagar Karandikar,
Bastian Koppelmann, Anup Patel, qemu-devel@nongnu.org Developers,
Alistair Francis, Palmer Dabbelt
On Mon, Jan 4, 2021 at 7:11 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> On Fri, Dec 18, 2020 at 5:48 AM Atish Patra <atish.patra@wdc.com> 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 <atish.patra@wdc.com>
> > ---
> > hw/riscv/boot.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
>
> Reviewed-by: Bin Meng <bin.meng@windriver.com>
> Tested-by: Bin Meng <bin.meng@windriver.com>
Thanks!
Applied to riscv-to-apply.next
Alistair
>
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
2021-01-05 3:11 ` Bin Meng
@ 2021-01-05 23:44 ` Atish Patra
-1 siblings, 0 replies; 42+ messages in thread
From: Atish Patra @ 2021-01-05 23:44 UTC (permalink / raw)
To: bmeng.cn
Cc: qemu-riscv, sagark, kbastian, Anup Patel, qemu-devel,
Alistair Francis, palmer
On Tue, 2021-01-05 at 11:11 +0800, Bin Meng wrote:
> On Fri, Dec 18, 2020 at 5:48 AM Atish Patra <atish.patra@wdc.com>
> 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 <atish.patra@wdc.com>
> > ---
> > hw/riscv/boot.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
>
> Reviewed-by: Bin Meng <bin.meng@windriver.com>
> Tested-by: Bin Meng <bin.meng@windriver.com>
Thanks.
--
Regards,
Atish
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2021-01-05 23:44 ` Atish Patra
0 siblings, 0 replies; 42+ messages in thread
From: Atish Patra @ 2021-01-05 23:44 UTC (permalink / raw)
To: bmeng.cn
Cc: Anup Patel, qemu-riscv, kbastian, Alistair Francis, palmer,
qemu-devel, sagark
On Tue, 2021-01-05 at 11:11 +0800, Bin Meng wrote:
> On Fri, Dec 18, 2020 at 5:48 AM Atish Patra <atish.patra@wdc.com>
> 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 <atish.patra@wdc.com>
> > ---
> > hw/riscv/boot.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
>
> Reviewed-by: Bin Meng <bin.meng@windriver.com>
> Tested-by: Bin Meng <bin.meng@windriver.com>
Thanks.
--
Regards,
Atish
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
2021-01-05 23:44 ` Atish Patra
@ 2021-01-06 0:04 ` Bin Meng
-1 siblings, 0 replies; 42+ messages in thread
From: Bin Meng @ 2021-01-06 0:04 UTC (permalink / raw)
To: Atish Patra
Cc: qemu-riscv, sagark, kbastian, Anup Patel, qemu-devel,
Alistair Francis, palmer
Hi Atish,
On Wed, Jan 6, 2021 at 7:44 AM Atish Patra <Atish.Patra@wdc.com> wrote:
>
> On Tue, 2021-01-05 at 11:11 +0800, Bin Meng wrote:
> > On Fri, Dec 18, 2020 at 5:48 AM Atish Patra <atish.patra@wdc.com>
> > 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
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2021-01-06 0:04 ` Bin Meng
0 siblings, 0 replies; 42+ messages in thread
From: Bin Meng @ 2021-01-06 0:04 UTC (permalink / raw)
To: Atish Patra
Cc: Anup Patel, qemu-riscv, kbastian, Alistair Francis, palmer,
qemu-devel, sagark
Hi Atish,
On Wed, Jan 6, 2021 at 7:44 AM Atish Patra <Atish.Patra@wdc.com> wrote:
>
> On Tue, 2021-01-05 at 11:11 +0800, Bin Meng wrote:
> > On Fri, Dec 18, 2020 at 5:48 AM Atish Patra <atish.patra@wdc.com>
> > 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
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
2021-01-06 0:04 ` Bin Meng
@ 2021-01-06 2:14 ` Atish Patra
-1 siblings, 0 replies; 42+ messages in thread
From: Atish Patra @ 2021-01-06 2:14 UTC (permalink / raw)
To: bmeng.cn
Cc: qemu-riscv, sagark, kbastian, Anup Patel, qemu-devel,
Alistair Francis, palmer
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 <Atish.Patra@wdc.com>
> wrote:
> >
> > On Tue, 2021-01-05 at 11:11 +0800, Bin Meng wrote:
> > > On Fri, Dec 18, 2020 at 5:48 AM Atish Patra <atish.patra@wdc.com>
> > > 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
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB
@ 2021-01-06 2:14 ` Atish Patra
0 siblings, 0 replies; 42+ messages in thread
From: Atish Patra @ 2021-01-06 2:14 UTC (permalink / raw)
To: bmeng.cn
Cc: sagark, qemu-riscv, kbastian, Alistair Francis, palmer,
Anup Patel, qemu-devel
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 <Atish.Patra@wdc.com>
> wrote:
> >
> > On Tue, 2021-01-05 at 11:11 +0800, Bin Meng wrote:
> > > On Fri, Dec 18, 2020 at 5:48 AM Atish Patra <atish.patra@wdc.com>
> > > 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
^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2021-01-06 2:14 UTC | newest]
Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-17 21:48 [PATCH] RISC-V: Place DTB at 3GB boundary instead of 4GB Atish Patra
2020-12-17 21:48 ` Atish Patra
2020-12-17 22:31 ` Palmer Dabbelt
2020-12-17 22:31 ` Palmer Dabbelt
2020-12-17 22:35 ` Atish Patra
2020-12-17 22:35 ` Atish Patra
2020-12-17 22:39 ` Palmer Dabbelt
2020-12-17 22:39 ` Palmer Dabbelt
2020-12-18 7:21 ` Bin Meng
2020-12-18 7:21 ` Bin Meng
2020-12-18 7:27 ` Atish Patra
2020-12-18 7:27 ` Atish Patra
2020-12-18 7:33 ` Bin Meng
2020-12-18 7:33 ` Bin Meng
2020-12-18 8:00 ` Atish Patra
2020-12-18 8:00 ` Atish Patra
2020-12-18 8:42 ` Bin Meng
2020-12-18 8:42 ` Bin Meng
2020-12-18 19:46 ` Atish Patra
2020-12-18 19:46 ` Atish Patra
2020-12-22 5:35 ` Bin Meng
2020-12-22 5:35 ` Bin Meng
2020-12-22 19:59 ` Atish Patra
2020-12-22 19:59 ` Atish Patra
2020-12-23 1:20 ` Bin Meng
2020-12-23 1:20 ` Bin Meng
2020-12-29 4:49 ` Bin Meng
2020-12-29 4:49 ` Bin Meng
2021-01-04 20:24 ` Atish Patra
2021-01-04 20:24 ` Atish Patra
2021-01-05 3:06 ` Bin Meng
2021-01-05 3:06 ` Bin Meng
2021-01-05 3:11 ` Bin Meng
2021-01-05 3:11 ` Bin Meng
2021-01-05 21:02 ` Alistair Francis
2021-01-05 21:02 ` Alistair Francis
2021-01-05 23:44 ` Atish Patra
2021-01-05 23:44 ` Atish Patra
2021-01-06 0:04 ` Bin Meng
2021-01-06 0:04 ` Bin Meng
2021-01-06 2:14 ` Atish Patra
2021-01-06 2:14 ` Atish Patra
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.