[lowrisc-dev] Re: Question on lowrisc project

Pawan Reddy Sibbala ps849 at cornell.edu
Sun Feb 7 06:27:43 GMT 2016


Hello Wei,

I have a question about the memory hierarchy of the rocket chip configured
on the zedboard FPGA.  Does the prebuilt FPGA image of the rocket chip for
zedboard have an L2 $ cache configured? In the zedboard/src/verilog folder,
I see that it DefaultFPGAConfig.v. From the "Configs.scala" file, I see
that L2 $ is not included in the DefaultFPGAConfig setting. So, I think
there is no L2$ configured in the prebuilt image. Am I correct?

http://wsong83.github.io/publication/comparch/riscv2015.pdf

But in the above paper, your configuration also has 128KB L2$. Did you use
different configuration settings to include the L2 $?

Thanks and regards,
Pawan

On Sat, Feb 6, 2016 at 11:32 PM, Pawan Reddy Sibbala <ps849 at cornell.edu>
wrote:

> 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
>



-- 
Pawan Reddy Sibbala
M.Eng ECE
Cornell University


More information about the lowrisc-dev mailing list