* [PATCH 01/12] RISC-V: defconfigs: Set CONFIG_FB=y, for FB console [not found] <20211119164413.29052-1-palmer@rivosinc.com> @ 2021-11-19 16:44 ` Palmer Dabbelt 2021-11-20 3:56 ` Anup Patel 2021-11-19 16:44 ` [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW Palmer Dabbelt 1 sibling, 1 reply; 12+ messages in thread From: Palmer Dabbelt @ 2021-11-19 16:44 UTC (permalink / raw) To: linux-riscv Cc: Paul Walmsley, Palmer Dabbelt, aou, anup.patel, heinrich.schuchardt, atish.patra, bin.meng, sagar.kadam, damien.lemoal, axboe, linux-riscv, linux-kernel, Palmer Dabbelt, stable 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 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH 01/12] RISC-V: defconfigs: Set CONFIG_FB=y, for FB console 2021-11-19 16:44 ` [PATCH 01/12] RISC-V: defconfigs: Set CONFIG_FB=y, for FB console Palmer Dabbelt @ 2021-11-20 3:56 ` Anup Patel 0 siblings, 0 replies; 12+ messages in thread From: Anup Patel @ 2021-11-20 3:56 UTC (permalink / raw) To: Palmer Dabbelt Cc: linux-riscv, Paul Walmsley, Palmer Dabbelt, Albert Ou, Anup Patel, Heinrich Schuchardt, Atish Patra, Bin Meng, Sagar Shrikant Kadam, Damien Le Moal, axboe, linux-kernel@vger.kernel.org List, stable 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW [not found] <20211119164413.29052-1-palmer@rivosinc.com> 2021-11-19 16:44 ` [PATCH 01/12] RISC-V: defconfigs: Set CONFIG_FB=y, for FB console Palmer Dabbelt @ 2021-11-19 16:44 ` Palmer Dabbelt 2021-11-20 3:57 ` Anup Patel 2022-01-11 16:04 ` Geert Uytterhoeven 1 sibling, 2 replies; 12+ messages in thread From: Palmer Dabbelt @ 2021-11-19 16:44 UTC (permalink / raw) To: linux-riscv Cc: Paul Walmsley, Palmer Dabbelt, aou, anup.patel, heinrich.schuchardt, atish.patra, bin.meng, sagar.kadam, damien.lemoal, axboe, linux-riscv, linux-kernel, Palmer Dabbelt, stable 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 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW 2021-11-19 16:44 ` [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW Palmer Dabbelt @ 2021-11-20 3:57 ` Anup Patel 2022-01-11 16:04 ` Geert Uytterhoeven 1 sibling, 0 replies; 12+ messages in thread From: Anup Patel @ 2021-11-20 3:57 UTC (permalink / raw) To: Palmer Dabbelt Cc: linux-riscv, Paul Walmsley, Palmer Dabbelt, Albert Ou, Anup Patel, Heinrich Schuchardt, Atish Patra, Bin Meng, Sagar Shrikant Kadam, Damien Le Moal, axboe, linux-kernel@vger.kernel.org List, stable 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW 2021-11-19 16:44 ` [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW Palmer Dabbelt 2021-11-20 3:57 ` Anup Patel @ 2022-01-11 16:04 ` Geert Uytterhoeven 2022-01-11 16:14 ` Alexandre ghiti 2022-01-14 8:40 ` Conor.Dooley 1 sibling, 2 replies; 12+ messages in thread From: Geert Uytterhoeven @ 2022-01-11 16:04 UTC (permalink / raw) To: Palmer Dabbelt Cc: linux-riscv, Paul Walmsley, Palmer Dabbelt, Albert Ou, Anup Patel, heinrich.schuchardt, Atish Patra, Bin Meng, Sagar Kadam, Damien Le Moal, Jens Axboe, Linux Kernel Mailing List, stable 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW 2022-01-11 16:04 ` Geert Uytterhoeven @ 2022-01-11 16:14 ` Alexandre ghiti 2022-01-14 10:12 ` Geert Uytterhoeven 2022-01-14 8:40 ` Conor.Dooley 1 sibling, 1 reply; 12+ messages in thread From: Alexandre ghiti @ 2022-01-11 16:14 UTC (permalink / raw) To: Geert Uytterhoeven, Palmer Dabbelt Cc: linux-riscv, Paul Walmsley, Palmer Dabbelt, Albert Ou, Anup Patel, heinrich.schuchardt, Atish Patra, Bin Meng, Sagar Kadam, Damien Le Moal, Jens Axboe, Linux Kernel Mailing List, stable 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW 2022-01-11 16:14 ` Alexandre ghiti @ 2022-01-14 10:12 ` Geert Uytterhoeven 2022-01-14 11:11 ` Alexandre Ghiti 0 siblings, 1 reply; 12+ messages in thread From: Geert Uytterhoeven @ 2022-01-14 10:12 UTC (permalink / raw) To: Alexandre ghiti Cc: Palmer Dabbelt, linux-riscv, Paul Walmsley, Palmer Dabbelt, Albert Ou, Anup Patel, heinrich.schuchardt, Atish Patra, Bin Meng, Sagar Kadam, Damien Le Moal, Jens Axboe, Linux Kernel Mailing List, stable 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW 2022-01-14 10:12 ` Geert Uytterhoeven @ 2022-01-14 11:11 ` Alexandre Ghiti 0 siblings, 0 replies; 12+ messages in thread From: Alexandre Ghiti @ 2022-01-14 11:11 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Palmer Dabbelt, linux-riscv, Paul Walmsley, Palmer Dabbelt, Albert Ou, Anup Patel, heinrich.schuchardt, Atish Patra, Bin Meng, Sagar Kadam, Damien Le Moal, Jens Axboe, Linux Kernel Mailing List, stable 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW 2022-01-11 16:04 ` Geert Uytterhoeven 2022-01-11 16:14 ` Alexandre ghiti @ 2022-01-14 8:40 ` Conor.Dooley 2022-01-14 9:09 ` Alexandre ghiti 1 sibling, 1 reply; 12+ messages in thread From: Conor.Dooley @ 2022-01-14 8:40 UTC (permalink / raw) To: geert, palmer Cc: linux-riscv, paul.walmsley, palmer, aou, anup.patel, heinrich.schuchardt, atish.patra, bin.meng, sagar.kadam, damien.lemoal, axboe, linux-kernel, stable 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW 2022-01-14 8:40 ` Conor.Dooley @ 2022-01-14 9:09 ` Alexandre ghiti 2022-01-14 9:41 ` Conor.Dooley 0 siblings, 1 reply; 12+ messages in thread From: Alexandre ghiti @ 2022-01-14 9:09 UTC (permalink / raw) To: Conor.Dooley, geert, palmer Cc: linux-riscv, paul.walmsley, palmer, aou, heinrich.schuchardt, bin.meng, sagar.kadam, damien.lemoal, axboe, linux-kernel, stable 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW 2022-01-14 9:09 ` Alexandre ghiti @ 2022-01-14 9:41 ` Conor.Dooley 2022-01-14 9:45 ` Alexandre Ghiti 0 siblings, 1 reply; 12+ messages in thread From: Conor.Dooley @ 2022-01-14 9:41 UTC (permalink / raw) To: alex, geert, palmer Cc: linux-riscv, paul.walmsley, palmer, aou, heinrich.schuchardt, bin.meng, sagar.kadam, damien.lemoal, axboe, linux-kernel, stable 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW 2022-01-14 9:41 ` Conor.Dooley @ 2022-01-14 9:45 ` Alexandre Ghiti 0 siblings, 0 replies; 12+ messages in thread From: Alexandre Ghiti @ 2022-01-14 9:45 UTC (permalink / raw) To: Conor.Dooley, geert, palmer Cc: linux-riscv, paul.walmsley, palmer, aou, heinrich.schuchardt, bin.meng, sagar.kadam, damien.lemoal, axboe, linux-kernel, stable 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2022-01-14 11:11 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20211119164413.29052-1-palmer@rivosinc.com>
2021-11-19 16:44 ` [PATCH 01/12] RISC-V: defconfigs: Set CONFIG_FB=y, for FB console Palmer Dabbelt
2021-11-20 3:56 ` Anup Patel
2021-11-19 16:44 ` [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW Palmer Dabbelt
2021-11-20 3:57 ` Anup Patel
2022-01-11 16:04 ` Geert Uytterhoeven
2022-01-11 16:14 ` Alexandre ghiti
2022-01-14 10:12 ` Geert Uytterhoeven
2022-01-14 11:11 ` Alexandre Ghiti
2022-01-14 8:40 ` Conor.Dooley
2022-01-14 9:09 ` Alexandre ghiti
2022-01-14 9:41 ` Conor.Dooley
2022-01-14 9:45 ` Alexandre Ghiti
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox