From: Alexandre Ghiti <alex@ghiti.fr>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Palmer Dabbelt <palmer@rivosinc.com>,
linux-riscv <linux-riscv@lists.infradead.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Anup Patel <anup.patel@wdc.com>,
heinrich.schuchardt@canonical.com,
Atish Patra <atish.patra@wdc.com>,
Bin Meng <bin.meng@windriver.com>,
Sagar Kadam <sagar.kadam@sifive.com>,
Damien Le Moal <damien.lemoal@wdc.com>,
Jens Axboe <axboe@kernel.dk>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
stable <stable@vger.kernel.org>
Subject: Re: [PATCH 02/12] RISC-V: MAXPHYSMEM_2GB doesn't depend on CMODEL_MEDLOW
Date: Fri, 14 Jan 2022 12:11:34 +0100 [thread overview]
Message-ID: <33d9a577-8e41-067e-2d21-472cd83ea2cb@ghiti.fr> (raw)
In-Reply-To: <CAMuHMdUpi7hJwDrcCyzrooJN=gQjmwShD073UwXp7UxghHeMSA@mail.gmail.com>
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
next prev parent reply other threads:[~2022-01-14 11:11 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-19 16:44 [PATCH 0/12] RISC-V: Clean up the defconfigs Palmer Dabbelt
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 [this message]
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
2021-11-19 16:44 ` [PATCH 03/12] RISC-V: defconfigs: Sort CONFIG_BPF_SYSCALL Palmer Dabbelt
2021-11-20 3:58 ` Anup Patel
2021-11-19 16:44 ` [PATCH 04/12] RISC-V: defconfigs: Sort CONFIG_SYSFS_SYSCALL Palmer Dabbelt
2021-11-20 3:58 ` Anup Patel
2021-11-19 16:44 ` [PATCH 05/12] RISC-V: defconfigs: Sort CONFIG_SOC_POLARFIRE Palmer Dabbelt
2021-11-20 3:59 ` Anup Patel
2021-11-19 16:44 ` [PATCH 06/12] RISC-V: defconfigs: Sort CONFIG_PTP_1588_CLOCK Palmer Dabbelt
2021-11-20 4:00 ` Anup Patel
2021-11-19 16:44 ` [PATCH 07/12] RISC-V: defconfigs: Sort CONFIG_MMC Palmer Dabbelt
2021-11-20 4:01 ` Anup Patel
2021-11-19 16:44 ` [PATCH 08/12] RISC-V: defconfigs: Sort CONFIG_SURFACE_PLATFORMS Palmer Dabbelt
2021-11-20 4:02 ` Anup Patel
2021-11-19 16:44 ` [PATCH 09/12] RISC-V: defconfigs: Sort CONFIG_BLK_DEV_BSG Palmer Dabbelt
2021-11-20 4:04 ` Anup Patel
2021-11-19 16:44 ` [PATCH 10/12] RISC-V: defconfigs: Remove redundant CONFIG_POWER_RESET Palmer Dabbelt
2021-11-20 4:04 ` Anup Patel
2021-11-19 16:44 ` [PATCH 11/12] RISC-V: defconfigs: Remove redundant CONFIG_EFI=y Palmer Dabbelt
2021-11-20 4:05 ` Anup Patel
2021-11-19 16:44 ` [PATCH 12/12] RISC-V: defconfigs: Remove redundant K210 DT source Palmer Dabbelt
2021-11-20 4:07 ` Anup Patel
2021-11-21 23:41 ` Damien Le Moal
2022-01-06 18:01 ` Palmer Dabbelt
2022-01-07 2:14 ` Damien Le Moal
2022-01-20 18:19 ` Palmer Dabbelt
2022-01-20 23:33 ` Damien Le Moal
2021-11-20 4:11 ` [PATCH 0/12] RISC-V: Clean up the defconfigs Anup Patel
2021-11-22 2:45 ` Bin Meng
2022-01-06 18:01 ` Palmer Dabbelt
2021-11-21 23:47 ` Damien Le Moal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=33d9a577-8e41-067e-2d21-472cd83ea2cb@ghiti.fr \
--to=alex@ghiti.fr \
--cc=anup.patel@wdc.com \
--cc=aou@eecs.berkeley.edu \
--cc=atish.patra@wdc.com \
--cc=axboe@kernel.dk \
--cc=bin.meng@windriver.com \
--cc=damien.lemoal@wdc.com \
--cc=geert@linux-m68k.org \
--cc=heinrich.schuchardt@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=palmer@rivosinc.com \
--cc=paul.walmsley@sifive.com \
--cc=sagar.kadam@sifive.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®