[PATCH 01/12] RISC-V: defconfigs: Set CONFIG_FB=y, for FB console

[PATCH 01/12] RISC-V: defconfigs: Set CONFIG_FB=y, for FB console

[Palmer Dabbelt]

From: Palmer Dabbelt <palmer@rivosinc.com>

We have CONFIG_FRAMEBUFFER_CONSOLE=y in the defconfigs, but that depends
on CONFIG_FB so it's not actually getting set.  I'm assuming most users
on real systems want a framebuffer console, so this enables CONFIG_FB to
allow that to take effect.

Fixes: 33c57c0d3c67 ("RISC-V: Add a basic defconfig")
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
---
 arch/riscv/configs/defconfig      | 1 +
 arch/riscv/configs/rv32_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index ef473e2f503b..11de2ab9ed6e 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -78,6 +78,7 @@ CONFIG_DRM=m
 CONFIG_DRM_RADEON=m
 CONFIG_DRM_NOUVEAU=m
 CONFIG_DRM_VIRTIO_GPU=m
+CONFIG_FB=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
diff --git a/arch/riscv/configs/rv32_defconfig b/arch/riscv/configs/rv32_defconfig
index 6e9f12ff968a..05b6f17adbc1 100644
--- a/arch/riscv/configs/rv32_defconfig
+++ b/arch/riscv/configs/rv32_defconfig
@@ -73,6 +73,7 @@ CONFIG_POWER_RESET=y
 CONFIG_DRM=y
 CONFIG_DRM_RADEON=y
 CONFIG_DRM_VIRTIO_GPU=y
+CONFIG_FB=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
-- 
2.32.0

[PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW

[Palmer Dabbelt]

From: Palmer Dabbelt <palmer@rivosinc.com>

For non-relocatable kernels we need to be able to link the kernel at
approximately PAGE_OFFSET, thus requiring medany (as medlow requires the
code to be linked within 2GiB of 0).  The inverse doesn't apply, though:
since medany code can be linked anywhere it's fine to link it close to
0, so we can support the smaller memory config.

Fixes: de5f4b8f634b ("RISC-V: Define MAXPHYSMEM_1GB only for RV32")
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>

---

I found this when going through the savedefconfig diffs for the K210
defconfigs.  I'm not entirely sure they're doing the right thing here
(they should probably be setting CMODEL_LOW to take advantage of the
better code generation), but I don't have any way to test those
platforms so I don't want to change too much.
---
 arch/riscv/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 821252b65f89..61f64512dcde 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -280,7 +280,7 @@ choice
 		depends on 32BIT
 		bool "1GiB"
 	config MAXPHYSMEM_2GB
-		depends on 64BIT && CMODEL_MEDLOW
+		depends on 64BIT
 		bool "2GiB"
 	config MAXPHYSMEM_128GB
 		depends on 64BIT && CMODEL_MEDANY
-- 
2.32.0

Re: [PATCH 01/12] RISC-V: defconfigs: Set CONFIG_FB=y, for FB console

[Anup Patel]

On Fri, Nov 19, 2021 at 10:14 PM Palmer Dabbelt <palmer@rivosinc.com> wrote:
>
> From: Palmer Dabbelt <palmer@rivosinc.com>
>
> We have CONFIG_FRAMEBUFFER_CONSOLE=y in the defconfigs, but that depends
> on CONFIG_FB so it's not actually getting set.  I'm assuming most users
> on real systems want a framebuffer console, so this enables CONFIG_FB to
> allow that to take effect.
>
> Fixes: 33c57c0d3c67 ("RISC-V: Add a basic defconfig")
> Cc: stable@vger.kernel.org
> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>

Looks good to me.

Reviewed-by: Anup Patel <anup@brainfault.org>

Regards,
Anup

> ---
>  arch/riscv/configs/defconfig      | 1 +
>  arch/riscv/configs/rv32_defconfig | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
> index ef473e2f503b..11de2ab9ed6e 100644
> --- a/arch/riscv/configs/defconfig
> +++ b/arch/riscv/configs/defconfig
> @@ -78,6 +78,7 @@ CONFIG_DRM=m
>  CONFIG_DRM_RADEON=m
>  CONFIG_DRM_NOUVEAU=m
>  CONFIG_DRM_VIRTIO_GPU=m
> +CONFIG_FB=y
>  CONFIG_FRAMEBUFFER_CONSOLE=y
>  CONFIG_USB=y
>  CONFIG_USB_XHCI_HCD=y
> diff --git a/arch/riscv/configs/rv32_defconfig b/arch/riscv/configs/rv32_defconfig
> index 6e9f12ff968a..05b6f17adbc1 100644
> --- a/arch/riscv/configs/rv32_defconfig
> +++ b/arch/riscv/configs/rv32_defconfig
> @@ -73,6 +73,7 @@ CONFIG_POWER_RESET=y
>  CONFIG_DRM=y
>  CONFIG_DRM_RADEON=y
>  CONFIG_DRM_VIRTIO_GPU=y
> +CONFIG_FB=y
>  CONFIG_FRAMEBUFFER_CONSOLE=y
>  CONFIG_USB=y
>  CONFIG_USB_XHCI_HCD=y
> --
> 2.32.0
>

Re: [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW

[Anup Patel]

On Fri, Nov 19, 2021 at 10:14 PM Palmer Dabbelt <palmer@rivosinc.com> wrote:
>
> From: Palmer Dabbelt <palmer@rivosinc.com>
>
> For non-relocatable kernels we need to be able to link the kernel at
> approximately PAGE_OFFSET, thus requiring medany (as medlow requires the
> code to be linked within 2GiB of 0).  The inverse doesn't apply, though:
> since medany code can be linked anywhere it's fine to link it close to
> 0, so we can support the smaller memory config.
>
> Fixes: de5f4b8f634b ("RISC-V: Define MAXPHYSMEM_1GB only for RV32")
> Cc: stable@vger.kernel.org
> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>

Looks good to me.

Reviewed-by: Anup Patel <anup@brainfault.org>

Regards,
Anup

>
> ---
>
> I found this when going through the savedefconfig diffs for the K210
> defconfigs.  I'm not entirely sure they're doing the right thing here
> (they should probably be setting CMODEL_LOW to take advantage of the
> better code generation), but I don't have any way to test those
> platforms so I don't want to change too much.
> ---
>  arch/riscv/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 821252b65f89..61f64512dcde 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -280,7 +280,7 @@ choice
>                 depends on 32BIT
>                 bool "1GiB"
>         config MAXPHYSMEM_2GB
> -               depends on 64BIT && CMODEL_MEDLOW
> +               depends on 64BIT
>                 bool "2GiB"
>         config MAXPHYSMEM_128GB
>                 depends on 64BIT && CMODEL_MEDANY
> --
> 2.32.0
>

Re: [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW

[Geert Uytterhoeven]

Hi Palmer,

On Fri, Nov 19, 2021 at 5:47 PM Palmer Dabbelt <palmer@rivosinc.com> wrote:
> From: Palmer Dabbelt <palmer@rivosinc.com>
>
> For non-relocatable kernels we need to be able to link the kernel at
> approximately PAGE_OFFSET, thus requiring medany (as medlow requires the
> code to be linked within 2GiB of 0).  The inverse doesn't apply, though:
> since medany code can be linked anywhere it's fine to link it close to
> 0, so we can support the smaller memory config.
>
> Fixes: de5f4b8f634b ("RISC-V: Define MAXPHYSMEM_1GB only for RV32")
> Cc: stable@vger.kernel.org
> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>

Thanks for your patch, which is now commit 9f36b96bc70f9707 ("RISC-V:
MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW").

> I found this when going through the savedefconfig diffs for the K210
> defconfigs.  I'm not entirely sure they're doing the right thing here
> (they should probably be setting CMODEL_LOW to take advantage of the
> better code generation), but I don't have any way to test those
> platforms so I don't want to change too much.

I can confirm MAXPHYSMEM_2GB works on K210 with CMODEL_MEDANY.

As the Icicle has 1760 MiB of RAM, I gave it a try with MAXPHYSMEM_2GB
(and CMODEL_MEDANY), too.  Unfortunately it crashes very early
(needs earlycon to see):

    OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
    Machine model: Microchip PolarFire-SoC Icicle Kit
    printk: debug: ignoring loglevel setting.
    earlycon: ns16550a0 at MMIO32 0x0000000020100000 (options '115200n8')
    printk: bootconsole [ns16550a0] enabled
    printk: debug: skip boot console de-registration.
    efi: UEFI not found.
    Unable to handle kernel paging request at virtual address ffffffff87e00001
    Oops [#1]
    Modules linked in:
    CPU: 0 PID: 0 Comm: swapper Not tainted 5.16.0-08771-g85515233477d #56
    Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)
    epc : fdt_check_header+0x14/0x208
     ra : early_init_dt_verify+0x16/0x94
    epc : ffffffff802ddacc ra : ffffffff8082415a sp : ffffffff81203ee0
     gp : ffffffff812ec3a8 tp : ffffffff8120cd80 t0 : 0000000000000005
     t1 : 0000001040000000 t2 : ffffffff80000000 s0 : ffffffff81203f00
     s1 : ffffffff87e00000 a0 : ffffffff87e00000 a1 : 000000040ffffce7
     a2 : 00000000000000e7 a3 : ffffffff8080394c a4 : 0000000000000000
     a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000
     s2 : ffffffff81203f98 s3 : 8000000a00006800 s4 : fffffffffffffff3
     s5 : 0000000000000000 s6 : 0000000000000001 s7 : 0000000000000000
     s8 : 0000000020236c20 s9 : 0000000000000000 s10: 0000000000000000
     s11: 0000000000000000 t3 : 0000000000000018 t4 : 00ff000000000000
     t5 : 0000000000000000 t6 : 0000000000000010
    status: 0000000200000100 badaddr: ffffffff87e00001 cause: 000000000000000d
    [<ffffffff802ddacc>] fdt_check_header+0x14/0x208
    [<ffffffff8082415a>] early_init_dt_verify+0x16/0x94
    [<ffffffff80802dee>] setup_arch+0xec/0x4ec
    [<ffffffff80800700>] start_kernel+0x88/0x6d6
    random: get_random_bytes called from
print_oops_end_marker+0x22/0x44 with crng_init=0
    ---[ end trace 903df1a0ade0b876 ]---
    Kernel panic - not syncing: Attempted to kill the idle task!
    ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---

So the FDT is at 0xffffffff87e00000, i.e. at 0x7e00000 from the start
of virtual memory (CONFIG_PAGE_OFFSET=0xffffffff80000000), and thus
within the 2 GiB range.

> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -280,7 +280,7 @@ choice
>                 depends on 32BIT
>                 bool "1GiB"
>         config MAXPHYSMEM_2GB
> -               depends on 64BIT && CMODEL_MEDLOW
> +               depends on 64BIT
>                 bool "2GiB"
>         config MAXPHYSMEM_128GB
>                 depends on 64BIT && CMODEL_MEDANY

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW

[Alexandre ghiti]

Hi Geert,

On 1/11/22 17:04, Geert Uytterhoeven wrote:
> Hi Palmer,
>
> On Fri, Nov 19, 2021 at 5:47 PM Palmer Dabbelt <palmer@rivosinc.com> wrote:
>> From: Palmer Dabbelt <palmer@rivosinc.com>
>>
>> For non-relocatable kernels we need to be able to link the kernel at
>> approximately PAGE_OFFSET, thus requiring medany (as medlow requires the
>> code to be linked within 2GiB of 0).  The inverse doesn't apply, though:
>> since medany code can be linked anywhere it's fine to link it close to
>> 0, so we can support the smaller memory config.
>>
>> Fixes: de5f4b8f634b ("RISC-V: Define MAXPHYSMEM_1GB only for RV32")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
> Thanks for your patch, which is now commit 9f36b96bc70f9707 ("RISC-V:
> MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW").
>
>> I found this when going through the savedefconfig diffs for the K210
>> defconfigs.  I'm not entirely sure they're doing the right thing here
>> (they should probably be setting CMODEL_LOW to take advantage of the
>> better code generation), but I don't have any way to test those
>> platforms so I don't want to change too much.
> I can confirm MAXPHYSMEM_2GB works on K210 with CMODEL_MEDANY.
>
> As the Icicle has 1760 MiB of RAM, I gave it a try with MAXPHYSMEM_2GB
> (and CMODEL_MEDANY), too.  Unfortunately it crashes very early
> (needs earlycon to see):
>
>      OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
>      Machine model: Microchip PolarFire-SoC Icicle Kit
>      printk: debug: ignoring loglevel setting.
>      earlycon: ns16550a0 at MMIO32 0x0000000020100000 (options '115200n8')
>      printk: bootconsole [ns16550a0] enabled
>      printk: debug: skip boot console de-registration.
>      efi: UEFI not found.
>      Unable to handle kernel paging request at virtual address ffffffff87e00001
>      Oops [#1]
>      Modules linked in:
>      CPU: 0 PID: 0 Comm: swapper Not tainted 5.16.0-08771-g85515233477d #56
>      Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)
>      epc : fdt_check_header+0x14/0x208
>       ra : early_init_dt_verify+0x16/0x94
>      epc : ffffffff802ddacc ra : ffffffff8082415a sp : ffffffff81203ee0
>       gp : ffffffff812ec3a8 tp : ffffffff8120cd80 t0 : 0000000000000005
>       t1 : 0000001040000000 t2 : ffffffff80000000 s0 : ffffffff81203f00
>       s1 : ffffffff87e00000 a0 : ffffffff87e00000 a1 : 000000040ffffce7
>       a2 : 00000000000000e7 a3 : ffffffff8080394c a4 : 0000000000000000
>       a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000
>       s2 : ffffffff81203f98 s3 : 8000000a00006800 s4 : fffffffffffffff3
>       s5 : 0000000000000000 s6 : 0000000000000001 s7 : 0000000000000000
>       s8 : 0000000020236c20 s9 : 0000000000000000 s10: 0000000000000000
>       s11: 0000000000000000 t3 : 0000000000000018 t4 : 00ff000000000000
>       t5 : 0000000000000000 t6 : 0000000000000010
>      status: 0000000200000100 badaddr: ffffffff87e00001 cause: 000000000000000d
>      [<ffffffff802ddacc>] fdt_check_header+0x14/0x208
>      [<ffffffff8082415a>] early_init_dt_verify+0x16/0x94
>      [<ffffffff80802dee>] setup_arch+0xec/0x4ec
>      [<ffffffff80800700>] start_kernel+0x88/0x6d6
>      random: get_random_bytes called from
> print_oops_end_marker+0x22/0x44 with crng_init=0
>      ---[ end trace 903df1a0ade0b876 ]---
>      Kernel panic - not syncing: Attempted to kill the idle task!
>      ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
>
> So the FDT is at 0xffffffff87e00000, i.e. at 0x7e00000 from the start
> of virtual memory (CONFIG_PAGE_OFFSET=0xffffffff80000000), and thus
> within the 2 GiB range.


I think you have just encountered what I suspected and mentioned in [1]: 
we recently moved the kernel to the PAGE_OFFSET address used with 
MAXPHYSMEM_2GB.

I would try to cherry-pick [1] and see if that works better :)

Alex

[1] 
https://patchwork.kernel.org/project/linux-riscv/patch/20211206104657.433304-6-alexandre.ghiti@canonical.com/


>
>> --- a/arch/riscv/Kconfig
>> +++ b/arch/riscv/Kconfig
>> @@ -280,7 +280,7 @@ choice
>>                  depends on 32BIT
>>                  bool "1GiB"
>>          config MAXPHYSMEM_2GB
>> -               depends on 64BIT && CMODEL_MEDLOW
>> +               depends on 64BIT
>>                  bool "2GiB"
>>          config MAXPHYSMEM_128GB
>>                  depends on 64BIT && CMODEL_MEDANY
> Gr{oetje,eeting}s,
>
>                          Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW

[Conor.Dooley]

On 11/01/2022 16:04, Geert Uytterhoeven wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi Palmer,
> 
> On Fri, Nov 19, 2021 at 5:47 PM Palmer Dabbelt <palmer@rivosinc.com> wrote:
>> From: Palmer Dabbelt <palmer@rivosinc.com>
>>
>> For non-relocatable kernels we need to be able to link the kernel at
>> approximately PAGE_OFFSET, thus requiring medany (as medlow requires the
>> code to be linked within 2GiB of 0).  The inverse doesn't apply, though:
>> since medany code can be linked anywhere it's fine to link it close to
>> 0, so we can support the smaller memory config.
>>
>> Fixes: de5f4b8f634b ("RISC-V: Define MAXPHYSMEM_1GB only for RV32")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
> 
> Thanks for your patch, which is now commit 9f36b96bc70f9707 ("RISC-V:
> MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW").
> 
>> I found this when going through the savedefconfig diffs for the K210
>> defconfigs.  I'm not entirely sure they're doing the right thing here
>> (they should probably be setting CMODEL_LOW to take advantage of the
>> better code generation), but I don't have any way to test those
>> platforms so I don't want to change too much.
> 
> I can confirm MAXPHYSMEM_2GB works on K210 with CMODEL_MEDANY.
> 
> As the Icicle has 1760 MiB of RAM, I gave it a try with MAXPHYSMEM_2GB
> (and CMODEL_MEDANY), too.  Unfortunately it crashes very early
> (needs earlycon to see):
Given you said 1760 MiB I assume you're not running the device tree 
currently in the kernel?
But the defconfig is /arch/riscv/configs/defconfig?

I tested it w/ my newer version of the dts, using both 1760 & 736 MiB 
(ddrc_cache_lo only) w/ MAXPHYSMEM_2GB.
Enabling MAXPHYSMEM_2GB with either CMODEL_MEDANY or CMODEL_MEDLOW
lead to the same boot failure as you got.
> 
>      OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
>      Machine model: Microchip PolarFire-SoC Icicle Kit
>      printk: debug: ignoring loglevel setting.
>      earlycon: ns16550a0 at MMIO32 0x0000000020100000 (options '115200n8')
>      printk: bootconsole [ns16550a0] enabled
>      printk: debug: skip boot console de-registration.
>      efi: UEFI not found.
>      Unable to handle kernel paging request at virtual address ffffffff87e00001
>      Oops [#1]
>      Modules linked in:
>      CPU: 0 PID: 0 Comm: swapper Not tainted 5.16.0-08771-g85515233477d #56
>      Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)
>      epc : fdt_check_header+0x14/0x208
>       ra : early_init_dt_verify+0x16/0x94
>      epc : ffffffff802ddacc ra : ffffffff8082415a sp : ffffffff81203ee0
>       gp : ffffffff812ec3a8 tp : ffffffff8120cd80 t0 : 0000000000000005
>       t1 : 0000001040000000 t2 : ffffffff80000000 s0 : ffffffff81203f00
>       s1 : ffffffff87e00000 a0 : ffffffff87e00000 a1 : 000000040ffffce7
>       a2 : 00000000000000e7 a3 : ffffffff8080394c a4 : 0000000000000000
>       a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000
>       s2 : ffffffff81203f98 s3 : 8000000a00006800 s4 : fffffffffffffff3
>       s5 : 0000000000000000 s6 : 0000000000000001 s7 : 0000000000000000
>       s8 : 0000000020236c20 s9 : 0000000000000000 s10: 0000000000000000
>       s11: 0000000000000000 t3 : 0000000000000018 t4 : 00ff000000000000
>       t5 : 0000000000000000 t6 : 0000000000000010
>      status: 0000000200000100 badaddr: ffffffff87e00001 cause: 000000000000000d
>      [<ffffffff802ddacc>] fdt_check_header+0x14/0x208
>      [<ffffffff8082415a>] early_init_dt_verify+0x16/0x94
>      [<ffffffff80802dee>] setup_arch+0xec/0x4ec
>      [<ffffffff80800700>] start_kernel+0x88/0x6d6
>      random: get_random_bytes called from
> print_oops_end_marker+0x22/0x44 with crng_init=0
>      ---[ end trace 903df1a0ade0b876 ]---
>      Kernel panic - not syncing: Attempted to kill the idle task!
>      ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
> 
> So the FDT is at 0xffffffff87e00000, i.e. at 0x7e00000 from the start
> of virtual memory (CONFIG_PAGE_OFFSET=0xffffffff80000000), and thus
> within the 2 GiB range.
> 
>> --- a/arch/riscv/Kconfig
>> +++ b/arch/riscv/Kconfig
>> @@ -280,7 +280,7 @@ choice
>>                  depends on 32BIT
>>                  bool "1GiB"
>>          config MAXPHYSMEM_2GB
>> -               depends on 64BIT && CMODEL_MEDLOW
>> +               depends on 64BIT
>>                  bool "2GiB"
>>          config MAXPHYSMEM_128GB
>>                  depends on 64BIT && CMODEL_MEDANY
> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
> 

Re: [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW

[Alexandre ghiti]

Hi Conor,

On 1/14/22 09:40, Conor.Dooley@microchip.com wrote:
> On 11/01/2022 16:04, Geert Uytterhoeven wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> Hi Palmer,
>>
>> On Fri, Nov 19, 2021 at 5:47 PM Palmer Dabbelt <palmer@rivosinc.com> wrote:
>>> From: Palmer Dabbelt <palmer@rivosinc.com>
>>>
>>> For non-relocatable kernels we need to be able to link the kernel at
>>> approximately PAGE_OFFSET, thus requiring medany (as medlow requires the
>>> code to be linked within 2GiB of 0).  The inverse doesn't apply, though:
>>> since medany code can be linked anywhere it's fine to link it close to
>>> 0, so we can support the smaller memory config.
>>>
>>> Fixes: de5f4b8f634b ("RISC-V: Define MAXPHYSMEM_1GB only for RV32")
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
>> Thanks for your patch, which is now commit 9f36b96bc70f9707 ("RISC-V:
>> MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW").
>>
>>> I found this when going through the savedefconfig diffs for the K210
>>> defconfigs.  I'm not entirely sure they're doing the right thing here
>>> (they should probably be setting CMODEL_LOW to take advantage of the
>>> better code generation), but I don't have any way to test those
>>> platforms so I don't want to change too much.
>> I can confirm MAXPHYSMEM_2GB works on K210 with CMODEL_MEDANY.
>>
>> As the Icicle has 1760 MiB of RAM, I gave it a try with MAXPHYSMEM_2GB
>> (and CMODEL_MEDANY), too.  Unfortunately it crashes very early
>> (needs earlycon to see):
> Given you said 1760 MiB I assume you're not running the device tree
> currently in the kernel?
> But the defconfig is /arch/riscv/configs/defconfig?
>
> I tested it w/ my newer version of the dts, using both 1760 & 736 MiB
> (ddrc_cache_lo only) w/ MAXPHYSMEM_2GB.
> Enabling MAXPHYSMEM_2GB with either CMODEL_MEDANY or CMODEL_MEDLOW
> lead to the same boot failure as you got.


Any chance you can give a try to [1] so that I can extract it from my 
sv48 patchset and propose it to fixes if it works?

Thanks,

Alex

https://patchwork.kernel.org/project/linux-riscv/patch/20211206104657.433304-6-alexandre.ghiti@canonical.com/


>>       OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
>>       Machine model: Microchip PolarFire-SoC Icicle Kit
>>       printk: debug: ignoring loglevel setting.
>>       earlycon: ns16550a0 at MMIO32 0x0000000020100000 (options '115200n8')
>>       printk: bootconsole [ns16550a0] enabled
>>       printk: debug: skip boot console de-registration.
>>       efi: UEFI not found.
>>       Unable to handle kernel paging request at virtual address ffffffff87e00001
>>       Oops [#1]
>>       Modules linked in:
>>       CPU: 0 PID: 0 Comm: swapper Not tainted 5.16.0-08771-g85515233477d #56
>>       Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)
>>       epc : fdt_check_header+0x14/0x208
>>        ra : early_init_dt_verify+0x16/0x94
>>       epc : ffffffff802ddacc ra : ffffffff8082415a sp : ffffffff81203ee0
>>        gp : ffffffff812ec3a8 tp : ffffffff8120cd80 t0 : 0000000000000005
>>        t1 : 0000001040000000 t2 : ffffffff80000000 s0 : ffffffff81203f00
>>        s1 : ffffffff87e00000 a0 : ffffffff87e00000 a1 : 000000040ffffce7
>>        a2 : 00000000000000e7 a3 : ffffffff8080394c a4 : 0000000000000000
>>        a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000
>>        s2 : ffffffff81203f98 s3 : 8000000a00006800 s4 : fffffffffffffff3
>>        s5 : 0000000000000000 s6 : 0000000000000001 s7 : 0000000000000000
>>        s8 : 0000000020236c20 s9 : 0000000000000000 s10: 0000000000000000
>>        s11: 0000000000000000 t3 : 0000000000000018 t4 : 00ff000000000000
>>        t5 : 0000000000000000 t6 : 0000000000000010
>>       status: 0000000200000100 badaddr: ffffffff87e00001 cause: 000000000000000d
>>       [<ffffffff802ddacc>] fdt_check_header+0x14/0x208
>>       [<ffffffff8082415a>] early_init_dt_verify+0x16/0x94
>>       [<ffffffff80802dee>] setup_arch+0xec/0x4ec
>>       [<ffffffff80800700>] start_kernel+0x88/0x6d6
>>       random: get_random_bytes called from
>> print_oops_end_marker+0x22/0x44 with crng_init=0
>>       ---[ end trace 903df1a0ade0b876 ]---
>>       Kernel panic - not syncing: Attempted to kill the idle task!
>>       ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
>>
>> So the FDT is at 0xffffffff87e00000, i.e. at 0x7e00000 from the start
>> of virtual memory (CONFIG_PAGE_OFFSET=0xffffffff80000000), and thus
>> within the 2 GiB range.
>>
>>> --- a/arch/riscv/Kconfig
>>> +++ b/arch/riscv/Kconfig
>>> @@ -280,7 +280,7 @@ choice
>>>                   depends on 32BIT
>>>                   bool "1GiB"
>>>           config MAXPHYSMEM_2GB
>>> -               depends on 64BIT && CMODEL_MEDLOW
>>> +               depends on 64BIT
>>>                   bool "2GiB"
>>>           config MAXPHYSMEM_128GB
>>>                   depends on 64BIT && CMODEL_MEDANY
>> Gr{oetje,eeting}s,
>>
>>                           Geert
>>
>> --
>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>>
>> In personal conversations with technical people, I call myself a hacker. But
>> when I'm talking to journalists I just say "programmer" or something like that.
>>                                   -- Linus Torvalds
>>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW

[Conor.Dooley]

On 14/01/2022 09:09, Alexandre ghiti wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know 
> the content is safe
> 
> Hi Conor,
> 
> On 1/14/22 09:40, Conor.Dooley@microchip.com wrote:
>> On 11/01/2022 16:04, Geert Uytterhoeven wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you 
>>> know the content is safe
>>>
>>> Hi Palmer,
>>>
>>> On Fri, Nov 19, 2021 at 5:47 PM Palmer Dabbelt <palmer@rivosinc.com> 
>>> wrote:
>>>> From: Palmer Dabbelt <palmer@rivosinc.com>
>>>>
>>>> For non-relocatable kernels we need to be able to link the kernel at
>>>> approximately PAGE_OFFSET, thus requiring medany (as medlow requires 
>>>> the
>>>> code to be linked within 2GiB of 0).  The inverse doesn't apply, 
>>>> though:
>>>> since medany code can be linked anywhere it's fine to link it close to
>>>> 0, so we can support the smaller memory config.
>>>>
>>>> Fixes: de5f4b8f634b ("RISC-V: Define MAXPHYSMEM_1GB only for RV32")
>>>> Cc: stable@vger.kernel.org
>>>> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
>>> Thanks for your patch, which is now commit 9f36b96bc70f9707 ("RISC-V:
>>> MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW").
>>>
>>>> I found this when going through the savedefconfig diffs for the K210
>>>> defconfigs.  I'm not entirely sure they're doing the right thing here
>>>> (they should probably be setting CMODEL_LOW to take advantage of the
>>>> better code generation), but I don't have any way to test those
>>>> platforms so I don't want to change too much.
>>> I can confirm MAXPHYSMEM_2GB works on K210 with CMODEL_MEDANY.
>>>
>>> As the Icicle has 1760 MiB of RAM, I gave it a try with MAXPHYSMEM_2GB
>>> (and CMODEL_MEDANY), too.  Unfortunately it crashes very early
>>> (needs earlycon to see):
>> Given you said 1760 MiB I assume you're not running the device tree
>> currently in the kernel?
>> But the defconfig is /arch/riscv/configs/defconfig?
>>
>> I tested it w/ my newer version of the dts, using both 1760 & 736 MiB
>> (ddrc_cache_lo only) w/ MAXPHYSMEM_2GB.
>> Enabling MAXPHYSMEM_2GB with either CMODEL_MEDANY or CMODEL_MEDLOW
>> lead to the same boot failure as you got.
> 
> 
> Any chance you can give a try to [1] so that I can extract it from my
> sv48 patchset and propose it to fixes if it works?
Applied, tested with 1760 & 736 MiB - booted fine. :)
> 
> Thanks,
> 
> Alex
> 
> https://patchwork.kernel.org/project/linux-riscv/patch/20211206104657.433304-6-alexandre.ghiti@canonical.com/ 
> 
> 
> 
>>>       OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
>>>       Machine model: Microchip PolarFire-SoC Icicle Kit
>>>       printk: debug: ignoring loglevel setting.
>>>       earlycon: ns16550a0 at MMIO32 0x0000000020100000 (options 
>>> '115200n8')
>>>       printk: bootconsole [ns16550a0] enabled
>>>       printk: debug: skip boot console de-registration.
>>>       efi: UEFI not found.
>>>       Unable to handle kernel paging request at virtual address 
>>> ffffffff87e00001
>>>       Oops [#1]
>>>       Modules linked in:
>>>       CPU: 0 PID: 0 Comm: swapper Not tainted 
>>> 5.16.0-08771-g85515233477d #56
>>>       Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)
>>>       epc : fdt_check_header+0x14/0x208
>>>        ra : early_init_dt_verify+0x16/0x94
>>>       epc : ffffffff802ddacc ra : ffffffff8082415a sp : ffffffff81203ee0
>>>        gp : ffffffff812ec3a8 tp : ffffffff8120cd80 t0 : 0000000000000005
>>>        t1 : 0000001040000000 t2 : ffffffff80000000 s0 : ffffffff81203f00
>>>        s1 : ffffffff87e00000 a0 : ffffffff87e00000 a1 : 000000040ffffce7
>>>        a2 : 00000000000000e7 a3 : ffffffff8080394c a4 : 0000000000000000
>>>        a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000
>>>        s2 : ffffffff81203f98 s3 : 8000000a00006800 s4 : fffffffffffffff3
>>>        s5 : 0000000000000000 s6 : 0000000000000001 s7 : 0000000000000000
>>>        s8 : 0000000020236c20 s9 : 0000000000000000 s10: 0000000000000000
>>>        s11: 0000000000000000 t3 : 0000000000000018 t4 : 00ff000000000000
>>>        t5 : 0000000000000000 t6 : 0000000000000010
>>>       status: 0000000200000100 badaddr: ffffffff87e00001 cause: 
>>> 000000000000000d
>>>       [<ffffffff802ddacc>] fdt_check_header+0x14/0x208
>>>       [<ffffffff8082415a>] early_init_dt_verify+0x16/0x94
>>>       [<ffffffff80802dee>] setup_arch+0xec/0x4ec
>>>       [<ffffffff80800700>] start_kernel+0x88/0x6d6
>>>       random: get_random_bytes called from
>>> print_oops_end_marker+0x22/0x44 with crng_init=0
>>>       ---[ end trace 903df1a0ade0b876 ]---
>>>       Kernel panic - not syncing: Attempted to kill the idle task!
>>>       ---[ end Kernel panic - not syncing: Attempted to kill the idle 
>>> task! ]---
>>>
>>> So the FDT is at 0xffffffff87e00000, i.e. at 0x7e00000 from the start
>>> of virtual memory (CONFIG_PAGE_OFFSET=0xffffffff80000000), and thus
>>> within the 2 GiB range.
>>>
>>>> --- a/arch/riscv/Kconfig
>>>> +++ b/arch/riscv/Kconfig
>>>> @@ -280,7 +280,7 @@ choice
>>>>                   depends on 32BIT
>>>>                   bool "1GiB"
>>>>           config MAXPHYSMEM_2GB
>>>> -               depends on 64BIT && CMODEL_MEDLOW
>>>> +               depends on 64BIT
>>>>                   bool "2GiB"
>>>>           config MAXPHYSMEM_128GB
>>>>                   depends on 64BIT && CMODEL_MEDANY
>>> Gr{oetje,eeting}s,
>>>
>>>                           Geert
>>>
>>> -- 
>>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
>>> geert@linux-m68k.org
>>>
>>> In personal conversations with technical people, I call myself a 
>>> hacker. But
>>> when I'm talking to journalists I just say "programmer" or something 
>>> like that.
>>>                                   -- Linus Torvalds
>>>
>>> _______________________________________________
>>> linux-riscv mailing list
>>> linux-riscv@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>>>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW

[Alexandre Ghiti]

On 1/14/22 10:41, Conor.Dooley@microchip.com wrote:
> On 14/01/2022 09:09, Alexandre ghiti wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>> the content is safe
>>
>> Hi Conor,
>>
>> On 1/14/22 09:40, Conor.Dooley@microchip.com wrote:
>>> On 11/01/2022 16:04, Geert Uytterhoeven wrote:
>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you
>>>> know the content is safe
>>>>
>>>> Hi Palmer,
>>>>
>>>> On Fri, Nov 19, 2021 at 5:47 PM Palmer Dabbelt <palmer@rivosinc.com>
>>>> wrote:
>>>>> From: Palmer Dabbelt <palmer@rivosinc.com>
>>>>>
>>>>> For non-relocatable kernels we need to be able to link the kernel at
>>>>> approximately PAGE_OFFSET, thus requiring medany (as medlow requires
>>>>> the
>>>>> code to be linked within 2GiB of 0).  The inverse doesn't apply,
>>>>> though:
>>>>> since medany code can be linked anywhere it's fine to link it close to
>>>>> 0, so we can support the smaller memory config.
>>>>>
>>>>> Fixes: de5f4b8f634b ("RISC-V: Define MAXPHYSMEM_1GB only for RV32")
>>>>> Cc: stable@vger.kernel.org
>>>>> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
>>>> Thanks for your patch, which is now commit 9f36b96bc70f9707 ("RISC-V:
>>>> MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW").
>>>>
>>>>> I found this when going through the savedefconfig diffs for the K210
>>>>> defconfigs.  I'm not entirely sure they're doing the right thing here
>>>>> (they should probably be setting CMODEL_LOW to take advantage of the
>>>>> better code generation), but I don't have any way to test those
>>>>> platforms so I don't want to change too much.
>>>> I can confirm MAXPHYSMEM_2GB works on K210 with CMODEL_MEDANY.
>>>>
>>>> As the Icicle has 1760 MiB of RAM, I gave it a try with MAXPHYSMEM_2GB
>>>> (and CMODEL_MEDANY), too.  Unfortunately it crashes very early
>>>> (needs earlycon to see):
>>> Given you said 1760 MiB I assume you're not running the device tree
>>> currently in the kernel?
>>> But the defconfig is /arch/riscv/configs/defconfig?
>>>
>>> I tested it w/ my newer version of the dts, using both 1760 & 736 MiB
>>> (ddrc_cache_lo only) w/ MAXPHYSMEM_2GB.
>>> Enabling MAXPHYSMEM_2GB with either CMODEL_MEDANY or CMODEL_MEDLOW
>>> lead to the same boot failure as you got.
>>
>> Any chance you can give a try to [1] so that I can extract it from my
>> sv48 patchset and propose it to fixes if it works?
> Applied, tested with 1760 & 736 MiB - booted fine. :)


Great, I'll extract it, rephrase it (since it is not a suspicion 
anymore), add Geert Reported-by and your Tested-by.

Thanks!

Alex


>> Thanks,
>>
>> Alex
>>
>> https://patchwork.kernel.org/project/linux-riscv/patch/20211206104657.433304-6-alexandre.ghiti@canonical.com/
>>
>>
>>
>>>>        OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
>>>>        Machine model: Microchip PolarFire-SoC Icicle Kit
>>>>        printk: debug: ignoring loglevel setting.
>>>>        earlycon: ns16550a0 at MMIO32 0x0000000020100000 (options
>>>> '115200n8')
>>>>        printk: bootconsole [ns16550a0] enabled
>>>>        printk: debug: skip boot console de-registration.
>>>>        efi: UEFI not found.
>>>>        Unable to handle kernel paging request at virtual address
>>>> ffffffff87e00001
>>>>        Oops [#1]
>>>>        Modules linked in:
>>>>        CPU: 0 PID: 0 Comm: swapper Not tainted
>>>> 5.16.0-08771-g85515233477d #56
>>>>        Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)
>>>>        epc : fdt_check_header+0x14/0x208
>>>>         ra : early_init_dt_verify+0x16/0x94
>>>>        epc : ffffffff802ddacc ra : ffffffff8082415a sp : ffffffff81203ee0
>>>>         gp : ffffffff812ec3a8 tp : ffffffff8120cd80 t0 : 0000000000000005
>>>>         t1 : 0000001040000000 t2 : ffffffff80000000 s0 : ffffffff81203f00
>>>>         s1 : ffffffff87e00000 a0 : ffffffff87e00000 a1 : 000000040ffffce7
>>>>         a2 : 00000000000000e7 a3 : ffffffff8080394c a4 : 0000000000000000
>>>>         a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000
>>>>         s2 : ffffffff81203f98 s3 : 8000000a00006800 s4 : fffffffffffffff3
>>>>         s5 : 0000000000000000 s6 : 0000000000000001 s7 : 0000000000000000
>>>>         s8 : 0000000020236c20 s9 : 0000000000000000 s10: 0000000000000000
>>>>         s11: 0000000000000000 t3 : 0000000000000018 t4 : 00ff000000000000
>>>>         t5 : 0000000000000000 t6 : 0000000000000010
>>>>        status: 0000000200000100 badaddr: ffffffff87e00001 cause:
>>>> 000000000000000d
>>>>        [<ffffffff802ddacc>] fdt_check_header+0x14/0x208
>>>>        [<ffffffff8082415a>] early_init_dt_verify+0x16/0x94
>>>>        [<ffffffff80802dee>] setup_arch+0xec/0x4ec
>>>>        [<ffffffff80800700>] start_kernel+0x88/0x6d6
>>>>        random: get_random_bytes called from
>>>> print_oops_end_marker+0x22/0x44 with crng_init=0
>>>>        ---[ end trace 903df1a0ade0b876 ]---
>>>>        Kernel panic - not syncing: Attempted to kill the idle task!
>>>>        ---[ end Kernel panic - not syncing: Attempted to kill the idle
>>>> task! ]---
>>>>
>>>> So the FDT is at 0xffffffff87e00000, i.e. at 0x7e00000 from the start
>>>> of virtual memory (CONFIG_PAGE_OFFSET=0xffffffff80000000), and thus
>>>> within the 2 GiB range.
>>>>
>>>>> --- a/arch/riscv/Kconfig
>>>>> +++ b/arch/riscv/Kconfig
>>>>> @@ -280,7 +280,7 @@ choice
>>>>>                    depends on 32BIT
>>>>>                    bool "1GiB"
>>>>>            config MAXPHYSMEM_2GB
>>>>> -               depends on 64BIT && CMODEL_MEDLOW
>>>>> +               depends on 64BIT
>>>>>                    bool "2GiB"
>>>>>            config MAXPHYSMEM_128GB
>>>>>                    depends on 64BIT && CMODEL_MEDANY
>>>> Gr{oetje,eeting}s,
>>>>
>>>>                            Geert
>>>>
>>>> -- 
>>>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
>>>> geert@linux-m68k.org
>>>>
>>>> In personal conversations with technical people, I call myself a
>>>> hacker. But
>>>> when I'm talking to journalists I just say "programmer" or something
>>>> like that.
>>>>                                    -- Linus Torvalds
>>>>
>>>> _______________________________________________
>>>> linux-riscv mailing list
>>>> linux-riscv@lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>>>>
>>> _______________________________________________
>>> linux-riscv mailing list
>>> linux-riscv@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW

[Geert Uytterhoeven]

Hi Alex,

On Tue, Jan 11, 2022 at 5:14 PM Alexandre ghiti <alex@ghiti.fr> wrote:
> On 1/11/22 17:04, Geert Uytterhoeven wrote:
> > On Fri, Nov 19, 2021 at 5:47 PM Palmer Dabbelt <palmer@rivosinc.com> wrote:
> >> From: Palmer Dabbelt <palmer@rivosinc.com>
> >>
> >> For non-relocatable kernels we need to be able to link the kernel at
> >> approximately PAGE_OFFSET, thus requiring medany (as medlow requires the
> >> code to be linked within 2GiB of 0).  The inverse doesn't apply, though:
> >> since medany code can be linked anywhere it's fine to link it close to
> >> 0, so we can support the smaller memory config.
> >>
> >> Fixes: de5f4b8f634b ("RISC-V: Define MAXPHYSMEM_1GB only for RV32")
> >> Cc: stable@vger.kernel.org
> >> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
> > Thanks for your patch, which is now commit 9f36b96bc70f9707 ("RISC-V:
> > MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW").
> >
> >> I found this when going through the savedefconfig diffs for the K210
> >> defconfigs.  I'm not entirely sure they're doing the right thing here
> >> (they should probably be setting CMODEL_LOW to take advantage of the
> >> better code generation), but I don't have any way to test those
> >> platforms so I don't want to change too much.
> > I can confirm MAXPHYSMEM_2GB works on K210 with CMODEL_MEDANY.
> >
> > As the Icicle has 1760 MiB of RAM, I gave it a try with MAXPHYSMEM_2GB
> > (and CMODEL_MEDANY), too.  Unfortunately it crashes very early
> > (needs earlycon to see):
> >
> >      OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
> >      Machine model: Microchip PolarFire-SoC Icicle Kit
> >      printk: debug: ignoring loglevel setting.
> >      earlycon: ns16550a0 at MMIO32 0x0000000020100000 (options '115200n8')
> >      printk: bootconsole [ns16550a0] enabled
> >      printk: debug: skip boot console de-registration.
> >      efi: UEFI not found.
> >      Unable to handle kernel paging request at virtual address ffffffff87e00001
> >      Oops [#1]
> >      Modules linked in:
> >      CPU: 0 PID: 0 Comm: swapper Not tainted 5.16.0-08771-g85515233477d #56
> >      Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)
> >      epc : fdt_check_header+0x14/0x208
> >       ra : early_init_dt_verify+0x16/0x94
> >      epc : ffffffff802ddacc ra : ffffffff8082415a sp : ffffffff81203ee0
> >       gp : ffffffff812ec3a8 tp : ffffffff8120cd80 t0 : 0000000000000005
> >       t1 : 0000001040000000 t2 : ffffffff80000000 s0 : ffffffff81203f00
> >       s1 : ffffffff87e00000 a0 : ffffffff87e00000 a1 : 000000040ffffce7
> >       a2 : 00000000000000e7 a3 : ffffffff8080394c a4 : 0000000000000000
> >       a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000
> >       s2 : ffffffff81203f98 s3 : 8000000a00006800 s4 : fffffffffffffff3
> >       s5 : 0000000000000000 s6 : 0000000000000001 s7 : 0000000000000000
> >       s8 : 0000000020236c20 s9 : 0000000000000000 s10: 0000000000000000
> >       s11: 0000000000000000 t3 : 0000000000000018 t4 : 00ff000000000000
> >       t5 : 0000000000000000 t6 : 0000000000000010
> >      status: 0000000200000100 badaddr: ffffffff87e00001 cause: 000000000000000d
> >      [<ffffffff802ddacc>] fdt_check_header+0x14/0x208
> >      [<ffffffff8082415a>] early_init_dt_verify+0x16/0x94
> >      [<ffffffff80802dee>] setup_arch+0xec/0x4ec
> >      [<ffffffff80800700>] start_kernel+0x88/0x6d6
> >      random: get_random_bytes called from
> > print_oops_end_marker+0x22/0x44 with crng_init=0
> >      ---[ end trace 903df1a0ade0b876 ]---
> >      Kernel panic - not syncing: Attempted to kill the idle task!
> >      ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
> >
> > So the FDT is at 0xffffffff87e00000, i.e. at 0x7e00000 from the start
> > of virtual memory (CONFIG_PAGE_OFFSET=0xffffffff80000000), and thus
> > within the 2 GiB range.
>
>
> I think you have just encountered what I suspected and mentioned in [1]:
> we recently moved the kernel to the PAGE_OFFSET address used with
> MAXPHYSMEM_2GB.
>
> I would try to cherry-pick [1] and see if that works better :)
>
> Alex
>
> [1]
> https://patchwork.kernel.org/project/linux-riscv/patch/20211206104657.433304-6-alexandre.ghiti@canonical.com/

Thanks, works fine with just that patch (needed small changes), or with
the full series.

Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW

[Alexandre Ghiti]

Hi Geert,

On 1/14/22 11:12, Geert Uytterhoeven wrote:
> Hi Alex,
>
> On Tue, Jan 11, 2022 at 5:14 PM Alexandre ghiti <alex@ghiti.fr> wrote:
>> On 1/11/22 17:04, Geert Uytterhoeven wrote:
>>> On Fri, Nov 19, 2021 at 5:47 PM Palmer Dabbelt <palmer@rivosinc.com> wrote:
>>>> From: Palmer Dabbelt <palmer@rivosinc.com>
>>>>
>>>> For non-relocatable kernels we need to be able to link the kernel at
>>>> approximately PAGE_OFFSET, thus requiring medany (as medlow requires the
>>>> code to be linked within 2GiB of 0).  The inverse doesn't apply, though:
>>>> since medany code can be linked anywhere it's fine to link it close to
>>>> 0, so we can support the smaller memory config.
>>>>
>>>> Fixes: de5f4b8f634b ("RISC-V: Define MAXPHYSMEM_1GB only for RV32")
>>>> Cc: stable@vger.kernel.org
>>>> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
>>> Thanks for your patch, which is now commit 9f36b96bc70f9707 ("RISC-V:
>>> MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW").
>>>
>>>> I found this when going through the savedefconfig diffs for the K210
>>>> defconfigs.  I'm not entirely sure they're doing the right thing here
>>>> (they should probably be setting CMODEL_LOW to take advantage of the
>>>> better code generation), but I don't have any way to test those
>>>> platforms so I don't want to change too much.
>>> I can confirm MAXPHYSMEM_2GB works on K210 with CMODEL_MEDANY.
>>>
>>> As the Icicle has 1760 MiB of RAM, I gave it a try with MAXPHYSMEM_2GB
>>> (and CMODEL_MEDANY), too.  Unfortunately it crashes very early
>>> (needs earlycon to see):
>>>
>>>       OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
>>>       Machine model: Microchip PolarFire-SoC Icicle Kit
>>>       printk: debug: ignoring loglevel setting.
>>>       earlycon: ns16550a0 at MMIO32 0x0000000020100000 (options '115200n8')
>>>       printk: bootconsole [ns16550a0] enabled
>>>       printk: debug: skip boot console de-registration.
>>>       efi: UEFI not found.
>>>       Unable to handle kernel paging request at virtual address ffffffff87e00001
>>>       Oops [#1]
>>>       Modules linked in:
>>>       CPU: 0 PID: 0 Comm: swapper Not tainted 5.16.0-08771-g85515233477d #56
>>>       Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)
>>>       epc : fdt_check_header+0x14/0x208
>>>        ra : early_init_dt_verify+0x16/0x94
>>>       epc : ffffffff802ddacc ra : ffffffff8082415a sp : ffffffff81203ee0
>>>        gp : ffffffff812ec3a8 tp : ffffffff8120cd80 t0 : 0000000000000005
>>>        t1 : 0000001040000000 t2 : ffffffff80000000 s0 : ffffffff81203f00
>>>        s1 : ffffffff87e00000 a0 : ffffffff87e00000 a1 : 000000040ffffce7
>>>        a2 : 00000000000000e7 a3 : ffffffff8080394c a4 : 0000000000000000
>>>        a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000
>>>        s2 : ffffffff81203f98 s3 : 8000000a00006800 s4 : fffffffffffffff3
>>>        s5 : 0000000000000000 s6 : 0000000000000001 s7 : 0000000000000000
>>>        s8 : 0000000020236c20 s9 : 0000000000000000 s10: 0000000000000000
>>>        s11: 0000000000000000 t3 : 0000000000000018 t4 : 00ff000000000000
>>>        t5 : 0000000000000000 t6 : 0000000000000010
>>>       status: 0000000200000100 badaddr: ffffffff87e00001 cause: 000000000000000d
>>>       [<ffffffff802ddacc>] fdt_check_header+0x14/0x208
>>>       [<ffffffff8082415a>] early_init_dt_verify+0x16/0x94
>>>       [<ffffffff80802dee>] setup_arch+0xec/0x4ec
>>>       [<ffffffff80800700>] start_kernel+0x88/0x6d6
>>>       random: get_random_bytes called from
>>> print_oops_end_marker+0x22/0x44 with crng_init=0
>>>       ---[ end trace 903df1a0ade0b876 ]---
>>>       Kernel panic - not syncing: Attempted to kill the idle task!
>>>       ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
>>>
>>> So the FDT is at 0xffffffff87e00000, i.e. at 0x7e00000 from the start
>>> of virtual memory (CONFIG_PAGE_OFFSET=0xffffffff80000000), and thus
>>> within the 2 GiB range.
>>
>> I think you have just encountered what I suspected and mentioned in [1]:
>> we recently moved the kernel to the PAGE_OFFSET address used with
>> MAXPHYSMEM_2GB.
>>
>> I would try to cherry-pick [1] and see if that works better :)
>>
>> Alex
>>
>> [1]
>> https://patchwork.kernel.org/project/linux-riscv/patch/20211206104657.433304-6-alexandre.ghiti@canonical.com/
> Thanks, works fine with just that patch (needed small changes), or with
> the full series.
>
> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>


Nice to know the full series works too, thank you, I'll add your Tested-by.

Thanks!

Alex


> Gr{oetje,eeting}s,
>
>                          Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv