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@gmail.com] Enviado el: martes, 28 de junio de 2016 19:40 Para: Alexis Ramos Amo <aramosam(a)nebrija.es&gt;; Wei Song <ws327(a)cam.ac.uk&gt;; lowrisc-dev(a)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@gmail.com<mailto:francesco.vgg@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@nebrija.es<mailto:aramosam@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) 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@nebrija.es<mailto:aramosam@nebrija.es> www.nebrija.com<http://www.nebrija.com/> ________________________________ De: lowrisc-dev-bounces@lists.lowrisc.org<mailto:lowrisc-dev-bounces@lists.lowrisc.org> <lowrisc-dev-bounces@lists.lowrisc.org<mailto:lowrisc-dev-bounces@lists.lowrisc.org>> en nombre de Wei Song <ws327@cam.ac.uk<mailto:ws327@cam.ac.uk>> Enviado: martes, 21 de junio de 2016 11:38:13 Para: Francesco Viggiano; lowrisc-dev@lists.lowrisc.org<mailto:lowrisc-dev@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: -- | 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 |

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:

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:

Yes. Sorry, I do not know. I am not much better than you on the kernel side. May be someone else knows. -Wei On 28/06/16 23:28, Francesco Viggiano wrote: > OK, I'll proceed with the verification code. > > > > Francesco > > On Tue, Jun 28, 2016 at 5:53 PM Wei Song <ws327(a)cam.ac.uk > <mailto:ws327@cam.ac.uk>> wrote: > > 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(a)cam.ac.uk >> <mailto:ws327@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(a)nebrija.es <mailto:aramosam@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@gmail.com >>> <mailto:francesco.vgg@gmail.com>] >>> *Enviado el:* martes, 28 de junio de 2016 19:40 >>> *Para:* Alexis Ramos Amo <aramosam(a)nebrija.es >>> <mailto:aramosam@nebrija.es>>; Wei Song <ws327(a)cam.ac.uk >>> <mailto:ws327@cam.ac.uk>>; lowrisc-dev(a)lists.lowrisc.org >>> <mailto:lowrisc-dev@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(a)gmail.com >>> <mailto:francesco.vgg@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 <mailto:aramosam@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.todop... >>> 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@nebrija.es>aramosam@nebrija.es >>> <mailto:aramosam@nebrija.es> >>> >>> * >>> *<http://www.nebrija.com/>www.nebrija.com >>> <http://www.nebrija.com> >>> >>> ------------------------------------------------------------------------ >>> >>> *De:*lowrisc-dev-bounces@lists.lowrisc.org >>> <mailto:lowrisc-dev-bounces@lists.lowrisc.org> >>> <lowrisc-dev-bounces(a)lists.lowrisc.org >>> <mailto:lowrisc-dev-bounces@lists.lowrisc.org>> >>> en nombre de Wei Song <ws327(a)cam.ac.uk >>> <mailto:ws327@cam.ac.uk>> >>> *Enviado:* martes, 21 de junio de 2016 11:38:13 >>> *Para:* Francesco Viggiano; >>> <mailto:lowrisc-dev@lists.lowrisc.org>lowrisc-dev@lists.lowrisc.org >>> <mailto:lowrisc-dev@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 | > > -- > | 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 |