riscvarchive / riscv-linux

RISC-V Linux Port
606 stars 210 forks source link

Having trouble running linux on spike #21

Closed samfin closed 7 years ago

samfin commented 9 years ago

I followed the instructions in the The Linux/RISC-V Installation Manual on the riscv-tools page and made it to the final step, after which I got the following output:

[    0.000000] Linux version 3.14.19-gc0f5580 (samfin@ubuntu) (gcc version 4.9.2 (GCC) ) #1 Mon Feb 16 15:01:07 EST 2015
[    0.000000] Detected 0xaec00000 bytes of physical memory
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x00000000-0x77ffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00000000-0x77ffffff]
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 244080
[    0.000000] Kernel command line: root=/dev/htifblk0
[    0.000000] PID hash table entries: 4096 (order: 2, 32768 bytes)
[    0.000000] Dentry cache hash table entries: 262144 (order: 8, 2097152 bytes)
[    0.000000] Inode-cache hash table entries: 131072 (order: 7, 1048576 bytes)
[    0.000000] Sorting __ex_table...
[    0.000000] Memory: 1946944K/1966080K available (1703K kernel code, 133K rwdata, 360K rodata, 64K init, 241K bss, 19136K reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS:8
[    0.150000] Calibrating delay using timer specific routine.. 200.56 BogoMIPS (lpj=1002825)
[    0.150000] pid_max: default: 32768 minimum: 301
[    0.150000] Mount-cache hash table entries: 4096 (order: 2, 32768 bytes)
[    0.150000] Mountpoint-cache hash table entries: 4096 (order: 2, 32768 bytes)
[    0.150000] devtmpfs: initialized
[    0.150000] NET: Registered protocol family 16
[    0.150000] bio: create slab <bio-0> at 0
[    0.150000] Switched to clocksource riscv_clocksource
[    0.160000] NET: Registered protocol family 2
[    0.160000] TCP established hash table entries: 16384 (order: 4, 131072 bytes)
[    0.160000] TCP bind hash table entries: 16384 (order: 4, 131072 bytes)
[    0.160000] TCP: Hash tables configured (established 16384 bind 16384)
[    0.160000] TCP: reno registered
[    0.160000] UDP hash table entries: 1024 (order: 2, 32768 bytes)
[    0.160000] UDP-Lite hash table entries: 1024 (order: 2, 32768 bytes)
[    0.160000] NET: Registered protocol family 1
[    0.160000] futex hash table entries: 256 (order: -1, 6144 bytes)
[    0.160000] io scheduler noop registered
[    0.160000] io scheduler cfq registered (default)
[    0.220000] htifcon htif1: detected console
[    0.220000] console [htifcon0] enabled
[    0.220000] htifblk htif2: detected disk
[    0.220000] htifblk htif2: added htifblk0
[    0.220000] TCP: cubic registered
[    0.230000] VFS: Mounted root (ext2 filesystem) readonly on device 254:0.
[    0.230000] devtmpfs: mounted
[    0.230000] Freeing unused kernel memory: 64K (ffffffff80002000 - ffffffff80012000)
init: can't open '/': Function not implemented
[   78.220000] random: nonblocking pool is initialized

I suspect that the "init: can't open '/': Function not implemented" error has something to do with a bad disk image, but I don't know what would trigger this error.

a0u commented 9 years ago

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 commented 9 years ago

That fixes the issue, thank you very much!

On Mon, Feb 16, 2015 at 6:46 PM, Albert Ou notifications@github.com 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 https://github.com/riscv/riscv-linux/issues/21#issuecomment-74592257.

cirosantilli commented 8 years ago

@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 commented 7 years ago

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