[lowrisc-dev] Re: Question on lowrisc project

Pawan Reddy Sibbala ps849 at cornell.edu
Sun Feb 7 04:32:59 GMT 2016


Hello Wei,

Thank you. I'm able to run binaries inside RISC-V linux now which are
compiled/linked statically.

Thanks and regards,
Pawan

On Mon, Feb 1, 2016 at 7:33 AM, Wei Song <ws327 at cam.ac.uk> wrote:

> Hello Pawan,
>
> For compiling a program to run statically inside RISC-V Linux, you need to
> add an argument "-static".
> There is a make file in $TOP/riscv-tools/hello.
> It generates three different executables for all environment.
> hello.linux is the one running in RISC-V Linux.
> May be you could have a look.
>
> best regards,
> Wei
>
>
> On 31/01/2016 22:30, Pawan Reddy Sibbala wrote:
>
> Hello Wei,
>
> Yes, the newly generated images work fine on the FPGA.
>
>       I suppose some busybox configuration options need to be enabled to
> support these features and I did not have enough time to figure out.
>       If in case you know how to do it, please let me know; therefore I
> can update the configuration file.
>
>      The prepared configure file is used by the following command:
>       http://www.lowrisc.org/docs/tagged-memory-v0.1/setup/
>       Build the root image (root.bin) for the Linux kernel
>       cp $TOP/riscv-tools/busybox_config .config
>
>      You can use the busybox configuration mechanism to generate your own
> configuration file.
>      cd $TOP/riscv-tools/busybox-1.21.1
>      make menuconfig
>      But be careful you may need to manually change the cross-compiler to
> riscv-gcc.
>
> I'm not quite sure how to do it now, but I'll definitely let you know if I
> figure it out in the future.
>
>      As for why you cannot run your own programs. May be you would like to
> show me the error messages?
>      And perhaps the script you used to compile your programs as well. It
> would be difficult for me to guess with a simple description of it does not
> run.
>      The common reasons would be wrong tool-chain or non-static
> compilation.
>      So any programs run inside the RISC-V Linux should be compiled using
> the riscv-gcc and should be statically compiled/linked.
>      There is no dynamic libraries in the RISC-V Linux. So if the
> executable needs some run-time libraries, it probably would not run
> properly.
>      There are ways to support dynamic libraries in the RISC-V Linux, only
> if you would like to be bothered with recompiling the libraries and
> manually install                them into a clean kernel.
>
> The programs I'm trying are as simple as printing "hello world" and adding
> two numbers.
>
> #include <stdio.h>
> int main(void) {
> printf("Hello World\n");
> return 0;
> }
>
> I'm generating the executable using the following command
> $ riscv-linux-gcc -o hello hello.c.  Do I have to do anything different
> for static linking ?
>
> Then, when I try to run the generated executable on linux booted on
> rocket, I get "segmentation fault" error as shown below. I tried it with
> few programs and I get the same error for all of them. However, when I
> compile the program using the following command
>
> $ riscv64-unknown-elf-gcc -o hello hello.c
>
> and try to run the generated executable using front-end server and pk, it
> runs without any issues.
>
>
>
> BusyBox v1.22.1 (2014-07-19 16:30:20 PDT) built-in shell (ash)
>
> Enter 'help' for a list of built-in commands.
>
> / # ls
> bin                     home                    sbin
>
> bzip2_base.gcc43-64bit  lib                     tests
>
> dev                     lost+found              tmp
>
> etc                     proc                    usr
>
> / # cd home
>
> /home # ls
>
> ctests
>
> /home # cd ctests/
>
> /home/ctests # ls
>
> add          hello        hello.c~     userinput.c
> add.c        hello.c      userinput
>
> /home/ctests # ./hello
>
> *Segmentation fault*
>
> I'm not sure what I'm missing to make the executables run on RISC-V linux
> kernel as the precompiled executables are running fine.
>
> Thanks and regards,
> Pawan
>
>
>
>
> On Thu, Jan 28, 2016 at 5:38 AM, Wei Song <ws327 at cam.ac.uk> wrote:
>
>> Hello Pawan,
>>
>> Good to know now you can regenerate a RISC-V kernel and root.bin to run
>> in Spike.
>> I suppose if you try the newly generated images on FPGA, they should just
>> work fine.
>>
>> Please keep the lowrisc mailist in cc as it would keep a record and
>> someone else may have the same problem.
>>
>> For your further questions:
>>
>> After the boot, when I try to press arrow keys, it acts weird ( as seen
>> above [[D^ etc ). One more difference I notice is, during the boot process
>> for precompiled FPGA image provided, even these lines are executed and the
>> command line doesnot act weird like in the above case. But, I am not able
>> to execute the binaries I compile in either of them. Could you tell me what
>> you think would be the problem?
>>
>>
>> This is actually OK. The precompiled root.bin is the original copy from
>> RISC-V (Berkeley team). They use a different busybox configuration which
>> was not disclosed.
>> I tried to make a similar configuration and this is probably the best I
>> get.
>> The problem for the weird characters is due to the lack of command
>> history and auto-filling.
>> This has no effect on executing programs.
>> I suppose some busybox configuration options need to be enabled to
>> support these features and I did not have enough time to figure out.
>> If in case you know how to do it, please let me know; therefore I can
>> update the configuration file.
>>
>> The prepared configure file is used by the following command:
>> http://www.lowrisc.org/docs/tagged-memory-v0.1/setup/
>> Build the root image (root.bin) for the Linux kernel
>> cp $TOP/riscv-tools/busybox_config .config
>>
>> You can use the busybox configuration mechanism to generate your own
>> configuration file.
>> cd $TOP/riscv-tools/busybox-1.21.1
>> make menuconfig
>> But be careful you may need to manually change the cross-compiler to
>> riscv-gcc.
>>
>> As for why you cannot run your own programs. May be you would like to
>> show me the error messages?
>> And perhaps the script you used to compile your programs as well. It
>> would be difficult for me to guess with a simple description of it does not
>> run.
>> The common reasons would be wrong tool-chain or non-static compilation.
>> So any programs run inside the RISC-V Linux should be compiled using the
>> riscv-gcc and should be statically compiled/linked.
>> There is no dynamic libraries in the RISC-V Linux. So if the executable
>> needs some run-time libraries, it probably would not run properly.
>> There are ways to support dynamic libraries in the RISC-V Linux, only if
>> you would like to be bothered with recompiling the libraries and manually
>> install them into a clean kernel.
>>
>> 2.   The SPECint benchmarks which you ran on FPGA, are they with the
>> help of proxy kernel ? I was wondering if you recorded the runtime of the
>> benchmarks? The link provided talks about miss rates and memory traffic.
>>
>>
>> Yes, I run them using the front-end server and pk (without Linux kernel).
>> Not all cases can run in this way.
>> For getting the runtime, you basically need some program to read the
>> CSR.cycle before and after the execution.
>> It is easier with pk since you can revise the pk or the front-end server
>> code to do this.
>> Run benchmark inside kernel is a little bit tricky.
>> I am not sure how to do it. May be you can have a separate program to
>> read time.
>> Then you can revise the benchmark script to call this extra program to
>> read time before and after each benchmark case.
>> I had never tried this.
>>
>> For running the SPECInt benchmark, Christopher Celio has a good wrapper
>> for it.
>> https://github.com/ccelio/Speckle
>> However, he must have updated the wrapper to work with the latest
>> toolchain. If you are going to use this, you need to check out an old
>> version.
>> What I had used is commit 6b9b92cbff85  10-April-2015.
>> I also needed to revise some of his scripts to make it work.
>>
>> Best regards,
>> Wei
>>
>>
>> On 28/01/2016 05:50, Pawan Reddy Sibbala wrote:
>>
>> Hello Wei,
>>
>> Right, I did not actually do the spike emulation the first time. Sorry
>> about that. But, I did it now and the results are the same as yours. Please
>> look at them below.
>>
>> $ gcc -v
>> Using built-in specs.
>> COLLECT_GCC=gcc
>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
>> Target: x86_64-linux-gnu
>> gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
>>
>> $ cd $TOP/riscv-tools
>> $ git status
>> HEAD detached at 722377f
>>
>> $ cd riscv-gcc
>> $ git status
>> On branch master
>> Your branch is up-to-date with 'origin/master'.
>>
>> $ riscv-linux-gcc -v
>> Using built-in specs.
>> COLLECT_GCC=riscv-linux-gcc
>>
>> COLLECT_LTO_WRAPPER=/home/siva/Desktop/taggedmemory/lowrisc-chip/riscv/libexec/gcc/riscv-linux/4.6.1/lto-wrapper
>> Target: riscv-linux
>> Configured with:
>> /home/siva/Desktop/taggedmemory/lowrisc-chip/riscv-tools/riscv-gcc/gcc-4.6.1/configure
>>  --target=riscv-linux
>> --prefix=/home/siva/Desktop/taggedmemory/lowrisc-chip/riscv --enable-shared
>>  --disable-threads --enable-tls --enable-languages=c,c++
>> --disable-libmudflap --disable-libssp
>>  --disable-libquadmath --disable-nls --disable-multilib
>> --disable-bootstrap --with-headers=
>>
>>  /home/siva/Desktop/taggedmemory/lowrisc-chip/riscv-tools/riscv-gcc/linux-headers//include
>> Thread model: single
>> gcc version 4.6.1 (GCC)
>>
>> $ riscv64-unknown-elf-gcc -v
>> Using built-in specs.
>> COLLECT_GCC=riscv64-unknown-elf-gcc
>>
>> COLLECT_LTO_WRAPPER=/home/siva/Desktop/taggedmemory/lowrisc-chip/riscv/libexec/gcc/riscv64-unknown-elf/4.9.2/lto-wrapper
>> Target: riscv64-unknown-elf
>> Configured with:
>> /home/siva/Desktop/taggedmemory/lowrisc-chip/riscv-tools/riscv-gnu-toolchain/build/src/newlib-gcc
>> /configure --target=riscv64-unknown-elf
>> --prefix=/home/siva/Desktop/taggedmemory/lowrisc-chip/riscv
>> --disable-shared --disable-threads --enable-tls --enable-languages=c,c++
>> --with-newlib --disable-libmudflap
>> --disable-libssp --disable-libquadmath --disable-libgomp --disable-nls
>> Thread model: single
>> gcc version 4.9.2 (GCC)
>>
>> $TOP/riscv-tools
>> $ spike +disk=./busybox-1.21.1/root.bin ./linux-3.14.13/vmlinux
>>
>> [    0.000000] Linux version 3.14.13-g989153f (siva at Siva-Ubuntu) (gcc
>> version 4.6.1 (GCC) ) #1 Wed Jan 27 00:35:01 EST 2016
>> [    0.000000] Detected 0x100000000 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] On node 0 totalpages: 245760
>> [    0.000000] free_area_init_node: node 0, pgdat ffffffff80247ef8,
>> node_mem_map ffffffff80290000
>> [    0.000000]   Normal zone: 1680 pages used for memmap
>> [    0.000000]   Normal zone: 0 pages reserved
>> [    0.000000]   Normal zone: 245760 pages, LIFO batch:15
>> [    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
>> [    0.000000] pcpu-alloc: [0] 0
>> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
>> Total pages: 244080
>> [    0.000000] Kernel command line: root=/dev/htifbd0 debug
>> [    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] Memory: 1946872K/1966080K available (1762K kernel code,
>> 136K rwdata, 368K rodata, 66K init, 248K bss, 19208K reserved)
>> [    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
>> [    0.000000] NR_IRQS:8
>> [    0.000000] console [htifcons0] enabled
>> [    0.150000] Calibrating delay using timer specific routine.. 200.36
>> BogoMIPS (lpj=1001806)
>> [    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] htifcons: detected console with ID 1
>> [    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] TCP: cubic registered
>> [    0.230000] htifbd: detected disk with ID 2
>> [    0.230000] htifbd: adding htifbd0
>> [    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)
>> [    0.250000] EXT2-fs (htifbd0): warning: mounting unchecked fs, running
>> e2fsck is recommended
>> # [   73.600000] random: nonblocking pool is initialized
>>
>> #
>> # ls
>> bin         etc         lib         lost+found  sbin        tmp
>> dev        linuxrc     proc        sys         usr
>> # cd ^[[D^[[D^[[D^[[C^[[C^[[A^[[B
>>
>> After the boot, when I try to press arrow keys, it acts weird ( as seen
>> above [[D^ etc ). One more difference I notice is, during the boot process
>> for precompiled FPGA image provided, even these lines are executed and the
>> command line doesnot act weird like in the above case. But, I am not able
>> to execute the binaries I compile in either of them. Could you tell me what
>> you think would be the problem?
>>
>> 2.   The SPECint benchmarks which you ran on FPGA, are they with the
>> help of proxy kernel ? I was wondering if you recorded the runtime of the
>> benchmarks? The link provided talks about miss rates and memory traffic.
>>
>> Thanks and regards,
>> Pawan
>>
>>
>>
>
>
> --
> Pawan Reddy Sibbala
> M.Eng ECE
> Cornell University
>
>
>


-- 
Pawan Reddy Sibbala
M.Eng ECE
Cornell University


More information about the lowrisc-dev mailing list