Linux booting help
by Francesco Viggiano
Hi all,
I'm trying to boot Linux on my own system architecture. As for now, I can
successfully run the SD card test example provided with lowRisc project.
I'd like more information on how to boot Linux, specifically:
1) My 1Gb DDR3 starts from address 0x0. I have a way to directly put a
program in Main memory. So I don't need the first stage bootloader, but I
can directly load the revised bbl in DDR. I have just modified the DDR,
uart and spi addresses on both bbl/ and driver/ folders. Is this the right
way to proceed?
2) On my SD card I have put the pre-compiled linux image following this
guide: www.lowrisc.org/docs/untether-v0.2/fpga-demo/#boot. So on my SD card
there are vmlinux and root.bin files.
3) When I run the bbl, It reaches the SD card, but it states: "fail to open
file vmlinux"
My questions are:
1) Do I need to compile my own linux image (if so, what do I have to
change?), or I can easily run yours?
2) Is the FPU in the rocket core mandatory in order to run Linux?
3) Why does it fail to load the vmlinux file?
Thank you for your time and support,
Francesco Viggiano
--
Francesco
7 years, 2 months
Errors regarding run bare metal exmaples
by Weizhong Huang
Hello, all
I have exactly followed the tutorial on the website and got to "Compile and
Run bare metal examples" in FPGA demo. I believe that I have successfully
generated a workable bitstream. There are errors regarding make file pop up
if I do "make hello". I also did make bit-update, it still did not work.
Thank you for all your help.
~/newlowRISC/DIR/lowrisc-chip/fpga/board/kc705$ make hello
cd examples && make
make[1]: Entering directory '/home/hplp/newlowRISC/DIR/lowrisc-
chip/fpga/board/kc705/examples'
make[1]: Nothing to be done for 'default'.
make[1]: Leaving directory '/home/hplp/newlowRISC/DIR/lowrisc-
chip/fpga/board/kc705/examples'
cp examples/hello.hex src/boot.mem && make bit-update
make[1]: Entering directory '/home/hplp/newlowRISC/DIR/lowrisc-
chip/fpga/board/kc705'
vivado -mode batch -source ../../common/script/search_ramb.tcl -tclargs
lowrisc-chip-imp > search-ramb.log
python ../../common/script/bmm_gen.py search-ramb.log src/boot.bmm 128 65536
data2mem -bm src/boot.mem -bd src/boot.mem -bt lowrisc-chip-imp/lowrisc-chip-
imp.runs/impl_1/chip_top.bit -o b lowrisc-chip-imp/lowrisc-chip-
imp.runs/impl_1/chip_top.new.bit
/opt/Xilinx/SDK/2015.3/bin/loader: line 164: 22333 Segmentation fault
(core dumped) "$RDI_PROG" "$@"
Makefile:159: recipe for target 'lowrisc-chip-imp/lowrisc-chip-
imp.runs/impl_1/chip_top.new.bit' failed
make[1]: *** [lowrisc-chip-imp/lowrisc-chip-imp.runs/impl_1/chip_top.new.bit]
Error 139
make[1]: Leaving directory '/home/hplp/newlowRISC/DIR/lowrisc-
chip/fpga/board/kc705'
Makefile:170: recipe for target 'hello' failed
make: *** [hello] Error 2
make bit-update
data2mem -bm src/boot.mem -bd src/boot.mem -bt lowrisc-chip-imp/lowrisc-chip-
imp.runs/impl_1/chip_top.bit -o b lowrisc-chip-imp/lowrisc-chip-
imp.runs/impl_1/chip_top.new.bit
/opt/Xilinx/SDK/2015.3/bin/loader: line 164: 23606 Segmentation fault
(core dumped) "$RDI_PROG" "$@"
Makefile:159: recipe for target 'lowrisc-chip-imp/lowrisc-chip-
imp.runs/impl_1/chip_top.new.bit' failed
make: *** [lowrisc-chip-imp/lowrisc-chip-imp.runs/impl_1/chip_top.new.bit]
Error 139
Sincerely,
Weizhong
7 years, 2 months
Re: [lowrisc-dev] Floating operations on RISCV
by Francesco Viggiano
Hello guys,
I'm trying to boot Linux but I have some problems that I'd like to discuss
with you. But first, I'm facing another strange behavior of the printf.
1) If in my dummy hello.c I write: printf("ok"); without the newline '\n'
character, the program prints nothing. if instead I add the new line
character it prints out the string correctly. What is going on?
2) I'm wondering if booting linux fails because it is stucked in a printf
without the new line character.
3) Do you know what happen from when vmlinux starts and the first attempt
to write on the console through the uart? My booting is stucked somewhere
and I'd like to know which are the "sensible" operations the kernel does as
soon as it starts. I tried to read the kernel source code but I didn't find
my answers, I'm very new in linux and kernel coding.
4) I've successfully ran the example codes in order to test the dram, uart,
sdcard.
Thank you for you precious help,
Francesco
On Wed, Jun 22, 2016 at 10:33 AM Francesco Viggiano <francesco.vgg(a)gmail.com>
wrote:
> Thank you Alexis, it could be very useful!
>
> Francesco
>
>
> On Tue, Jun 21, 2016 at 11:10 AM Alexis Ramos Amo <aramosam(a)nebrija.es>
> wrote:
>
>> Hello Francesco,
>>
>>
>>
>> I've faced the same problem and I had to write my own "Print Float"
>> function.
>>
>> Maybe this can help you.
>>
>>
>>
>> #define NFloatingPoint 1000 // Print 3 decimal numbers in float
>>
>> static void printFloat(float myfloat) {
>> uart_init();
>> int IntegerPart;
>> unsigned int FloatingPart;
>>
>> IntegerPart=myfloat;
>> FloatingPart=(int)(myfloat*NFloatingPoint)%NFloatingPoint;
>>
>> printf ("%u,%03u ", IntegerPart, FloatingPart);
>>
>> }
>>
>> int main() {
>> printFloat (3.5);
>> return 0;
>> }
>>
>>
>> I take some part of the code from
>> http://www.todopic.com.ar/foros/index.php?topic=27731 (reference in
>> spanish)
>>
>>
>> [image: a]
>>
>> Alexis Ramos Amo
>> Researcher / PhD Candidate
>>
>>
>>
>> Electronic Design and Space Technology group Universidad Nebrija
>>
>>
>>
>> La Dehesa de La Villa Campus
>> 28040 Calle Pirineos, 55 – Madrid
>>
>> Spain
>>
>>
>> (+34) 91 452 11 00 (ext. 2805)
>>
>> aramosam(a)nebrija.es
>>
>>
>> www.nebrija.com
>>
>>
>>
>>
>> ------------------------------
>>
>> *De:* lowrisc-dev-bounces(a)lists.lowrisc.org <
>> lowrisc-dev-bounces(a)lists.lowrisc.org> en nombre de Wei Song <
>> ws327(a)cam.ac.uk>
>> *Enviado:* martes, 21 de junio de 2016 11:38:13
>> *Para:* Francesco Viggiano; lowrisc-dev(a)lists.lowrisc.org
>> *Asunto:* Re: [lowrisc-dev] Floating operations on RISCV
>>
>>
>>
>> Hello Francesco,
>>
>> The printf() implementation in the driver of lowrisc-nexys4 git repo is
>> very limited.
>> It does not recognize %f and if you try printing out floating point
>> numbers by %d, there is no automatic type conversion from float to int.
>> Then printf() tries to interpret the floating point number as an
>> integer, leading to a wrong number.
>>
>> The easiest way to do it perhaps is to try inside a RISC-V Linux, where
>> you get full support of printf.
>>
>> Best regards,
>> Wei
>>
>> On 21/06/2016 00:57, Francesco Viggiano wrote:
>> > Hi all,
>> > I'm trying to see if the FPU is working properly on my Rocket
>> > implementation. I have the simplest C code possible:
>> >
>> > *...*
>> > *float a=6; float b=2; printf("a/b = %f",a/b);*
>> > *...*
>> >
>> > When I try to run it in bare metal, it simply prints out "a/b = %f"! If
>> I
>> > put %d instead of %f it writes 0 as a result of 6 divided by 2. That is
>> a
>> > very strange behavior.
>> >
>> > I'm using this script to compile the C code:
>> >
>> > *riscv64-unknown-elf-gcc -static -Wa,-march=RVIMAFD -std=gnu99 -g
>> > -ffast-math -fno-common -fno-builtin-printf -I./driver -c
>> > ./driver/syscalls.c -o ./driver/syscalls.o*
>> >
>> > *riscv64-unknown-elf-gcc -static -Wa,-march=RVIMAFD -std=gnu99 -g
>> > -ffast-math -fno-common -fno-builtin-printf -I./driver -c
>> ./driver/spi.c -o
>> > ./driver/spi.o*
>> >
>> > *riscv64-unknown-elf-gcc -static -Wa,-march=RVIMAFD -std=gnu99 -g
>> > -ffast-math -fno-common -fno-builtin-printf -I./driver -c
>> ./driver/uart.c
>> > -o ./driver/uart.o*
>> >
>> > *riscv64-unknown-elf-gcc -static -Wa,-march=RVIMAFD -std=gnu99 -g
>> > -ffast-math -fno-common -fno-builtin-printf -I./driver -c
>> ./driver/memory.c
>> > -o ./driver/memory.o*
>> >
>> > *riscv64-unknown-elf-gcc -static -Wa,-march=RVIMAFD -std=gnu99 -g
>> > -ffast-math -fno-common -fno-builtin-printf -I./driver -c
>> ./driver/elf.c -o
>> > ./driver/elf.o*
>> >
>> > *riscv64-unknown-elf-gcc -static -Wa,-march=RVIMAFD -std=gnu99 -g
>> > -ffast-math -fno-common -fno-builtin-printf -I./driver -c
>> ./driver/diskio.c
>> > -o ./driver/diskio.o*
>> >
>> > *riscv64-unknown-elf-gcc -static -Wa,-march=RVIMAFD -std=gnu99 -g
>> > -ffast-math -fno-common -fno-builtin-printf -I./driver -c ./driver/ff.c
>> -o
>> > ./driver/ff.o*
>> >
>> > *riscv64-unknown-elf-gcc -static -Wa,-march=RVIMAFD -std=gnu99 -g
>> > -ffast-math -fno-common -fno-builtin-printf -I./driver -c
>> ./driver/crt.S -o
>> > crt.o*
>> >
>> > *riscv64-unknown-elf-gcc -T ./driver/test.ld -static -Wa,-march=RVIMAFD
>> > -std=gnu99 -g -ffast-math -fno-common -fno-builtin-printf -I./driver -o
>> > hello.riscv hello.c ./driver/syscalls.o ./driver/spi.o ./driver/uart.o
>> > ./driver/memory.o ./driver/elf.o ./driver/diskio.o ./dri\*
>> >
>> > *ver/ff.o crt.o -nostdlib -nostartfiles -ffast-math -lc -lgcc*
>> >
>> >
>> > Is this correct?
>> >
>> >
>> > Thank you for your help,
>> >
>> >
>> > Francesco
>>
>>
>> --
> | Francesco Viggiano, Columbia University, Staff associate researcher at
> Computer Science Building |
> | Phone: +1 646-9829-535, Skype ID: francesco.vgg |
> | Department of Computer Science 1214 Amsterdam Avenue |
> | Columbia University Mail Code 0401 | New York, NY 10027-7003 |
>
--
| Francesco Viggiano, Columbia University, Staff associate researcher at
Computer Science Building |
| Phone: +1 646-9829-535, Skype ID: francesco.vgg |
| Department of Computer Science 1214 Amsterdam Avenue |
| Columbia University Mail Code 0401 | New York, NY 10027-7003 |
7 years, 2 months
Re: Introducing our IMC-sponsored intern team
by Gary Guo
Hi All,
I am Gary Guo, who have just finished part IA Computer Science course here at Cambridge. I'll be with Alistair, Nathanael and Profir-Petru this summer doing this internship kindly sponsored by IMC. Currently we are still experimenting on the infrastructure and tools. We've just got toolchains set up and FPGA working few hours ago. I hope things work well and we can make some progress in next few weeks.
Best,
Gary
> From: asb(a)asbradbury.org
> Date: Tue, 28 Jun 2016 10:13:53 +0100
> To: lowrisc-dev(a)lists.lowrisc.org
> Subject: [lowrisc-dev] Introducing our IMC-sponsored intern team
>
> Hi list,
>
> Yesterday a group of four interns started here at the University of
> Cambridge Computer Lab, kindly supported by IMC Financial Markets
> (http://www.imc.nl/). I thought it would be good for them to briefly
> introduce themselves to the wider community so you should see them
> responding to this post with a brief introduction.
>
> Right now Alistair, Gary, Nathanael and Profir-Petru are mainly
> getting up to speed with the lowRISC infrastructure, and starting to
> plan for their next steps. The intern team will be working together to
> define their plan over the coming days, and I'd expect a blog post
> next week giving more detail. We're very interested in exploring
> graphical output, partly as a means to producing fun demos but more
> importantly as it's a good example of attaching a custom accelerator.
> The internship runs for 10 weeks and I'm excited to see what the team
> are able to produce in this time.
>
> I hope you'll make them feel welcome. Best,
>
> Alex
>
7 years, 2 months
Introducing our IMC-sponsored intern team
by Alex Bradbury
Hi list,
Yesterday a group of four interns started here at the University of
Cambridge Computer Lab, kindly supported by IMC Financial Markets
(http://www.imc.nl/). I thought it would be good for them to briefly
introduce themselves to the wider community so you should see them
responding to this post with a brief introduction.
Right now Alistair, Gary, Nathanael and Profir-Petru are mainly
getting up to speed with the lowRISC infrastructure, and starting to
plan for their next steps. The intern team will be working together to
define their plan over the coming days, and I'd expect a blog post
next week giving more detail. We're very interested in exploring
graphical output, partly as a means to producing fun demos but more
importantly as it's a good example of attaching a custom accelerator.
The internship runs for 10 weeks and I'm excited to see what the team
are able to produce in this time.
I hope you'll make them feel welcome. Best,
Alex
7 years, 2 months
[GSoC2016] Weekly Report of Porting musl to RISC-V Project #4
by Masanori Ogino
Hello all,
This is the fourth issue of weekly report on porting musl to RISC-V
GSoC project.
This week, I have tried to run libc-test [1] on Spike with the
musl-based toolchain, but not succeeded. I found a minor problem with
recent cpp (I will report it to the maintainer of libc-test later) but
it is not the main issue preventing the test. I will continue
debugging this weekend.
There is no significant progress on the project this week. I will try
to contact other developers more and more to gain speed.
Have a nice weekend!
[1]: http://nsz.repo.hu/git/?p=libc-test
--
Masanori Ogino
7 years, 2 months
Floating operations on RISCV
by Francesco Viggiano
Hi all,
I'm trying to see if the FPU is working properly on my Rocket
implementation. I have the simplest C code possible:
*...*
*float a=6; float b=2; printf("a/b = %f",a/b);*
*...*
When I try to run it in bare metal, it simply prints out "a/b = %f"! If I
put %d instead of %f it writes 0 as a result of 6 divided by 2. That is a
very strange behavior.
I'm using this script to compile the C code:
*riscv64-unknown-elf-gcc -static -Wa,-march=RVIMAFD -std=gnu99 -g
-ffast-math -fno-common -fno-builtin-printf -I./driver -c
./driver/syscalls.c -o ./driver/syscalls.o*
*riscv64-unknown-elf-gcc -static -Wa,-march=RVIMAFD -std=gnu99 -g
-ffast-math -fno-common -fno-builtin-printf -I./driver -c ./driver/spi.c -o
./driver/spi.o*
*riscv64-unknown-elf-gcc -static -Wa,-march=RVIMAFD -std=gnu99 -g
-ffast-math -fno-common -fno-builtin-printf -I./driver -c ./driver/uart.c
-o ./driver/uart.o*
*riscv64-unknown-elf-gcc -static -Wa,-march=RVIMAFD -std=gnu99 -g
-ffast-math -fno-common -fno-builtin-printf -I./driver -c ./driver/memory.c
-o ./driver/memory.o*
*riscv64-unknown-elf-gcc -static -Wa,-march=RVIMAFD -std=gnu99 -g
-ffast-math -fno-common -fno-builtin-printf -I./driver -c ./driver/elf.c -o
./driver/elf.o*
*riscv64-unknown-elf-gcc -static -Wa,-march=RVIMAFD -std=gnu99 -g
-ffast-math -fno-common -fno-builtin-printf -I./driver -c ./driver/diskio.c
-o ./driver/diskio.o*
*riscv64-unknown-elf-gcc -static -Wa,-march=RVIMAFD -std=gnu99 -g
-ffast-math -fno-common -fno-builtin-printf -I./driver -c ./driver/ff.c -o
./driver/ff.o*
*riscv64-unknown-elf-gcc -static -Wa,-march=RVIMAFD -std=gnu99 -g
-ffast-math -fno-common -fno-builtin-printf -I./driver -c ./driver/crt.S -o
crt.o*
*riscv64-unknown-elf-gcc -T ./driver/test.ld -static -Wa,-march=RVIMAFD
-std=gnu99 -g -ffast-math -fno-common -fno-builtin-printf -I./driver -o
hello.riscv hello.c ./driver/syscalls.o ./driver/spi.o ./driver/uart.o
./driver/memory.o ./driver/elf.o ./driver/diskio.o ./dri\*
*ver/ff.o crt.o -nostdlib -nostartfiles -ffast-math -lc -lgcc*
Is this correct?
Thank you for your help,
Francesco
--
| Francesco Viggiano, Columbia University, Staff associate researcher at
Computer Science Building |
| Phone: +1 646-9829-535, Skype ID: francesco.vgg |
| Department of Computer Science 1214 Amsterdam Avenue |
| Columbia University Mail Code 0401 | New York, NY 10027-7003 |
7 years, 3 months
Re: [lowrisc-dev] What are you working on this week?
by Alex Bradbury
On 16 June 2016 at 20:02, Reinoud Zandijk <reinoud(a)netbsd.org> wrote:
> Hi folks, hi Alex,
>
> well for one, I am still refining a document about an integrated
> debug/virtualisation/device SoC design. Regretfully I dont have much time to
> work on it so it keeps being a work-in-progress.
>
> If there I repost it here again but its 5th revision isn't 100% complete yet.
> Now if I only had the time to create it in Chissel (and time to learn Chissel
> enough ;-)).
>
> Alex, do you we could find some time to discuss the current proposal?
> Preferably together with Rob? On or off-list?
Hi Reinoud. Yes, I'm hoping we can discuss your proposals in more
detail soon. It's looking like the time I have available will be
increasing in the near future. Sorry for the slow responses on our
side.
Have you considered prototyping your ideas in Spike or QEMU?
Alex
7 years, 3 months
