Having trouble running linux on spike about riscv-linux

[a0u]

Support for deprecated system calls was recently removed from the kernel port, but riscv-tools still points to an older revision of riscv-gnu-toolchain which predates the ABI change. In this case, the -ENOSYS ("Function not implemented") error arose from glibc's open(3) function invoking sys_open (now non-existent) instead of sys_openat.

Until we bump the submodules (after some consistency checks), you can resolve the mismatch by switching to the master branch of riscv-gnu-toolchain and rebuilding statically-linked BusyBox with the updated riscv64-unknown-linux-gnu toolchain. If BusyBox is dynamically linked, then it should only be necessary to recopy the shared libraries from the sysroot to the filesystem image.

Also, I noticed that the inittab(5) example in the Linux/RISC-V Installation Manual is slightly outdated with respect to the device node naming:

::sysinit:/bin/busybox mount -o remount,rw /dev/htifbd0 /

should instead be

::sysinit:/bin/busybox mount -o remount,rw /dev/htifblk0 /

[samfin]

That fixes the issue, thank you very much!

On Mon, Feb 16, 2015 at 6:46 PM, Albert Ou [email protected] wrote:

Support for deprecated system calls was recently removed from the kernel
port, but riscv-tools still points to an older revision of
riscv-gnu-toolchain which predates the ABI change. In this case, the
-ENOSYS ("Function not implemented") error arose from glibc's open(3)
function invoking sys_open (now non-existent) instead of sys_openat.

Until we bump the submodules (after some consistency checks), you can
resolve the mismatch by switching to the master branch of
riscv-gnu-toolchain and rebuilding BusyBox with the updated
riscv64-unknown-linux-gnu toolchain.

Also, I noticed that the inittab(5) example in the Linux/RISC-V
Installation Manual is slightly outdated with respect to the device node
naming:

::sysinit:/bin/busybox mount -o remount,rw /dev/htifbd0 /

should instead be

::sysinit:/bin/busybox mount -o remount,rw /dev/htifblk0 /

—
Reply to this email directly or view it on GitHub
#21 (comment).

[************]

@a0u any updates on this? I feel it is not very good for the project to have master "broken" for so long, maybe the consistency checks you mention could be done on another branch?

[palmer-dabbelt]

I'm closing this as it's quite old.