It's not. Before LoongArch, Loongson made MIPS64 CPUs. But this is about LoongArch which is similar but incompatible with MIPS64.

Loongson started with MIPS CPUs but current CPUs are not MIPS-compatible. LoongArch, while being very similar to MIPS, uses a different encoding. And some other details have changed. Better to say, MIPS-inspired.

> LoongArch is now a fully legitimate, upstreamed ISA—with mainline Linux, Debian, and Rust support—ensuring it will be maintainable and usable at scale, but its momentum is institutional and domestic rather than market-driven: it exists to guarantee China a sovereign, unblockable CPU stack on a short timeline, not to attract global vendors, startups, or cloud ecosystems. In contrast, RISC-V is accumulating multi-vendor, cross-border adoption and economic gravity that define a global ISA; LoongArch’s success criteria are different, narrower, and largely already met.

The Orange Pi Nova will use Loongson's 2K3000 SoC and should be available on Amazon. Looking forward to getting one in for review.

[dead]

"suspiciously close" isn't close enough, unfortunately, though it might make the task less work:

If your uname output, compiler architecture ifdefs, etc, don't match the existing architecture then basically every program that does per architecture specialisation will need updating, even if fairly trivially so.

If you're not building and running identical binaries, then anybody who distributes binaries needs to be persuaded that it's worthwhile to get hold of build machines and devote archive space and maintenance time to your new architecture.

There may be political issues where neither the owners of the old architecture nor the owners of the new clone want to come out and admit that it's very similar. This may result in projects treating it as "genuinely new architecture" rather than "variant of an existing one", which is more work. (There are also technical concerns about future divergence that might argue for "not just a variant".)

If you have to have the code structure of a complete new architecture then this can also trigger more work where the old arch code got to get away with legacy practices and APIs but the newcomer is expected to reach any project standards for new code, so "copy, paste, rename" is insufficient. Sometimes this imposes constraints that make more work elsewhere: for instance a new architecture in Linux is expected to follow a modern syscall numbering scheme and set of syscalls, so it won't have a userspace ABI that's compatible with the arch it is cloning.

If the architecture you're cloning is a "declining" architecture now mostly in legacy setups, then modern projects you care about for your new architecture might not have good or any support for it. (If you cloned sh4 you won't have easy rust support, for example.)

Overall, getting a new architecture from "we have a spec" to comprehensive open source ecosystem support is a heavy lift, and clone and copy doesn't get you out of all of it. (Look back at how long it took 32 bit Arm and then 64 bit Arm and now how riscv is following similar paths. These have all been years long efforts with a very long tail.)