This patch series introduces initial support for the Anlogic DR1V90 SoC
[1] and the Milianke MLKPAI-FS01 [2] board.

The DR1V90 is a RISC-V based FPSoC from Anlogic, featuring a Nuclei
UX900 [3] core as its processing system (PS) and 94,464 LUTs in the
programmable logic (PL) part. The Milianke MLKPAI-FS01 board is one of
the first platforms based on this SoC, with UART1 routed to a Type-C
interface for console access.

Tested on the Milianke MLKPAI-FS01 board with both the vendor's OpenSBI
and the not-yet-upstreamed mainline OpenSBI [4], as well as the vendor’s
U-Boot. Because the vendor’s OpenSBI is loaded at 0x1f300000, we have
to additionally reserve the DRAM region 0x1fe00000–0x1fffffff to prevent
overlap if using vendor's OpenSBI.

Notice: A "no4lvl" bootarg or dependency patch [5] is currently required
for successful boot on the DR1V90 platform, since the SoC hangs if the
kernel attempts to use unsupported 4-level or 5-level paging modes.

Link: https://www.anlogic.com/product/fpga/saldragon/dr1 [1]
Link: https://www.milianke.com/product-item-104.html [2]
Link: https://nucleisys.com/product/900.php [3]
Link: https://github.com/pigmoral/opensbi/tree/dr1v90 [4]
Link: https://lore.kernel.org/linux-riscv/20250722-satp-from-fdt-v1-0-5ba22218fa5f@pigmoral.tech [5]
---
Changes in v2:
- Add MAINTAINERS entry for the DR1V90 platform
- Remove the riscv,isa property of cpu and reorder propertyies
- Fix clint base address in the dtsi
- Change the memory node to cover the full 512MB RAM in board dts
- Link to v1: https://lore.kernel.org/r/20250721-dr1v90-basic-dt-v1-0-5740c5199c47@pigmoral.tech

---
Junhui Liu (11):
      dt-bindings: vendor-prefixes: Add Anlogic, Milianke and Nuclei
      dt-bindings: riscv: Add Nuclei UX900 compatibles
      dt-bindings: riscv: Add Anlogic DR1V90
      dt-bindings: timer: Add Anlogic DR1V90 CLINT
      dt-bindings: interrupt-controller: Add Anlogic DR1V90 PLIC
      dt-bindings: serial: snps-dw-apb-uart: Add Anlogic DR1V90 uart
      riscv: Add Anlogic SoC famly Kconfig support
      riscv: dts: Add initial Anlogic DR1V90 SoC device tree
      riscv: dts: anlogic: Add Milianke MLKPAI FS01 board
      riscv: defconfig: Enable Anlogic SoC
      MAINTAINERS: Setup support for Anlogic DR1V90 SoC tree

 .../interrupt-controller/sifive,plic-1.0.0.yaml    |  1 +
 .../devicetree/bindings/riscv/anlogic.yaml         | 27 +++++++
 Documentation/devicetree/bindings/riscv/cpus.yaml  |  1 +
 .../bindings/serial/snps-dw-apb-uart.yaml          |  1 +
 .../devicetree/bindings/timer/sifive,clint.yaml    |  1 +
 .../devicetree/bindings/vendor-prefixes.yaml       |  6 ++
 MAINTAINERS                                        |  9 +++
 arch/riscv/Kconfig.socs                            |  5 ++
 arch/riscv/boot/dts/Makefile                       |  1 +
 arch/riscv/boot/dts/anlogic/Makefile               |  2 +
 arch/riscv/boot/dts/anlogic/dr1v90-mlkpai-fs01.dts | 28 +++++++
 arch/riscv/boot/dts/anlogic/dr1v90.dtsi            | 85 ++++++++++++++++++++++
 arch/riscv/configs/defconfig                       |  1 +
 13 files changed, 168 insertions(+)
---
base-commit: 07e27ad16399afcd693be20211b0dfae63e0615f
change-id: 20250710-dr1v90-basic-dt-352e9ae5acb8

Best regards,
-- 
Junhui Liu <junhui.liu@pigmoral.tech>

On Mon, Sep 22, 2025 at 08:46:30PM +0800, Junhui Liu wrote:
> This patch series introduces initial support for the Anlogic DR1V90 SoC
> [1] and the Milianke MLKPAI-FS01 [2] board.

It's a bit late for v6.18 content, since the merge window likely opens
on Monday, but how do you intend getting the series into mainline?

There is a document https://docs.kernel.org/process/maintainer-soc.html
containing information about how the platform maintenance process works.
Arnd has suggested that the best way to get a platform initially added
is to send the whole patchset, rather than a PR - it leaves you with
fewer things to deal with at once. This patchset should be sent to
soc@kernel.org, with a note saying that it is ready for inclusion in
your cover letter. 

Ideally, the initial patchset for an SoC should contain clock (and
pinctrl) support, rather than use fake fixed-clocks, but you have none of
those in your base dts so I have no objections. fixed-clocks can become
a problem if the dts is imported into U-Boot via OF_UPSTREAM or
elsewhere, since it can cause regressions for them. I would highly
suggest that upstreaming the clock/reset controller is the next step
that you take, because other peripherals are going to need clocks.

Please let me know if you have any questions - either by email (and it
can be off-list if needed if it relates to platform maintenance
questions) or on irc (I'm conchuod on libera.chat).

Cheers,
Conor.

On Thu, Sep 25, 2025 at 06:22:41PM +0100, Conor Dooley wrote:
> On Mon, Sep 22, 2025 at 08:46:30PM +0800, Junhui Liu wrote:
> > This patch series introduces initial support for the Anlogic DR1V90 SoC
> > [1] and the Milianke MLKPAI-FS01 [2] board.
> 
> It's a bit late for v6.18 content, since the merge window likely opens
> on Monday, but how do you intend getting the series into mainline?
> 
> There is a document https://docs.kernel.org/process/maintainer-soc.html
> containing information about how the platform maintenance process works.
> Arnd has suggested that the best way to get a platform initially added
> is to send the whole patchset, rather than a PR - it leaves you with
> fewer things to deal with at once. This patchset should be sent to
> soc@kernel.org, with a note saying that it is ready for inclusion in
> your cover letter. 
> 
> Ideally, the initial patchset for an SoC should contain clock (and
> pinctrl) support, rather than use fake fixed-clocks, but you have none of
> those in your base dts so I have no objections. fixed-clocks can become
> a problem if the dts is imported into U-Boot via OF_UPSTREAM or
> elsewhere, since it can cause regressions for them. I would highly
> suggest that upstreaming the clock/reset controller is the next step
> that you take, because other peripherals are going to need clocks.
> 
> Please let me know if you have any questions - either by email (and it
> can be off-list if needed if it relates to platform maintenance
> questions) or on irc (I'm conchuod on libera.chat).

I had a chat with Junhui on irc the other day, where they expressed
unwillingness to act as the platform maintainer, to avoid being in
conflict with the vendor. I'm disappointed of course that the vendor's
behaviour has had this impact, but of course I understand where Junhui
is coming from.

Fortunately Junhui is still willing to post patches for the platform, as
they want to run mainline on their board. I will add the platform to my
"misc" branch, along with the other platforms I apply patches for until
either Junhui changes their mind or until people who understand the
process and standards wish to take it over.

Cheers,
Conor.