From: Sean Anderson <seanga2@gmail.com>
To: Atish Patra <atishp@atishpatra.org>
Cc: linux-riscv <linux-riscv@lists.infradead.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Damien Le Moal <Damien.LeMoal@wdc.com>
Subject: Re: [PATCH v2 9/9] riscv: Do not initialize PMP on Kendryte SoC
Date: Thu, 12 Mar 2020 14:49:01 -0400 [thread overview]
Message-ID: <e7835ca3-0754-8143-33cd-bac97878a0ad@gmail.com> (raw)
In-Reply-To: <CAOnJCUK15kiMohMoqfPUNE43Yq+BTW=kY4AHYjyKkdr9Htg-ug@mail.gmail.com>
On 3/12/20 2:29 PM, Atish Patra wrote:
> On Thu, Mar 12, 2020 at 11:14 AM Sean Anderson <seanga2@gmail.com> wrote:
>>
>>
>>> I don't think supporting old specs in Linux is a good idea. As per the
>>> patch guideline
>>> for RISC-V Linux, patches for only "frozen" or "ratified"
>>> specifications are allowed.
>>>
>>
>> Well this CPU follows the v1.9 spec. It's real hardware, if it is to be
>> be supported, then the 1.9 spec needs to be as well.
>>
>
> As RISC-V is an open ISA and it's continuously evolving, there will be
> some hardware
> that will implement old specifications or non-backward compatible features.
> I fear the number of hardware with such features/implementations will
> grow in the future.
> If Linux is going to support all of them, it may be a maintenance nightmare.
I agree. There is also no standard way to communicate the implemented
privileged spec level e.g. in the device tree. The base integer
instruction set version can be specified in the riscv,isa property, such
as
riscv,isa = "rv64i2p1..."
However, there is no "extension" for the privileged specification.
A method to specify this would be helpful, especially since the
bootloader may need to enable the MMU before loading Linux since there
is no way to enable it from S-mode until v1.10.
On the other hand, there is relatively little changed from v1.9 to the
current revision. The following list has the differences from the
current spec:
* The PMP has flipped polarity
* The mcounteren CSRs are split
* sfence.vma is sfence.vm (though this should be handled by the sbi
anyway)
* satp has a different name, and mode no longer exists in the top four
bits. Since these bits used to be part of ASID, it's fine to write the
mode to those bits. If linux never switches from (e.g.) sv39 to
something else, there will be no observed difference either.
Everything else is mostly forwards-compatible, as far as I can tell.
That is, assuming new behaviour on old hardware won't cause problems.
A sufficiently smart kernel could even detect the version at runtime by
intentionally triggering behaviour which is illegal depending on the
privileged version, and then checking for an exception.
--Sean
next prev parent reply other threads:[~2020-03-12 18:49 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-12 5:10 [PATCH v2 0/9] Kendryte k210 SoC boards support Damien Le Moal
2020-03-12 5:10 ` [PATCH v2 1/9] riscv: Unaligned load/store handling for M_MODE Damien Le Moal
2020-03-12 5:11 ` [PATCH v2 2/9] riscv: Add BUILTIN_DTB support Damien Le Moal
2020-03-12 20:03 ` Atish Patra
2020-03-12 5:11 ` [PATCH v2 3/9] riscv: Add SOC early init support Damien Le Moal
2020-03-12 18:21 ` Sean Anderson
2020-03-13 5:52 ` Damien Le Moal
2020-03-12 19:50 ` Atish Patra
2020-03-12 20:53 ` Atish Patra
2020-03-13 6:42 ` Damien Le Moal
2020-03-13 21:10 ` Atish Patra
2020-03-16 0:34 ` Damien Le Moal
2020-03-12 5:11 ` [PATCH v2 4/9] riscv: Add Kendryte K210 SoC support Damien Le Moal
2020-03-12 18:19 ` Sean Anderson
2020-03-13 5:43 ` Damien Le Moal
2020-03-12 5:11 ` [PATCH v2 5/9] riscv: Select required drivers for Kendryte SOC Damien Le Moal
2020-03-12 5:11 ` [PATCH v2 6/9] riscv: Add Kendryte K210 device tree Damien Le Moal
2020-03-12 18:16 ` Sean Anderson
2020-03-13 5:29 ` Damien Le Moal
2020-03-12 5:11 ` [PATCH v2 7/9] riscv: Kendryte K210 default config Damien Le Moal
2020-03-12 19:03 ` Atish Patra
2020-03-13 5:52 ` Damien Le Moal
2020-03-12 5:11 ` [PATCH v2 8/9] riscv: create a loader.bin boot image for Kendryte SoC Damien Le Moal
2020-03-12 5:11 ` [PATCH v2 9/9] riscv: Do not initialize PMP on " Damien Le Moal
2020-03-12 15:20 ` Sean Anderson
2020-03-12 18:10 ` Atish Patra
2020-03-12 18:14 ` Sean Anderson
2020-03-12 18:29 ` Atish Patra
2020-03-12 18:49 ` Sean Anderson [this message]
2020-03-12 19:12 ` Atish Patra
2020-03-12 20:09 ` Sean Anderson
2020-03-13 6:03 ` Damien Le Moal
2020-03-13 5:40 ` Anup Patel
2020-03-13 5:25 ` Damien Le Moal
2020-03-13 5:47 ` Atish Patra
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=e7835ca3-0754-8143-33cd-bac97878a0ad@gmail.com \
--to=seanga2@gmail.com \
--cc=Damien.LeMoal@wdc.com \
--cc=atishp@atishpatra.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
/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