Re: Question on lowrisc project
by Wei Song
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@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
>
7 years
- 4
- 14
Untethered lowRISC 0.2 with Zedboard
by Alexis Ramos Amo
Hi,
I've seen that new Untethered lowRISC 0.2 lacks of support for Zynq Zedboard.
Are you going to add support for this board or any of the Zynq family (like ZC706) in the future?.
Thank you
Alexis Ramos Amo
Researcher
7 years, 1 month
- 3
- 2
KC705 untethered - Discuss RAM at 0x0 and MMIO space?
by Michael Clark
Hello Wei, RISC-V folk,
Just a quick note about a successful bootstrap on the KC705 following
Wei's excellent untethered lowRISC tutorial.
I compiled the kc705 Rocket bitstream, lowrisc-kc705-bbl (boot),
vmlinux, busybox and a custom root.bin completely from source using the
riscv.org riscv-gnu-toolchain.
* https://github.com/riscv/riscv-linux (3.14.41)
* https://github.com/riscv/riscv-gnu-toolchain
* https://github.com/lowRISC/lowrisc-chip
I encountered one small issue while compiling the lowrisc-kc705-bbl with
the upstream riscv-gnu-toolchain (see mcall_send_ipi diffs below). I was
able to temporarily work around the issue by commenting out the IPI code
given I had only synthesized a single core (see first diff below).
I have now just had time to look into the issue today and discovered the
send_ipi CSR has been renamed to mipi in riscv-tools. See the last patch
which I have just compiled and booted on the KC705 (note: it requires an
update to lowrisc-kc705/bbl/encoding.h). When I get time I'll try to
build 2 cores and test IPI properly.
I also managed to trigger this panic in io_irq_service when running
(busybox) vi:
panic("io_irq_service(): no record");
BTW Great work, everyone! This is pretty well integrated so far... It
will be great when the boot protocol, platform memory map and interrupt
controller get nailed down.
Random thoughts. Would an improved boot protocol have the on-chip ROM
download a first stage boot from off-board EEPROM using SPI in an 'L1
cached mapped in machine mode' (write-back caching, no backing store)
i.e. no DRAM enabled. Outside of FPGA we will need to inquire the SPDs
over SMBus before we can configure DRAM (in early boot EEPROM code). L1
Cache would be mapped literally anywhere, early boot just has to take
care not to be evicted. After EEPROM is loaded into cache (mapped at 0x0
like bbl in spike) by the on-chip ROM the EEPROM boot code can (using
MMIO to the memory controller or however) turn on DRAM backing for the
cache and start flushing and then stop worrying about being evicted.
I guess as long as RAM/DRAM is in the device tree, it doesn't matter
where it is in machine mode, but ideally it can be mapped at 0x0 to
match spike.
We would need a standardized cache control CSR at minimum? but there
needs to be some MMIO space and memory controller protocol for early
EEPROM code to get DRAM mapped at 0x0.
Also, if RAM can be at 0x0 physical (like spike), then the bigger
question is where will these MMIO apertures will be in the physical
address. I guess they will be in device tree and RAM is already working
when Linux and FreeBSD start up so they are already happy.
I see we have IO on the kc705 currently at 0x0000000080000000. If we
wanted to punch a tinier hole for a small 4GB system wouldn't
0x00000000f8000000 be better? (symmetry with Ring 0 VA space in Linux;
only positive). 64MB would would be enough room for all bootstrap MMIO
(PIC, memory controller, PCI configuration space, IO MMU, etc), until IO
MMU can be bootstrapped to map bigger chunks of IO space outside of the
RAM physical address space (large memory systems). A very simple memory
controller that couldn't remap this space would then only waste 64MB on
a 4GB system. i.e. works on both small and large scales.
Regards,
Michael.
# build error
mclark@munty:~/src/lowrisc-chip/fpga/board/kc705/bbl$ make
riscv64-unknown-elf-gcc -MMD -MP -Wall -Werror -D__NO_INLINE__ -DENABLE_ATOMICS -mcmodel=medany -O2 -std=gnu99 -Wno-unused -Wno-attributes -fno-delete-null-pointer-checks -I. -I.. -c mtrap.c -o mtrap.o
mtrap.c: Assembler messages:
mtrap.c:316: Error: Instruction csrw requires absolute expression
Makefile:84: recipe for target 'mtrap.o' failed
make: *** [mtrap.o] Error 1
# my temporary workaround
mclark@munty:~/src/lowrisc-chip/fpga/board/kc705$ git diff bbl/mtrap.c
diff --git a/bbl/mtrap.c b/bbl/mtrap.c
index 5b25d7e..c3066f7 100644
--- a/bbl/mtrap.c
+++ b/bbl/mtrap.c
@@ -313,7 +313,7 @@ static uintptr_t mcall_send_ipi(uintptr_t recipient)
if (atomic_swap(&OTHER_HLS(recipient)->ipi_pending, 1) == 0) {
mb();
- write_csr(send_ipi, recipient);
+ //write_csr(send_ipi, recipient);
}
return 0;
# riscv bbl
@@ -213,7 +313,7 @@
if (atomic_swap(&OTHER_HLS(recipient)->ipi_pending, 1) == 0) {
mb();
- OTHER_HLS(recipient)->csrs[CSR_MIPI] = 0;
+ write_csr(send_ipi, recipient);
}
# proper fix
diff --git a/bbl/mtrap.c b/bbl/mtrap.c
index 5b25d7e..c678d81 100644
--- a/bbl/mtrap.c
+++ b/bbl/mtrap.c
@@ -313,7 +313,7 @@ static uintptr_t mcall_send_ipi(uintptr_t recipient)
if (atomic_swap(&OTHER_HLS(recipient)->ipi_pending, 1) == 0) {
mb();
- write_csr(send_ipi, recipient);
+ write_csr(mipi, recipient);
}
return 0;
7 years, 1 month
- 2
- 4
Re: Question on lowrisc project
by Christopher Celio
> 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.
Wei,
I hope things are going well for you!
If you're having issues with Speckle, please let me know (preferably via the github issue) so I can address any problems that you or others are facing. =)
The only thing that should need to change as the riscv toolchain evolves are the compiler flags found within the riscv.cfg file. I'd also like to know what changes to the scripts you've needed to make, so that perhaps I can make them more flexible to fit different use-cases. There have been at least one or two useful bug fixes, so I'd hate for people to have to use an older commit for things to work!
>> 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.
I myself run SPECInt on the Linux kernel, but the riscv.cfg I provide in Speckle also works on the proxy kernel. I record run-times by using a second process that reads the uarch counters and prints them to the screen, but is otherwise asleep for the duration of the SPEC benchmark run.
-Chris
> On Jan 28, 2016, at 4:00 AM, lowrisc-dev-request(a)lists.lowrisc.org wrote:
>
> Send lowrisc-dev mailing list submissions to
> lowrisc-dev(a)lists.lowrisc.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/lowrisc-dev-lis...
>
> or, via email, send a message with subject or body 'help' to
> lowrisc-dev-request(a)lists.lowrisc.org
>
> You can reach the person managing the list at
> lowrisc-dev-owner(a)lists.lowrisc.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of lowrisc-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Question on lowrisc project (Wei Song)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 28 Jan 2016 10:38:01 +0000
> From: Wei Song <ws327(a)cam.ac.uk>
> Subject: [lowrisc-dev] Re: Question on lowrisc project
> To: Pawan Reddy Sibbala <ps849(a)cornell.edu>
> Cc: "lowrisc-dev(a)lists.lowrisc.org" <lowrisc-dev(a)lists.lowrisc.org>
> Message-ID: <56A9EF89.9040505(a)cam.ac.uk>
> Content-Type: text/plain; charset=utf-8
>
> 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@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
>>
>
>
>
> ------------------------------
>
> _______________________________________________
> lowrisc-dev mailing list
> lowrisc-dev(a)lists.lowrisc.org
> http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/lowrisc-dev-lis...
>
>
> End of lowrisc-dev Digest, Vol 16, Issue 3
> ******************************************
7 years, 1 month
- 2
- 1
Re: Question on lowrisc project
by Wei Song
Hello Pawan Reddy Sibbala,
Putting your modified root.bin aside, the first thing is to figure out
why you cannot regenerate a working root.bin.
From the screen output, it seems to me like you already have a working
root.bin but you had messed up it by non-clean exiting RISC-V Linux
(without exit before shutdown).
May be what you need is just to regenerate a clean root.bin and try again.
Remember to use command exit otherwise the root.bin image can be broken.
If it is still not working, I think I need to double check whether you
are using the correct toolchain as I have just gone through the whole
make process again and it is OK on my machine.
So here is my toolchain:
$ 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.4 (Ubuntu 4.8.4-2ubuntu1~14.04)
$ cd $TOP/riscv-tools
$ git status
HEAD detached at 722377f
$ cd $TOP/riscv-tools/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=/local/scratch/ws327/proj/tagged/lowrisc-chip/riscv/bin/../libexec/gcc/riscv-linux/4.6.1/lto-wrapper
Target: riscv-linux
gcc version 4.6.1 (GCC)
$ riscv64-unknown-elf-gcc -v
Using built-in specs.
COLLECT_GCC=riscv64-unknown-elf-gcc
COLLECT_LTO_WRAPPER=/local/scratch/ws327/proj/tagged/lowrisc-chip/riscv/bin/../libexec/gcc/riscv64-unknown-elf/4.9.2/lto-wrapper
Target: riscv64-unknown-elf
gcc version 4.9.2 (GCC)
$ cd $TOP/riscv-tools/riscv-gcc
$ spike +disk=./busybox-1.21.1/root.bin ./linux-3.14.13/vmlinux
[ 0.000000] Linux version 3.14.13-g989153f
(ws327(a)valencia.cl.cam.ac.uk) (gcc version 4.6.1 (GCC) ) #1 Mon Jan 25
11:58:50 GMT 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.40
BogoMIPS (lpj=1002040)
[ 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)
#
Let me know if there is anything that does not match.
Best regards,
Wei
On 24/01/16 00:04, Pawan Reddy Sibbala wrote:
> Hi Wei,
>
> Thank you for responding. Yes, I am able to boot linux into a shell
> with the already existing root.bin. However, I have trouble compiling
> my own root.bin. It does not show any errors when I compile it but
> when I try to boot linux using the root.bin which is compiled by me,
> it shows the error message I sent you. I didn't make any revisions to
> the busybox binary. I'm only adding a new folder when i'm creating
> root.bin.
>
> I double-checked and tried to compile my own root.bin once again using
> the toolchain pointed by this link
> http://www.lowrisc.org/docs/tagged-memory-v0.1/setup/.
>
> However, I'm still unable to compile a correct root.bin. When I try to
> boot linux into a shell, kernel is booted but the lines in inittab are
> not executed. I attached my screen output for your reference.
>
> I would greatly appreciate your help in this regard. Looking forward
> to hearing from you.
>
> On Thu, Jan 21, 2016 at 6:34 PM, Wei Song <ws327(a)cam.ac.uk
> <mailto:ws327@cam.ac.uk>> wrote:
>
> Hello Pawan Reddy Sibbala,
>
> It seems the Linux kernel is booted OK but the kernel cannot run
> the init.
> The tagged memory release uses an old toolchain which is
> incompatible with the latest one from RISC-V.
> May be you could double check whether you are using the old
> toolchain that is pointed by the tagged memory release?
> I assume you can boot Linux into a shell using the preprepared
> root.bin.
> Can you compile your own root.bin and boot the Linux into a shell?
> If you can, your toolchain is OK. Then it probably is your
> revision to the busybox causing the issue.
> Otherwise, try to find out why you cannot compile your own
> root.bin (wrong toolchain, wrong configure, etc).
>
> Good luck,
> Wei
>
>
>
> On 21/01/16 19:28, Pawan Reddy Sibbala wrote:
>> Hello Wei,
>>
>> I am an MEng student at Cornell University. I am working with the
>> FPGA setup of the rocket chip on the zedboard FPGA. I wanted to
>> do some performance measurements of the rocket chip. So, I tried
>> modifying the root.bin file system to add some binaries by
>> following the steps in the tutorial in this link.
>> http://www.lowrisc.org/docs/tagged-memory-v0.1/setup/
>>
>> However, after I create root.bin myself and try to boot linux on
>> the rocket, it gives me following error on boot up.
>>
>> /"0.460000] Starting init: /sbin/init exists but couldn't execute
>> it (error -22)
>> /
>> /[ 0.470000] Kernel panic - not syncing: No working init
>> found. Try passing init= option to kernel. See Linux
>> Documentation/init.txt for guidance."/
>> /
>> /
>> I was not able to figure out what the error was. Could you please
>> help me with this? I would greatly appreciate your help.
>>
>> Thanks and regards,
>> Pawan Reddy Sibbala
>> M.Eng ECE
>> Cornell University
>>
>
>
>
>
> --
> Pawan Reddy Sibbala
> M.Eng ECE
> Cornell University
7 years, 1 month
- 2
- 2
- ← Newer
- 1
- Older →