Green Hu posted a patch to support the NDS32 architecture. He described the current status as, "It is able to boot to shell and passes most LTP-2017 testsuites in nds32 AE3XX platform."

Arnd Bergmann approved the patch, but Linus Torvalds wanted a little more of a description—an overview of the "uses, quirks, reasons for existing" for this chip, to include in the changelog.

Arnd replied:

The non-marketing description is that this is a fairly conventional (in a good way) low-end RISC architecture that is usually integrated into custom microcontroller and SoC designs, competing with the similar ARM32, ARC, MIPS32, RISC-V, Xtensa and (currently under review) C-Sky architectures that occupy the same space. The most interesting bit from my perspective is that Andestech are already selling a new generation of CPU cores that are based on 32-bit and 64-bit RISC-V, but are still supporting enough customers on the existing cores to invest in both.

And Green also said:

Andes nds32 architecture supports Linux for Andes's N10, D10, N13, N15, D15 processor cores.

Based on the patented 16/32-bit AndeStar RISC-like architecture, we designed the configurable AndesCore series of embedded processor families. AndesCores range from highly performance-efficient small-footprint cores for microcontrollers and deeply-embedded applications to 1GHz+ cores running Linux, covering general-purpose N-series cores for a wide range of computing needs; DSP-capable D-series cores for digital signal control; instruction-extensible E-series cores for application-specific acceleration; and secure S-series cores for best protection of the most valuable.

Our customers together have shipped over 2.5 billion SoCs with Andes processors embedded (including non-MMU IP cores). It will help our customers to get better Linux support if we are merged into mainline.

It looks like there's no controversy over this port, and it should fly into the main tree. One reason for the easy adoption is that it doesn't touch any other part of the kernel—if the patch breaks anything, it'll break only that one architecture, so there's very little risk in letting Green make his own choices about what to include and what to leave out. Linus's main threshold will probably be, does it compile? If yes, then it's okay to go in.

The situation may start to become interesting if other parts of the kernel begin offering special behaviors for the NDS32 architecture, and if those behaviors start deviating too far from other architectures. For example, some architectures have special memory managing features that the kernel proper can take advantage of. Once NDS32 starts influencing code in other parts of the kernel, that likely would be the time Green's patches start to get a lot more scrutiny.

Note: if you're mentioned above and want to post a response above the comment section, send a message with your response text to ljeditor@linuxjournal.com.