The Andes AX45MP core has a Programmable Physical Memory Attributes (PMA)
block that allows dynamic adjustment of memory attributes in the runtime.
It contains a configurable amount of PMA entries implemented as CSR
registers to control the attributes of memory locations in interest.
Below are the memory attributes supported:
* Device, Non-bufferable
* Device, bufferable
* Memory, Non-cacheable, Non-bufferable
* Memory, Non-cacheable, Bufferable
* Memory, Write-back, No-allocate
* Memory, Write-back, Read-allocate
* Memory, Write-back, Write-allocate
* Memory, Write-back, Read and Write-allocate
This patch adds support to configure the memory attributes of the
memory regions as passed from the core node. Currently the OpenSBI code
implements support for "Memory, Non-cacheable, Non-bufferable" option
with SBI_EXT_ANDES_SET_PMA.
More info about PMA (section 10.3):
http://www.andestech.com/wp-content/uploads/AX45MP-1C-Rev.-5.0.0-Datasheet.pdf
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
Note: the current implementation only supports "Memory, Non-cacheable,
Bufferable" option.
---
arch/riscv/Kbuild | 2 +
arch/riscv/include/asm/sbi.h | 1 +
arch/riscv/vendors/Makefile | 3 +
arch/riscv/vendors/andes/Makefile | 3 +
arch/riscv/vendors/andes/ax45mp.c | 93 ++++++++++++++++++++++++++
arch/riscv/vendors/andes/include/sbi.h | 27 ++++++++
6 files changed, 129 insertions(+)
create mode 100644 arch/riscv/vendors/Makefile
create mode 100644 arch/riscv/vendors/andes/Makefile
create mode 100644 arch/riscv/vendors/andes/ax45mp.c
create mode 100644 arch/riscv/vendors/andes/include/sbi.h
diff --git a/arch/riscv/Kbuild b/arch/riscv/Kbuild
index afa83e307a2e..d6821f660fc3 100644
--- a/arch/riscv/Kbuild
+++ b/arch/riscv/Kbuild
@@ -5,6 +5,8 @@ obj-$(CONFIG_BUILTIN_DTB) += boot/dts/
obj-y += errata/
obj-$(CONFIG_KVM) += kvm/
+obj-y += vendors/
+
obj-$(CONFIG_ARCH_HAS_KEXEC_PURGATORY) += purgatory/
# for cleaning
diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
index 2a0ef738695e..10a7c855d125 100644
--- a/arch/riscv/include/asm/sbi.h
+++ b/arch/riscv/include/asm/sbi.h
@@ -37,6 +37,7 @@ enum sbi_ext_id {
/* Vendor extensions must lie within this range */
SBI_EXT_VENDOR_START = 0x09000000,
+ SBI_EXT_ANDES = 0x0900031E,
SBI_EXT_VENDOR_END = 0x09FFFFFF,
};
diff --git a/arch/riscv/vendors/Makefile b/arch/riscv/vendors/Makefile
new file mode 100644
index 000000000000..0a5a5541d2a3
--- /dev/null
+++ b/arch/riscv/vendors/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_ARCH_R9A07G043) += andes/
diff --git a/arch/riscv/vendors/andes/Makefile b/arch/riscv/vendors/andes/Makefile
new file mode 100644
index 000000000000..60fa8226c4a3
--- /dev/null
+++ b/arch/riscv/vendors/andes/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_ARCH_R9A07G043) += ax45mp.o
diff --git a/arch/riscv/vendors/andes/ax45mp.c b/arch/riscv/vendors/andes/ax45mp.c
new file mode 100644
index 000000000000..931cba754f41
--- /dev/null
+++ b/arch/riscv/vendors/andes/ax45mp.c
@@ -0,0 +1,93 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AX45MP setup
+ * - PMA
+ *
+ * Copyright (C) 2022 Renesas Electronics Corp.
+ *
+ */
+
+#include <linux/device.h>
+#include <linux/of.h>
+
+#include <asm/sbi.h>
+
+#include "include/sbi.h"
+
+#define ANDES_AX45MP_MAX_PMA_REGIONS 16
+
+struct pma_arg_t {
+ phys_addr_t offset;
+ unsigned long vaddr;
+ size_t size;
+ size_t entry_id;
+};
+
+static long sbi_set_pma(void *arg)
+{
+ phys_addr_t offset = ((struct pma_arg_t *)arg)->offset;
+ unsigned long vaddr = ((struct pma_arg_t *)arg)->vaddr;
+ size_t entry_id = ((struct pma_arg_t *)arg)->entry_id;
+ size_t size = ((struct pma_arg_t *)arg)->size;
+ struct sbiret ret;
+
+ ret = sbi_ecall(SBI_EXT_ANDES, SBI_EXT_ANDES_SET_PMA, offset, vaddr, size, entry_id, 0, 0);
+
+ return ret.value;
+}
+
+static unsigned long cpu_nocache_area_set(unsigned long start,
+ unsigned long size,
+ unsigned long entry_id)
+{
+ struct pma_arg_t pma_arg;
+ unsigned long ret = 0;
+
+ pma_arg.offset = start;
+ pma_arg.size = size;
+ pma_arg.vaddr = start + size;
+ pma_arg.entry_id = entry_id;
+ ret = sbi_set_pma(&pma_arg);
+
+ return ret;
+}
+
+static void ax45mp_configure_pma_regions(struct device_node *np, int count)
+{
+ u64 start, size;
+ unsigned int i;
+
+ for (i = 0 ; i < count ; i++) {
+ of_property_read_u64_index(np, "pma-regions", (i << 1), &start);
+ of_property_read_u64_index(np, "pma-regions", (i << 1) + 1, &size);
+ cpu_nocache_area_set(start, size, i);
+ }
+}
+
+static const struct of_device_id ax45mp_ids[] = {
+ { .compatible = "andestech,ax45mp" },
+ { /* sentinel */ }
+};
+
+static int __init ax45mp_init(void)
+{
+ struct device_node *np;
+ int count;
+
+ np = of_find_matching_node(NULL, ax45mp_ids);
+ if (!np)
+ return -ENODEV;
+
+ count = of_property_count_elems_of_size(np, "pma-regions",
+ sizeof(u32) * 4);
+ if (count < 0)
+ return 0;
+
+ if (count > ANDES_AX45MP_MAX_PMA_REGIONS)
+ return -EINVAL;
+
+ ax45mp_configure_pma_regions(np, count);
+
+ return 0;
+}
+arch_initcall(ax45mp_init);
diff --git a/arch/riscv/vendors/andes/include/sbi.h b/arch/riscv/vendors/andes/include/sbi.h
new file mode 100644
index 000000000000..6dcd215bb5f8
--- /dev/null
+++ b/arch/riscv/vendors/andes/include/sbi.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+#ifndef __RISCV_ANDES_SBI_H
+#define __RISCV_ANDES_SBI_H
+
+enum sbi_ext_andes_fid {
+ SBI_EXT_ANDES_GET_MCACHE_CTL_STATUS = 0,
+ SBI_EXT_ANDES_GET_MMISC_CTL_STATUS,
+ SBI_EXT_ANDES_SET_MCACHE_CTL,
+ SBI_EXT_ANDES_SET_MMISC_CTL,
+ SBI_EXT_ANDES_ICACHE_OP,
+ SBI_EXT_ANDES_DCACHE_OP,
+ SBI_EXT_ANDES_L1CACHE_I_PREFETCH,
+ SBI_EXT_ANDES_L1CACHE_D_PREFETCH,
+ SBI_EXT_ANDES_NON_BLOCKING_LOAD_STORE,
+ SBI_EXT_ANDES_WRITE_AROUND,
+ SBI_EXT_ANDES_SET_PMA,
+ SBI_EXT_ANDES_FREE_PMA,
+ SBI_EXT_ANDES_PROBE_PMA,
+ SBI_EXT_ANDES_DCACHE_WBINVAL_ALL,
+ SBI_EXT_ANDES_GET_MICM_CTL_STATUS,
+ SBI_EXT_ANDES_GET_MDCM_CTL_STATUS,
+ SBI_EXT_ANDES_GET_MMSC_CTL_STATUS,
+ SBI_EXT_ANDES_GET_MISA_CTL_STATUS,
+};
+
+#endif
--
2.25.1On 06/09/2022 11:21, Lad Prabhakar wrote:
> diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
> index 2a0ef738695e..10a7c855d125 100644
> --- a/arch/riscv/include/asm/sbi.h
> +++ b/arch/riscv/include/asm/sbi.h
> @@ -37,6 +37,7 @@ enum sbi_ext_id {
>
> /* Vendor extensions must lie within this range */
> SBI_EXT_VENDOR_START = 0x09000000,
> + SBI_EXT_ANDES = 0x0900031E,
> SBI_EXT_VENDOR_END = 0x09FFFFFF,
> };
Everything else aside, I am very interested in what's happening
here. I'll take a proper look through things later, but for now:
For PolarFire SoC we have an InterHart Communication SBI EXT that
would would like to upstream support for. We are not aiming to put
the driver itself in arch/riscv - it's just a mailbox driver, but
I would like to use sbi.h for defining the vendor id etc.
I am not sure how this all aligns with:
> We’ll only accept patches for new modules or extensions if the
> specifications for those modules or extensions are listed as being
> “Frozen” or “Ratified” by the RISC-V Foundation. (Developers may, of
> course, maintain their own Linux kernel trees that contain code for
> any draft extensions that they wish.)
>
> Additionally, the RISC-V specification allows implementors to create
> their own custom extensions. These custom extensions aren’t required
> to go through any review or ratification process by the RISC-V
> Foundation. To avoid the maintenance complexity and potential
> performance impact of adding kernel code for implementor-specific
> RISC-V extensions, we’ll only to accept patches for extensions that
> have been officially frozen or ratified by the RISC-V Foundation.
> (Implementors, may, of course, maintain their own Linux kernel trees
> containing code for any custom extensions that they wish.)
Which is in: https://docs.kernel.org/riscv/patch-acceptance.html
It is unclear to me whether that is just for ISA extensions or if that
covers SBI extensions too. At least for us, since we don't touch arch
code there is relatively little friction & there's no concerns about
reducing the portability of a kernel since it is just a regular old
driver.
I was planning on cornering some people *cough* Palmer *cough* at
LPC and asking him what his thoughts were there.
FWIW this is what we have been doing:
https://github.com/linux4microchip/linux/blob/linux-5.15-mchp/drivers/mailbox/mailbox-miv-ihc.c#L27
The IP itself has not stabilised yet, so we have not sent any patches
yet, but we do intend doing so...
But yea, I'll take a properly look at what you're doing here soonTM,
although at this point it may be the other side of LPC.
btw, where can I get my hands on your hardware?
Thanks,
Conor.
Hello Conor,
Thank you for your interest.
> From: Conor.Dooley@microchip.com <Conor.Dooley@microchip.com>
> Sent: 06 September 2022 11:39
>
> On 06/09/2022 11:21, Lad Prabhakar wrote:
>
> > diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
> > index 2a0ef738695e..10a7c855d125 100644
> > --- a/arch/riscv/include/asm/sbi.h
> > +++ b/arch/riscv/include/asm/sbi.h
> > @@ -37,6 +37,7 @@ enum sbi_ext_id {
> >
> > /* Vendor extensions must lie within this range */
> > SBI_EXT_VENDOR_START = 0x09000000,
> > + SBI_EXT_ANDES = 0x0900031E,
> > SBI_EXT_VENDOR_END = 0x09FFFFFF,
> > };
>
> Everything else aside, I am very interested in what's happening
> here. I'll take a proper look through things later, but for now:
>
> For PolarFire SoC we have an InterHart Communication SBI EXT that
> would would like to upstream support for. We are not aiming to put
> the driver itself in arch/riscv - it's just a mailbox driver, but
> I would like to use sbi.h for defining the vendor id etc.
>
> I am not sure how this all aligns with:
> > We’ll only accept patches for new modules or extensions if the
> > specifications for those modules or extensions are listed as being
> > “Frozen” or “Ratified” by the RISC-V Foundation. (Developers may, of
> > course, maintain their own Linux kernel trees that contain code for
> > any draft extensions that they wish.)
> >
> > Additionally, the RISC-V specification allows implementors to create
> > their own custom extensions. These custom extensions aren’t required
> > to go through any review or ratification process by the RISC-V
> > Foundation. To avoid the maintenance complexity and potential
> > performance impact of adding kernel code for implementor-specific
> > RISC-V extensions, we’ll only to accept patches for extensions that
> > have been officially frozen or ratified by the RISC-V Foundation.
> > (Implementors, may, of course, maintain their own Linux kernel trees
> > containing code for any custom extensions that they wish.)
>
> Which is in: https://docs.kernel.org/riscv/patch-acceptance.html
>
> It is unclear to me whether that is just for ISA extensions or if that
> covers SBI extensions too. At least for us, since we don't touch arch
> code there is relatively little friction & there's no concerns about
> reducing the portability of a kernel since it is just a regular old
> driver.
>
> I was planning on cornering some people *cough* Palmer *cough* at
> LPC and asking him what his thoughts were there.
>
> FWIW this is what we have been doing:
> https://github.com/linux4microchip/linux/blob/linux-5.15-mchp/drivers/mailbox/mailbox-miv-ihc.c#L27
>
> The IP itself has not stabilised yet, so we have not sent any patches
> yet, but we do intend doing so...
>
> But yea, I'll take a properly look at what you're doing here soonTM,
> although at this point it may be the other side of LPC.
>
> btw, where can I get my hands on your hardware?
The latest information I have is that it should be available via various distributors on the 21st Sept.
Kind regards, Chris
>
> Thanks,
> Conor.
>
Hello Conor, > > > > btw, where can I get my hands on your hardware? > > The latest information I have is that it should be available via various > distributors on the 21st Sept. I've now seen it at the following distributors, perhaps there is also availability elsewhere. https://uk.farnell.com/renesas/rtk9743f01s01000be/evaluation-board-kit-64bit-risc/dp/4051136 https://www.futureelectronics.com/p/semiconductors--embedded-solutions--embedded-boards--embedded-software/rtk9743f01s01000be-renesas-7166252 https://www.avnet.com/shop/us/products/renesas-electronics/rtk9743f01s01000be-3074457345649323718/ For those interested, the part number to google for is RTK9743F01S01000BE. Kind regards, Chris
Hi Conor,
Thanks for the quick glance!
On Tue, Sep 6, 2022 at 11:39 AM <Conor.Dooley@microchip.com> wrote:
>
> On 06/09/2022 11:21, Lad Prabhakar wrote:
>
> > diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
> > index 2a0ef738695e..10a7c855d125 100644
> > --- a/arch/riscv/include/asm/sbi.h
> > +++ b/arch/riscv/include/asm/sbi.h
> > @@ -37,6 +37,7 @@ enum sbi_ext_id {
> >
> > /* Vendor extensions must lie within this range */
> > SBI_EXT_VENDOR_START = 0x09000000,
> > + SBI_EXT_ANDES = 0x0900031E,
> > SBI_EXT_VENDOR_END = 0x09FFFFFF,
> > };
>
> Everything else aside, I am very interested in what's happening
> here. I'll take a proper look through things later, but for now:
>
> For PolarFire SoC we have an InterHart Communication SBI EXT that
> would would like to upstream support for. We are not aiming to put
> the driver itself in arch/riscv - it's just a mailbox driver, but
> I would like to use sbi.h for defining the vendor id etc.
>
sbi.h seems appropriate for now, unless the maintainers have other ideas.
> I am not sure how this all aligns with:
> > We’ll only accept patches for new modules or extensions if the
> > specifications for those modules or extensions are listed as being
> > “Frozen” or “Ratified” by the RISC-V Foundation. (Developers may, of
> > course, maintain their own Linux kernel trees that contain code for
> > any draft extensions that they wish.)
> >
> > Additionally, the RISC-V specification allows implementors to create
> > their own custom extensions. These custom extensions aren’t required
> > to go through any review or ratification process by the RISC-V
> > Foundation. To avoid the maintenance complexity and potential
> > performance impact of adding kernel code for implementor-specific
> > RISC-V extensions, we’ll only to accept patches for extensions that
> > have been officially frozen or ratified by the RISC-V Foundation.
> > (Implementors, may, of course, maintain their own Linux kernel trees
> > containing code for any custom extensions that they wish.)
>
> Which is in: https://docs.kernel.org/riscv/patch-acceptance.html
>
I had completely missed this, thanks for pointing it out.
> It is unclear to me whether that is just for ISA extensions or if that
> covers SBI extensions too. At least for us, since we don't touch arch
> code there is relatively little friction & there's no concerns about
> reducing the portability of a kernel since it is just a regular old
> driver.
>
> I was planning on cornering some people *cough* Palmer *cough* at
> LPC and asking him what his thoughts were there.
>
I too will be attending the LPC (virtually though) and would like to
attend/chat on this topic. Please keep me posted.
> FWIW this is what we have been doing:
> https://github.com/linux4microchip/linux/blob/linux-5.15-mchp/drivers/mailbox/mailbox-miv-ihc.c#L27
>
From the looks of it it's on similar lines ;)
> The IP itself has not stabilised yet, so we have not sent any patches
> yet, but we do intend doing so...
>
I see..
> But yea, I'll take a properly look at what you're doing here soonTM,
> although at this point it may be the other side of LPC.
>
Thanks.
> btw, where can I get my hands on your hardware?
>
I shall share the link as soon as it's available.
Cheers,
Prabhakar
© 2016 - 2026 Red Hat, Inc.