When the Linux kernel tries to execute a printf or printk, is the bbl
that actually takes care of sending the data to the uart? I suppose
through a mcall_trap and and a mcall_dev_req in mtrap.c. Is this
correct? Since the bbl is the only one who knows the uart address,
stored in driver/uart.h.
Yes.
Also, is the start_kernel (in init/main.c in linux folder) the first
C
function of the Linux kernel? If I put a printf as the first
instruction in that function, should it work?
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.
>
When the Linux kernel tries to execute a printf or printk, is the bbl
that actually takes care of sending the data to the uart? I suppose
through a mcall_trap and and a mcall_dev_req in mtrap.c. Is this
correct? Since the bbl is the only one who knows the uart address,
stored in driver/uart.h.
>
Also, is the start_kernel (in init/main.c in linux folder) the first
C
function of the Linux kernel? If I put a printf as the first
instruction in that function, should it work?
>
> 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 |