[lowrisc-dev] Floating operations on RISCV

Wei Song ws327 at cam.ac.uk
Tue Jun 28 22:53:46 BST 2016


Yes, I was talking about the load_elf() function.
Surely it does not give you errors, otherwise, bbl will just stops there.
The current load_elf does not do verification, so if there buffer 
overflow, or wrong page table configuration, or even hardware issues in 
L1/2 caches, the load process may silently fail.
It is not very helpful to just look at the first byte or even first 
hundreds of bytes. I would suggest to verify every byte by some 
verification code added to load_elf().

Currently we do not have this verification in place, although it would 
be very helpful if there is one.

-Wei

On 28/06/16 20:42, Francesco Viggiano wrote:
> Hello Wei,
> Thank you for your support.
>
> When you say elf loader, you mean a call to function load_elf() in 
> init.c file? That functions doesn't give any errors, If I look at the 
> DDR, I see that vmlinux is loaded at address 0x0020_0000, comparing 
> the first couple of words with the vmlinux dump file.
>
> Also, does the elf load test already exist, or should I write it on my 
> own?
>
> Bests,
>
> Francesco
>
> On Tue, Jun 28, 2016 at 3:00 PM Wei Song <ws327 at cam.ac.uk 
> <mailto:ws327 at cam.ac.uk>> wrote:
>
>     Hello Francesco,
>
>     The issue with printf() is expected. There is a write buffer.
>     Whenever putchar() is called, the char is first stored in the
>     buffer. When the char == '\n', the content of this buffer is then
>     sent to UART. So if you printf("ok") without '\n', there is
>     nothing printed out. The printf() support in bare-metal mode is
>     limited.
>
>     As for Linux kernel, UART print happens rather late. There are a
>     lot of operations before console (UART).
>     I think tracking the sbi calls in bbl is the right way to go.
>
>     If pc stops at random places but bbl seems to work, I would
>     suggest you to verify the kernel image is correctly loaded.
>     My thought would be read and compare all bytes in bbl's elf loader.
>     You should have printf() there. If elf loader fails to load the
>     correct kernel, there is no point to try further.
>
>     Do let me know if you run elf load test and it actually failed.
>     Then it very likely to be a bug on my side.
>
>     Best regards,
>     Wei
>
>
>     On 28/06/2016 19:15, Francesco Viggiano wrote:
>>     The code is simply :
>>
>>     #include<stdio.h>
>>     #include"uart.h"
>>
>>     int main (int argc, char*  argv[]){
>>     uart_init();
>>     printf("ok");
>>     return 0;
>>     }
>>     Compiled with the driver found in fpga/board/kc705/driver in
>>     which I've changed the addresses of DRAM, SD and UART.
>>
>>     As regards the Linux boot, I'm using the bbl found inside
>>     fpga/board/kc705/bbl. I know that the bbl loads vmlinux in DRAM
>>     and then executes it. Then I see some mcall_trap regarding the
>>     timer,  and then nothing else. The program counter seems stucked
>>     at different position on each run.
>>
>>     Francesco
>>
>>     On Tue, Jun 28, 2016 at 1:49 PM Alexis Ramos Amo
>>     <aramosam at nebrija.es <mailto:aramosam at nebrija.es>> wrote:
>>
>>         Could you attached some code? Did you write the uart_init()
>>         function at the beginning of your code?
>>
>>         Alexis Ramos Amo
>>         Researcher / PhD Candidate
>>
>>         Electronic Design and Space Technology group
>>
>>         Nebrija University
>>
>>         *De:*Francesco Viggiano [mailto:francesco.vgg at gmail.com
>>         <mailto:francesco.vgg at gmail.com>]
>>         *Enviado el:* martes, 28 de junio de 2016 19:40
>>         *Para:* Alexis Ramos Amo <aramosam at nebrija.es
>>         <mailto:aramosam at nebrija.es>>; Wei Song <ws327 at cam.ac.uk
>>         <mailto:ws327 at cam.ac.uk>>; lowrisc-dev at lists.lowrisc.org
>>         <mailto:lowrisc-dev at lists.lowrisc.org>
>>
>>
>>         *Asunto:* Re: [lowrisc-dev] Floating operations on RISCV
>>
>>         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 at gmail.com <mailto:francesco.vgg at 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 at nebrija.es <mailto:aramosam at 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>http://www.todopic.com.ar/foros/index.php?topic=27731(reference
>>                 in spanish)
>>
>>                 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)
>>
>>                 <mailto:aramosam at nebrija.es>aramosam at nebrija.es
>>                 <mailto:aramosam at nebrija.es>
>>
>>                 *
>>                 *<http://www.nebrija.com/>www.nebrija.com
>>                 <http://www.nebrija.com>
>>
>>                 ------------------------------------------------------------------------
>>
>>                 *De:*lowrisc-dev-bounces at lists.lowrisc.org
>>                 <mailto:lowrisc-dev-bounces at lists.lowrisc.org>
>>                 <lowrisc-dev-bounces at lists.lowrisc.org
>>                 <mailto:lowrisc-dev-bounces at lists.lowrisc.org>> en
>>                 nombre de Wei Song <ws327 at cam.ac.uk
>>                 <mailto:ws327 at cam.ac.uk>>
>>                 *Enviado:* martes, 21 de junio de 2016 11:38:13
>>                 *Para:* Francesco Viggiano;
>>                 <mailto:lowrisc-dev at lists.lowrisc.org>lowrisc-dev at lists.lowrisc.org
>>                 <mailto:lowrisc-dev at 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 |
>>
>>     -- 
>>     | 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 |



More information about the lowrisc-dev mailing list