On Thu, Sep 25, 2025 at 11:06:50AM +0800, fushan.zeng wrote:

On Mon, 22 Sep 2025 20:46:30 +0800, Junhui Liu wrote:

quoted

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.

Thanks first.
Anloigc already has the open source SDK at https://gitee.com/anlogic/sdk,

I think very few people actually use Gitee around here.

and will submit it to mainline at suitable time.
It is better that anlogic SOCs are long term maintained and supported
by Anlogic officially in mainline and for customers.
The code should be a full feature version after lots of tests, not the
modified and simplified version from Anlogic open source.

I understand how you feel:
You want to be responsible for both the code and the customers.

And we hope that there won't be two different versions code of anlogic SOCs,
it may confuse customers.

This is almost impossible.
Mainline means simple, clear, compliant, fully open source.
Some features, like GPU, are nearly impossible to fully upstream.
Vendor versions are complex and implement full hardware features.
It also seems you expect only official folks to handle this,
which would take significant effort to maintain,
perhaps even requiring dedicated personnel.

                - Troy

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv