There is no no-MMU Linux port at present. The port requires FDPIC support in binutils. In regular PIC binaries, the offset between the read-only .text,.rodata sections and the read-write .data,.bss sections is fixed. This is historical. No-MMU systems require multiple instances of the same binary or shlib to be shared with the same addresses for .text,.rodata and different memory addresses for .data,.bss.
In FDPIC, the offset to .data,.bss is no longer PC-Relative like it is with PIC rather it is relative to a TOC register, likely gp-relative on RISC-V as gp is currently reserved when generating PIC code. FDPIC also requires function pointers to point to function descriptors that contain both the function address and the FDPIC register value (pointer to GOT Base in .data,.bss). The FDPIC register needs to be loaded in the PLTs for inter-module calls, so each module can find its .data,.bss (as it’s no longer PC-Relative).
FDPIC has some interesting properties. A larger set of pointers can be leaked without revealing the location of .text (via static analysis i.e. known .data pointer can reveal .text via static analysis which can be used for ROP). However this is only partial as pointers to .rodata can still be leaked.
Unfortunately no-MMU Linux is crusty because nobody tests it so your out of luck. Nevertheless FDPIC would be useful for other no-MMU applications where there is more than one ELF loaded in memory or where the ROM/RAM layout (distance between ROM and RAM) is not known at link time. It’s a pity. Also we don’t have ASLR for regular PIC.