Re: sparc-erc32 testsuites failures

[Niteesh]

I have updated the doc to use erc32-sis, and attached the patch file in
this mail. Can someone review it.

On Mon, Nov 18, 2019 at 12:07 PM Niteesh  wrote:

> I know this, but the docs are not updated so should I send a pull request?
>
>
> On Mon, Nov 18, 2019 at 12:06 PM Vaibhav Gupta 
> wrote:
>
>>
>>
>> On Mon, Nov 18, 2019, 11:12 AM Niteesh  wrote:
>>
>>> On Mon, Nov 18, 2019 at 3:17 AM Joel Sherrill  wrote:
>>>
>>>> The instructions are out of date by a couple of months. The SPARC
>>>> Instruction Simulator (sis) has seen significant enhancements and it's now
>>>> a standalone program. It is not enabled as a built-in with gdb because
>>>> that's some very old version of sis. The new version has symmetric
>>>> multiprocessing and support for the RISC-V.
>>>>
>>>> Those instructions worked for a LONG time but need to be updated to
>>>> reflect the recent changes with SIS.
>>>>
>>>> If you used rtems-tester, it should work. And looking at the .ini file
>>>> for this bsp will sure you have to just run programs with the simulator. My
>>>> recollection is that by adding -gdb argument, you can attached to it as a
>>>> remote debugger.
>>>>
>>> Yes. And I also faced this problem (in my case it was riscv)and i guess
>> this question was asked by others also on devel.
>> I simply used these steps:
>>
>> Open Terminal 1:
>>
>> $ sparc-rtems5-sis -gdb
>>
>> # It will print 'gdb: listening on port 1234'.
>>
>> # Note you can define port number with '-port' option.
>>
>> Open Terminal 2:
>>
>> $ sparc-rtems5-gdb hello.exe
>>
>> # gdb asks for several inputs
>>
>> $ target extended-remote localhost:1234
>>
>> $ load
>>
>> $ r
>>
>> You will see output in Terminal 1.
>>
>>> I would like to update the docs for this, Can I proceed? I am planning
>>> to change the cmd to use erc-sis instead of erc. And also the build your
>>> application section is incomplete, can I add the instruction to modify a
>>> test program and build it in this section?
>>>
>>>> BTW I know it's a way too early for GSOC but I have anyway attached the
>>>>> patch for hello world.
>>>>>
>>>>
>>>> What type projects are you interested in?
>>>>
>>> I am interested in driver development and BSP support.
>>>
>>>> ___
>>>>> devel mailing list
>>>>> devel@rtems.org
>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>
>>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
From c7768d10a55a557abf65867d9039d7dc0642b270 Mon Sep 17 00:00:00 2001
From: gs-niteesh 
Date: Mon, 18 Nov 2019 12:46:43 +0530
Subject: [PATCH] user/start/bsp-test.rst: Changed bsp to erc32-sis.

This commit removd the target sim from gdb id=abc540105d10ddc9cad7de3c7ac0a9aa209ac828
but the doc was not updated, so on running rtems test caused failures,
this commit changes it use the erc32-sis which used standalone sis
simulator.
---
 user/start/bsp-test.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/start/bsp-test.rst b/user/start/bsp-test.rst
index 5278375..8a14862 100644
--- a/user/start/bsp-test.rst
+++ b/user/start/bsp-test.rst
@@ -21,7 +21,7 @@ Just run this command:
 .. code-block:: none
 
 cd $HOME/quick-start/build/b-erc32
-rtems-test --rtems-bsp=erc32 --rtems-tools=$HOME/quick-start/rtems/5 .
+rtems-test --rtems-bsp=erc32-sis --rtems-tools=$HOME/quick-start/rtems/5 .
 
 This command should output something like this (omitted lines are denoted by
 ...).  In this output the base directory :file:`$HOME/quick-start` was replaced
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] user/start/bsp-test.rst: Changed bsp to erc32-sis.

[Niteesh]

I am new to this, so can you please elaborate on the steps.

On Tue, Nov 19, 2019 at 10:16 PM Gedare Bloom  wrote:

> Hi Niteesh,
>
> Can you please provide a patch with your name on the authorship for
> tracking copyright purpose?
>
> On Mon, Nov 18, 2019, 2:29 AM  wrote:
>
>> From: gs-niteesh 
>>
>> This commit (id=abc540105d10ddc9cad7de3c7ac0a9aa209ac828) removed
>> the target sim from gdb, but the doc was not updated, so on running
>> rtems test as per the doc caused failures, this commit changes it
>> use the erc32-sis which used standalone sis simulator.
>> ---
>>  user/start/bsp-test.rst | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/user/start/bsp-test.rst b/user/start/bsp-test.rst
>> index 5278375..8a14862 100644
>> --- a/user/start/bsp-test.rst
>> +++ b/user/start/bsp-test.rst
>> @@ -21,7 +21,7 @@ Just run this command:
>>  .. code-block:: none
>>
>>  cd $HOME/quick-start/build/b-erc32
>> -rtems-test --rtems-bsp=erc32 --rtems-tools=$HOME/quick-start/rtems/5
>> .
>> +rtems-test --rtems-bsp=erc32-sis
>> --rtems-tools=$HOME/quick-start/rtems/5 .
>>
>>  This command should output something like this (omitted lines are
>> denoted by
>>  ...).  In this output the base directory :file:`$HOME/quick-start` was
>> replaced
>> --
>> 2.17.1
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] user/start/bsp-test.rst: Changed bsp to erc32-sis.

[Niteesh]

I actually google about the authorship stuff, do you want me to add the
--author command to the commit?

On Tue, Nov 19, 2019 at 10:55 PM Niteesh  wrote:

> I am new to this, so can you please elaborate on the steps.
>
> On Tue, Nov 19, 2019 at 10:16 PM Gedare Bloom 
> wrote:
>
>> Hi Niteesh,
>>
>> Can you please provide a patch with your name on the authorship for
>> tracking copyright purpose?
>>
>> On Mon, Nov 18, 2019, 2:29 AM  wrote:
>>
>>> From: gs-niteesh 
>>>
>>> This commit (id=abc540105d10ddc9cad7de3c7ac0a9aa209ac828) removed
>>> the target sim from gdb, but the doc was not updated, so on running
>>> rtems test as per the doc caused failures, this commit changes it
>>> use the erc32-sis which used standalone sis simulator.
>>> ---
>>>  user/start/bsp-test.rst | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/user/start/bsp-test.rst b/user/start/bsp-test.rst
>>> index 5278375..8a14862 100644
>>> --- a/user/start/bsp-test.rst
>>> +++ b/user/start/bsp-test.rst
>>> @@ -21,7 +21,7 @@ Just run this command:
>>>  .. code-block:: none
>>>
>>>  cd $HOME/quick-start/build/b-erc32
>>> -rtems-test --rtems-bsp=erc32
>>> --rtems-tools=$HOME/quick-start/rtems/5 .
>>> +rtems-test --rtems-bsp=erc32-sis
>>> --rtems-tools=$HOME/quick-start/rtems/5 .
>>>
>>>  This command should output something like this (omitted lines are
>>> denoted by
>>>  ...).  In this output the base directory :file:`$HOME/quick-start` was
>>> replaced
>>> --
>>> 2.17.1
>>>
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] user/start/bsp-test.rst: Changed bsp to erc32-sis.

[Niteesh]

>
> It's seems that there are many places where the doc has to be updated
> about the erc32-sis stuff, so shall I change all of them  and send a
> commit?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Interested in BSP's (No idea where to start?)

[Niteesh]

Hii, everyone
I am interested in contributing to RTEMS, specifically to the arm based
BSP's. I am a sophomore in electronics and communication engineering
interested in operating systems, and systems programming. I have written
small drivers and libraries for Arduino, bare metal avr chips to interface
with sensors. I would like to take it a bit further by learning about
ARM-based devices.

I have completed the hello world task for GSOC. As I said early I am
interested in contributing to the drivers and BSP section for most likely
raspberry pi and beaglebone. But I have no idea how to proceed further, any
suggestions on where to start and is it okay to ask tons of questions?
because I had a look at the previous year's project ideas and very little
made sense to me. I am ready to put in my best effort just need some
guidance from your side.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Interested in BSP's (No idea where to start?)

[Niteesh]

Do both raspberry pi and raspberrypi2 use the same BSP? If not how to build
for raspberry pi 2
I couldn't find any datasheet's for BCM2711(raspberrypi4), could only find
for BCM2835 (raspberrypi1):
https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
but I think we can maybe use the Linux device tree for raspberry pi as a
reference,
https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/boot/dts/bcm2838.dtsi
https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/boot/dts/bcm2838-rpi-4-b.dts

These are some changes that I found out through google:
1) Peripheral base address is now moved to 0x7E00
2) There's a mention of ARM's GIC400 @ 0x40041000 but probably is only the
distributor since the old CPU interface is still there @ 0x4000
On Tue, Nov 26, 2019 at 7:19 PM Joel Sherrill  wrote:

>
>
> On Tue, Nov 26, 2019 at 5:42 AM Niteesh  wrote:
>
>> Hii, everyone
>> I am interested in contributing to RTEMS, specifically to the arm based
>> BSP's. I am a sophomore in electronics and communication engineering
>> interested in operating systems, and systems programming. I have written
>> small drivers and libraries for Arduino, bare metal avr chips to interface
>> with sensors. I would like to take it a bit further by learning about
>> ARM-based devices.
>>
>> I have completed the hello world task for GSOC. As I said early I am
>> interested in contributing to the drivers and BSP section for most likely
>> raspberry pi and beaglebone. But I have no idea how to proceed further, any
>> suggestions on where to start and is it okay to ask tons of questions?
>> because I had a look at the previous year's project ideas and very little
>> made sense to me. I am ready to put in my best effort just need some
>> guidance from your side.
>>
>
> This is a hard question to answer. There is a balance of something
> interesting to do with not sending you on a quest. One extreme would be a
> full BSP from scratch for some expensive hardware that you don't have and
> shouldn't even try to afford. The other extreme is something so simple that
> it isn't interesting. At the same time, it should be useful to the
> community.
>
> I thought a little while about this and think updating the raspberrypi BSP
> to support the pi3/pi4 should be a useful and tractable BSP issue to
> address. It is also useful to the community.
>
> Discussions when this was brought up before indicate that the precise
> System on Chip model changed from the 2 to the 3/4 and at least the base
> address of the UART for the console changed. Getting it working should be a
> combination of detective work to figure out what precisely changed and fix
> it along with the possibility of the need for a different device driver on
> the 3/4.
>
> FWIW I noticed that the RSB package qemu4 includes a simulator for the pi2
> although I haven't had a chance to see if it works with RTEMS. If it does,
> that eliminates absolutely needing pi2 hardware.
>
Can someone provide instruction on the simulator, I searched a lot but
found no help.

>
>
Anyway, that's just one idea. It would be useful.
>
> Thanks.
>
> --joel
>
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

raspberrypi BSP current status

[Niteesh]

I am interested in contributing to the raspberry pi BSP. As of now RTEMS
only has support for RPi1 and RPi2, but It seems that most of the code for
RPi2 should work unmodified for RPi3 and RPi4, I am sure about the
peripherals since the base address of the registers haven't changed in the
new ones.
I looked at the previous GSOC work and README section of the raspberrypi,
but they look not up to date. I want to know the current status of the BSP,
what all is completed, yet to be done? so that's I could start working on
something.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: raspberrypi BSP current status

[Niteesh]

On Sat, Nov 30, 2019 at 3:03 AM Christian Mauderer 
wrote:

> On 29/11/2019 21:12, Niteesh wrote:
> > I am interested in contributing to the raspberry pi BSP. As of now RTEMS
> > only has support for RPi1 and RPi2, but It seems that most of the code
> > for RPi2 should work unmodified for RPi3 and RPi4, I am sure about the
> > peripherals since the base address of the registers haven't changed in
> > the new ones.
> > I looked at the previous GSOC work and README section of the
> > raspberrypi, but they look not up to date. I want to know the current
> > status of the BSP, what all is completed, yet to be done? so that's I
> > could start working on something.
> >
>
> Hello Niteesh,
>
> from a quick look there are the following drivers:
> - Serial
> - GPIO
> - I2C
> - SPI
> - Some Framebuffer
>
> In 2016 a GSoC student tried to port the USB and Ethernet driver. But it
> seems that this work hadn't been merged:
>
>   https://devel.rtems.org/wiki/GSoC/2016
>
> Regarding good starting points: I think you already found some with just
> this mail.
>
> - If you have an old Pi1 or 2, you could try to run some basic RTEMS
> there as a first step. Or did you already try that?
>
I only have the Pi3 model B. But I did try running basic examples like
hello, ticker
on qemu using this command:
 qemu-system-arm -M raspi2 -m 1G -kernel hello.exe -serial mon:stdio -net
none -nographic -dtb bcm2709-rpi-2-b.dtb
But this does not work sometimes for the same program, it results in fatal
source exception.
I am yet to try these examples on Pi3 because I waiting for my USB - TTL
converter

> - You say that it "should work" on RPi3 and RPi4. It would be great if
> you could try it and update the documentation if it does.
>
> - If you take some notes while doing the tests, it would be great if you
> could donate them to the documentation so the old README could be
> replaced:
> https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#raspberrypi
>
> - If you want to start a bigger project you could take a look at the USB
> work and test it. Most likely it still needs some work.
>
I am very much interested in working on projects like USB, but I lack the
basic's. I having a look at the previous GSOC work, and
other USB work's from different BSP's(beagle). Can you recommend some
resources or things that I should know before hand?

> - If you are interested in any other peripheral of the Pi: Just ask.
>
I found no example of the GPIO working on raspberrypi, And also there no
clear doc for the GPIO API, is there any examples or docs
that you could point me to?

> Best regards
>
> Christian
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

raspberry pi simulation

[Niteesh]

I want to simulate old raspberry pi 1 and 2 using qemu.
* qemu-system-arm -kernel hello.exe  -cpu cortex-a7 -M raspi2 -m 512
-no-reboot -serial stdio*

I use the above command to run the examples, and it does run, but not
always sometimes I get this weird output's where my whole screen gets
filled up with 0's. and sometimes I get an *RTEMS_FATAL_SOURCE_EXCEPTION*
with *executing thread is NULL *message at the bottom.
with a dump of something like this:

RTEMS RPi 2B 1.1 (1GB) [00a21041]


*** FATAL


**
fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)

R0   = 0x0020e6d8 R8  = 0x
R1   = 0x R9  = 0x0001
R2   = 0x00303e10 R10 = 0x1000
R3   = 0x R11 = 0x49444c45
R4   = 0x R12 = 0x00303c78
R5   = 0x0020e6d8 SP  = 0x00300b80
R6   = 0x LR  = 0x00302b1c
R7   = 0x PC  = 0x00204016
CPSR = 0x61f3 VEC = 0x0004
FPEXC = 0x4000
FPSCR = 0x
D00 = 0x
D01 = 0x
D02 = 0x
D03 = 0x
D04 = 0x
D05 = 0x
D06 = 0x
D07 = 0x
D08 = 0x
D09 = 0x
D10 = 0x
D11 = 0x
D12 = 0x
D13 = 0x
D14 = 0x
D15 = 0x
D16 = 0x
D17 = 0x
D18 = 0x
D19 = 0x
D20 = 0x
D21 = 0x
D22 = 0x
D23 = 0x
D24 = 0x
D25 = 0x
D26 = 0x
D27 = 0x
D28 = 0x
D29 = 0x
D30 = 0x
D31 = 0x
RTEMS version: 5.0.0.c6d8589bb00a9d2a5a094c68c90290df1dc44807-modified
RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB
83fa79314dd87c0a8c78fd642b2cea3138be8dd6, Newlib 3e24fbf6f)
executing thread ID: 0x089010001
executing thread name:

I also did try running the examples on the real raspi3 but still got no
luck. The steps I followed where mixture from where sources.
1. I first created a img file using objcopy.
2. Copied the kernel.img to SD card and modified the config.txt,
But still it couldn't boot got no output on my serial.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Problem running RTEMS on raspberrypi3

[Niteesh]

I am trying to get RTEMS examples running on the RPI3, the RPI3 is similar
to RPI2 so the examples built for RPI2 should technically run on the
RPi3.But they don't :(, I am really sure of what is causing the problem.
I followed the steps from
http://alanstechnotes.blogspot.com/2013/03/running-your-first-rtems-program-on.html
(modified
commands to use rtems5) to build the kernel img. I did try running it on
Qemu but it doesn't always work, sometimes it gives weird output.
The steps that I followed are:
1. Created a bootable SD card using raspbian.
2. Replaced the kernel.img file with RTEMS kernel.img file and modified the
config.txt to boot from the RTEMs kernel (boots in aarch32 bit mode).
I am still not able to wrap my head around the RPI bsp build process. This
is what I understood as of now, correct me if I am wrong.
Both RPi and Rpi2 are based on the same BSP, they just differ in the
peripheral offsets, hardcoded checks are used to select the right offset at
the time of compiling and the linkercmd file is responsible for building
the final executable file.
I looked at the linker script, it seem's to have the start section at
address 0x20, I also loaded it in GDB and the start address is *Start
address 0x200080,* I did some bare metal programming on RPI3 there I had
the start section at address 0x8000 Is this causing the problem?
I have no idea on how to debug this, any suggestion on how to start would
be really helpfull.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Problem running RTEMS on raspberrypi3

[Niteesh]

On Sun, Dec 15, 2019 at 10:15 PM Christian Mauderer 
wrote:

> Hello Niteesh,
>
> On 15/12/2019 09:05, Niteesh wrote:
> > I am trying to get RTEMS examples running on the RPI3, the RPI3 is
> > similar to RPI2 so the examples built for RPI2 should technically run on
> > the RPi3.But they don't :(, I am really sure of what is causing the
> problem.
>
> Note that there are at least two different versions of the RPi3 which
> use different chips. The original RPi3 which uses a BCM2837 (same like
> later versions of RPi2) and the RPi3+ which uses a BCM2837B0. Broadcom
> is always quite sparse with documentation so it's not easy to tell the
> differences. Which one do you have?
>
I have Rpi3 model b v1.2 which uses BCM2837 SOC, in my bare-metal
programming I used the
2835 doc as a reference because the only major difference these two SOC is
the peripheral base address
offset. But this is arm cpu is also capable of executing in 64bit mode.

> > I followed the steps
> > from
> http://alanstechnotes.blogspot.com/2013/03/running-your-first-rtems-program-on.html
>  (modified
> > commands to use rtems5) to build the kernel img.
>
> It's a bit odd that the Bootloader doesn't use some image format like
> U-Boot but if that's the case for Raspberry, that's OK.
>
Do you want me to try U-Boot, I was planning to use it for my bare-metal
stuff because copying the kernel
to SD-card was a real pain. Will it even work with RTEMS?

> > I did try running it on
> > Qemu but it doesn't always work, sometimes it gives weird output.

How did you run it on Qemu? Did you build some image for that too?

qemu-system-arm -M raspi2 -m 1G -kernel hello.exe -serial mon:stdio
-nographic

*qemu-system-aarch64: GLib: g_mapped_file_unref: assertion 'file != NULL'
failed *I get this error
while trying to emulate raspi3.

I ran qemu along with GDB to find what was causing the wrong output. I am
really not sure if this is right,
I still have a lot to learn, but my assumption's using GDB are as follows.
There are 4 active thread which run the same code.

(gdb) info thread
  Id   Target IdFrame
* 1Thread 1.1 (CPU#0 [running]) _start () at
../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/shared/start/start.S:153
  2Thread 1.2 (CPU#1 [running]) _start () at
../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/shared/start/start.S:153
  3Thread 1.3 (CPU#2 [running]) _start () at
../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/shared/start/start.S:153
  4Thread 1.4 (CPU#3 [running]) _start () at
../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/shared/start/start.S:153

After some time one of the thread call's the BSP reset function this is
when the program crashes, the other threads complain "*executing thread is
NULL*"

*** FATAL ***
fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)

R0   = 0x45e6 R8  = 0x
R1   = 0x0001 R9  = 0x
R2   = 0xba1a R10 = 0x
R3   = 0x R11 = 0x
R4   = 0x002001db R12 = 0x
R5   = 0x SP  = 0x00300bd0
R6   = 0x LR  = 0x00100fc4
R7   = 0x PC  = 0x00100fc4
CPSR = 0x01d3 VEC = 0x0002
FPEXC = 0x4000
FPSCR = 0x
D00 = 0x
D01 = 0x
D02 = 0x
D03 = 0x
D04 = 0x
D05 = 0x
D06 = 0x
D07 = 0x
D08 = 0x
D09 = 0x
D10 = 0x
D11 = 0x
D12 = 0x
D13 = 0x
D14 = 0x
D15 = 0x
D16 = 0x
D17 = 0x0010
D18 = 0x
D19 = 0x
D20 = 0x
D21 = 0x
D22 = 0x
D23 = 0x
D24 = 0x
D25 = 0x
D26 = 0x
D27 = 0x
D28 = 0x
D29 = 0x
D30 = 0x
D31 = 0x
RTEMS version: 5.0.0.c6d8589bb00a9d2a5a094c68c90290df1dc44807-modified
RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB
83fa79314dd87c0a8c78fd642b2cea3138be8dd6, Newlib 3e24fbf6f)
executing thread is NULL

> The steps that I followed are:
> > 1. Created a bootable SD card using raspbian.
> > 2. Replaced the kernel.img file with RTEMS kernel.img file and modified
> > the config.txt to boot from the RTEMs kernel (boots in aarch32 bit mode).
> > I am still not able to wrap my head around the RPI bsp build process.
> > This is what I understood as of now, correct me if I am wrong.
> > Both RPi and Rpi2 are based on the same BSP, they just differ in the
> > 

Re: Problem running RTEMS on raspberrypi3

[Niteesh]

On Mon, Dec 16, 2019 at 12:53 AM Christian Mauderer 
wrote:

> On 15/12/2019 19:46, Niteesh wrote:
> >
> >
> > On Sun, Dec 15, 2019 at 10:15 PM Christian Mauderer  > <mailto:l...@c-mauderer.de>> wrote:
> >
> > Hello Niteesh,
> >
> > On 15/12/2019 09:05, Niteesh wrote:
> > > I am trying to get RTEMS examples running on the RPI3, the RPI3 is
> > > similar to RPI2 so the examples built for RPI2 should technically
> > run on
> > > the RPi3.But they don't :(, I am really sure of what is causing
> > the problem.
> >
> > Note that there are at least two different versions of the RPi3 which
> > use different chips. The original RPi3 which uses a BCM2837 (same
> like
> > later versions of RPi2) and the RPi3+ which uses a BCM2837B0.
> Broadcom
> > is always quite sparse with documentation so it's not easy to tell
> the
> > differences. Which one do you have?
> >
> > I have Rpi3 model b v1.2 which uses BCM2837 SOC, in my bare-metal
> > programming I used the
> > 2835 doc as a reference because the only major difference these two SOC
> > is the peripheral base address
> > offset. But this is arm cpu is also capable of executing in 64bit mode.
>
> OK. Did you check, whether the offset is correct? In the raspberrypi.h
> in RTEMS there is the following define:
>
> #if (BSP_IS_RPI2 == 1)
>#define RPI_PERIPHERAL_BASE  0x3F00
> #else
>#define RPI_PERIPHERAL_BASE  0x2000
> #endif
>
> The offsets are right.

> >
> > > I followed the steps
> > >
> > from
> http://alanstechnotes.blogspot.com/2013/03/running-your-first-rtems-program-on.html
>  (modified
> > > commands to use rtems5) to build the kernel img.
> >
> > It's a bit odd that the Bootloader doesn't use some image format like
> > U-Boot but if that's the case for Raspberry, that's OK.
> >
> > Do you want me to try U-Boot, I was planning to use it for my bare-metal
> > stuff because copying the kernel
> > to SD-card was a real pain. Will it even work with RTEMS?
>
> The manual that you linked uses the default Raspberry bootloader. I'm
> not sure whether it's an U-Boot. If you skip the bootloader entirely,
> your SDRAM might isn't initialized.

The manual uses the default bootloader. I don't think we have to worry
about the SDRAM initialization
because all of that is taken care of by the GPU. When using Uboot, the GPU
will load the uboot image and
pass the control to the CPU. And then the uboot continue's it's execution.

>
>
PS: You answered that further below. You are using the stage 3 loader.
>
> >
> > > I did try running it on
> > > Qemu but it doesn't always work, sometimes it gives weird output.
> >
> > How did you run it on Qemu? Did you build some image for that too?
> >
> > qemu-system-arm -M raspi2 -m 1G -kernel hello.exe -serial mon:stdio
> > -nographic
> > *
> > *
> > *
> > qemu-system-aarch64: GLib: g_mapped_file_unref: assertion 'file != NULL'
> > failed *I get this error
> > while trying to emulate raspi3.
>
> That sounds like a problem with Qemu. Is there some official test image
> for rpi3 on qemu? Note that this isn't really relevant for your current
> problem. So if you don't have some manual just ignore the question.
>
> >
> > I ran qemu along with GDB to find what was causing the wrong output. I
> > am really not sure if this is right,
> > I still have a lot to learn, but my assumption's using GDB are as
> follows.
> > There are 4 active thread which run the same code.
> >
> > (gdb) info thread
> >   Id   Target IdFrame
> > * 1Thread 1.1 (CPU#0 [running]) _start () at
> >
>  
> ../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/shared/start/start.S:153
> >   2Thread 1.2 (CPU#1 [running]) _start () at
> >
>  
> ../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/shared/start/start.S:153
> >   3Thread 1.3 (CPU#2 [running]) _start () at
> >
>  
> ../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/shared/start/start.S:153
> >   4Thread 1.4 (CPU#3 [running]) _start () at
> >
>  
> ../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/shared/start/start.S:153
>
> In this case that are not threads but it's th

Re: Problem running RTEMS on raspberrypi3

[Niteesh]

On Mon, Dec 16, 2019 at 2:36 AM Christian Mauderer 
wrote:

>
>
> On 15/12/2019 21:29, Niteesh wrote:
> >
> >
> > On Mon, Dec 16, 2019 at 12:53 AM Christian Mauderer  > <mailto:l...@c-mauderer.de>> wrote:
> >
> > On 15/12/2019 19:46, Niteesh wrote:
> > >
> > >
> > > On Sun, Dec 15, 2019 at 10:15 PM Christian Mauderer
> > mailto:l...@c-mauderer.de>
> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> wrote:
> > >
> > > Hello Niteesh,
> > >
> > > On 15/12/2019 09:05, Niteesh wrote:
> > > > I am trying to get RTEMS examples running on the RPI3, the
> > RPI3 is
> > > > similar to RPI2 so the examples built for RPI2 should
> > technically
> > > run on
> > > > the RPi3.But they don't :(, I am really sure of what is
> causing
> > > the problem.
> > >
> > > Note that there are at least two different versions of the
> > RPi3 which
> > > use different chips. The original RPi3 which uses a BCM2837
> > (same like
> > > later versions of RPi2) and the RPi3+ which uses a BCM2837B0.
> > Broadcom
> > > is always quite sparse with documentation so it's not easy to
> > tell the
> > > differences. Which one do you have?
> > >
> > > I have Rpi3 model b v1.2 which uses BCM2837 SOC, in my bare-metal
> > > programming I used the
> > > 2835 doc as a reference because the only major difference these
> > two SOC
> > > is the peripheral base address
> > > offset. But this is arm cpu is also capable of executing in 64bit
> > mode.
> >
> > OK. Did you check, whether the offset is correct? In the
> raspberrypi.h
> > in RTEMS there is the following define:
> >
> > #if (BSP_IS_RPI2 == 1)
> >#define RPI_PERIPHERAL_BASE  0x3F00
> > #else
> >#define RPI_PERIPHERAL_BASE  0x2000
> > #endif
> >
> > The offsets are right.
>
> Good.
>
> >
> > >
> > > > I followed the steps
> > > >
> > >
> >  from
> http://alanstechnotes.blogspot.com/2013/03/running-your-first-rtems-program-on.html
>  (modified
> > > > commands to use rtems5) to build the kernel img.
> > >
> > > It's a bit odd that the Bootloader doesn't use some image
> > format like
> > > U-Boot but if that's the case for Raspberry, that's OK.
> > >
> > > Do you want me to try U-Boot, I was planning to use it for my
> > bare-metal
> > > stuff because copying the kernel
> > > to SD-card was a real pain. Will it even work with RTEMS?
> >
> > The manual that you linked uses the default Raspberry bootloader. I'm
> > not sure whether it's an U-Boot. If you skip the bootloader entirely,
> > your SDRAM might isn't initialized.
> >
> > The manual uses the default bootloader. I don't think we have to worry
> > about the SDRAM initialization
> > because all of that is taken care of by the GPU.
>
> Sounds OK.
>
> > When using Uboot, the
> > GPU will load the uboot image and
> > pass the control to the CPU. And then the uboot continue's it's
> execution.
> >
>
> I don't wanted to suggest to use an extra U-Boot. I was just not sure
> whether the stage 3 loader is an U-Boot. Your approach sounds fine so far.
>
> >
> >
> > PS: You answered that further below. You are using the stage 3
> loader.
> >
> > >
> > > > I did try running it on
> > > > Qemu but it doesn't always work, sometimes it gives
> > weird output.
> > >
> > > How did you run it on Qemu? Did you build some image for that
> too?
> > >
> > > qemu-system-arm -M raspi2 -m 1G -kernel hello.exe -serial mon:stdio
> > > -nographic
> > > *
> > > *
> > > *
> > > qemu-system-aarch64: GLib: g_mapped_file_unref: assertion 'file !=
> > NULL'
> > > failed *I get this error
> > > while trying to emulate raspi3.
> >
> > That sounds like a problem with Qemu. Is there some official test
> image
> > for r

Re: Problem running RTEMS on raspberrypi3

[Niteesh]

I got uboot running on my raspi3. But I can't figure out to load and run a
custom kernel. Can you explain the steps or point me to some
reference.
On Mon, Dec 16, 2019 at 5:13 PM Niteesh  wrote:

> On Mon, Dec 16, 2019 at 2:36 AM Christian Mauderer 
> wrote:
>
>>
>>
>> On 15/12/2019 21:29, Niteesh wrote:
>> >
>> >
>> > On Mon, Dec 16, 2019 at 12:53 AM Christian Mauderer > > <mailto:l...@c-mauderer.de>> wrote:
>> >
>> > On 15/12/2019 19:46, Niteesh wrote:
>> > >
>> > >
>> > > On Sun, Dec 15, 2019 at 10:15 PM Christian Mauderer
>> >     mailto:l...@c-mauderer.de>
>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> wrote:
>> > >
>> > > Hello Niteesh,
>> > >
>> > > On 15/12/2019 09:05, Niteesh wrote:
>> > > > I am trying to get RTEMS examples running on the RPI3, the
>> > RPI3 is
>> > > > similar to RPI2 so the examples built for RPI2 should
>> > technically
>> > > run on
>> > > > the RPi3.But they don't :(, I am really sure of what is
>> causing
>> > > the problem.
>> > >
>> > > Note that there are at least two different versions of the
>> > RPi3 which
>> > > use different chips. The original RPi3 which uses a BCM2837
>> > (same like
>> > > later versions of RPi2) and the RPi3+ which uses a BCM2837B0.
>> > Broadcom
>> > > is always quite sparse with documentation so it's not easy to
>> > tell the
>> > > differences. Which one do you have?
>> > >
>> > > I have Rpi3 model b v1.2 which uses BCM2837 SOC, in my bare-metal
>> > > programming I used the
>> > > 2835 doc as a reference because the only major difference these
>> > two SOC
>> > > is the peripheral base address
>> > > offset. But this is arm cpu is also capable of executing in 64bit
>> > mode.
>> >
>> > OK. Did you check, whether the offset is correct? In the
>> raspberrypi.h
>> > in RTEMS there is the following define:
>> >
>> > #if (BSP_IS_RPI2 == 1)
>> >#define RPI_PERIPHERAL_BASE  0x3F00
>> > #else
>> >#define RPI_PERIPHERAL_BASE  0x2000
>> > #endif
>> >
>> > The offsets are right.
>>
>> Good.
>>
>> >
>> > >
>> > > > I followed the steps
>> > > >
>> > >
>> >  from
>> http://alanstechnotes.blogspot.com/2013/03/running-your-first-rtems-program-on.html
>>  (modified
>> > > > commands to use rtems5) to build the kernel img.
>> > >
>> > > It's a bit odd that the Bootloader doesn't use some image
>> > format like
>> > > U-Boot but if that's the case for Raspberry, that's OK.
>> > >
>> > > Do you want me to try U-Boot, I was planning to use it for my
>> > bare-metal
>> > > stuff because copying the kernel
>> > > to SD-card was a real pain. Will it even work with RTEMS?
>> >
>> > The manual that you linked uses the default Raspberry bootloader.
>> I'm
>> > not sure whether it's an U-Boot. If you skip the bootloader
>> entirely,
>> > your SDRAM might isn't initialized.
>> >
>> > The manual uses the default bootloader. I don't think we have to worry
>> > about the SDRAM initialization
>> > because all of that is taken care of by the GPU.
>>
>> Sounds OK.
>>
>> > When using Uboot, the
>> > GPU will load the uboot image and
>> > pass the control to the CPU. And then the uboot continue's it's
>> execution.
>> >
>>
>> I don't wanted to suggest to use an extra U-Boot. I was just not sure
>> whether the stage 3 loader is an U-Boot. Your approach sounds fine so far.
>>
>> >
>> >
>> > PS: You answered that further below. You are using the stage 3
>> loader.
>> >
>> > >
>> > > > I did try running it on
>> > > > Qemu but it doesn't always work, sometimes it gives
>> >

Re: [EXTERNAL] Re: Problem running RTEMS on raspberrypi3

[Niteesh]

I looked at the source code for UART. RTEMS uses the PL011 which is by
default connected to the bluetooth module, but this can be changed by
adding disable-bt command to the config.txt
this will configure PL011 as the primary uart. So I don't think anything
has to be changed.

On Mon, Dec 16, 2019 at 6:57 PM Cudmore, Alan P. (GSFC-5820) <
alan.p.cudm...@nasa.gov> wrote:

> Has the RPI3 UART/Console been addressed in RTEMS?
>
> My understanding is that the RPI 1, Zero (without wireless) and 2 all
> share the same UART/Console driver. But the Raspberry Pi 3 and Zero W use
> that UART to talk to the Bluetooth module. The “mini” UART is then used for
> the console.
>
> So, at a minimum, I think the RPI3 needs a different console driver.
>
>
>
> https://www.raspberrypi.org/documentation/configuration/uart.md
>
>
>
> *From: *devel  on behalf of Niteesh <
> gsnb...@gmail.com>
> *Date: *Monday, December 16, 2019 at 8:02 AM
> *To: *Christian Mauderer 
> *Cc: *"rtems-de...@rtems.org" 
> *Subject: *[EXTERNAL] Re: Problem running RTEMS on raspberrypi3
>
>
>
> I got uboot running on my raspi3. But I can't figure out to load and run a
> custom kernel. Can you explain the steps or point me to some
>
> reference.
>
> On Mon, Dec 16, 2019 at 5:13 PM Niteesh  wrote:
>
> On Mon, Dec 16, 2019 at 2:36 AM Christian Mauderer 
> wrote:
>
>
>
> On 15/12/2019 21:29, Niteesh wrote:
> >
> >
> > On Mon, Dec 16, 2019 at 12:53 AM Christian Mauderer  > <mailto:l...@c-mauderer.de>> wrote:
> >
> > On 15/12/2019 19:46, Niteesh wrote:
> > >
> > >
> > > On Sun, Dec 15, 2019 at 10:15 PM Christian Mauderer
> > mailto:l...@c-mauderer.de>
> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> wrote:
> > >
> > > Hello Niteesh,
> > >
> > > On 15/12/2019 09:05, Niteesh wrote:
> > > > I am trying to get RTEMS examples running on the RPI3, the
> > RPI3 is
> > > > similar to RPI2 so the examples built for RPI2 should
> > technically
> > > run on
> > > > the RPi3.But they don't :(, I am really sure of what is
> causing
> > > the problem.
> > >
> > > Note that there are at least two different versions of the
> > RPi3 which
> > > use different chips. The original RPi3 which uses a BCM2837
> > (same like
> > > later versions of RPi2) and the RPi3+ which uses a BCM2837B0.
> > Broadcom
> > > is always quite sparse with documentation so it's not easy to
> > tell the
> > > differences. Which one do you have?
> > >
> > > I have Rpi3 model b v1.2 which uses BCM2837 SOC, in my bare-metal
> > > programming I used the
> > > 2835 doc as a reference because the only major difference these
> > two SOC
> > > is the peripheral base address
> > > offset. But this is arm cpu is also capable of executing in 64bit
> > mode.
> >
> > OK. Did you check, whether the offset is correct? In the
> raspberrypi.h
> > in RTEMS there is the following define:
> >
> > #if (BSP_IS_RPI2 == 1)
> >#define RPI_PERIPHERAL_BASE  0x3F00
> > #else
> >#define RPI_PERIPHERAL_BASE  0x2000
> > #endif
> >
> > The offsets are right.
>
> Good.
>
> >
> > >
> > > > I followed the steps
> > > >
> > >
> >  from
> http://alanstechnotes.blogspot.com/2013/03/running-your-first-rtems-program-on.html
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__alanstechnotes.blogspot.com_2013_03_running-2Dyour-2Dfirst-2Drtems-2Dprogram-2Don.html&d=DwMFaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=mgmnjRRtQ0UiBECza6LBUdPRMlI07FCjTRHH5qFTYRk&s=RXd0TjeCxMP_Y43iLHMAMB4sv7Tfq1pjRRVKJbqfyJg&e=>
>  (modified
> > > > commands to use rtems5) to build the kernel img.
> > >
> > > It's a bit odd that the Bootloader doesn't use some image
> > format like
> > > U-Boot but if that's the case for Raspberry, that's OK.
> > >
> > > Do you want me to try U-Boot, I was planning to use it for my
> > bare-metal
> > > stuff because copying the kernel
> > > to SD-card was a real pain. Will it even wor

Re: [EXTERNAL] Re: Problem running RTEMS on raspberrypi3

[Niteesh]

If possible can you write down the exact steps of how you loaded the image?
I tried running it on my RPi3 by placing the rtems kernel.img in my SD card
but it didn't work.

On Mon, Dec 16, 2019 at 7:33 PM Cudmore, Alan P. (GSFC-5820) <
alan.p.cudm...@nasa.gov> wrote:

> That’s good to know. I would like to try the Raspberry Pi Zero W and make
> sure it works like the Pi Zero without the wireless.
>
>
>
> *From: *Niteesh 
> *Date: *Monday, December 16, 2019 at 8:54 AM
> *To: *Alan Cudmore 
> *Cc: *Christian Mauderer , "rtems-de...@rtems.org" <
> devel@rtems.org>
> *Subject: *Re: [EXTERNAL] Re: Problem running RTEMS on raspberrypi3
>
>
>
> I looked at the source code for UART. RTEMS uses the PL011 which is by
> default connected to the bluetooth module, but this can be changed by
> adding disable-bt command to the config.txt
>
> this will configure PL011 as the primary uart. So I don't think anything
> has to be changed.
>
>
>
> On Mon, Dec 16, 2019 at 6:57 PM Cudmore, Alan P. (GSFC-5820) <
> alan.p.cudm...@nasa.gov> wrote:
>
> Has the RPI3 UART/Console been addressed in RTEMS?
>
> My understanding is that the RPI 1, Zero (without wireless) and 2 all
> share the same UART/Console driver. But the Raspberry Pi 3 and Zero W use
> that UART to talk to the Bluetooth module. The “mini” UART is then used for
> the console.
>
> So, at a minimum, I think the RPI3 needs a different console driver.
>
>
>
> https://www.raspberrypi.org/documentation/configuration/uart.md
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.raspberrypi.org_documentation_configuration_uart.md&d=DwMFaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=HjAtDcAxrxRahiF3zEE7-O2MuNEcjdC01tK5I6ybOGM&s=PiiVvSpbmmRGLGOH4BljOgj_9M4JEXJNaQAvLBgh8sQ&e=>
>
>
>
> *From: *devel  on behalf of Niteesh <
> gsnb...@gmail.com>
> *Date: *Monday, December 16, 2019 at 8:02 AM
> *To: *Christian Mauderer 
> *Cc: *"rtems-de...@rtems.org" 
> *Subject: *[EXTERNAL] Re: Problem running RTEMS on raspberrypi3
>
>
>
> I got uboot running on my raspi3. But I can't figure out to load and run a
> custom kernel. Can you explain the steps or point me to some
>
> reference.
>
> On Mon, Dec 16, 2019 at 5:13 PM Niteesh  wrote:
>
> On Mon, Dec 16, 2019 at 2:36 AM Christian Mauderer 
> wrote:
>
>
>
> On 15/12/2019 21:29, Niteesh wrote:
> >
> >
> > On Mon, Dec 16, 2019 at 12:53 AM Christian Mauderer  > <mailto:l...@c-mauderer.de>> wrote:
> >
> > On 15/12/2019 19:46, Niteesh wrote:
> > >
> > >
> > > On Sun, Dec 15, 2019 at 10:15 PM Christian Mauderer
> > mailto:l...@c-mauderer.de>
> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> wrote:
> > >
> > > Hello Niteesh,
> > >
> > > On 15/12/2019 09:05, Niteesh wrote:
> > > > I am trying to get RTEMS examples running on the RPI3, the
> > RPI3 is
> > > > similar to RPI2 so the examples built for RPI2 should
> > technically
> > > run on
> > > > the RPi3.But they don't :(, I am really sure of what is
> causing
> > > the problem.
> > >
> > > Note that there are at least two different versions of the
> > RPi3 which
> > > use different chips. The original RPi3 which uses a BCM2837
> > (same like
> > > later versions of RPi2) and the RPi3+ which uses a BCM2837B0.
> > Broadcom
> > > is always quite sparse with documentation so it's not easy to
> > tell the
> > > differences. Which one do you have?
> > >
> > > I have Rpi3 model b v1.2 which uses BCM2837 SOC, in my bare-metal
> > > programming I used the
> > > 2835 doc as a reference because the only major difference these
> > two SOC
> > > is the peripheral base address
> > > offset. But this is arm cpu is also capable of executing in 64bit
> > mode.
> >
> > OK. Did you check, whether the offset is correct? In the
> raspberrypi.h
> > in RTEMS there is the following define:
> >
> > #if (BSP_IS_RPI2 == 1)
> >#define RPI_PERIPHERAL_BASE  0x3F00
> > #else
> >#define RPI_PERIPHERAL_BASE  0x2000
> > #endif
> >
> > The offsets are right.
>
> Good.
>
> >
> > >
> > &

Re: Problem running RTEMS on raspberrypi3

[Niteesh]

But I am not able to boot using the 3 stage bootloader. Can someone try
booting any examples on raspi3 or other newer models? If it's work's please
post the instructions. The steps that I followed are:
1. arm-rtems5-objcopy -Obinary hello.exe kernel.img
2. copied the kernel image to sd card and modified the config.txt to load
the kernel img.
No success in following these steps.
I think this is maybe because of the different start addresses. The default
kernel load address for raspberry pi is 0x8000 in 32bit mode and 0x8 in
64bit mode.
but RTEMS has a start address of 0x200080.


On Mon, Dec 16, 2019 at 7:51 PM Christian Mauderer 
wrote:

> I think I have guided you to a wrong path here. I mentioned U-Boot
> because it is often used on a lot of evaluation boards. In the raspberry
> case it seems that the stage 3 loader is something different. But
> everything should work with that stage 3 loader. I don't think that
> U-Boot is necessary.
>
> On 16/12/2019 14:01, Niteesh wrote:
> > I got uboot running on my raspi3. But I can't figure out to load and run
> > a custom kernel. Can you explain the steps or point me to some
> > reference.
> > On Mon, Dec 16, 2019 at 5:13 PM Niteesh  > <mailto:gsnb...@gmail.com>> wrote:
> >
> > On Mon, Dec 16, 2019 at 2:36 AM Christian Mauderer
> > mailto:l...@c-mauderer.de>> wrote:
> >
> >
> >
> > On 15/12/2019 21:29, Niteesh wrote:
> > >
> > >
> > > On Mon, Dec 16, 2019 at 12:53 AM Christian Mauderer
> > mailto:l...@c-mauderer.de>
> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>
> wrote:
> > >
> > > On 15/12/2019 19:46, Niteesh wrote:
> > > >
> > > >
> > > > On Sun, Dec 15, 2019 at 10:15 PM Christian Mauderer
> > > mailto:l...@c-mauderer.de>
> >     <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>
> >     > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>
> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>> wrote:
> > > >
> > > > Hello Niteesh,
> > > >
> > > > On 15/12/2019 09:05, Niteesh wrote:
> > > > > I am trying to get RTEMS examples running on the
> > RPI3, the
> > > RPI3 is
> > > > > similar to RPI2 so the examples built for RPI2
> should
> > > technically
> > > > run on
> > > > > the RPi3.But they don't :(, I am really sure of
> > what is causing
> > > > the problem.
> > > >
> > > > Note that there are at least two different versions
> > of the
> > > RPi3 which
> > > > use different chips. The original RPi3 which uses a
> > BCM2837
> > > (same like
> > > > later versions of RPi2) and the RPi3+ which uses a
> > BCM2837B0.
> > > Broadcom
> > > > is always quite sparse with documentation so it's
> > not easy to
> > > tell the
> > > > differences. Which one do you have?
> > > >
> > > > I have Rpi3 model b v1.2 which uses BCM2837 SOC, in my
> > bare-metal
> > > > programming I used the
> > > > 2835 doc as a reference because the only major
> > difference these
> > > two SOC
> > > > is the peripheral base address
> > > > offset. But this is arm cpu is also capable of
> > executing in 64bit
> > > mode.
> > >
> > > OK. Did you check, whether the offset is correct? In the
> > raspberrypi.h
> > > in RTEMS there is the following define:
> > >
> > > #if (BSP_IS_RPI2 == 1)
> > >#define RPI_PERIPHERAL_BASE  0x3F00
> > > #else
> > >#define RPI_PERIPHERAL_BASE  0x2000
> > > #endif
> > >
> > > The offsets are right.
> >
> > Good.
> >
> > >
> &

Re: Problem running RTEMS on raspberrypi3

[Niteesh]

What about using U-boot? I just tried running my own bare metal example
using u-boot and it works fine.
The 3rd stage bootloader start the u-boot and I was able to interact with
it through serial. and then I used
fatload mmc 0 0x8000 kernel.img ; go 0x8000
to load and run the img. I tried the same for rtems
fatload mmc 0 0x20 rtems_kernel.img ; go 0x200080
but this result's in a

## Starting application at 0x00200080 ...
"Synchronous Abort" handler, esr 0x0200
elr: c1d29080 lr : 000838b0 (reloc)
elr: 00200080 lr : 3e55a8b0
x0 : 0001 x1 : 3e15e6c8
x2 : 3e15e6c8 x3 : 00200080
x4 :  x5 : 
x6 : 00c0c0c0 x7 : 000f
x8 : ffd0 x9 : 0008
x10: 0010 x11: 3e159cc0
x12:  x13: 0200
x14: 0005 x15: 0008
x16:  x17: 0020
x18: 3e152de0 x19: 3e15e6c8
x20: 0002 x21: 00200080
x22: 3e15e6c0 x23: 0002
x24: 3e5d4d44 x25: 
x26:  x27: 
x28: 3e1567e0 x29: 3e152b20

Code: 0020b048 0020b048 0020b048 0020b048 (e1a05001)
Resetting CPU ...


On Mon, Dec 16, 2019 at 8:11 PM Niteesh  wrote:

> But I am not able to boot using the 3 stage bootloader. Can someone try
> booting any examples on raspi3 or other newer models? If it's work's please
> post the instructions. The steps that I followed are:
> 1. arm-rtems5-objcopy -Obinary hello.exe kernel.img
> 2. copied the kernel image to sd card and modified the config.txt to load
> the kernel img.
> No success in following these steps.
> I think this is maybe because of the different start addresses. The
> default kernel load address for raspberry pi is 0x8000 in 32bit mode and
> 0x8 in 64bit mode.
> but RTEMS has a start address of 0x200080.
>
>
> On Mon, Dec 16, 2019 at 7:51 PM Christian Mauderer 
> wrote:
>
>> I think I have guided you to a wrong path here. I mentioned U-Boot
>> because it is often used on a lot of evaluation boards. In the raspberry
>> case it seems that the stage 3 loader is something different. But
>> everything should work with that stage 3 loader. I don't think that
>> U-Boot is necessary.
>>
>> On 16/12/2019 14:01, Niteesh wrote:
>> > I got uboot running on my raspi3. But I can't figure out to load and run
>> > a custom kernel. Can you explain the steps or point me to some
>> > reference.
>> > On Mon, Dec 16, 2019 at 5:13 PM Niteesh > > <mailto:gsnb...@gmail.com>> wrote:
>> >
>> > On Mon, Dec 16, 2019 at 2:36 AM Christian Mauderer
>> > mailto:l...@c-mauderer.de>> wrote:
>> >
>> >
>> >
>> > On 15/12/2019 21:29, Niteesh wrote:
>> > >
>> > >
>> > > On Mon, Dec 16, 2019 at 12:53 AM Christian Mauderer
>> > mailto:l...@c-mauderer.de>
>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>
>> wrote:
>> > >
>> > > On 15/12/2019 19:46, Niteesh wrote:
>> > > >
>> > > >
>> > > > On Sun, Dec 15, 2019 at 10:15 PM Christian Mauderer
>> > > mailto:l...@c-mauderer.de>
>> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>
>> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>
>> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>>
>> wrote:
>> > > >
>> > > > Hello Niteesh,
>> > > >
>> > > > On 15/12/2019 09:05, Niteesh wrote:
>> > > > > I am trying to get RTEMS examples running on the
>> > RPI3, the
>> > > RPI3 is
>> > > > > similar to RPI2 so the examples built for RPI2
>> should
>> > > technically
>> > > > run on
>> > > > > the RPi3.But they don't :(, I am really sure of
>> > what is causing
>> > > > the problem.
>> > > >
>> > > > Note that there are at least two different versions
>> > of the
>> > > RPi3 which
>> > > > use different chips. The original RPi3

Re: Problem running RTEMS on raspberrypi3

[Niteesh]

Yes, I did try that but still, it doesn't work.  I don't have any other
pi's with me, maybe let's wait for someone to try it out on any older
models.

On Wed, Dec 18, 2019 at 2:06 AM Christian Mauderer 
wrote:

> That handler doesn't look like an RTEMS handler. So it failed at a very
> early stage.
>
> Did you try a go 0x20 instead? Normally the first vector is a reset
> vector which jumps to the right start address. The jump can have a mode
> with it. So if you directly jump to 0x200080 the core might is in a
> wrong mode.
>
> On 16/12/2019 15:54, Niteesh wrote:
> > What about using U-boot? I just tried running my own bare metal example
> > using u-boot and it works fine.
> > The 3rd stage bootloader start the u-boot and I was able to interact
> > with it through serial. and then I used
> > fatload mmc 0 0x8000 kernel.img ; go 0x8000
> > to load and run the img. I tried the same for rtems
> > fatload mmc 0 0x20 rtems_kernel.img ; go 0x200080
> > but this result's in a
> >
> > ## Starting application at 0x00200080 ...
> > "Synchronous Abort" handler, esr 0x0200
> > elr: c1d29080 lr : 000838b0 (reloc)
> > elr: 00200080 lr : 3e55a8b0
> > x0 : 0001 x1 : 3e15e6c8
> > x2 : 3e15e6c8 x3 : 00200080
> > x4 :  x5 : 
> > x6 : 00c0c0c0 x7 : 000f
> > x8 : ffd0 x9 : 0008
> > x10: 0010 x11: 3e159cc0
> > x12:  x13: 0200
> > x14: 0005 x15: 0008
> > x16:  x17: 0020
> > x18: 3e152de0 x19: 3e15e6c8
> > x20: 0002 x21: 00200080
> > x22: 3e15e6c0 x23: 0002
> > x24: 3e5d4d44 x25: 
> > x26:  x27: 
> > x28: 3e1567e0 x29: 3e152b20
> >
> > Code: 0020b048 0020b048 0020b048 0020b048 (e1a05001)
> > Resetting CPU ...
> >
> >
> > On Mon, Dec 16, 2019 at 8:11 PM Niteesh  > <mailto:gsnb...@gmail.com>> wrote:
> >
> > But I am not able to boot using the 3 stage bootloader. Can someone
> > try booting any examples on raspi3 or other newer models? If it's
> > work's please
> > post the instructions. The steps that I followed are:
> > 1. arm-rtems5-objcopy -Obinary hello.exe kernel.img
> > 2. copied the kernel image to sd card and modified the config.txt to
> > load the kernel img.
> > No success in following these steps.
> > I think this is maybe because of the different start addresses. The
> > default kernel load address for raspberry pi is 0x8000 in 32bit mode
> > and 0x8 in 64bit mode.
> > but RTEMS has a start address of 0x200080.
> >
> >
> > On Mon, Dec 16, 2019 at 7:51 PM Christian Mauderer
> > mailto:l...@c-mauderer.de>> wrote:
> >
> > I think I have guided you to a wrong path here. I mentioned
> U-Boot
> > because it is often used on a lot of evaluation boards. In the
> > raspberry
> > case it seems that the stage 3 loader is something different. But
> > everything should work with that stage 3 loader. I don't think
> that
> > U-Boot is necessary.
> >
> > On 16/12/2019 14:01, Niteesh wrote:
> > > I got uboot running on my raspi3. But I can't figure out to
> > load and run
> > > a custom kernel. Can you explain the steps or point me to some
> > > reference.
> > > On Mon, Dec 16, 2019 at 5:13 PM Niteesh  > <mailto:gsnb...@gmail.com>
> > > <mailto:gsnb...@gmail.com <mailto:gsnb...@gmail.com>>> wrote:
> > >
> > > On Mon, Dec 16, 2019 at 2:36 AM Christian Mauderer
> > > mailto:l...@c-mauderer.de>
> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> wrote:
> > >
> > >
> > >
> > > On 15/12/2019 21:29, Niteesh wrote:
> > > >
> > > >
> > > > On Mon, Dec 16, 2019 at 12:53 AM Christian Mauderer
> > > mailto:l...@c-mauderer.de>
> > <mailto:l...@c-mauderer.de <mailto:l..

Re: raspberry BSP: Maybe there is a bug in the linker file?

[Niteesh]

As far as I know, 0x8000 is a fixed address where the bootloader jumps to
after loading the application assuming the CPU is in 32bit mode. For 64bit
mode, it jumps to 0x8.


On Thu, Dec 19, 2019 at 6:58 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 19/12/2019 14:24, Christian Mauderer wrote:
> > Hello,
> >
> > triggered by the discussion regarding RTEMS on raspberrypi 3 I did some
> > tests. I haven't been able to start a RTEMS on my Pi 1 if I tried a
> > version after commit c5fd79cd4704a4270ba0114a1009ab8556f997c9 from
> > 29.07.2019. Right before it everything works as expected.
> >
> > The commit changes the memory locations. From what I understood, the
> > bootloader on a raspberry always jumps to address 0x8000 after loading
> > the application. So I'm not convinced that the change is correct.
>
> Is the 0x8000 a fixed address or you configure this in a boot image header?
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: raspberry BSP: Maybe there is a bug in the linker file?

[Niteesh]

I will do it by either today or tomorrow.


On Fri, 20 Dec, 2019, 12:03 PM Sebastian Huber, <
sebastian.hu...@embedded-brains.de> wrote:

> On 19/12/2019 15:28, Niteesh wrote:
> > As far as I know, 0x8000 is a fixed address where the bootloader jumps
> > to after loading the application assuming the CPU is in 32bit mode. For
> > 64bit mode, it jumps to 0x8.
>
> Would you mind testing this patch:
>
> https://lists.rtems.org/pipermail/devel/2019-December/056551.html
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: raspberry BSP: Maybe there is a bug in the linker file?

[Niteesh]

How do you test a patch? Do you checkout that particular commit and build
and the BSP again?.
@Christian Mauderer   how did you build it for the
rpi1? Did you follow the steps as in previous threads?
and how did you come to the conclusion that these changes cause the
exceptions, as a beginner these ideas
will help in the future.
On Fri, Dec 20, 2019 at 2:46 PM Christian Mauderer 
wrote:

> On 20/12/2019 09:22, Christian Mauderer wrote:
> > On 20/12/2019 07:33, Sebastian Huber wrote:
> >> On 19/12/2019 15:28, Niteesh wrote:
> >>> As far as I know, 0x8000 is a fixed address where the bootloader jumps
> >>> to after loading the application assuming the CPU is in 32bit mode.
> >>> For 64bit mode, it jumps to 0x8.
> >>
> >> Would you mind testing this patch:
> >>
> >> https://lists.rtems.org/pipermail/devel/2019-December/056551.html
> >>
> >
> > On the Pi 1 now the binary has three time the size (with a lot of 0x00
> > in it) and at least RTEMS starts. But it runs into an exception quite
> > fast. I'll investigate that a bit.
> >
> > @Niteesh: For the Pi 3 I would expect that it still doesn't print
> > anything on the console due to the different UART pins.
> >
> > The output on the Pi 1 is:
> >
> > executing�
> > *** FATAL ***
> > fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
> >
> > R0   = 0xfc037f80 R8  = 0x
> > R1   = 0xfc345980 R9  = 0x0010
> > R2   = 0x0001 R10 = 0xfc037f8a
> > R3   = 0x03fc8080 R11 = 0x0030da00
> > R4   = 0xfc037f80 R12 = 0xfc345988
> > R5   = 0x0008 SP  = 0x00300ba8
> > R6   = 0x0030d9fe LR  = 0x00205a78
> > R7   = 0x00305218 PC  = 0x00205ac8
> > CPSR = 0x61d3 VEC = 0x0004
> > RTEMS version: 5.0.0.254f38583fe68c3e17dfe274a2deeb00a5a538d6
> > RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (6c65fc237b9e modified),
> > Newlib d14714c69)
>
> The exception seems to be caused by some of the changes in bspstart.c
> and bspgetworkarea.c in patch a4d7e4cee77d16b0e34ef543f0804e7eb2954137.
> So the fix for the linker command file is fine.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: raspberry BSP: Maybe there is a bug in the linker file?

[Niteesh]

Did you take a look at the exception? I still couldn't get it running on
the rpi3 using rpi2 bsp.
I built the bsp again by checking out a commit before
c5fd79cd4704a4270ba0114a1009ab8556f997c9
and created a kernel.img using objcopy.
I tried running it on gdb with set scheduler-locking on. I seem to jump to
bsp_vector_table_begin and hang there (0x00c).


On Sat, Dec 21, 2019 at 1:42 AM Christian Mauderer 
wrote:

> On 20/12/2019 19:19, Niteesh wrote:
> > How do you test a patch? Do you checkout that particular commit and
> > build and the BSP again?.
>
> Basically yes: You check out the version that you want fixed and apply
> the patch. In that case I have gone back and forward a few times to find
> the commit that introduced the second bug.
>
> > @Christian Mauderer <mailto:l...@c-mauderer.de>  how did you build it
> > for the rpi1? Did you follow the steps as in previous threads?
>
> Basically the same steps like for every BSP:
> 1. Build a recent toolchain using RSB.
> 2. Build the BSP.
> 3. Test it on the board.
>
> For the rpi1 the BSP is "raspberrypi" instead of "raspberrypi2". And I
> didn't install the BSP because I only wanted the tests and no extra
> application.
>
> For testing it I used the guide that you found: Objcopy into a binary
> file and replace the kernel.img with it.
>
> > and how did you come to the conclusion that these changes cause the
> > exceptions,
>
> I had a look at the history of the raspberry BSP (`gitk
> bsps/arm/raspberrypi` or `git log bsps/arm/raspberrypi`) and looked for
> suspicious patches. For the raspberry there are not much patches in the
> last year so that was quite easy. Then I just tested before and after
> some of the patches to find the ones that introduced the bugs.
>
> Again: In this case it was necessary to backport Sebastians patch so
> that I have been able to test before / after the one that introduces the
> exception.
>
> I haven't had a detailled look at the exception yet but I assume it's
> some problem that the wrong variant is used or that my RPi1 is an early
> model with less RAM or something like that.
>
> > as a beginner these ideas
> > will help in the future.
> > On Fri, Dec 20, 2019 at 2:46 PM Christian Mauderer  > <mailto:l...@c-mauderer.de>> wrote:
> >
> > On 20/12/2019 09:22, Christian Mauderer wrote:
> > > On 20/12/2019 07:33, Sebastian Huber wrote:
> > >> On 19/12/2019 15:28, Niteesh wrote:
> > >>> As far as I know, 0x8000 is a fixed address where the bootloader
> > jumps
> > >>> to after loading the application assuming the CPU is in 32bit
> mode.
> > >>> For 64bit mode, it jumps to 0x8.
> > >>
> > >> Would you mind testing this patch:
> > >>
> > >> https://lists.rtems.org/pipermail/devel/2019-December/056551.html
> > >>
> > >
> > > On the Pi 1 now the binary has three time the size (with a lot of
> 0x00
> > > in it) and at least RTEMS starts. But it runs into an exception
> quite
> > > fast. I'll investigate that a bit.
> > >
> > > @Niteesh: For the Pi 3 I would expect that it still doesn't print
> > > anything on the console due to the different UART pins.
> > >
> > > The output on the Pi 1 is:
> > >
> > > executing�
> > > *** FATAL ***
> > > fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
> > >
> > > R0   = 0xfc037f80 R8  = 0x
> > > R1   = 0xfc345980 R9  = 0x0010
> > > R2   = 0x0001 R10 = 0xfc037f8a
> > > R3   = 0x03fc8080 R11 = 0x0030da00
> > > R4   = 0xfc037f80 R12 = 0xfc345988
> > > R5   = 0x0008 SP  = 0x00300ba8
> > > R6   = 0x0030d9fe LR  = 0x00205a78
> > > R7   = 0x00305218 PC  = 0x00205ac8
> > > CPSR = 0x61d3 VEC = 0x0004
> > > RTEMS version: 5.0.0.254f38583fe68c3e17dfe274a2deeb00a5a538d6
> > > RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (6c65fc237b9e
> modified),
> > > Newlib d14714c69)
> >
> > The exception seems to be caused by some of the changes in bspstart.c
> > and bspgetworkarea.c in patch
> a4d7e4cee77d16b0e34ef543f0804e7eb2954137.
> > So the fix for the linker command file is fine.
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: raspberry BSP: Maybe there is a bug in the linker file?

[Niteesh]

I am very much interested in taking part in GSOC 2020. I want to get this
running on raspberrypi3
so that I could start learning and exploring more of RTEMS. I am planning
to add framebuffer support, using this year's GSOC work
on beagle bone as a reference.
On Sat, Dec 21, 2019 at 2:20 PM Christian Mauderer 
wrote:

> On 21/12/2019 08:28, Niteesh wrote:
> > Did you take a look at the exception?
>
> Not yet.
>
> > I still couldn't get it running on
> > the rpi3 using rpi2 bsp.
>
> Again: It's quite likely that the serial interface is a problem. I don't
> think that you'll see any output on rpi3 without changes.
>
> > I built the bsp again by checking out a commit before
> > c5fd79cd4704a4270ba0114a1009ab8556f997c9
> > and created a kernel.img using objcopy.
>
> That should work. But Most likely you'll get your output on the serial
> interface that is pointing to the bluetooth module.
>
I configured such that PL011 it is pointing to the serial port. We can do
that by adding disable-bt in the config.txt file.

> > I tried running it on gdb with set scheduler-locking on. I seem to jump
> > to bsp_vector_table_begin and hang there (0x00c).
>
> I thought you don't have a debugger connected? How do you run it with gdb?

Ran the executable with qemu and connected to it.
qemu-system-arm -M raspi2 -m 1G -kernel hello.exe -serial mon:stdio
-nographic -S -s

>
> >
> >
> > On Sat, Dec 21, 2019 at 1:42 AM Christian Mauderer  > <mailto:l...@c-mauderer.de>> wrote:
> >
> > On 20/12/2019 19:19, Niteesh wrote:
> > > How do you test a patch? Do you checkout that particular commit and
> > > build and the BSP again?.
> >
> > Basically yes: You check out the version that you want fixed and
> apply
> > the patch. In that case I have gone back and forward a few times to
> find
> > the commit that introduced the second bug.
> >
> > > @Christian Mauderer <mailto:l...@c-mauderer.de
> > <mailto:l...@c-mauderer.de>>  how did you build it
> > > for the rpi1? Did you follow the steps as in previous threads?
> >
> > Basically the same steps like for every BSP:
> > 1. Build a recent toolchain using RSB.
> > 2. Build the BSP.
> > 3. Test it on the board.
> >
> > For the rpi1 the BSP is "raspberrypi" instead of "raspberrypi2". And
> I
> > didn't install the BSP because I only wanted the tests and no extra
> > application.
> >
> > For testing it I used the guide that you found: Objcopy into a binary
> > file and replace the kernel.img with it.
> >
> > > and how did you come to the conclusion that these changes cause the
> > > exceptions,
> >
> > I had a look at the history of the raspberry BSP (`gitk
> > bsps/arm/raspberrypi` or `git log bsps/arm/raspberrypi`) and looked
> for
> > suspicious patches. For the raspberry there are not much patches in
> the
> > last year so that was quite easy. Then I just tested before and after
> > some of the patches to find the ones that introduced the bugs.
> >
> > Again: In this case it was necessary to backport Sebastians patch so
> > that I have been able to test before / after the one that introduces
> the
> > exception.
> >
> > I haven't had a detailled look at the exception yet but I assume it's
> > some problem that the wrong variant is used or that my RPi1 is an
> early
> > model with less RAM or something like that.
> >
> > > as a beginner these ideas
> > > will help in the future.
> > > On Fri, Dec 20, 2019 at 2:46 PM Christian Mauderer
> > mailto:l...@c-mauderer.de>
> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> wrote:
> > >
> > > On 20/12/2019 09:22, Christian Mauderer wrote:
> > > > On 20/12/2019 07:33, Sebastian Huber wrote:
> > > >> On 19/12/2019 15:28, Niteesh wrote:
> > > >>> As far as I know, 0x8000 is a fixed address where the
> > bootloader
> > > jumps
> > > >>> to after loading the application assuming the CPU is in
> > 32bit mode.
> > > >>> For 64bit mode, it jumps to 0x8.
> > > >>
> > > >> Would you mind testing this patch:
> > > >>
> > > >>
> > https://lists.rtems.org/pipermail/de

Re: raspberry BSP: Maybe there is a bug in the linker file?

[Niteesh]

Looks like there is already framebuffer support for RPi, but still I would
like to play with it and add some GUI example as in
https://blog.thelunatic.dev/gsoc-final-report/

On Sat, Dec 21, 2019 at 2:32 PM Niteesh  wrote:

> I am very much interested in taking part in GSOC 2020. I want to get this
> running on raspberrypi3
> so that I could start learning and exploring more of RTEMS. I am planning
> to add framebuffer support, using this year's GSOC work
> on beagle bone as a reference.
> On Sat, Dec 21, 2019 at 2:20 PM Christian Mauderer 
> wrote:
>
>> On 21/12/2019 08:28, Niteesh wrote:
>> > Did you take a look at the exception?
>>
>> Not yet.
>>
>> > I still couldn't get it running on
>> > the rpi3 using rpi2 bsp.
>>
>> Again: It's quite likely that the serial interface is a problem. I don't
>> think that you'll see any output on rpi3 without changes.
>>
>> > I built the bsp again by checking out a commit before
>> > c5fd79cd4704a4270ba0114a1009ab8556f997c9
>> > and created a kernel.img using objcopy.
>>
>> That should work. But Most likely you'll get your output on the serial
>> interface that is pointing to the bluetooth module.
>>
> I configured such that PL011 it is pointing to the serial port. We can do
> that by adding disable-bt in the config.txt file.
>
>> > I tried running it on gdb with set scheduler-locking on. I seem to jump
>> > to bsp_vector_table_begin and hang there (0x00c).
>>
>> I thought you don't have a debugger connected? How do you run it with gdb?
>
> Ran the executable with qemu and connected to it.
> qemu-system-arm -M raspi2 -m 1G -kernel hello.exe -serial mon:stdio
> -nographic -S -s
>
>>
>> >
>> >
>> > On Sat, Dec 21, 2019 at 1:42 AM Christian Mauderer > > <mailto:l...@c-mauderer.de>> wrote:
>> >
>> > On 20/12/2019 19:19, Niteesh wrote:
>> > > How do you test a patch? Do you checkout that particular commit
>> and
>> > > build and the BSP again?.
>> >
>> > Basically yes: You check out the version that you want fixed and
>> apply
>> > the patch. In that case I have gone back and forward a few times to
>> find
>> > the commit that introduced the second bug.
>> >
>> > > @Christian Mauderer <mailto:l...@c-mauderer.de
>> > <mailto:l...@c-mauderer.de>>  how did you build it
>> > > for the rpi1? Did you follow the steps as in previous threads?
>> >
>> > Basically the same steps like for every BSP:
>> > 1. Build a recent toolchain using RSB.
>> > 2. Build the BSP.
>> > 3. Test it on the board.
>> >
>> > For the rpi1 the BSP is "raspberrypi" instead of "raspberrypi2".
>> And I
>> > didn't install the BSP because I only wanted the tests and no extra
>> > application.
>> >
>> > For testing it I used the guide that you found: Objcopy into a
>> binary
>> > file and replace the kernel.img with it.
>> >
>> > > and how did you come to the conclusion that these changes cause
>> the
>> > > exceptions,
>> >
>> > I had a look at the history of the raspberry BSP (`gitk
>> > bsps/arm/raspberrypi` or `git log bsps/arm/raspberrypi`) and looked
>> for
>> > suspicious patches. For the raspberry there are not much patches in
>> the
>> > last year so that was quite easy. Then I just tested before and
>> after
>> > some of the patches to find the ones that introduced the bugs.
>> >
>> > Again: In this case it was necessary to backport Sebastians patch so
>> > that I have been able to test before / after the one that
>> introduces the
>> > exception.
>> >
>> > I haven't had a detailled look at the exception yet but I assume
>> it's
>> > some problem that the wrong variant is used or that my RPi1 is an
>> early
>> > model with less RAM or something like that.
>> >
>> > > as a beginner these ideas
>> > > will help in the future.
>> > > On Fri, Dec 20, 2019 at 2:46 PM Christian Mauderer
>> > mailto:l...@c-mauderer.de>
>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> wrote:
>> > >
>> > > On 20/12/2019 09:22, Christian Mauderer wrote:
>> > 

Re: raspberry BSP: Maybe there is a bug in the linker file?

[Niteesh]

Shall I start writing a driver for raspberrypi3 PL011?


On Sat, Dec 21, 2019 at 8:40 PM Christian Mauderer 
wrote:

> On 19/12/2019 15:05, Christian Mauderer wrote:
> > On 19/12/2019 14:27, Sebastian Huber wrote:
> >> On 19/12/2019 14:24, Christian Mauderer wrote:
> >>> Hello,
> >>>
> >>> triggered by the discussion regarding RTEMS on raspberrypi 3 I did some
> >>> tests. I haven't been able to start a RTEMS on my Pi 1 if I tried a
> >>> version after commit c5fd79cd4704a4270ba0114a1009ab8556f997c9 from
> >>> 29.07.2019. Right before it everything works as expected.
> >>>
> >>> The commit changes the memory locations. From what I understood, the
> >>> bootloader on a raspberry always jumps to address 0x8000 after loading
> >>> the application. So I'm not convinced that the change is correct.
> >>
> >> Is the 0x8000 a fixed address or you configure this in a boot image
> header?
> >>
> >
> >>From what I've seen the bootloader just uses a fixed address. All guides
> > that I've found just use objcopy to generate a binary from the elf files
> > without adding a header. For example a guide for RTEMS:
> >
> >
> >
> http://alanstechnotes.blogspot.com/2013/03/running-your-first-rtems-program-on.html
> >
> > A FreeRTOS port mentions this behavior explicitly in a comment in the
> > linker file:
> >
> >
> >
> https://github.com/jameswalmsley/RaspberryPi-FreeRTOS/blob/master/raspberrypi.ld#L17
> >
> > The "graphics processor" is no typo here. It seems the initialization is
> > really done by the graphics processor on the pi.
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
> I just found an option: It is possible to set a "kernel_address" in the
> config.txt:
>
>
> https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md
>
> So the start address can be changed and maybe the adaption to the linker
> file isn't necessary.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: raspberry BSP: Maybe there is a bug in the linker file?

[Niteesh]

There is already a PL011 driver in the arm shared section. should we just
import it?

On Sat, Dec 21, 2019 at 10:46 PM Niteesh  wrote:

> Shall I start writing a driver for raspberrypi3 PL011?
>
>
> On Sat, Dec 21, 2019 at 8:40 PM Christian Mauderer 
> wrote:
>
>> On 19/12/2019 15:05, Christian Mauderer wrote:
>> > On 19/12/2019 14:27, Sebastian Huber wrote:
>> >> On 19/12/2019 14:24, Christian Mauderer wrote:
>> >>> Hello,
>> >>>
>> >>> triggered by the discussion regarding RTEMS on raspberrypi 3 I did
>> some
>> >>> tests. I haven't been able to start a RTEMS on my Pi 1 if I tried a
>> >>> version after commit c5fd79cd4704a4270ba0114a1009ab8556f997c9 from
>> >>> 29.07.2019. Right before it everything works as expected.
>> >>>
>> >>> The commit changes the memory locations. From what I understood, the
>> >>> bootloader on a raspberry always jumps to address 0x8000 after loading
>> >>> the application. So I'm not convinced that the change is correct.
>> >>
>> >> Is the 0x8000 a fixed address or you configure this in a boot image
>> header?
>> >>
>> >
>> >>From what I've seen the bootloader just uses a fixed address. All guides
>> > that I've found just use objcopy to generate a binary from the elf files
>> > without adding a header. For example a guide for RTEMS:
>> >
>> >
>> >
>> http://alanstechnotes.blogspot.com/2013/03/running-your-first-rtems-program-on.html
>> >
>> > A FreeRTOS port mentions this behavior explicitly in a comment in the
>> > linker file:
>> >
>> >
>> >
>> https://github.com/jameswalmsley/RaspberryPi-FreeRTOS/blob/master/raspberrypi.ld#L17
>> >
>> > The "graphics processor" is no typo here. It seems the initialization is
>> > really done by the graphics processor on the pi.
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>> >
>>
>> I just found an option: It is possible to set a "kernel_address" in the
>> config.txt:
>>
>>
>> https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md
>>
>> So the start address can be changed and maybe the adaption to the linker
>> file isn't necessary.
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: raspberry BSP: Maybe there is a bug in the linker file?

[Niteesh]

On inspecting the code, the driver is for PL011. We have to write a driver
for the mini uart.
which we will have start from scratch. So, how do you want the structure to
be?

The code of PL011 can be improved. We could use gpio functions to configure
pins.
And also many of the UART values are set in place instead of using the
appropriate function, for example
the usart_set_baud is empty and the baud rate is set directly in the init
function.
What do you think about these changes? Should we change them also?
On Sun, Dec 22, 2019 at 12:25 AM Christian Mauderer 
wrote:

> On 21/12/2019 19:26, Niteesh wrote:
> > There is already a PL011 driver in the arm shared section. should we
> > just import it?
>
> If you say "import" and you mean "use" and not "copy": yes, that would
> be great.
>
> >
> > On Sat, Dec 21, 2019 at 10:46 PM Niteesh  > <mailto:gsnb...@gmail.com>> wrote:
> >
> > Shall I start writing a driver for raspberrypi3 PL011?
> >
> >
> > On Sat, Dec 21, 2019 at 8:40 PM Christian Mauderer
> > mailto:l...@c-mauderer.de>> wrote:
> >
> > On 19/12/2019 15:05, Christian Mauderer wrote:
> > > On 19/12/2019 14:27, Sebastian Huber wrote:
> > >> On 19/12/2019 14:24, Christian Mauderer wrote:
> > >>> Hello,
> > >>>
> > >>> triggered by the discussion regarding RTEMS on raspberrypi 3
> > I did some
> > >>> tests. I haven't been able to start a RTEMS on my Pi 1 if I
> > tried a
> > >>> version after commit
> > c5fd79cd4704a4270ba0114a1009ab8556f997c9 from
> > >>> 29.07.2019. Right before it everything works as expected.
> > >>>
> > >>> The commit changes the memory locations. From what I
> > understood, the
> > >>> bootloader on a raspberry always jumps to address 0x8000
> > after loading
> > >>> the application. So I'm not convinced that the change is
> > correct.
> > >>
> > >> Is the 0x8000 a fixed address or you configure this in a boot
> > image header?
> > >>
> > >
> > >>From what I've seen the bootloader just uses a fixed address.
> > All guides
> > > that I've found just use objcopy to generate a binary from the
> > elf files
> > > without adding a header. For example a guide for RTEMS:
> > >
> > >
> > >
> >
> http://alanstechnotes.blogspot.com/2013/03/running-your-first-rtems-program-on.html
> > >
> > > A FreeRTOS port mentions this behavior explicitly in a comment
> > in the
> > > linker file:
> > >
> > >
> > >
> >
> https://github.com/jameswalmsley/RaspberryPi-FreeRTOS/blob/master/raspberrypi.ld#L17
> > >
> > > The "graphics processor" is no typo here. It seems the
> > initialization is
> > > really done by the graphics processor on the pi.
> > > ___
> > > devel mailing list
> > > devel@rtems.org <mailto:devel@rtems.org>
> > > http://lists.rtems.org/mailman/listinfo/devel
> > >
> >
> > I just found an option: It is possible to set a "kernel_address"
> > in the
> > config.txt:
> >
> >
> >
> https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md
> >
> > So the start address can be changed and maybe the adaption to
> > the linker
> > file isn't necessary.
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: raspberry BSP: Maybe there is a bug in the linker file?

[Niteesh]

On raspberry pis equipped with the wireless/Bluetooth module, the PL011 is
connected to the Bluetooth module,
and the mini UART is used as the primary UART. On all other models, the
PL011 is used as the primary UART.

The mini UART has smaller FIFOs. Combined with the lack of flow control,
this makes it more prone to losing characters at higher baudrates. It is
also generally less capable than the PL011, mainly due to its baud rate
link to the VPU clock speed.

The particular deficiencies of the mini UART compared to the PL011 are :

No break detection
No framing errors detection
No parity bit
No receive timeout interrupt
No DCD, DSR, DTR or RI signals

https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
the official doc from broadcom, this is what I used while developing
drivers for bare metal project.



On Sun, Dec 22, 2019 at 1:56 AM Christian Mauderer 
wrote:

> I haven't had a look at the different types of UARTS yet. What is the
> difference? What do you use as reference?
>
> If it is just a variant of an existing driver, the existing one should
> be extended to support both variants.
>
> On 21/12/2019 20:45, Niteesh wrote:
> > On inspecting the code, the driver is for PL011. We have to write a
> > driver for the mini uart.
> > which we will have start from scratch. So, how do you want the structure
> > to be?
> >
> > The code of PL011 can be improved. We could use gpio functions to
> > configure pins.
> > And also many of the UART values are set in place instead of using the
> > appropriate function, for example
> > the usart_set_baud is empty and the baud rate is set directly in the
> > init function.
> > What do you think about these changes? Should we change them also?
> > On Sun, Dec 22, 2019 at 12:25 AM Christian Mauderer  > <mailto:l...@c-mauderer.de>> wrote:
> >
> > On 21/12/2019 19:26, Niteesh wrote:
> > > There is already a PL011 driver in the arm shared section. should
> we
> > > just import it?
> >
> > If you say "import" and you mean "use" and not "copy": yes, that
> would
> > be great.
> >
> > >
> > > On Sat, Dec 21, 2019 at 10:46 PM Niteesh  > <mailto:gsnb...@gmail.com>
> > > <mailto:gsnb...@gmail.com <mailto:gsnb...@gmail.com>>> wrote:
> > >
> > > Shall I start writing a driver for raspberrypi3 PL011?
> > >
> > >
> > > On Sat, Dec 21, 2019 at 8:40 PM Christian Mauderer
> > > mailto:l...@c-mauderer.de>
> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> wrote:
> > >
> > > On 19/12/2019 15:05, Christian Mauderer wrote:
> > > > On 19/12/2019 14:27, Sebastian Huber wrote:
> > > >> On 19/12/2019 14:24, Christian Mauderer wrote:
> > > >>> Hello,
> > > >>>
> > > >>> triggered by the discussion regarding RTEMS on
> > raspberrypi 3
> > > I did some
> > > >>> tests. I haven't been able to start a RTEMS on my Pi 1
> > if I
> > > tried a
> > > >>> version after commit
> > > c5fd79cd4704a4270ba0114a1009ab8556f997c9 from
> > > >>> 29.07.2019. Right before it everything works as
> expected.
> > > >>>
> > > >>> The commit changes the memory locations. From what I
> > > understood, the
> > > >>> bootloader on a raspberry always jumps to address
> 0x8000
> > > after loading
> > > >>> the application. So I'm not convinced that the change
> is
> > > correct.
> > > >>
> > > >> Is the 0x8000 a fixed address or you configure this in
> > a boot
> > > image header?
> > > >>
> > > >
> > > >>From what I've seen the bootloader just uses a fixed
> > address.
> > > All guides
> > > > that I've found just use objcopy to generate a binary
> > from the
> > > elf files
> > > > without adding a header. For example a guide for RTEMS:
> > > >
> > > >
> > > >
> > >
&g

Raspberrypi3: Mini UART driver

[Niteesh]

The rpi1 and rpi2 use the PL011 UART, whereas, with RPI's equipped with
wireless/Bluetooth module, the PL011 is connected to the Bluetooth module,
and the mini UART is used as the primary UART.

https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
But from the above doc (PAGE 10), the mini uart has 16550 like registers
and RTEMS already has the driver for it bsps/shared/dev/serial/ns16550.c.
But I am not sure how compatible they are? Should a new driver be
implemented from scratch or use ns16550 if possible?

Also, the core clock on which the PL011 is based on is changed in rpi3.
Rpi1 and 2 use 250Mhz as the default clock but it was changed to 400Mhz in
Rpi3 and newer

Few differences between PL011 and Mini uart
The mini UART has smaller FIFOs. Combined with the lack of flow control,
this makes it more prone to losing characters at higher baud rates. It is
also generally less capable than the PL011, mainly due to its baud rate
link to the VPU clock speed.

The particular deficiencies of the mini UART compared to the PL011 are :

No break detection
No framing errors detection
No parity bit
No receive timeout interrupt
No DCD, DSR, DTR or RI signals
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Raspberrypi3: Mini UART driver

[Niteesh]

On Sun, Dec 22, 2019 at 8:44 PM Christian Mauderer 
wrote:

> Hello Niteesh,
>
> thanks for doing that work.
>
> On 22/12/2019 12:10, Niteesh wrote:
> > The rpi1 and rpi2 use the PL011 UART, whereas, with RPI's equipped with
> > wireless/Bluetooth module, the PL011 is connected to the Bluetooth
> > module, and the mini UART is used as the primary UART.
>
> In my opinion it would be great if you could use the FDT to distinguish
> between the boards. That should allow to add raspberry 3 (and maybe 4)
> support without adding another BSP. More BSPs mean a bigger maintenance
> effort for the RTEMS community.

Learning more about FDT is on my list for a long time.  I would love to
work on that
but I have almost no exp with FDT's.
But another thing could also be done, in raspberrypi/start/bspstart.c we
get the revision and
model of the board using the mailbox. Every board has a unique id, which we
could use to initialize
the BSP. But using FDT seems to be a more elegant option, it is a lot of
work I think, but we could take
help from libbsd and linux I suppose. What do you think?

> >
> >
> https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
> > But from the above doc (PAGE 10), the mini uart has 16550 like registers
> > and RTEMS already has the driver for it
> > bsps/shared/dev/serial/ns16550.c. But I am not sure how compatible they
> > are? Should a new driver be implemented from scratch or use ns16550 if
> > possible?
>
> In general it's better to re-use existing code. That has multiple
> advantages:
>
> - It reduces the maintenance effort. Fewer code means fewer work.
> - If you have multiple driver for the same or similar hardware it can
> happen that a bug is fixed in one but not the other.
> - It's simpler to find a hardware to test changes.
> - The driver becomes more universal with every new supported hardware.
> That increases the chance that it fits the next new hardware.
>
> I'm sure there are some more if you ask someone else.

I do understand the issues, I just spent some time reading the driver code.
I think we could most probably use it. I will take a closer look and will
update.

>
>
>
> > Also, the core clock on which the PL011 is based on is changed in rpi3.
> > Rpi1 and 2 use 250Mhz as the default clock but it was changed to 400Mhz
> > in Rpi3 and newer
>
> Again: Would be great if that could be adapted based on FDT or by
> reading the right registers.
>
> >
> > Few differences between PL011 and Mini uart
> > The mini UART has smaller FIFOs. Combined with the lack of flow control,
> > this makes it more prone to losing characters at higher baud rates. It
> > is also generally less capable than the PL011, mainly due to its baud
> > rate link to the VPU clock speed.
>
> That shouldn't really be a problem for the system console.
>
> >
> > The particular deficiencies of the mini UART compared to the PL011 are :
> >
> > No break detection
> > No framing errors detection
> > No parity bit
> > No receive timeout interrupt
> > No DCD, DSR, DTR or RI signals
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Raspberrypi3: Mini UART driver

[Niteesh]

I would like to clarify my doubts regarding the console driver. I went
through the documentation
for the console driver
https://docs.rtems.org/branches/master/bsp-howto/console.html#introduction.
But it is quite different from how some BSPs initialize.
Correct me if I am wrong
The console_tbl contains the various entries of serial ports.
The console_fns is a struct of function pointers, which point to the BSP
uart functions.
The BSP_output_char_function_type is what will be called for printing a
char on to the console.
How does RTEMS initialize the uart? It's seems not to be same for all BSPs.
The doc says that the driver's initialization function is called once
during the rtems initialization process.
The console init function install the serial driver using
rtems_termios_device_install but there seems to be
no such function in the raspberry pi? But there is a entry in console_fns
for init function, but then how does it
gets called?
And for BSP's with multiple serial's, the output function chooses the right
serial using console_port_minor,
Is it during initialization?
What is the need for get and set register functions?

On Mon, Dec 23, 2019 at 1:04 AM Christian Mauderer 
wrote:

> On 22/12/2019 19:45, Joel Sherrill wrote:
> >
> >
> > On Sun, Dec 22, 2019, 12:29 PM Niteesh  > <mailto:gsnb...@gmail.com>> wrote:
> >
> > On Sun, Dec 22, 2019 at 8:44 PM Christian Mauderer
> > mailto:l...@c-mauderer.de>> wrote:
> >
> > Hello Niteesh,
> >
> > thanks for doing that work.
> >
> > On 22/12/2019 12:10, Niteesh wrote:
> > > The rpi1 and rpi2 use the PL011 UART, whereas, with RPI's
> > equipped with
> > > wireless/Bluetooth module, the PL011 is connected to the
> Bluetooth
> > > module, and the mini UART is used as the primary UART.
> >
> > In my opinion it would be great if you could use the FDT to
> > distinguish
> > between the boards. That should allow to add raspberry 3 (and
> > maybe 4)
> > support without adding another BSP. More BSPs mean a bigger
> > maintenance
> > effort for the RTEMS community.
> >
> > Learning more about FDT is on my list for a long time.  I would love
> > to work on that
> > but I have almost no exp with FDT's.
> > But another thing could also be done, in
> > raspberrypi/start/bspstart.c we get the revision and
> > model of the board using the mailbox. Every board has a unique id,
> > which we could use to initialize
> > the BSP. But using FDT seems to be a more elegant option, it is a
> > lot of work I think, but we could take
> > help from libbsd and linux I suppose. What do you think?
> >
> >
> > I think there are almost always two steps to a project like this: get it
> > to work and make it nice. :)
> >
> > If you fix the startup code to read the board revision and memory size,
> > you can get a working BSP that dynamically adapts to the models and
> > memory variations with minimal modifications. If you want to then
> > convert the BSP to FDT, it will be a LOT easier to debug with a working
> BSP.
> >
> > Plus you may be able to identify every variation point based on just the
> > model info. Then FDT is just a matter of switching the source of
> > some/all of the info.
> >
> > That would be my work plan anyway.
>
> I agree with Joel that a secure development basis (also known as "hack")
> as a first step is a good idea. You maybe even just make the mini UART
> the default driver while you are developing. Then you can be sure that
> you have the right driver.
>
> As soon as that works you can either change to the revision method or
> (better) to the FDT one and after that the patches can be merged. Using
> the FDT isn't that complicated. Basically you search for a node based on
> different parameters. For an example you can take a look at the imx BSP.
> In imx_uart_probe (bsps/arm/imx/console/console-config.c) a fdt node is
> searched and based on that a UART driver is used. But again: Follow
> Joels suggestion to start simple and secure.
>
> >
> > >
> > >
> >
> https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
> > > But from the above doc (PAGE 10), the mini uart has 16550 like
> > registers
> > > and RTEMS already has the driver for it
> > > bsps/shared/dev/serial/ns16550.c. But I am not sure how
> > compatible they
> > > are? Should

Re: Raspberrypi3: Mini UART driver

[Niteesh]

Is the correct port minor number set during the initialization? What is the
application want's to
access some other port?

On Tue, Dec 24, 2019 at 12:16 AM Niteesh  wrote:

> I would like to clarify my doubts regarding the console driver. I went
> through the documentation
> for the console driver
> https://docs.rtems.org/branches/master/bsp-howto/console.html#introduction
> .
> But it is quite different from how some BSPs initialize.
> Correct me if I am wrong
> The console_tbl contains the various entries of serial ports.
> The console_fns is a struct of function pointers, which point to the BSP
> uart functions.
> The BSP_output_char_function_type is what will be called for printing a
> char on to the console.
> How does RTEMS initialize the uart? It's seems not to be same for all BSPs.
> The doc says that the driver's initialization function is called once
> during the rtems initialization process.
> The console init function install the serial driver using
> rtems_termios_device_install but there seems to be
> no such function in the raspberry pi? But there is a entry in console_fns
> for init function, but then how does it
> gets called?
> And for BSP's with multiple serial's, the output function chooses the
> right serial using console_port_minor,
> Is it during initialization?
> What is the need for get and set register functions?
>
> On Mon, Dec 23, 2019 at 1:04 AM Christian Mauderer 
> wrote:
>
>> On 22/12/2019 19:45, Joel Sherrill wrote:
>> >
>> >
>> > On Sun, Dec 22, 2019, 12:29 PM Niteesh > > <mailto:gsnb...@gmail.com>> wrote:
>> >
>> > On Sun, Dec 22, 2019 at 8:44 PM Christian Mauderer
>> > mailto:l...@c-mauderer.de>> wrote:
>> >
>> > Hello Niteesh,
>> >
>> > thanks for doing that work.
>> >
>> > On 22/12/2019 12:10, Niteesh wrote:
>> > > The rpi1 and rpi2 use the PL011 UART, whereas, with RPI's
>> > equipped with
>> > > wireless/Bluetooth module, the PL011 is connected to the
>> Bluetooth
>> > > module, and the mini UART is used as the primary UART.
>> >
>> > In my opinion it would be great if you could use the FDT to
>> > distinguish
>> > between the boards. That should allow to add raspberry 3 (and
>> > maybe 4)
>> > support without adding another BSP. More BSPs mean a bigger
>> > maintenance
>> > effort for the RTEMS community.
>> >
>> > Learning more about FDT is on my list for a long time.  I would love
>> > to work on that
>> > but I have almost no exp with FDT's.
>> > But another thing could also be done, in
>> > raspberrypi/start/bspstart.c we get the revision and
>> > model of the board using the mailbox. Every board has a unique id,
>> > which we could use to initialize
>> > the BSP. But using FDT seems to be a more elegant option, it is a
>> > lot of work I think, but we could take
>> > help from libbsd and linux I suppose. What do you think?
>> >
>> >
>> > I think there are almost always two steps to a project like this: get it
>> > to work and make it nice. :)
>> >
>> > If you fix the startup code to read the board revision and memory size,
>> > you can get a working BSP that dynamically adapts to the models and
>> > memory variations with minimal modifications. If you want to then
>> > convert the BSP to FDT, it will be a LOT easier to debug with a working
>> BSP.
>> >
>> > Plus you may be able to identify every variation point based on just the
>> > model info. Then FDT is just a matter of switching the source of
>> > some/all of the info.
>> >
>> > That would be my work plan anyway.
>>
>> I agree with Joel that a secure development basis (also known as "hack")
>> as a first step is a good idea. You maybe even just make the mini UART
>> the default driver while you are developing. Then you can be sure that
>> you have the right driver.
>>
>> As soon as that works you can either change to the revision method or
>> (better) to the FDT one and after that the patches can be merged. Using
>> the FDT isn't that complicated. Basically you search for a node based on
>> different parameters. For an example you can take a look at the imx BSP.
>> In imx_uart_probe (bsps/arm/imx/console/console-config.c) a fdt node is
>> 

Re: Raspberrypi3: Mini UART driver

[Niteesh]

And finally, how does printf work? It is a macro? In that case, how does
any write to
a console work?

On Tue, Dec 24, 2019 at 12:18 AM Niteesh  wrote:

> Is the correct port minor number set during the initialization? What is
> the application want's to
> access some other port?
>
> On Tue, Dec 24, 2019 at 12:16 AM Niteesh  wrote:
>
>> I would like to clarify my doubts regarding the console driver. I went
>> through the documentation
>> for the console driver
>> https://docs.rtems.org/branches/master/bsp-howto/console.html#introduction
>> .
>> But it is quite different from how some BSPs initialize.
>> Correct me if I am wrong
>> The console_tbl contains the various entries of serial ports.
>> The console_fns is a struct of function pointers, which point to the BSP
>> uart functions.
>> The BSP_output_char_function_type is what will be called for printing a
>> char on to the console.
>> How does RTEMS initialize the uart? It's seems not to be same for all
>> BSPs.
>> The doc says that the driver's initialization function is called once
>> during the rtems initialization process.
>> The console init function install the serial driver using
>> rtems_termios_device_install but there seems to be
>> no such function in the raspberry pi? But there is a entry in console_fns
>> for init function, but then how does it
>> gets called?
>> And for BSP's with multiple serial's, the output function chooses the
>> right serial using console_port_minor,
>> Is it during initialization?
>> What is the need for get and set register functions?
>>
>> On Mon, Dec 23, 2019 at 1:04 AM Christian Mauderer 
>> wrote:
>>
>>> On 22/12/2019 19:45, Joel Sherrill wrote:
>>> >
>>> >
>>> > On Sun, Dec 22, 2019, 12:29 PM Niteesh >> > <mailto:gsnb...@gmail.com>> wrote:
>>> >
>>> > On Sun, Dec 22, 2019 at 8:44 PM Christian Mauderer
>>> > mailto:l...@c-mauderer.de>> wrote:
>>> >
>>> > Hello Niteesh,
>>> >
>>> > thanks for doing that work.
>>> >
>>> > On 22/12/2019 12:10, Niteesh wrote:
>>> > > The rpi1 and rpi2 use the PL011 UART, whereas, with RPI's
>>> > equipped with
>>> > > wireless/Bluetooth module, the PL011 is connected to the
>>> Bluetooth
>>> > > module, and the mini UART is used as the primary UART.
>>> >
>>> > In my opinion it would be great if you could use the FDT to
>>> > distinguish
>>> > between the boards. That should allow to add raspberry 3 (and
>>> > maybe 4)
>>> > support without adding another BSP. More BSPs mean a bigger
>>> > maintenance
>>> > effort for the RTEMS community.
>>> >
>>> > Learning more about FDT is on my list for a long time.  I would
>>> love
>>> > to work on that
>>> > but I have almost no exp with FDT's.
>>> > But another thing could also be done, in
>>> > raspberrypi/start/bspstart.c we get the revision and
>>> > model of the board using the mailbox. Every board has a unique id,
>>> > which we could use to initialize
>>> > the BSP. But using FDT seems to be a more elegant option, it is a
>>> > lot of work I think, but we could take
>>> > help from libbsd and linux I suppose. What do you think?
>>> >
>>> >
>>> > I think there are almost always two steps to a project like this: get
>>> it
>>> > to work and make it nice. :)
>>> >
>>> > If you fix the startup code to read the board revision and memory size,
>>> > you can get a working BSP that dynamically adapts to the models and
>>> > memory variations with minimal modifications. If you want to then
>>> > convert the BSP to FDT, it will be a LOT easier to debug with a
>>> working BSP.
>>> >
>>> > Plus you may be able to identify every variation point based on just
>>> the
>>> > model info. Then FDT is just a matter of switching the source of
>>> > some/all of the info.
>>> >
>>> > That would be my work plan anyway.
>>>
>>> I agree with Joel that a secure development basis (also known as "hack")
>>> as a first step is a good idea. You maybe even just make the

Re: Raspberrypi3: Mini UART driver

[Niteesh]

Thank you so much, for such a detailed answer. Now things make really good
sense to me,
going through the code now is just a breeze. But I still have one question
for the newer driver interface is console_initialize the function which
RTEMS calls while initializing
the console? Which means I can't mess with the name right? It is similar to
the main function, right?

The current driver is a legacy one, how do you want me to proceed, shall I
rewrite the legacy to a
the new one, this is will be a great learning experience for me also and we
also get the BSP updated to the latest interface.


On Tue, Dec 24, 2019 at 3:20 AM Christian Mauderer 
wrote:

> Hello Niteesh,
>
> quite a lot of questions. I'll try to answer them. Note that it has been
> some time since I had a detailed look at that code so if something I
> tell seems odd please don't hesitate to question it.
>
> Please note that in RTEMS their are more or less two "levels" of support
> for a serial console:
>
> 1. A very basic polled system console (also known as "debug-console" in
> some BSPs). This one is used for printk and should work in basically
> every case. It is used for critical system messages like printing the
> exception frame. For that a BSP has to provide a "BSP_output_char"
> function.
>
> 2. A full featured UART driver integrated into Termios. That one will be
> used for all normal I/O on the UARTs.
>
> As far as I know the "console_tbl Console_Configuration_Ports" belongs
> to a table based legacy interface. It is handled in the file
> bsps/shared/dev/serial/legacy-console.c. I'm not sure whether it is
> documented in the BSP guide because it shouldn't be used for new BSPs.
> Same is true for the "major" and "minor" stuff: It's not really used for
> new drivers.
>
> Newer drivers use the initialization that is described in the manual
> that you have already found. Basically they use
> "rtems_termios_device_install" to register a new UART as
> "/dev/ttySomething". Some recent (ARM) BSPs that do that are the imx or
> the atsam.
>
> The console that is used for stdin, stdout and stderr (printf, scanf,
> ...) is the one called "/dev/console" (defined in CONSOLE_DEVICE_NAME).
> For the legacy table based interface it's the one with the index of
> "Console_Port_Minor".
>
>
> If you want to access any UART other than the one for stdin and stdout
> you do that the same way like on Linux: Just use the "open" function on
> the "/dev/ttySomething" and use "read", "write" and simmilar or use
> "fopen" together with "fread", "fwrite", "fprintf", ...
>
>
> "printf" (and family) is a function belonging to the C library. In our
> case that's newlib. It will format your message and after some other
> preprocessing will call the "write" function of the file that is opened
> as stdout (which is "/dev/console" in the default case).
>
>
> I hope that I helped you with that explanation. Please feel free to ask
> anything if it isn't clear.
>
> Best regards
>
> Christian
>
> On 23/12/2019 19:50, Niteesh wrote:
> > And finally, how does printf work? It is a macro? In that case, how does
> > any write to
> > a console work?
> >
> > On Tue, Dec 24, 2019 at 12:18 AM Niteesh  > <mailto:gsnb...@gmail.com>> wrote:
> >
> > Is the correct port minor number set during the initialization? What
> > is the application want's to
> > access some other port?
> >
> > On Tue, Dec 24, 2019 at 12:16 AM Niteesh  > <mailto:gsnb...@gmail.com>> wrote:
> >
> > I would like to clarify my doubts regarding the console driver.
> > I went through the documentation
> > for the console
> > driver
> https://docs.rtems.org/branches/master/bsp-howto/console.html#introduction
> .
> > But it is quite different from how some BSPs initialize.
> > Correct me if I am wrong
> > The console_tbl contains the various entries of serial ports.
> > The console_fns is a struct of function pointers, which point to
> > the BSP uart functions.
> > The BSP_output_char_function_type is what will be called for
> > printing a char on to the console.
> > How does RTEMS initialize the uart? It's seems not to be same
> > for all BSPs.
> > The doc says that the driver's initialization function is called
> > once during the rtems initialization pro

Re: Raspberrypi3: Mini UART driver

[Niteesh]

The current raspi console section is like this:
The bsp_console_select in console_select.c is responsible for selecting
between uart and the framebuffer. It does so
by setting the Console_port_minor.
The console_config is responsible for output_char function.
And other files are driver code.
If rewriting, this would be my approach,
Rewrite the bsp_console_select to set some kind of a variable like in IMX,
then in console_initialize function
link the right driver to /dev/console.
Replace the console_tbl with the device_context and console_fns with
termios_device_handlers and
finally add in the console_initialization function.

On Tue, Dec 24, 2019 at 2:13 PM Niteesh  wrote:

> Thank you so much, for such a detailed answer. Now things make really good
> sense to me,
> going through the code now is just a breeze. But I still have one question
> for the newer driver interface is console_initialize the function which
> RTEMS calls while initializing
> the console? Which means I can't mess with the name right? It is similar
> to the main function, right?
>
> The current driver is a legacy one, how do you want me to proceed, shall I
> rewrite the legacy to a
> the new one, this is will be a great learning experience for me also and
> we also get the BSP updated to the latest interface.
>
>
> On Tue, Dec 24, 2019 at 3:20 AM Christian Mauderer 
> wrote:
>
>> Hello Niteesh,
>>
>> quite a lot of questions. I'll try to answer them. Note that it has been
>> some time since I had a detailed look at that code so if something I
>> tell seems odd please don't hesitate to question it.
>>
>> Please note that in RTEMS their are more or less two "levels" of support
>> for a serial console:
>>
>> 1. A very basic polled system console (also known as "debug-console" in
>> some BSPs). This one is used for printk and should work in basically
>> every case. It is used for critical system messages like printing the
>> exception frame. For that a BSP has to provide a "BSP_output_char"
>> function.
>>
>> 2. A full featured UART driver integrated into Termios. That one will be
>> used for all normal I/O on the UARTs.
>>
>> As far as I know the "console_tbl Console_Configuration_Ports" belongs
>> to a table based legacy interface. It is handled in the file
>> bsps/shared/dev/serial/legacy-console.c. I'm not sure whether it is
>> documented in the BSP guide because it shouldn't be used for new BSPs.
>> Same is true for the "major" and "minor" stuff: It's not really used for
>> new drivers.
>>
>> Newer drivers use the initialization that is described in the manual
>> that you have already found. Basically they use
>> "rtems_termios_device_install" to register a new UART as
>> "/dev/ttySomething". Some recent (ARM) BSPs that do that are the imx or
>> the atsam.
>>
>> The console that is used for stdin, stdout and stderr (printf, scanf,
>> ...) is the one called "/dev/console" (defined in CONSOLE_DEVICE_NAME).
>> For the legacy table based interface it's the one with the index of
>> "Console_Port_Minor".
>>
>>
>> If you want to access any UART other than the one for stdin and stdout
>> you do that the same way like on Linux: Just use the "open" function on
>> the "/dev/ttySomething" and use "read", "write" and simmilar or use
>> "fopen" together with "fread", "fwrite", "fprintf", ...
>>
>>
>> "printf" (and family) is a function belonging to the C library. In our
>> case that's newlib. It will format your message and after some other
>> preprocessing will call the "write" function of the file that is opened
>> as stdout (which is "/dev/console" in the default case).
>>
>>
>> I hope that I helped you with that explanation. Please feel free to ask
>> anything if it isn't clear.
>>
>> Best regards
>>
>> Christian
>>
>> On 23/12/2019 19:50, Niteesh wrote:
>> > And finally, how does printf work? It is a macro? In that case, how does
>> > any write to
>> > a console work?
>> >
>> > On Tue, Dec 24, 2019 at 12:18 AM Niteesh > > <mailto:gsnb...@gmail.com>> wrote:
>> >
>> > Is the correct port minor number set during the initialization? What
>> > is the application want's to
>> > access some other port?
>> >
>> > On Tue, Dec 24, 2019 at 12:16 AM Niteesh > > <mailto:gsnb.

Re: Raspberrypi3: Mini UART driver

[Niteesh]

How to handle different serial devices? In other BSPs the uart devices are
the same, so
they were able to put it under a single array? But here we have 2 uarts and
a FB?


On Tue, Dec 24, 2019 at 8:18 PM Christian Mauderer 
wrote:

> On 24/12/2019 12:06, Niteesh wrote:
> > The current raspi console section is like this:
> > The bsp_console_select in console_select.c is responsible for selecting
> > between uart and the framebuffer. It does so
> > by setting the Console_port_minor.
> > The console_config is responsible for output_char function.
> > And other files are driver code.
> > If rewriting, this would be my approach,
> > Rewrite the bsp_console_select to set some kind of a variable like in
> > IMX, then in console_initialize function
> > link the right driver to /dev/console.
> > Replace the console_tbl with the device_context and console_fns with
> > termios_device_handlers and
> > finally add in the console_initialization function.
>
> I agree that this would be a clean solution. So if you want you can do
> that. But there might is a hurdle: As far as I understood you you only
> have a Pi3? So you might have a hard time testing the changes. Maybe the
> simulator could work.
>
> Another possibility could be to set the "Console_port_minor" to
> something unused (for example -1). In that case you can define another
> /dev/console.
>
> Best regards and merry Christmas (in case you celebrate)
>
> Christian
>
> >
> > On Tue, Dec 24, 2019 at 2:13 PM Niteesh  > <mailto:gsnb...@gmail.com>> wrote:
> >
> > Thank you so much, for such a detailed answer. Now things make
> > really good sense to me,
> > going through the code now is just a breeze. But I still have one
> > question
> > for the newer driver interface is console_initialize the function
> > which RTEMS calls while initializing
> > the console? Which means I can't mess with the name right? It is
> > similar to the main function, right?
> >
> > The current driver is a legacy one, how do you want me to proceed,
> > shall I rewrite the legacy to a
> > the new one, this is will be a great learning experience for me also
> > and we also get the BSP updated to the latest interface.
> >
> >
> > On Tue, Dec 24, 2019 at 3:20 AM Christian Mauderer
> > mailto:l...@c-mauderer.de>> wrote:
> >
> > Hello Niteesh,
> >
> > quite a lot of questions. I'll try to answer them. Note that it
> > has been
> > some time since I had a detailed look at that code so if
> something I
> > tell seems odd please don't hesitate to question it.
> >
> > Please note that in RTEMS their are more or less two "levels" of
> > support
> > for a serial console:
> >
> > 1. A very basic polled system console (also known as
> > "debug-console" in
> > some BSPs). This one is used for printk and should work in
> basically
> > every case. It is used for critical system messages like
> > printing the
> > exception frame. For that a BSP has to provide a
> > "BSP_output_char" function.
> >
> > 2. A full featured UART driver integrated into Termios. That one
> > will be
> > used for all normal I/O on the UARTs.
> >
> > As far as I know the "console_tbl Console_Configuration_Ports"
> > belongs
> > to a table based legacy interface. It is handled in the file
> > bsps/shared/dev/serial/legacy-console.c. I'm not sure whether it
> is
> > documented in the BSP guide because it shouldn't be used for new
> > BSPs.
> > Same is true for the "major" and "minor" stuff: It's not really
> > used for
> > new drivers.
> >
> > Newer drivers use the initialization that is described in the
> manual
> > that you have already found. Basically they use
> > "rtems_termios_device_install" to register a new UART as
> > "/dev/ttySomething". Some recent (ARM) BSPs that do that are the
> > imx or
> > the atsam.
> >
> > The console that is used for stdin, stdout and stderr (printf,
> > scanf,
> > ...) is the one called "/dev/console" (defined in
> > CONSOLE_DEVICE_NAME).
> > For the legacy table based interf

Re: Raspberrypi3: Mini UART driver

[Niteesh]

And also the register definitions are in raspberrpi.h file should I move
them to usart.h.
I have a doubt we have a register field in device_context
typedef struct {

rtems_termios_device_context base;

const char *device_name;

volatile some_chip_registers *regs;

} my_driver_context;

How does the reg field point to the correct memory location? for instance
in IMX BSP,
there is a struct with register field's but none of the define a memory
location?

On Tue, Dec 24, 2019 at 11:37 PM Niteesh  wrote:

> How to handle different serial devices? In other BSPs the uart devices are
> the same, so
> they were able to put it under a single array? But here we have 2 uarts
> and a FB?
>
>
> On Tue, Dec 24, 2019 at 8:18 PM Christian Mauderer 
> wrote:
>
>> On 24/12/2019 12:06, Niteesh wrote:
>> > The current raspi console section is like this:
>> > The bsp_console_select in console_select.c is responsible for selecting
>> > between uart and the framebuffer. It does so
>> > by setting the Console_port_minor.
>> > The console_config is responsible for output_char function.
>> > And other files are driver code.
>> > If rewriting, this would be my approach,
>> > Rewrite the bsp_console_select to set some kind of a variable like in
>> > IMX, then in console_initialize function
>> > link the right driver to /dev/console.
>> > Replace the console_tbl with the device_context and console_fns with
>> > termios_device_handlers and
>> > finally add in the console_initialization function.
>>
>> I agree that this would be a clean solution. So if you want you can do
>> that. But there might is a hurdle: As far as I understood you you only
>> have a Pi3? So you might have a hard time testing the changes. Maybe the
>> simulator could work.
>>
>> Another possibility could be to set the "Console_port_minor" to
>> something unused (for example -1). In that case you can define another
>> /dev/console.
>>
>> Best regards and merry Christmas (in case you celebrate)
>>
>> Christian
>>
>> >
>> > On Tue, Dec 24, 2019 at 2:13 PM Niteesh > > <mailto:gsnb...@gmail.com>> wrote:
>> >
>> > Thank you so much, for such a detailed answer. Now things make
>> > really good sense to me,
>> > going through the code now is just a breeze. But I still have one
>> > question
>> > for the newer driver interface is console_initialize the function
>> > which RTEMS calls while initializing
>> > the console? Which means I can't mess with the name right? It is
>> > similar to the main function, right?
>> >
>> > The current driver is a legacy one, how do you want me to proceed,
>> > shall I rewrite the legacy to a
>> > the new one, this is will be a great learning experience for me also
>> > and we also get the BSP updated to the latest interface.
>> >
>> >
>> > On Tue, Dec 24, 2019 at 3:20 AM Christian Mauderer
>> > mailto:l...@c-mauderer.de>> wrote:
>> >
>> > Hello Niteesh,
>> >
>> > quite a lot of questions. I'll try to answer them. Note that it
>> > has been
>> > some time since I had a detailed look at that code so if
>> something I
>> > tell seems odd please don't hesitate to question it.
>> >
>> > Please note that in RTEMS their are more or less two "levels" of
>> > support
>> > for a serial console:
>> >
>> > 1. A very basic polled system console (also known as
>> > "debug-console" in
>> > some BSPs). This one is used for printk and should work in
>> basically
>> > every case. It is used for critical system messages like
>> > printing the
>> > exception frame. For that a BSP has to provide a
>> > "BSP_output_char" function.
>> >
>> > 2. A full featured UART driver integrated into Termios. That one
>> > will be
>> > used for all normal I/O on the UARTs.
>> >
>> > As far as I know the "console_tbl Console_Configuration_Ports"
>> > belongs
>> > to a table based legacy interface. It is handled in the file
>> > bsps/shared/dev/serial/legacy-console.c. I'm not sure whether
>> it is
>> > documented in the BSP guide because it should

Re: Raspberrypi3: Mini UART driver

[Niteesh]

I figured the register part, it is setting itself through the FDT.

On Tue, Dec 24, 2019 at 11:49 PM Niteesh  wrote:

> And also the register definitions are in raspberrpi.h file should I move
> them to usart.h.
> I have a doubt we have a register field in device_context
> typedef struct {
>
> rtems_termios_device_context base;
>
> const char *device_name;
>
> volatile some_chip_registers *regs;
>
> } my_driver_context;
>
> How does the reg field point to the correct memory location? for instance
> in IMX BSP,
> there is a struct with register field's but none of the define a memory
> location?
>
> On Tue, Dec 24, 2019 at 11:37 PM Niteesh  wrote:
>
>> How to handle different serial devices? In other BSPs the uart devices
>> are the same, so
>> they were able to put it under a single array? But here we have 2 uarts
>> and a FB?
>>
>>
>> On Tue, Dec 24, 2019 at 8:18 PM Christian Mauderer 
>> wrote:
>>
>>> On 24/12/2019 12:06, Niteesh wrote:
>>> > The current raspi console section is like this:
>>> > The bsp_console_select in console_select.c is responsible for selecting
>>> > between uart and the framebuffer. It does so
>>> > by setting the Console_port_minor.
>>> > The console_config is responsible for output_char function.
>>> > And other files are driver code.
>>> > If rewriting, this would be my approach,
>>> > Rewrite the bsp_console_select to set some kind of a variable like in
>>> > IMX, then in console_initialize function
>>> > link the right driver to /dev/console.
>>> > Replace the console_tbl with the device_context and console_fns with
>>> > termios_device_handlers and
>>> > finally add in the console_initialization function.
>>>
>>> I agree that this would be a clean solution. So if you want you can do
>>> that. But there might is a hurdle: As far as I understood you you only
>>> have a Pi3? So you might have a hard time testing the changes. Maybe the
>>> simulator could work.
>>>
>>> Another possibility could be to set the "Console_port_minor" to
>>> something unused (for example -1). In that case you can define another
>>> /dev/console.
>>>
>>> Best regards and merry Christmas (in case you celebrate)
>>>
>>> Christian
>>>
>>> >
>>> > On Tue, Dec 24, 2019 at 2:13 PM Niteesh >> > <mailto:gsnb...@gmail.com>> wrote:
>>> >
>>> > Thank you so much, for such a detailed answer. Now things make
>>> > really good sense to me,
>>> > going through the code now is just a breeze. But I still have one
>>> > question
>>> > for the newer driver interface is console_initialize the function
>>> > which RTEMS calls while initializing
>>> > the console? Which means I can't mess with the name right? It is
>>> > similar to the main function, right?
>>> >
>>> > The current driver is a legacy one, how do you want me to proceed,
>>> > shall I rewrite the legacy to a
>>> > the new one, this is will be a great learning experience for me
>>> also
>>> > and we also get the BSP updated to the latest interface.
>>> >
>>> >
>>> > On Tue, Dec 24, 2019 at 3:20 AM Christian Mauderer
>>> > mailto:l...@c-mauderer.de>> wrote:
>>> >
>>> > Hello Niteesh,
>>> >
>>> > quite a lot of questions. I'll try to answer them. Note that it
>>> > has been
>>> > some time since I had a detailed look at that code so if
>>> something I
>>> > tell seems odd please don't hesitate to question it.
>>> >
>>> > Please note that in RTEMS their are more or less two "levels"
>>> of
>>> > support
>>> > for a serial console:
>>> >
>>> > 1. A very basic polled system console (also known as
>>> > "debug-console" in
>>> > some BSPs). This one is used for printk and should work in
>>> basically
>>> > every case. It is used for critical system messages like
>>> > printing the
>>> > exception frame. For that a BSP has to provide a
>>> > "BSP_output_char" function.
>>> >
>>> > 2. A full

Re: Raspberrypi3: Mini UART driver

[Niteesh]

 usart_read_polled,
-  .deviceWrite = usart_write_support_polled,
-  .deviceInitialize = usart_initialize,
-  .deviceWritePolled = usart_write_polled,
-  .deviceSetAttributes = usart_set_attributes,
-  .deviceOutputUsesInterrupts = false
-};
+const rtems_termios_device_handler bcm2835_uart0_handler_polled = {
+  .first_open = usart_first_open,
+  .last_close = usart_last_close,
+  .poll_read = usart_read_polled,
+  .set_attributes = usart_set_attributes,
+  .write = usart_write_support_polled,
+  .mode = TERMIOS_POLLED
+}
\ No newline at end of file

On Wed, Dec 25, 2019 at 12:36 AM Joel Sherrill  wrote:

>
>
> On Tue, Dec 24, 2019, 12:19 PM Niteesh  wrote:
>
>> And also the register definitions are in raspberrpi.h file should I move
>> them to usart.h.
>>
>
> Sounds right if you mean bsp/usart.h
>
> I have a doubt we have a register field in device_context
>> typedef struct {
>>
>> rtems_termios_device_context base;
>>
>> const char *device_name;
>>
>> volatile some_chip_registers *regs;
>>
>> } my_driver_context;
>>
>> How does the reg field point to the correct memory location? for instance
>> in IMX BSP,
>> there is a struct with register field's but none of the define a memory
>> location?
>>
>
> Make sure the structure has volatiles and proper alignment. :)
>
>>
>> On Tue, Dec 24, 2019 at 11:37 PM Niteesh  wrote:
>>
>>> How to handle different serial devices? In other BSPs the uart devices
>>> are the same, so
>>> they were able to put it under a single array? But here we have 2 uarts
>>> and a FB?
>>>
>>>
>>> On Tue, Dec 24, 2019 at 8:18 PM Christian Mauderer 
>>> wrote:
>>>
>>>> On 24/12/2019 12:06, Niteesh wrote:
>>>> > The current raspi console section is like this:
>>>> > The bsp_console_select in console_select.c is responsible for
>>>> selecting
>>>> > between uart and the framebuffer. It does so
>>>> > by setting the Console_port_minor.
>>>> > The console_config is responsible for output_char function.
>>>> > And other files are driver code.
>>>> > If rewriting, this would be my approach,
>>>> > Rewrite the bsp_console_select to set some kind of a variable like in
>>>> > IMX, then in console_initialize function
>>>> > link the right driver to /dev/console.
>>>> > Replace the console_tbl with the device_context and console_fns with
>>>> > termios_device_handlers and
>>>> > finally add in the console_initialization function.
>>>>
>>>> I agree that this would be a clean solution. So if you want you can do
>>>> that. But there might is a hurdle: As far as I understood you you only
>>>> have a Pi3? So you might have a hard time testing the changes. Maybe the
>>>> simulator could work.
>>>>
>>>> Another possibility could be to set the "Console_port_minor" to
>>>> something unused (for example -1). In that case you can define another
>>>> /dev/console.
>>>>
>>>> Best regards and merry Christmas (in case you celebrate)
>>>>
>>>> Christian
>>>>
>>>> >
>>>> > On Tue, Dec 24, 2019 at 2:13 PM Niteesh >>> > <mailto:gsnb...@gmail.com>> wrote:
>>>> >
>>>> > Thank you so much, for such a detailed answer. Now things make
>>>> > really good sense to me,
>>>> > going through the code now is just a breeze. But I still have one
>>>> > question
>>>> > for the newer driver interface is console_initialize the function
>>>> > which RTEMS calls while initializing
>>>> > the console? Which means I can't mess with the name right? It is
>>>> > similar to the main function, right?
>>>> >
>>>> > The current driver is a legacy one, how do you want me to proceed,
>>>> > shall I rewrite the legacy to a
>>>> > the new one, this is will be a great learning experience for me
>>>> also
>>>> > and we also get the BSP updated to the latest interface.
>>>> >
>>>> >
>>>> > On Tue, Dec 24, 2019 at 3:20 AM Christian Mauderer
>>>> > mailto:l...@c-mauderer.de>> wrote:
>>>> >
>>>> > Hello Niteesh,
>>>> >
>>>> > quite a lot of questions. I'll try to an

Re: Raspberrypi3: Mini UART driver

[Niteesh]

What about the framebuffer it still uses minor and major's?

On Wed, Dec 25, 2019 at 3:20 PM Niteesh  wrote:

> Just to make sure I am going in the right track.
> I moved the uart register definitions to bsp/usart.h into a struct of
> uint32_t called usart0_regs
> here is git diff of usart.c after changing it to the latest console
> interface.
>
> diff --git a/bsps/arm/raspberrypi/console/usart.c
> b/bsps/arm/raspberrypi/console/usart.c
> index 25fb523621..b12f375a1c 100644
> --- a/bsps/arm/raspberrypi/console/usart.c
> +++ b/bsps/arm/raspberrypi/console/usart.c
> @@ -47,6 +47,12 @@ static uint32_t usart_get_baud(const console_tbl *ct)
>  }
>  #endif
>
> +typedef struct {
> +  rtems_termios_device_context base;
> +  const char *device_name;
> +  volatile usart0_regs *regs;
> +}uart0_context;
> +
>  static void usart_set_baud(int minor, int baud)
>  {
>   /*
> @@ -55,10 +61,17 @@ static void usart_set_baud(int minor, int baud)
>   return;
>  }
>
> -static void usart_initialize(int minor)
> +static volatile usart0_regs
> *rpi_uart_get_regs(rtems_termios_device_context *base)
>  {
> -  unsigned int gpio_reg;
> +  uart0_context *ctx;
> +
> +  ctx = (usart0_regs *) base;
> +  return ctx->regs;
> +}
>
> +static void usart_initialize(rtems_termios_device_context *base)
> +{
> +  unsigned int gpio_reg;
>/*
>** Program GPIO pins for UART 0
>*/
> @@ -75,67 +88,81 @@ static void usart_initialize(int minor)
>usart_delay(150);
>BCM2835_REG(BCM2835_GPIO_GPPUDCLK0) = 0;
>
> +  volatile uint32_t *uart_regs = rpi_uart_get_regs(base);
> +
>/*
>** Init the PL011 UART
>*/
> -  BCM2835_REG(BCM2835_UART0_CR)   = 0;
> -  BCM2835_REG(BCM2835_UART0_ICR)  = 0x7FF;
> -  BCM2835_REG(BCM2835_UART0_IMSC) = 0;
> -  BCM2835_REG(BCM2835_UART0_IBRD) = 1;
> -  BCM2835_REG(BCM2835_UART0_FBRD) = 40;
> -  BCM2835_REG(BCM2835_UART0_LCRH) = 0x70;
> -  BCM2835_REG(BCM2835_UART0_RSRECR) =  0;
> -
> -  BCM2835_REG(BCM2835_UART0_CR)   = 0x301;
> -
> -  BCM2835_REG(BCM2835_UART0_IMSC) = BCM2835_UART0_IMSC_RX;
> -
> -  usart_set_baud(minor, 115000);
> +  uart_regs->cr  = 0;
> +  uart_regs->icr = 0x7ff;
> +  uart_regs->imsc = 0;
> +  uart_regs->ibrd = 1;
> +  uart_regs->fbrd= 40;
> +  uart_regs->lcrh= 0x70;
> +  uart_regs->rsrecr= 0;
> +  uart_regs->cr = 0x301;
> +  uart_regs->imsc = BCM2835_UART0_IMSC_RX;
> +  // usart_set_baud(minor, 115000);
>  }
>
> -static int usart_first_open(int major, int minor, void *arg)
> +static bool usart_first_open(
> +  rtems_termios_tty *tty,
> +  rtems_termios_device_context *base,
> +  struct termios *term,
> +  rtems_libio_open_close_args_t *args
> +)
>  {
> -  rtems_libio_open_close_args_t *oc = (rtems_libio_open_close_args_t *)
> arg;
> -  struct rtems_termios_tty *tty = (struct rtems_termios_tty *)
> oc->iop->data1;
> -  const console_tbl *ct = Console_Port_Tbl [minor];
> -  console_data *cd = &Console_Port_Data [minor];
> +  rtems_status_code sc;
> +  uart0_context *ctx;
> +  bool ok;
>
> -  cd->termios_data = tty;
> -  rtems_termios_set_initial_baud(tty, ct->ulClock);
> +  ctx = (uart0_context *) base;
>
> -  return 0;
> +  usart_initialize(base);
> +
> +  sc = rtems_termios_set_initial_baud(tty,  USART0_DEFAULT_BAUD);
> +  if ( sc != RTEMS_SUCCESSFUL ){
> +printk("Error setting the baud for termios\n");
> +return false;
> +  }
>  }
>
> -static int usart_last_close(int major, int minor, void *arg)
> +static int usart_last_close(
> +  rtems_termios_tty *tty,
> +  rtems_termios_device_context *base,
> +  rtems_termios_open_close_args_t *arg)
>  {
>return 0;
>  }
>
> -static int usart_read_polled(int minor)
> +static int usart_read_polled(rtems_termios_device_context *base)
>  {
> -  if (minor == 0) {
> -if (((BCM2835_REG(BCM2835_UART0_FR)) & BCM2835_UART0_FR_RXFE) == 0) {
> -   return((BCM2835_REG(BCM2835_UART0_DR)) & 0xFF );
> -} else {
> -  return -1;
> -}
> -  } else {
> -printk("Unknown console minor number: %d\n", minor);
> -return -1;
> +  volatile usart0_regs *regs;
> +
> +  regs = rpi_uart_get_regs(base);
> +
> +  if ((regs->fr & BCM2835_UART0_FR_RXFE) == 0) {
> +return (regs->dr & 0xFF);
>}
> +
> +  return -1;
>  }
>
> -static void usart_write_polled(int minor, char c)
> +static void usart_write_polled(rtems_termios_device_context *base, char c)
>  {
> -   while (1) {
> - if ((BCM2835_REG(BCM2835_UART0_FR) & BCM2835_UART0_FR_TXFF) == 0)
> -   break;
> -   }
> -   BCM2835_REG(BC

Re: Raspberrypi3: Mini UART driver

[Niteesh]

On Fri, Dec 27, 2019 at 1:58 AM Christian Mauderer 
wrote:

> Hello Niteesh,
>
> sorry for not answering earlier. During this time of the year you have
> to expect some delays on the mailing list due to public holydays and
> vacations.

That's okay, I understand.

>
>
On 25/12/2019 10:50, Niteesh wrote:
> > Just to make sure I am going in the right track.
> > I moved the uart register definitions to bsp/usart.h into a struct of
> > uint32_t called usart0_regs
> > here is git diff of usart.c after changing it to the latest console
> > interface.
>
> Do you have a plan how you want to test these changes?
>
> The direction looks OK. Some notes below.
>
> By the way: Maybe it would be a better idea to just remove it completely
> and use the bsps/arm/shared/serial/arm-pl011.c driver instead? That
> reduces the ammount of code and therefore ammount of bugs we have in
> this BSP.


>
>
> > diff --git a/bsps/arm/raspberrypi/console/usart.c
> > b/bsps/arm/raspberrypi/console/usart.c
> > index 25fb523621..b12f375a1c 100644
> > --- a/bsps/arm/raspberrypi/console/usart.c
> > +++ b/bsps/arm/raspberrypi/console/usart.c
> > @@ -47,6 +47,12 @@ static uint32_t usart_get_baud(const console_tbl *ct)
> >  }
> >  #endif
> >
> > +typedef struct {
> > +  rtems_termios_device_context base;
> > +  const char *device_name;
> > +  volatile usart0_regs *regs;
> > +}uart0_context;
>
> Why uart0_context and not usart_context? All other names in this file
> are called usart_...
>
> Sorry, for the inconsistent naming, should I rename it as pl011_context
since we will be adding
mini uart for rpi3, IMHO it would be better.

> > +
> >  static void usart_set_baud(int minor, int baud)
> >  {
> >   /*
> > @@ -55,10 +61,17 @@ static void usart_set_baud(int minor, int baud)
> >   return;
> >  }
> >
> > -static void usart_initialize(int minor)
> > +static volatile usart0_regs
> > *rpi_uart_get_regs(rtems_termios_device_context *base)
> >  {
> > -  unsigned int gpio_reg;
> > +  uart0_context *ctx;
> > +
> > +  ctx = (usart0_regs *) base;
> > +  return ctx->regs;
> > +}
> >
> > +static void usart_initialize(rtems_termios_device_context *base)
> > +{
> > +  unsigned int gpio_reg;
> >/*
> >** Program GPIO pins for UART 0
> >*/
> > @@ -75,67 +88,81 @@ static void usart_initialize(int minor)
> >usart_delay(150);
> >BCM2835_REG(BCM2835_GPIO_GPPUDCLK0) = 0;
> >
> > +  volatile uint32_t *uart_regs = rpi_uart_get_regs(base);
> > +
> >/*
> >** Init the PL011 UART
> >*/
> > -  BCM2835_REG(BCM2835_UART0_CR)   = 0;
> > -  BCM2835_REG(BCM2835_UART0_ICR)  = 0x7FF;
> > -  BCM2835_REG(BCM2835_UART0_IMSC) = 0;
> > -  BCM2835_REG(BCM2835_UART0_IBRD) = 1;
> > -  BCM2835_REG(BCM2835_UART0_FBRD) = 40;
> > -  BCM2835_REG(BCM2835_UART0_LCRH) = 0x70;
> > -  BCM2835_REG(BCM2835_UART0_RSRECR) =  0;
> > -
> > -  BCM2835_REG(BCM2835_UART0_CR)   = 0x301;
> > -
> > -  BCM2835_REG(BCM2835_UART0_IMSC) = BCM2835_UART0_IMSC_RX;
> > -
> > -  usart_set_baud(minor, 115000);
> > +  uart_regs->cr  = 0;
> > +  uart_regs->icr = 0x7ff;
> > +  uart_regs->imsc = 0;
> > +  uart_regs->ibrd = 1;
> > +  uart_regs->fbrd= 40;
> > +  uart_regs->lcrh= 0x70;
> > +  uart_regs->rsrecr= 0;
> > +  uart_regs->cr = 0x301;
> > +  uart_regs->imsc = BCM2835_UART0_IMSC_RX;
> > +  // usart_set_baud(minor, 115000);
>
> Why is this line commented now?
>
It actually does nothing. The function body was empty. The current baud
rate is set directly
in the initialization function. I was planning to update it once, I was
finished with the interface.

>
> >  }
> >
> > -static int usart_first_open(int major, int minor, void *arg)
> > +static bool usart_first_open(
> > +  rtems_termios_tty *tty,
> > +  rtems_termios_device_context *base,
> > +  struct termios *term,
> > +  rtems_libio_open_close_args_t *args
> > +)
> >  {
> > -  rtems_libio_open_close_args_t *oc = (rtems_libio_open_close_args_t *)
> > arg;
> > -  struct rtems_termios_tty *tty = (struct rtems_termios_tty *)
> > oc->iop->data1;
> > -  const console_tbl *ct = Console_Port_Tbl [minor];
> > -  console_data *cd = &Console_Port_Data [minor];
> > +  rtems_status_code sc;
> > +  uart0_context *ctx;
> > +  bool ok;
> >
> > -  cd->termios_data = tty;
> > -  rtems_termios_set_initial_baud(tty, ct->u

Re: Raspberrypi3: Mini UART driver

[Niteesh]

On Fri, Dec 27, 2019 at 1:59 AM Christian Mauderer 
wrote:

> On 25/12/2019 15:32, Niteesh wrote:
> > What about the framebuffer it still uses minor and major's?
>
> I'm not entirely sure but I don't think that it is a problem to mix
> legacy and new style drivers.

I want to create rtems_termios_device_handler for the framebuffer, the
current driver uses console_fns and
the functions have the old signatures, which uses major and minor numbers,
but the device handler uses the newer interface

static bool my_driver_first_open(

  rtems_termios_tty *tty,
  rtems_termios_device_context  *base,
  struct termios*term,
  rtems_libio_open_close_args_t *args)

as mentioned in the doc will it cause any trouble? If it does then will
also have to rewrite the fb right?

>
>
>
> > On Wed, Dec 25, 2019 at 3:20 PM Niteesh  > <mailto:gsnb...@gmail.com>> wrote:
> >
> > Just to make sure I am going in the right track.
> > I moved the uart register definitions to bsp/usart.h into a struct
> > of uint32_t called usart0_regs
> > here is git diff of usart.c after changing it to the latest console
> > interface.
> >
> > diff --git a/bsps/arm/raspberrypi/console/usart.c
> > b/bsps/arm/raspberrypi/console/usart.c
> > index 25fb523621..b12f375a1c 100644
> > --- a/bsps/arm/raspberrypi/console/usart.c
> > +++ b/bsps/arm/raspberrypi/console/usart.c
> > @@ -47,6 +47,12 @@ static uint32_t usart_get_baud(const console_tbl
> *ct)
> >  }
> >  #endif
> >
> > +typedef struct {
> > +  rtems_termios_device_context base;
> > +  const char *device_name;
> > +  volatile usart0_regs *regs;
> > +}uart0_context;
> > +
> >  static void usart_set_baud(int minor, int baud)
> >  {
> >   /*
> > @@ -55,10 +61,17 @@ static void usart_set_baud(int minor, int baud)
> >   return;
> >  }
> >
> > -static void usart_initialize(int minor)
> > +static volatile usart0_regs
> > *rpi_uart_get_regs(rtems_termios_device_context *base)
> >  {
> > -  unsigned int gpio_reg;
> > +  uart0_context *ctx;
> > +
> > +  ctx = (usart0_regs *) base;
> > +  return ctx->regs;
> > +}
> >
> > +static void usart_initialize(rtems_termios_device_context *base)
> > +{
> > +  unsigned int gpio_reg;
> >/*
> >** Program GPIO pins for UART 0
> >*/
> > @@ -75,67 +88,81 @@ static void usart_initialize(int minor)
> >usart_delay(150);
> >BCM2835_REG(BCM2835_GPIO_GPPUDCLK0) = 0;
> >
> > +  volatile uint32_t *uart_regs = rpi_uart_get_regs(base);
> > +
> >/*
> >** Init the PL011 UART
> >*/
> > -  BCM2835_REG(BCM2835_UART0_CR)   = 0;
> > -  BCM2835_REG(BCM2835_UART0_ICR)  = 0x7FF;
> > -  BCM2835_REG(BCM2835_UART0_IMSC) = 0;
> > -  BCM2835_REG(BCM2835_UART0_IBRD) = 1;
> > -  BCM2835_REG(BCM2835_UART0_FBRD) = 40;
> > -  BCM2835_REG(BCM2835_UART0_LCRH) = 0x70;
> > -  BCM2835_REG(BCM2835_UART0_RSRECR) =  0;
> > -
> > -  BCM2835_REG(BCM2835_UART0_CR)   = 0x301;
> > -
> > -  BCM2835_REG(BCM2835_UART0_IMSC) = BCM2835_UART0_IMSC_RX;
> > -
> > -  usart_set_baud(minor, 115000);
> > +  uart_regs->cr  = 0;
> > +  uart_regs->icr = 0x7ff;
> > +  uart_regs->imsc = 0;
> > +  uart_regs->ibrd = 1;
> > +  uart_regs->fbrd= 40;
> > +  uart_regs->lcrh= 0x70;
> > +  uart_regs->rsrecr= 0;
> > +  uart_regs->cr = 0x301;
> > +  uart_regs->imsc = BCM2835_UART0_IMSC_RX;
> > +  // usart_set_baud(minor, 115000);
> >  }
> >
> > -static int usart_first_open(int major, int minor, void *arg)
> > +static bool usart_first_open(
> > +  rtems_termios_tty *tty,
> > +  rtems_termios_device_context *base,
> > +  struct termios *term,
> > +  rtems_libio_open_close_args_t *args
> > +)
> >  {
> > -  rtems_libio_open_close_args_t *oc =
> > (rtems_libio_open_close_args_t *) arg;
> > -  struct rtems_termios_tty *tty = (struct rtems_termios_tty *)
> > oc->iop->data1;
> > -  const console_tbl *ct = Console_Port_Tbl [minor];
> > -  console_data *cd = &Console_Port_Data [minor];
> > +  rtems_status_code sc;
> > +  uart0_context *ctx;
> > +  bool 

Re: Raspberrypi3: Mini UART driver

[Niteesh]

Does the device's initialization happen in the first_open function for the
new interface? Because the old legacy driver
call's the initialization function directly.

On Fri, Dec 27, 2019 at 2:00 PM Niteesh  wrote:

> On Fri, Dec 27, 2019 at 1:59 AM Christian Mauderer 
> wrote:
>
>> On 25/12/2019 15:32, Niteesh wrote:
>> > What about the framebuffer it still uses minor and major's?
>>
>> I'm not entirely sure but I don't think that it is a problem to mix
>> legacy and new style drivers.
>
> I want to create rtems_termios_device_handler for the framebuffer, the
> current driver uses console_fns and
> the functions have the old signatures, which uses major and minor numbers,
> but the device handler uses the newer interface
>
> static bool my_driver_first_open(
>
>   rtems_termios_tty *tty,
>   rtems_termios_device_context  *base,
>   struct termios*term,
>   rtems_libio_open_close_args_t *args)
>
> as mentioned in the doc will it cause any trouble? If it does then will
> also have to rewrite the fb right?
>
>>
>>
> >
>> > On Wed, Dec 25, 2019 at 3:20 PM Niteesh > > <mailto:gsnb...@gmail.com>> wrote:
>> >
>> > Just to make sure I am going in the right track.
>> > I moved the uart register definitions to bsp/usart.h into a struct
>> > of uint32_t called usart0_regs
>> > here is git diff of usart.c after changing it to the latest console
>> > interface.
>> >
>> > diff --git a/bsps/arm/raspberrypi/console/usart.c
>> > b/bsps/arm/raspberrypi/console/usart.c
>> > index 25fb523621..b12f375a1c 100644
>> > --- a/bsps/arm/raspberrypi/console/usart.c
>> > +++ b/bsps/arm/raspberrypi/console/usart.c
>> > @@ -47,6 +47,12 @@ static uint32_t usart_get_baud(const console_tbl
>> *ct)
>> >  }
>> >  #endif
>> >
>> > +typedef struct {
>> > +  rtems_termios_device_context base;
>> > +  const char *device_name;
>> > +  volatile usart0_regs *regs;
>> > +}uart0_context;
>> > +
>> >  static void usart_set_baud(int minor, int baud)
>> >  {
>> >   /*
>> > @@ -55,10 +61,17 @@ static void usart_set_baud(int minor, int baud)
>> >   return;
>> >  }
>> >
>> > -static void usart_initialize(int minor)
>> > +static volatile usart0_regs
>> > *rpi_uart_get_regs(rtems_termios_device_context *base)
>> >  {
>> > -  unsigned int gpio_reg;
>> > +  uart0_context *ctx;
>> > +
>> > +  ctx = (usart0_regs *) base;
>> > +  return ctx->regs;
>> > +}
>> >
>> > +static void usart_initialize(rtems_termios_device_context *base)
>> > +{
>> > +  unsigned int gpio_reg;
>> >/*
>> >** Program GPIO pins for UART 0
>> >*/
>> > @@ -75,67 +88,81 @@ static void usart_initialize(int minor)
>> >usart_delay(150);
>> >BCM2835_REG(BCM2835_GPIO_GPPUDCLK0) = 0;
>> >
>> > +  volatile uint32_t *uart_regs = rpi_uart_get_regs(base);
>> > +
>> >/*
>> >** Init the PL011 UART
>> >*/
>> > -  BCM2835_REG(BCM2835_UART0_CR)   = 0;
>> > -  BCM2835_REG(BCM2835_UART0_ICR)  = 0x7FF;
>> > -  BCM2835_REG(BCM2835_UART0_IMSC) = 0;
>> > -  BCM2835_REG(BCM2835_UART0_IBRD) = 1;
>> > -  BCM2835_REG(BCM2835_UART0_FBRD) = 40;
>> > -  BCM2835_REG(BCM2835_UART0_LCRH) = 0x70;
>> > -  BCM2835_REG(BCM2835_UART0_RSRECR) =  0;
>> > -
>> > -  BCM2835_REG(BCM2835_UART0_CR)   = 0x301;
>> > -
>> > -  BCM2835_REG(BCM2835_UART0_IMSC) = BCM2835_UART0_IMSC_RX;
>> > -
>> > -  usart_set_baud(minor, 115000);
>> > +  uart_regs->cr  = 0;
>> > +  uart_regs->icr = 0x7ff;
>> > +  uart_regs->imsc = 0;
>> > +  uart_regs->ibrd = 1;
>> > +  uart_regs->fbrd= 40;
>> > +  uart_regs->lcrh= 0x70;
>> > +  uart_regs->rsrecr= 0;
>> > +  uart_regs->cr = 0x301;
>> > +  uart_regs->imsc = BCM2835_UART0_IMSC_RX;
>> > +  // usart_set_baud(minor, 115000);
>> >  }
>> >
>> > -static int usart_first_open(int major, int minor, void *arg)
>> > +static bool usart_first_o

Re: Raspberrypi3: Mini UART driver

[Niteesh]

I have sent the patch. I also sent a documentation update for the
quick-start section
a few months ago. But no one took a look at it. Can you have a look at it?

https://www.mail-archive.com/devel@rtems.org/msg20965.html
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Raspberrypi3: Mini UART driver

[Niteesh]

Is there something else that I could work on? I am interested in taking
part
GSOC of 2020. And I want to learn as much as possible.

On Fri, Dec 27, 2019 at 5:07 PM Christian Mauderer 
wrote:

> On 27/12/2019 12:20, Niteesh wrote:
> > I have sent the patch. I also sent a documentation update for the
> > quick-start section
> > a few months ago. But no one took a look at it. Can you have a look at
> it?
>
> I'll try to have a look at it soon.
>
> >
> > https://www.mail-archive.com/devel@rtems.org/msg20965.html
>
> If you don't get any responses to a patch please just send a reminder
> one or two weeks later. It's quite likely that the patch just slipped
> the attention.
>
> Normally I leave documentation patches to our native speakers. They spot
> a lot of errors that I won't be able to find.
>
> Can you please send a ping for the patch. You can add me to CC and for
> this one I would suggest to CC Chris Johns too.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Raspberrypi3: Mini UART driver

[Niteesh]

On Sat, 28 Dec, 2019, 3:51 AM Christian Mauderer, 
wrote:

> On 27/12/2019 19:06, Niteesh wrote:
> > Is there something else that I could work on? I am interested in taking
> > part
> > GSOC of 2020. And I want to learn as much as possible.
>
> Do you search tasks specific to raspberry or general ones? Do you search
> something for GSoC or just to warm up?
>
Anything is fine as long as I am learning something. Since rpi3 is the only
hardware I have, I am interested in tasks specific to raspi and general
ones which do not require any hardware.

>
> >
> > On Fri, Dec 27, 2019 at 5:07 PM Christian Mauderer  > <mailto:l...@c-mauderer.de>> wrote:
> >
> > On 27/12/2019 12:20, Niteesh wrote:
> > > I have sent the patch. I also sent a documentation update for the
> > > quick-start section
> > > a few months ago. But no one took a look at it. Can you have a
> > look at it?
> >
> > I'll try to have a look at it soon.
> >
> > >
> > > https://www.mail-archive.com/devel@rtems.org/msg20965.html
> >
> > If you don't get any responses to a patch please just send a reminder
> > one or two weeks later. It's quite likely that the patch just slipped
> > the attention.
> >
> > Normally I leave documentation patches to our native speakers. They
> spot
> > a lot of errors that I won't be able to find.
> >
> > Can you please send a ping for the patch. You can add me to CC and
> for
> > this one I would suggest to CC Chris Johns too.
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Raspberrypi: updated the console interface.

[Niteesh]

I didn't get any of these warnings, which command did you use?

On Sat, Dec 28, 2019 at 3:48 AM Christian Mauderer 
wrote:

> Hello,
>
> git complained about some whitespaces when applying the patch:
>
> 
> git am \[PATCH\]\ Raspberrypi:\ updated\ the\ console\ interface..eml
> Applying: Raspberrypi: updated the console interface.
> /home/christian/rtems/rtems-bbb/.git/modules/rtems/rebase-apply/patch:96:
> trailing
> whitespace.
>
> /home/christian/rtems/rtems-bbb/.git/modules/rtems/rebase-apply/patch:304:
> trailing whitespace.
> const rtems_termios_device_handler fbcons_fns =
> /home/christian/rtems/rtems-bbb/.git/modules/rtems/rebase-apply/patch:481:
> trailing whitespace.
> bool fbcons_probe(
> /home/christian/rtems/rtems-bbb/.git/modules/rtems/rebase-apply/patch:515:
> trailing whitespace.
>  * @name Current Serial Device
> warning: 4 lines add whitespace errors.
> 
>
Fixed all the whitespace erros.

> When compiling I get some warnings like
>
> 
>
> /home/christian/rtems/rtems-bbb/build/..//libs/rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/raspberrypi/console/console-config.c:
> In function 'output_char':
>
> /home/christian/rtems/rtems-bbb/build/..//libs/rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/raspberrypi/console/console-config.c:64:3:
> warning: enumeration value 'AUX_UART' not handled in switch [-Wswitch]
>switch(SERIAL){
>^~
> 
>
> and
>
> 
>
> /home/christian/rtems/rtems-bbb/build/..//libs/rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/raspberrypi/console/fbcons.c:174:17:
> warning: initialization from incompatible pointer type
> [-Wincompatible-pointer-types]
>.first_open = fbcons_open,
>  ^~~
> 
>
> Please fix these. I'm not entirely sure about the first warning. That
> might has been there before. If possible it would be nice if you could
> fix it anyway. In that case maybe in an extra commit.

At least the PL011 works on a Pi2 on real hardware too. I haven't tested
> the framebuffer yet. I'm still trying to find out how to select it
> before or after the patch.
>
> Please see my notes in the patch below regarding some points.
>
> Best regards
>
> Christian
>
> On 27/12/2019 12:08, G S Niteesh wrote:
> > The patch updates the older console interface used by the BSP,
> > to newer one. It also replaces the custom usart(PL011) driver
> > with arm-pl011. The fb functions signatures where also changed
> > to accommodate with interface update.
> > ---
> >  bsps/arm/raspberrypi/console/console-config.c |  67 +
> >  bsps/arm/raspberrypi/console/console_select.c |  65 +---
> >  bsps/arm/raspberrypi/console/fbcons.c |  50 +++---
> >  bsps/arm/raspberrypi/console/usart.c  | 142 --
> >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  19 ++-
> >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  52 ++-
> >  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
> >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   5 +-
> >  8 files changed, 105 insertions(+), 300 deletions(-)
> >
> > diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> > index d2186c918b..1f6dec384a 100644
> > --- a/bsps/arm/raspberrypi/console/console-config.c
> > +++ b/bsps/arm/raspberrypi/console/console-config.c
> > @@ -22,45 +22,54 @@
> >
> >  #include 
> >
> > -#include 
> > -#include 
> > +#include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> > +#include 
> > +
> > +#include 
> >
> > -console_tbl Console_Configuration_Ports [] = {
> > -{
> > -  .sDeviceName = "/dev/ttyS0",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = &bcm2835_usart_fns,
> > -  .deviceProbe = NULL,
> > -  .pDeviceFlow = NULL,
> > -  .ulCtrlPort1 = BCM2835_UART0_BASE,
> > -  .ulCtrlPort2 = 0,
> > -  .ulClock = USART0_DEFAULT_BAUD,
> > -  .ulIntVector = BCM2835_IRQ_ID_UART
> > -},
> > -{
> > -  .sDeviceName ="/dev/fbcons",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = &fbcons_fns,
> > -  .deviceProbe = fbcons_probe,
> > -  .pDeviceFlow = NULL,
> > -},
> > +arm_pl011_context pl011_context = {
> > +  .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER("PL011"),
> > +  .regs = (volatile pl0

Re: [PATCH] Raspberrypi: updated the console interface.

[Niteesh]

On Sat, Dec 28, 2019 at 3:20 PM Christian Mauderer 
wrote:

> Missed your question further below in my first mail.
>
> On 28/12/2019 10:45, Christian Mauderer wrote:
> > On 28/12/2019 09:38, Niteesh wrote:
> >> I didn't get any of these warnings, which command did you use?
> >
> > Just the usual make in the build directory. I configured with the
> > following line:
> >
> > /home/christian/rtems/rtems-bbb/build/..//libs/rtems/configure
> > --target=arm-rtems5
> > --prefix=/home/christian/rtems/rtems-bbb/build/..//install/rtems/5/
> > --enable-rtemsbsp=raspberrypi --enable-maintainer-mode
> > --enable-tests=samples --disable-networking
> >
> > Don't let the "bbb" irritate you: I hacked my normal beagle build
> > environment for use with the raspberry.
> >
> > There are quite a lot of messages. So the warnings might are a bit
> > hidden. Also note that you only get them if the file is recompiled. So
> > either you have to change something or remove the console-config.o and
> > fbcons.o object file to trigger them on a re-make.
> >
> >>
> >> On Sat, Dec 28, 2019 at 3:48 AM Christian Mauderer  >> <mailto:l...@c-mauderer.de>> wrote:
> >>
> >> Hello,
> >>
> >> git complained about some whitespaces when applying the patch:
> >>
> >> 
> >> git am \[PATCH\]\ Raspberrypi:\ updated\ the\ console\
> interface..eml
> >> Applying: Raspberrypi: updated the console interface.
> >>
>  /home/christian/rtems/rtems-bbb/.git/modules/rtems/rebase-apply/patch:96:
> >> trailing
> >> whitespace.
> >>
> >>
>  /home/christian/rtems/rtems-bbb/.git/modules/rtems/rebase-apply/patch:304:
> >> trailing whitespace.
> >> const rtems_termios_device_handler fbcons_fns =
> >>
>  /home/christian/rtems/rtems-bbb/.git/modules/rtems/rebase-apply/patch:481:
> >> trailing whitespace.
> >> bool fbcons_probe(
> >>
>  /home/christian/rtems/rtems-bbb/.git/modules/rtems/rebase-apply/patch:515:
> >> trailing whitespace.
> >>  * @name Current Serial Device
> >> warning: 4 lines add whitespace errors.
> >> 
> >>
> >> Fixed all the whitespace erros.
> >>
> >> When compiling I get some warnings like
> >>
> >> 
> >>
>  
> /home/christian/rtems/rtems-bbb/build/..//libs/rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/raspberrypi/console/console-config.c:
> >> In function 'output_char':
> >>
>  
> /home/christian/rtems/rtems-bbb/build/..//libs/rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/raspberrypi/console/console-config.c:64:3:
> >> warning: enumeration value 'AUX_UART' not handled in switch
> [-Wswitch]
> >>switch(SERIAL){
> >>^~
> >> 
> >>
> >> and
> >>
> >> 
> >>
>  
> /home/christian/rtems/rtems-bbb/build/..//libs/rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/raspberrypi/console/fbcons.c:174:17:
> >> warning: initialization from incompatible pointer type
> >> [-Wincompatible-pointer-types]
> >>.first_open = fbcons_open,
> >>      ^~~
> >> 
> >>
> >> Please fix these. I'm not entirely sure about the first warning.
> That
> >> might has been there before. If possible it would be nice if you
> could
> >> fix it anyway. In that case maybe in an extra commit.
> >>
> >> At least the PL011 works on a Pi2 on real hardware too. I haven't
> tested
> >> the framebuffer yet. I'm still trying to find out how to select it
> >> before or after the patch.
> >>
> >> Please see my notes in the patch below regarding some points.
> >>
> >> Best regards
> >>
> >> Christian
> >>
> >> On 27/12/2019 12:08, G S Niteesh wrote:
> >> > The patch updates the older console interface used by the BSP,
> >> > to newer one. It also replaces the custom usart(PL011) driver
> >> > with arm-pl011. The fb functions signatures where also changed
> >> > to accommodate with interface update.
> >> > ---
> >> >  bsps/arm/raspberrypi/console/console-config.c |  67 

Re: [PATCH v2] Raspberrypi: updated the console interface.

[Niteesh]

I think you misunderstood, I was talking about the casting in the
rtems_termios_device_handler
const rtems_termios_device_handler fbcons_fns =
{
  .first_open = fbcons_open,
  .last_close = fbcons_close,
  .poll_read = fbcons_inbyte_nonblocking_polled,
  .write = (void (*)(rtems_termios_device_context *, const char *,
size_t))fbcons_write_support_polled,
  .set_attributes = fbcons_set_attributes,
  .mode = TERMIOS_POLLED
};

the write requires a function type of




*void (*write)(rtems_termios_device_context *context,const char
*buf,size_t len  );*

but the fbcons function is of type




*static ssize_t fbcons_write_support_polled(  rtems_termios_device_context
*base,  const char *buf,  size_t  len)*

Well, if the above cast in the device handler causes a problem, can you
elaborate more on
what kind of a problem would it be?

And for the BSP_output_char function, I used a function pointer. The
console_select assigns the
appropriate function to the function pointer and the output_char call's it
by providing the context.
static void output_char(char c)
{
  const console_device *dev = &console_device_table[console_select];
  rtems_termios_device_context *con = dev->context;
  console_instance(con, c);
}
console_instance is the function pointer, which is assigned to
arm_pl011_write_polled  by
default, or to fbcons_write_polled, if frame buffer is decided to be used.

On Sat, Dec 28, 2019 at 8:50 PM Christian Mauderer 
wrote:

> On 28/12/2019 14:10, G S Niteesh wrote:
> > The patch updates the older console interface used by the BSP,
> > to newer one. It also replaces the custom usart(PL011) driver
> > with arm-pl011. The fb function's signatures where also changed
> > to accommodate with interface update.
> > Update #3034
> > ---
> >  bsps/arm/raspberrypi/console/console-config.c |  62 
> >  bsps/arm/raspberrypi/console/console_select.c |  68 ++---
> >  bsps/arm/raspberrypi/console/fbcons.c |  71 -
> >  bsps/arm/raspberrypi/console/usart.c  | 142 --
> >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  19 ++-
> >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  70 +
> >  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
> >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   5 +-
> >  8 files changed, 136 insertions(+), 306 deletions(-)
> >
> > diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> > index d2186c918b..f479e19d99 100644
> > --- a/bsps/arm/raspberrypi/console/console-config.c
> > +++ b/bsps/arm/raspberrypi/console/console-config.c
> > @@ -22,45 +22,47 @@
> >
> >  #include 
> >
> > -#include 
> > -#include 
> > -#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> > +#include 
> > +
> > +#include 
> >
> > -console_tbl Console_Configuration_Ports [] = {
> > -{
> > -  .sDeviceName = "/dev/ttyS0",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = &bcm2835_usart_fns,
> > -  .deviceProbe = NULL,
> > -  .pDeviceFlow = NULL,
> > -  .ulCtrlPort1 = BCM2835_UART0_BASE,
> > -  .ulCtrlPort2 = 0,
> > -  .ulClock = USART0_DEFAULT_BAUD,
> > -  .ulIntVector = BCM2835_IRQ_ID_UART
> > -},
> > -{
> > -  .sDeviceName ="/dev/fbcons",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = &fbcons_fns,
> > -  .deviceProbe = fbcons_probe,
> > -  .pDeviceFlow = NULL,
> > -},
> > +arm_pl011_context pl011_context = {
> > +  .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER("PL011"),
> > +  .regs = (volatile pl011 *) BCM2835_PL011_BASE,
> > +  .initial_baud = PL011_DEFAULT_BAUD
> >  };
> >
> > -#define PORT_COUNT \
> > -  (sizeof(Console_Configuration_Ports) \
> > -/ sizeof(Console_Configuration_Ports [0]))
> > +rpi_fb_context fb_context = {
> > +  .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER("FB")
> > +};
> > +
> > +const console_device console_device_table[] = {
> > +  {
> > +.device_file = "/dev/ttyS0",
> > +.probe = console_device_probe_default,
> > +.handler = &arm_pl011_fns,
> > +.context = &pl011_context.base
> > +  },
> > +  {
> > +.device_file = "/dev/fbcons",
> > +.probe = fbcons_probe,
> > +.handler = &fbcons_fns,
> > +.context = &fb_context.base
> > +  }
> > +};
> >
> > -unsigned long Console_Configur

Re: [PATCH v2] Raspberrypi: updated the console interface.

[Niteesh]

On Sat, Dec 28, 2019 at 11:12 PM Christian Mauderer 
wrote:

> On 28/12/2019 17:22, Niteesh wrote:
> > I think you misunderstood, I was talking about the casting in the
> > rtems_termios_device_handler
>
> Yes, I misunderstood you there.
>
> > const rtems_termios_device_handler fbcons_fns =
> > {
> >   .first_open = fbcons_open,
> >   .last_close = fbcons_close,
> >   .poll_read = fbcons_inbyte_nonblocking_polled,
> >   .write = (void (*)(rtems_termios_device_context *, const char *,
> > size_t))fbcons_write_support_polled,
> >   .set_attributes = fbcons_set_attributes,
> >   .mode = TERMIOS_POLLED
> > };
> >
> > the write requires a function type of
> >   *void (*write)(
> > rtems_termios_device_context *context,
> > const char *buf,
> > size_t len
> >   );*
> >
> > but the fbcons function is of type
> > *static ssize_t fbcons_write_support_polled(
> >   rtems_termios_device_context *base,
> >   const char *buf,
> >   size_t  len
> > )*
> >
> > Well, if the above cast in the device handler causes a problem, can you
> > elaborate more on
> > what kind of a problem would it be?
>
> In that case it should work. But why do you need to cast it there?
> Wouldn't it be simpler to just change the fbcons_write_support_polled
> function? It isn't used anywhere else or did I miss something?
>
No, it is not used anywhere. I'll change the function.

> >
> > And for the BSP_output_char function, I used a function pointer. The
> > console_select assigns the
> > appropriate function to the function pointer and the output_char call's
> > it by providing the context.
> > static void output_char(char c)
> > {
> >   const console_device *dev = &console_device_table[console_select];
> >   rtems_termios_device_context *con = dev->context;
> >   console_instance(con, c);
> > }
> > console_instance is the function pointer, which is assigned to
> > arm_pl011_write_polled  by
> > default, or to fbcons_write_polled, if frame buffer is decided to be
> used.
>
>
> Yes it will work and it's resonable performant. We are talking about a
> slow serial interface in an exception case. But anyway I'm not entirely
> happy.
>
> The compiler should make something like the following out of it:
>
> - Look up and call the value of BSP_output_char
> - Load the context (start of table + console_select + fixed offset) into
> "con"
> - Look up and call the value of console_instance
>
> If you use the way I suggested below you will have about the following:
>
> - Look up and call the value of BSP_output_char (one of the wrappers)
> - Call the right function with a fixed parameter
>
> So it's a bit shorter and beneath that you save a global variable.
>
Sure, will change it.

> >
> > On Sat, Dec 28, 2019 at 8:50 PM Christian Mauderer  > <mailto:l...@c-mauderer.de>> wrote:
> >
> > On 28/12/2019 14:10, G S Niteesh wrote:
> > > The patch updates the older console interface used by the BSP,
> > > to newer one. It also replaces the custom usart(PL011) driver
> > > with arm-pl011. The fb function's signatures where also changed
> > > to accommodate with interface update.
> > > Update #3034
> > > ---
> > >  bsps/arm/raspberrypi/console/console-config.c |  62 
> > >  bsps/arm/raspberrypi/console/console_select.c |  68 ++---
> > >  bsps/arm/raspberrypi/console/fbcons.c |  71 -
> > >  bsps/arm/raspberrypi/console/usart.c  | 142
> > --
> > >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  19 ++-
> > >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  70 +
> > >  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
> > >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   5 +-
> > >  8 files changed, 136 insertions(+), 306 deletions(-)
> > >
> > > diff --git a/bsps/arm/raspberrypi/console/console-config.c
> > b/bsps/arm/raspberrypi/console/console-config.c
> > > index d2186c918b..f479e19d99 100644
> > > --- a/bsps/arm/raspberrypi/console/console-config.c
> > > +++ b/bsps/arm/raspberrypi/console/console-config.c
> > > @@ -22,45 +22,47 @@
> > >
> > >  #include 
> > >
> > > -#include 
> > > -#include 
> > > -#include 
> > > +#include 
> > >  #include

Re: [PATCH v2] Raspberrypi: updated the console interface.

[Niteesh]

I am sorry if this question sounds silly, but how can I access the
output_char_fb if it
is marked as static in console-select.c, currently the fb context is in
console-config.c
Should I move the BSP_select_function to console-config? for shall I remove
the static qualifier
from the function?

Currently, the console_select has 2 functions, bsp_Is_Available and
bsp_console_select.

On Sat, Dec 28, 2019 at 11:30 PM Niteesh  wrote:

> On Sat, Dec 28, 2019 at 11:12 PM Christian Mauderer 
> wrote:
>
>> On 28/12/2019 17:22, Niteesh wrote:
>> > I think you misunderstood, I was talking about the casting in the
>> > rtems_termios_device_handler
>>
>> Yes, I misunderstood you there.
>>
>> > const rtems_termios_device_handler fbcons_fns =
>> > {
>> >   .first_open = fbcons_open,
>> >   .last_close = fbcons_close,
>> >   .poll_read = fbcons_inbyte_nonblocking_polled,
>> >   .write = (void (*)(rtems_termios_device_context *, const char *,
>> > size_t))fbcons_write_support_polled,
>> >   .set_attributes = fbcons_set_attributes,
>> >   .mode = TERMIOS_POLLED
>> > };
>> >
>> > the write requires a function type of
>> >   *void (*write)(
>> > rtems_termios_device_context *context,
>> > const char *buf,
>> > size_t len
>> >   );*
>> >
>> > but the fbcons function is of type
>> > *static ssize_t fbcons_write_support_polled(
>> >   rtems_termios_device_context *base,
>> >   const char *buf,
>> >   size_t  len
>> > )*
>> >
>> > Well, if the above cast in the device handler causes a problem, can you
>> > elaborate more on
>> > what kind of a problem would it be?
>>
>> In that case it should work. But why do you need to cast it there?
>> Wouldn't it be simpler to just change the fbcons_write_support_polled
>> function? It isn't used anywhere else or did I miss something?
>>
> No, it is not used anywhere. I'll change the function.
>
>> >
>> > And for the BSP_output_char function, I used a function pointer. The
>> > console_select assigns the
>> > appropriate function to the function pointer and the output_char call's
>> > it by providing the context.
>> > static void output_char(char c)
>> > {
>> >   const console_device *dev = &console_device_table[console_select];
>> >   rtems_termios_device_context *con = dev->context;
>> >   console_instance(con, c);
>> > }
>> > console_instance is the function pointer, which is assigned to
>> > arm_pl011_write_polled  by
>> > default, or to fbcons_write_polled, if frame buffer is decided to be
>> used.
>>
>>
>> Yes it will work and it's resonable performant. We are talking about a
>> slow serial interface in an exception case. But anyway I'm not entirely
>> happy.
>>
>> The compiler should make something like the following out of it:
>>
>> - Look up and call the value of BSP_output_char
>> - Load the context (start of table + console_select + fixed offset) into
>> "con"
>> - Look up and call the value of console_instance
>>
>> If you use the way I suggested below you will have about the following:
>>
>> - Look up and call the value of BSP_output_char (one of the wrappers)
>> - Call the right function with a fixed parameter
>>
>> So it's a bit shorter and beneath that you save a global variable.
>>
> Sure, will change it.
>
>> >
>> > On Sat, Dec 28, 2019 at 8:50 PM Christian Mauderer > > <mailto:l...@c-mauderer.de>> wrote:
>> >
>> > On 28/12/2019 14:10, G S Niteesh wrote:
>> > > The patch updates the older console interface used by the BSP,
>> > > to newer one. It also replaces the custom usart(PL011) driver
>> > > with arm-pl011. The fb function's signatures where also changed
>> > > to accommodate with interface update.
>> > > Update #3034
>> > > ---
>> > >  bsps/arm/raspberrypi/console/console-config.c |  62 
>> > >  bsps/arm/raspberrypi/console/console_select.c |  68 ++---
>> > >  bsps/arm/raspberrypi/console/fbcons.c |  71 -
>> > >  bsps/arm/raspberrypi/console/usart.c  | 142
>> > --
>> > >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  19 ++-
>> > >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  70 

Re: [PATCH v2] Raspberrypi: updated the console interface.

[Niteesh]

Is bsp_console_select legacy? And the new way will be by linking
the correct serial device to /dev/console in console_initialization, right?
If so, shall I add one?

On Sat, Dec 28, 2019 at 11:50 PM Niteesh  wrote:

> I am sorry if this question sounds silly, but how can I access the
> output_char_fb if it
> is marked as static in console-select.c, currently the fb context is in
> console-config.c
> Should I move the BSP_select_function to console-config? for shall I
> remove the static qualifier
> from the function?
>
> Currently, the console_select has 2 functions, bsp_Is_Available and
> bsp_console_select.
>
> On Sat, Dec 28, 2019 at 11:30 PM Niteesh  wrote:
>
>> On Sat, Dec 28, 2019 at 11:12 PM Christian Mauderer 
>> wrote:
>>
>>> On 28/12/2019 17:22, Niteesh wrote:
>>> > I think you misunderstood, I was talking about the casting in the
>>> > rtems_termios_device_handler
>>>
>>> Yes, I misunderstood you there.
>>>
>>> > const rtems_termios_device_handler fbcons_fns =
>>> > {
>>> >   .first_open = fbcons_open,
>>> >   .last_close = fbcons_close,
>>> >   .poll_read = fbcons_inbyte_nonblocking_polled,
>>> >   .write = (void (*)(rtems_termios_device_context *, const char *,
>>> > size_t))fbcons_write_support_polled,
>>> >   .set_attributes = fbcons_set_attributes,
>>> >   .mode = TERMIOS_POLLED
>>> > };
>>> >
>>> > the write requires a function type of
>>> >   *void (*write)(
>>> > rtems_termios_device_context *context,
>>> > const char *buf,
>>> > size_t len
>>> >   );*
>>> >
>>> > but the fbcons function is of type
>>> > *static ssize_t fbcons_write_support_polled(
>>> >   rtems_termios_device_context *base,
>>> >   const char *buf,
>>> >   size_t  len
>>> > )*
>>> >
>>> > Well, if the above cast in the device handler causes a problem, can you
>>> > elaborate more on
>>> > what kind of a problem would it be?
>>>
>>> In that case it should work. But why do you need to cast it there?
>>> Wouldn't it be simpler to just change the fbcons_write_support_polled
>>> function? It isn't used anywhere else or did I miss something?
>>>
>> No, it is not used anywhere. I'll change the function.
>>
>>> >
>>> > And for the BSP_output_char function, I used a function pointer. The
>>> > console_select assigns the
>>> > appropriate function to the function pointer and the output_char call's
>>> > it by providing the context.
>>> > static void output_char(char c)
>>> > {
>>> >   const console_device *dev = &console_device_table[console_select];
>>> >   rtems_termios_device_context *con = dev->context;
>>> >   console_instance(con, c);
>>> > }
>>> > console_instance is the function pointer, which is assigned to
>>> > arm_pl011_write_polled  by
>>> > default, or to fbcons_write_polled, if frame buffer is decided to be
>>> used.
>>>
>>>
>>> Yes it will work and it's resonable performant. We are talking about a
>>> slow serial interface in an exception case. But anyway I'm not entirely
>>> happy.
>>>
>>> The compiler should make something like the following out of it:
>>>
>>> - Look up and call the value of BSP_output_char
>>> - Load the context (start of table + console_select + fixed offset) into
>>> "con"
>>> - Look up and call the value of console_instance
>>>
>>> If you use the way I suggested below you will have about the following:
>>>
>>> - Look up and call the value of BSP_output_char (one of the wrappers)
>>> - Call the right function with a fixed parameter
>>>
>>> So it's a bit shorter and beneath that you save a global variable.
>>>
>> Sure, will change it.
>>
>>> >
>>> > On Sat, Dec 28, 2019 at 8:50 PM Christian Mauderer >> > <mailto:l...@c-mauderer.de>> wrote:
>>> >
>>> > On 28/12/2019 14:10, G S Niteesh wrote:
>>> > > The patch updates the older console interface used by the BSP,
>>> > > to newer one. It also replaces the custom usart(PL011) driver
>>> > > with arm-pl011. The fb function's signatures where also changed
>>> > &g

Re: [PATCH v2] Raspberrypi: updated the console interface.

[Niteesh]

I will start working on a patch that uses FDT. Instead of merging this
I create a patch v3 that uses FDT. Shall I remove some files, I will be
heavily using
the imx and other FDT based drivers as a reference.

On Sun, Dec 29, 2019 at 12:27 AM Christian Mauderer 
wrote:

> On 28/12/2019 19:48, Niteesh wrote:
> > Is bsp_console_select legacy? And the new way will be by linking
> > the correct serial device to /dev/console in console_initialization,
> right?
> > If so, shall I add one?
>
> The function is only called from legacy-console.c. So yes: This function
> can be removed. The logic on the other hand should move to somewhere else.
>
> The console-termios-init.c creates a link named CONSOLE_DEVICE_NAME. So
> you can't use that code and create your link manually. If you use the
> table based approach (which is OK as a first step) you can't really
> select the console.
>
> I would suggest to either clean that patch up so it can be merged and
> move to a fdt based approach simmilar to imx in a second patch. In that
> case the console_initialize() function from console-termios-init.c will
> be replaced by a custom function that searches the FDT for the devices.
> The FDT will make it simpler to adapt to RPi3. Or if you prefere it you
> can do that right now and create a patch v3 that directly uses FDT.
>
> >
> > On Sat, Dec 28, 2019 at 11:50 PM Niteesh  > <mailto:gsnb...@gmail.com>> wrote:
> >
> > I am sorry if this question sounds silly, but how can I access the
> > output_char_fb if it
> > is marked as static in console-select.c, currently the fb context is
> > in console-config.c
> > Should I move the BSP_select_function to console-config? for shall I
> > remove the static qualifier
> > from the function?
> >
> > Currently, the console_select has 2 functions, bsp_Is_Available and
> > bsp_console_select.
> >
> > On Sat, Dec 28, 2019 at 11:30 PM Niteesh  > <mailto:gsnb...@gmail.com>> wrote:
> >
> > On Sat, Dec 28, 2019 at 11:12 PM Christian Mauderer
> > mailto:l...@c-mauderer.de>> wrote:
> >
> > On 28/12/2019 17:22, Niteesh wrote:
> > > I think you misunderstood, I was talking about the casting
> > in the
> > > rtems_termios_device_handler
> >
> > Yes, I misunderstood you there.
> >
> > > const rtems_termios_device_handler fbcons_fns =
> > > {
> > >   .first_open = fbcons_open,
> > >   .last_close = fbcons_close,
> > >   .poll_read = fbcons_inbyte_nonblocking_polled,
> > >   .write = (void (*)(rtems_termios_device_context *, const
> > char *,
> > > size_t))fbcons_write_support_polled,
> > >   .set_attributes = fbcons_set_attributes,
> > >   .mode = TERMIOS_POLLED
> > > };
> > >
> > > the write requires a function type of
> > >   *void (*write)(
> > > rtems_termios_device_context *context,
> > > const char *buf,
> > > size_t len
> > >   );*
> > >
> > > but the fbcons function is of type
> > > *static ssize_t fbcons_write_support_polled(
> > >   rtems_termios_device_context *base,
> > >   const char *buf,
> > >   size_t  len
> > > )*
> > >
> > > Well, if the above cast in the device handler causes a
> > problem, can you
> > > elaborate more on
> > > what kind of a problem would it be?
> >
> > In that case it should work. But why do you need to cast it
> > there?
> > Wouldn't it be simpler to just change the
> > fbcons_write_support_polled
> > function? It isn't used anywhere else or did I miss
> something?
> >
> > No, it is not used anywhere. I'll change the function.
> >
> > >
> > > And for the BSP_output_char function, I used a function
> > pointer. The
> > > console_select assigns the
> > > appropriate function to the function pointer and the
> > output_char call's
> > > it by providing the context.
> 

Re: [PATCH v2] Raspberrypi: updated the console interface.

[Niteesh]

Where does qemu place the dtb file? we can pass the dtb file to the kernel
using -dtb, but not sure where it puts it? googled a lot but couldn't find
it.

I also tried running u-boot, it successfully ran on raspi3 in 64bit mode. I
couldn't get it running on raspi2.
The qemu raspi3 doesn't support networking nor usb, but qemu raspi2 does,
so if we could get u-boot
working on raspi2 it would make your work way better.
Could you give it a try?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] Raspberrypi: updated the console interface.

[Niteesh]

I am sorry, I sent the previous without testing and building, so it might
contain some errors.
Just tell me if you are happy with the code, I will fix all the error's and
send in a new patch.

On Sun, Dec 29, 2019 at 8:04 PM G S Niteesh  wrote:

> The patch updates the older console interface used by the BSP,
> to newer one. It also replaces the custom usart(PL011) driver
> with arm-pl011. The fb function's signatures where also changed
> to accommodate with interface update.
> Update #3034
> ---
>  bsps/arm/raspberrypi/console/console-config.c | 182 ++
>  bsps/arm/raspberrypi/console/console_select.c |  97 +-
>  bsps/arm/raspberrypi/console/fbcons.c |  79 
>  bsps/arm/raspberrypi/console/usart.c  | 167 
>  bsps/arm/raspberrypi/include/bsp/fbcons.h |  21 +-
>  .../arm/raspberrypi/include/bsp/raspberrypi.h |  48 ++---
>  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
>  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   5 +-
>  8 files changed, 225 insertions(+), 379 deletions(-)
>  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
>
> diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> index d2186c918b..52859656f4 100644
> --- a/bsps/arm/raspberrypi/console/console-config.c
> +++ b/bsps/arm/raspberrypi/console/console-config.c
> @@ -19,50 +19,162 @@
>   */
>
>  #include 
> +#include 
>
>  #include 
>
> -#include 
> -#include 
> -#include 
> +#include 
>  #include 
> +#include 
> +#include 
>  #include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +arm_pl011_context pl011_context;
> +rpi_fb_context fb_context;
> +
> +static void output_char_serial(char c)
> +{
> +  arm_pl011_write_polled(&pl011_context.base, c);
> +}
> +
> +void output_char_fb(char c)
> +{
> +  fbcons_write_polled(&fb_context.base, c);
> +}
> +
> +static void *get_reg_of_node(const void *fdt, int node)
> +{
> +  int len;
> +  const uint32_t *val;
> +
> +  val = fdt_getprop(fdt, node, "reg", &len);
> +  if (val == NULL || len < 4) {
> +return NULL;
> +  }
> +
> +  return (void *) fdt32_to_cpu(val[0]);
> +}
> +
> +static bool register_arm_pl011(const void *fdt, const char *serial, const
> char *path)
> +{
> +  arm_pl011_context *ctx = &pl011_context;
> +  int node;
> +
> +  if (strcmp(serial, "uart0")) {
> +rtems_termios_device_context_initialize(&ctx->base, "UART");
> +node = fdt_path_offset(fdt, serial);
> +ctx->regs = get_reg_of_node(fdt, node);
> +
> +rtems_termios_device_install(
> +  path,
> +  &arm_pl011_fns,
> +  NULL,
> +  &pl011_context.base
> +);
> +
> +return true;
> +  }
> +  return false;
> +}
>
> -console_tbl Console_Configuration_Ports [] = {
> -{
> -  .sDeviceName = "/dev/ttyS0",
> -  .deviceType = SERIAL_CUSTOM,
> -  .pDeviceFns = &bcm2835_usart_fns,
> -  .deviceProbe = NULL,
> -  .pDeviceFlow = NULL,
> -  .ulCtrlPort1 = BCM2835_UART0_BASE,
> -  .ulCtrlPort2 = 0,
> -  .ulClock = USART0_DEFAULT_BAUD,
> -  .ulIntVector = BCM2835_IRQ_ID_UART
> -},
> -{
> -  .sDeviceName ="/dev/fbcons",
> -  .deviceType = SERIAL_CUSTOM,
> -  .pDeviceFns = &fbcons_fns,
> -  .deviceProbe = fbcons_probe,
> -  .pDeviceFlow = NULL,
> -},
> -};
> -
> -#define PORT_COUNT \
> -  (sizeof(Console_Configuration_Ports) \
> -/ sizeof(Console_Configuration_Ports [0]))
> -
> -unsigned long Console_Configuration_Count = PORT_COUNT;
> -
> -static void output_char(char c)
> +static bool register_fb()
>  {
> -  const console_fns *con =
> -Console_Configuration_Ports [Console_Port_Minor].pDeviceFns;
> +  if( !fbcons_probe(&fb_context.base) ) {
> +return false;
> +  }
> +
> +  rtems_termios_device_install(
> +"/dev/fbcons",
> +&fbcons_fns,
> +NULL,
> +&fb_context.base);
> +
> +  return true;
> +}
> +
> +static void uart_probe(const void *fdt, int node)
> +{
> +  char path[] = "/dev/ttyS?";
> +  size_t i = 0;
> +  int offset = fdt_first_property_offset(fdt, node);
> +
> +  while (offset >= 0) {
> +const struct fdt_property *prop;
> +
> +prop = fdt_get_property_by_offset(fdt, offset, NULL);
> +
> +if (prop != NULL) {
> +  const char *name;
> +  name = fdt_string(fdt, fdt32_to_cpu(prop->nameoff));
> +
> +  if(strstr(name, "serial") != 

Re: [PATCH v3] Raspberrypi: updated the console interface.

[Niteesh]

Where does RTEMS except the DTB file to be present?

On Sun, Dec 29, 2019 at 8:27 PM Niteesh  wrote:

> I am sorry, I sent the previous without testing and building, so it might
> contain some errors.
> Just tell me if you are happy with the code, I will fix all the error's
> and send in a new patch.
>
> On Sun, Dec 29, 2019 at 8:04 PM G S Niteesh  wrote:
>
>> The patch updates the older console interface used by the BSP,
>> to newer one. It also replaces the custom usart(PL011) driver
>> with arm-pl011. The fb function's signatures where also changed
>> to accommodate with interface update.
>> Update #3034
>> ---
>>  bsps/arm/raspberrypi/console/console-config.c | 182 ++
>>  bsps/arm/raspberrypi/console/console_select.c |  97 +-
>>  bsps/arm/raspberrypi/console/fbcons.c |  79 
>>  bsps/arm/raspberrypi/console/usart.c  | 167 
>>  bsps/arm/raspberrypi/include/bsp/fbcons.h |  21 +-
>>  .../arm/raspberrypi/include/bsp/raspberrypi.h |  48 ++---
>>  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
>>  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   5 +-
>>  8 files changed, 225 insertions(+), 379 deletions(-)
>>  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
>>
>> diff --git a/bsps/arm/raspberrypi/console/console-config.c
>> b/bsps/arm/raspberrypi/console/console-config.c
>> index d2186c918b..52859656f4 100644
>> --- a/bsps/arm/raspberrypi/console/console-config.c
>> +++ b/bsps/arm/raspberrypi/console/console-config.c
>> @@ -19,50 +19,162 @@
>>   */
>>
>>  #include 
>> +#include 
>>
>>  #include 
>>
>> -#include 
>> -#include 
>> -#include 
>> +#include 
>>  #include 
>> +#include 
>> +#include 
>>  #include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +
>> +arm_pl011_context pl011_context;
>> +rpi_fb_context fb_context;
>> +
>> +static void output_char_serial(char c)
>> +{
>> +  arm_pl011_write_polled(&pl011_context.base, c);
>> +}
>> +
>> +void output_char_fb(char c)
>> +{
>> +  fbcons_write_polled(&fb_context.base, c);
>> +}
>> +
>> +static void *get_reg_of_node(const void *fdt, int node)
>> +{
>> +  int len;
>> +  const uint32_t *val;
>> +
>> +  val = fdt_getprop(fdt, node, "reg", &len);
>> +  if (val == NULL || len < 4) {
>> +return NULL;
>> +  }
>> +
>> +  return (void *) fdt32_to_cpu(val[0]);
>> +}
>> +
>> +static bool register_arm_pl011(const void *fdt, const char *serial,
>> const char *path)
>> +{
>> +  arm_pl011_context *ctx = &pl011_context;
>> +  int node;
>> +
>> +  if (strcmp(serial, "uart0")) {
>> +rtems_termios_device_context_initialize(&ctx->base, "UART");
>> +node = fdt_path_offset(fdt, serial);
>> +ctx->regs = get_reg_of_node(fdt, node);
>> +
>> +rtems_termios_device_install(
>> +  path,
>> +  &arm_pl011_fns,
>> +  NULL,
>> +  &pl011_context.base
>> +);
>> +
>> +return true;
>> +  }
>> +  return false;
>> +}
>>
>> -console_tbl Console_Configuration_Ports [] = {
>> -{
>> -  .sDeviceName = "/dev/ttyS0",
>> -  .deviceType = SERIAL_CUSTOM,
>> -  .pDeviceFns = &bcm2835_usart_fns,
>> -  .deviceProbe = NULL,
>> -  .pDeviceFlow = NULL,
>> -  .ulCtrlPort1 = BCM2835_UART0_BASE,
>> -  .ulCtrlPort2 = 0,
>> -  .ulClock = USART0_DEFAULT_BAUD,
>> -  .ulIntVector = BCM2835_IRQ_ID_UART
>> -},
>> -{
>> -  .sDeviceName ="/dev/fbcons",
>> -  .deviceType = SERIAL_CUSTOM,
>> -  .pDeviceFns = &fbcons_fns,
>> -  .deviceProbe = fbcons_probe,
>> -  .pDeviceFlow = NULL,
>> -},
>> -};
>> -
>> -#define PORT_COUNT \
>> -  (sizeof(Console_Configuration_Ports) \
>> -/ sizeof(Console_Configuration_Ports [0]))
>> -
>> -unsigned long Console_Configuration_Count = PORT_COUNT;
>> -
>> -static void output_char(char c)
>> +static bool register_fb()
>>  {
>> -  const console_fns *con =
>> -Console_Configuration_Ports [Console_Port_Minor].pDeviceFns;
>> +  if( !fbcons_probe(&fb_context.base) ) {
>> +return false;
>> +  }
>> +
>> +  rtems_termios_device_install(
>> +"/dev/fbcons",
>>

Re: [PATCH v3] Raspberrypi: updated the console interface.

[Niteesh]

arm_pl011_context pl011_context;
rpi_fb_context fb_context;
char uart_instance[20];


static void output_char_serial(char c)
{
arm_pl011_write_polled(&pl011_context.base, c);
}

void output_char_fb(char c)
{
fbcons_write_polled(&fb_context.base, c);
}


static void *get_reg_of_node(const void *fdt, int node)
{
int len;
const uint32_t *val;

val = fdt_getprop(fdt, node, "reg", &len);
if (val == NULL || len < 4) {
return NULL;
}

return (void *) fdt32_to_cpu(val[0]);
}

static void arm_pl011_init_ctx(
const void *fdt,
const char *serial
)
{
arm_pl011_context *ctx = &pl011_context;
int node;

if (strcmp(serial, "uart0") == 0) {

rtems_termios_device_context_initialize(&ctx->base, "UART");
node = fdt_path_offset(fdt, serial);
ctx->regs = get_reg_of_node(fdt, node);
}
}

static void console_select( const char *console )
{
const char *opt;

opt = rpi_cmdline_get_arg("--console=");

if ( opt ) {
if ( strncmp( opt, "fbcons", sizeof( "fbcons" ) - 1 ) == 0 ) {
if ( rpi_video_is_initialized() > 0 ) {
strcpy(uart_instance, "/dev/fbcons");
BSP_output_char = output_char_fb;
}
}else{

if ( console == NULL ){
bsp_fatal( BSP_FATAL_CONSOLE_NO_DEV );
}
BSP_output_char = output_char_serial;
strcpy(uart_instance, "/dev/ttyS0");
}
}
}

static void uart_probe(void)
{
const void *fdt;
const char *console;
int node;

fdt = bsp_fdt_get();
node = fdt_path_offset(fdt, "/chosen");

console = fdt_getprop(fdt, node, "stdout-path", NULL);

node = fdt_path_offset(fdt, "/aliases");

int offset = fdt_first_property_offset(fdt, node);

while (offset >= 0) {
const struct fdt_property *prop;
prop = fdt_get_property_by_offset(fdt, offset, NULL);
if (prop != NULL) {
const char *name;

name = fdt_string(fdt, fdt32_to_cpu(prop->nameoff));
if(strstr(name, "serial") != NULL) {
const char *serial;
serial = prop->data;

arm_pl011_init_ctx(fdt, serial);
}
}

offset = fdt_next_property_offset(fdt, offset);
}
console_select(console);
}


static void output_char(char c)
{
uart_probe();
(*BSP_output_char)(c);
}

rtems_status_code console_initialize(
rtems_device_major_number major,
rtems_device_minor_number minor,
void *arg
)
{

rtems_termios_initialize();
rtems_termios_device_install(
"/dev/ttyS0",
&arm_pl011_fns,
NULL,
&pl011_context.base
);
rtems_termios_device_install(
"/dev/fbcons",
&fbcons_fns,
NULL,
&fb_context.base);

link(uart_instance, CONSOLE_DEVICE_NAME);

return RTEMS_SUCCESSFUL;
}

BSP_output_char_function_type BSP_output_char = output_char;

BSP_polling_getchar_function_type BSP_poll_char = NULL;

RTEMS_SYSINIT_ITEM(
uart_probe,
RTEMS_SYSINIT_BSP_START,
RTEMS_SYSINIT_ORDER_LAST
);
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] Raspberrypi: updated the console interface.

[Niteesh]

I am not happy with my code at all, I can please provide some suggestions.

On Mon, Dec 30, 2019 at 12:17 AM Niteesh  wrote:

> arm_pl011_context pl011_context;
> rpi_fb_context fb_context;
> char uart_instance[20];
>
>
> static void output_char_serial(char c)
> {
> arm_pl011_write_polled(&pl011_context.base, c);
> }
>
> void output_char_fb(char c)
> {
> fbcons_write_polled(&fb_context.base, c);
> }
>
>
> static void *get_reg_of_node(const void *fdt, int node)
> {
> int len;
> const uint32_t *val;
>
> val = fdt_getprop(fdt, node, "reg", &len);
> if (val == NULL || len < 4) {
> return NULL;
> }
>
> return (void *) fdt32_to_cpu(val[0]);
> }
>
> static void arm_pl011_init_ctx(
> const void *fdt,
> const char *serial
> )
> {
> arm_pl011_context *ctx = &pl011_context;
> int node;
>
> if (strcmp(serial, "uart0") == 0) {
>
> rtems_termios_device_context_initialize(&ctx->base, "UART");
> node = fdt_path_offset(fdt, serial);
> ctx->regs = get_reg_of_node(fdt, node);
> }
> }
>
> static void console_select( const char *console )
> {
> const char *opt;
>
> opt = rpi_cmdline_get_arg("--console=");
>
> if ( opt ) {
> if ( strncmp( opt, "fbcons", sizeof( "fbcons" ) - 1 ) == 0 ) {
> if ( rpi_video_is_initialized() > 0 ) {
> strcpy(uart_instance, "/dev/fbcons");
> BSP_output_char = output_char_fb;
> }
> }else{
>
> if ( console == NULL ){
> bsp_fatal( BSP_FATAL_CONSOLE_NO_DEV );
> }
> BSP_output_char = output_char_serial;
> strcpy(uart_instance, "/dev/ttyS0");
> }
> }
> }
>
> static void uart_probe(void)
> {
> const void *fdt;
> const char *console;
> int node;
>
> fdt = bsp_fdt_get();
> node = fdt_path_offset(fdt, "/chosen");
>
> console = fdt_getprop(fdt, node, "stdout-path", NULL);
>
> node = fdt_path_offset(fdt, "/aliases");
>
> int offset = fdt_first_property_offset(fdt, node);
>
> while (offset >= 0) {
> const struct fdt_property *prop;
> prop = fdt_get_property_by_offset(fdt, offset, NULL);
> if (prop != NULL) {
> const char *name;
>
> name = fdt_string(fdt, fdt32_to_cpu(prop->nameoff));
> if(strstr(name, "serial") != NULL) {
> const char *serial;
> serial = prop->data;
>
> arm_pl011_init_ctx(fdt, serial);
> }
> }
>
> offset = fdt_next_property_offset(fdt, offset);
> }
> console_select(console);
> }
>
>
> static void output_char(char c)
> {
> uart_probe();
> (*BSP_output_char)(c);
> }
>
> rtems_status_code console_initialize(
> rtems_device_major_number major,
> rtems_device_minor_number minor,
> void *arg
> )
> {
>
> rtems_termios_initialize();
> rtems_termios_device_install(
> "/dev/ttyS0",
> &arm_pl011_fns,
> NULL,
> &pl011_context.base
> );
> rtems_termios_device_install(
> "/dev/fbcons",
> &fbcons_fns,
> NULL,
> &fb_context.base);
>
> link(uart_instance, CONSOLE_DEVICE_NAME);
>
> return RTEMS_SUCCESSFUL;
> }
>
> BSP_output_char_function_type BSP_output_char = output_char;
>
> BSP_polling_getchar_function_type BSP_poll_char = NULL;
>
> RTEMS_SYSINIT_ITEM(
> uart_probe,
> RTEMS_SYSINIT_BSP_START,
> RTEMS_SYSINIT_ORDER_LAST
> );
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: What do you want to study in GSOC 2020?

[Niteesh]

On Mon, Dec 30, 2019 at 4:44 AM Peter Dufault  wrote:

>
> Niteesh, what do you want to study?  Go over what most interests you most
> about working in a real-time environment like RTEMS, and not about working
> on the RPI, and look at the earlier GSOC projects. Propose an ideal project
> for yourself and get some feedback.

 I love learning about how the software and hardware interact, I have been
programming from 9th grade and have a wide variety of interests(networking,
app development). But recently I took a course called nandtotetris were we
build an 8bit computer from scratch, we start with NAND gates and finally
finish with a Tetris game. Low-level software, systems programming, and
operating systems are always quite fascinating for me. While learning about
operating systems, I came across the concepts of real-time systems. Back
then arduino was the only hardware I was having while searching for an RTOS
to play with, I came across RTEMS. RTOS was harder for me to grasp but were
always interesting, being a critical part of a system, I always wanted to
learn how they worked from inside. That's what bought me to contributing to
RTOS.
I wanted to contribute to core of RTEMS, but it was a bit complex for me to
understand, so I started with driver development for RTEMS.
After going through some of the previous GSOC projects, BSP development and
real-time tracing are what I find interesting. While also converting the
console driver of rpi to FDT based one, *Christian Mauderer *explained how
FDT worked in FreeBSD and Linux, and RTEMS lacked that infrastructure, I
have no idea of how hard it would it, and if I am even capable of
developing it. But one proposal would be to build the FDT infrastructure
similar to FreeBSD or Linux and have the driver's probe and attach to the
hardware.

> > On Dec 28, 2019, at 05:12 , Christian Mauderer 
> wrote:
> >
> > On 28/12/2019 07:12, Niteesh wrote:
> >>
> >>
> >> On Sat, 28 Dec, 2019, 3:51 AM Christian Mauderer,  >> <mailto:l...@c-mauderer.de>> wrote:
> >>
> >>On 27/12/2019 19:06, Niteesh wrote:
> >>> Is there something else that I could work on? I am interested in
> >>taking
> >>> part
> >>> GSOC of 2020. And I want to learn as much as possible.
> >>
> >>Do you search tasks specific to raspberry or general ones? Do you
> search
> >>something for GSoC or just to warm up?
> >>
> >> Anything is fine as long as I am learning something. Since rpi3 is the
> >> only hardware I have, I am interested in tasks specific to raspi and
> >> general ones which do not require any hardware.
> >
> > For raspberry I think you could continue to get it running on RPi3. My
> > suggestion would be to replace the table based initialization (which is
> > handled by console-termios-init.c) with one based on the fdt that is
> > similar to the one in the imx BSP. That will allow to use the same
> > binary on RPi2 and RPi3. But please do that in an extra patch after the
> > one that you currently have sent to the mailing list.
> >
> >
> > Some other raspberry specific topics could be the following. Note that
> > this are only suggestions. I don't want to force you to do any of them
> > if you don't like them:
> >
> > - Documentation how you run an application in QEMU / on real hardware
> > for the user manual:
> >
> https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#raspberrypi
> > (I hope I didn't miss a patch that you already sent ;-) )
> >
> > - A configuration for RTEMS tester that uses the QEMU or real hardware
> > (I think the pi3 allows network boot?). This allows regular test runs
> > for this BSP:
> > https://docs.rtems.org/branches/master/user/testing/index.html and
> > https://docs.rtems.org/branches/master/user/tools/tester.html
> >
> > - Chris created a boot image generator last year. It would be great if
> > you could add a configuration to create raspberry SD images to it:
> > https://docs.rtems.org/branches/master/user/tools/boot-image.html
> >
> > - You can pick basically any component that isn't already there and
> > integrate it. If you want to work with libbsd: Testing or porting
> > Ethernet support could be something.
> >
> > - You most likely want to do something with RPi in your GSoC too. So
> > maybe some comments ("x is already done", "y seems to be still open")
> > for the ticket for it would be nice too:
> https://devel.rtems.org/ticket/2899
> >
> >
> > For non raspberry topics: We have a lot of open bugs where everyone is
> > happy if they are closed: 

Re: [PATCH v3] Raspberrypi: updated the console interface.

[Niteesh]

On Mon, 30 Dec, 2019, 2:07 AM Christian Mauderer, 
wrote:

> I assume you want suggestions regarding this code rather than the
> original patch?
>
> One suggestion: If you post code please try to use a mail program that
> keeps the indentation. It's hard to read in this form. But that's most
> likely not the suggestion you searched for ;-)
>
> On 29/12/2019 19:48, Niteesh wrote:
> > I am not happy with my code at all, I can please provide some
> suggestions.
> >
> > On Mon, Dec 30, 2019 at 12:17 AM Niteesh  > <mailto:gsnb...@gmail.com>> wrote:
> >
> > arm_pl011_context pl011_context;
> > rpi_fb_context fb_context;
>
> Is it sure that we only ever have one UART of each type? Otherwise some
> dynamic handling (allocating the memory for the context) might would be
> necessary. I think the chip has only these two modules? In that case
> this is OK for now.

I just checked the uarts for rpi4, it has 6uarts not sure which model they
are though.
My idea is to call all the uart register functions, register_pl011,
register_aux or register_xxx inside uart_probe which will see if they can
handle that particular node. If not they just return. The FB is registered
seperately in the console_initialise. Are you okay with or would like to
change something?

>
> > char uart_instance[20];
> >
>
> A global just to pass a name around? Would it be possible to search for
> a more elegant solution?
>
I first was setting the name for the uarts from the fdt property itself. In
fdt, the pl011 is uart0 and aux is uart1. So the correct path name is set
from the fdt property itself. For eg: if the current node is uart0 it will
be /dev/ttyS0 and ttyS1 if uart1. Is this approach fine?

> >
> > static void output_char_serial(char c)
> > {
> > arm_pl011_write_polled(&pl011_context.base, c);
> > }
> >
> > void output_char_fb(char c)
> > {
> > fbcons_write_polled(&fb_context.base, c);
> > }
> >
> >
> > static void *get_reg_of_node(const void *fdt, int node)
> > {
> > int len;
> > const uint32_t *val;
> >
> > val = fdt_getprop(fdt, node, "reg", &len);
> > if (val == NULL || len < 4) {
> > return NULL;
> > }
> >
> > return (void *) fdt32_to_cpu(val[0]);
> > }
> >
> > static void arm_pl011_init_ctx(
> > const void *fdt,
> > const char *serial
> > )
> > {
> > arm_pl011_context *ctx = &pl011_context;
> > int node;
> >
> > if (strcmp(serial, "uart0") == 0) {
> >
> > rtems_termios_device_context_initialize(&ctx->base, "UART");
> > node = fdt_path_offset(fdt, serial);
> > ctx->regs = get_reg_of_node(fdt, node);
> > }
> > }
> >
> > static void console_select( const char *console )
> > {
> > const char *opt;
> >
> > opt = rpi_cmdline_get_arg("--console=");
> >
> > if ( opt ) {
> > if ( strncmp( opt, "fbcons", sizeof( "fbcons" ) - 1 ) == 0 ) {
> > if ( rpi_video_is_initialized() > 0 ) {
> > strcpy(uart_instance, "/dev/fbcons");
> > BSP_output_char = output_char_fb;
> > }
> > }else{
> >
> > if ( console == NULL ){
> > bsp_fatal( BSP_FATAL_CONSOLE_NO_DEV );
> > }
> > BSP_output_char = output_char_serial;
> > strcpy(uart_instance, "/dev/ttyS0");
> > }
> > }
> > }
> >
> > static void uart_probe(void)
> > {
> > const void *fdt;
> > const char *console;
> > int node;
> >
> > fdt = bsp_fdt_get();
> > node = fdt_path_offset(fdt, "/chosen");
> >
> > console = fdt_getprop(fdt, node, "stdout-path", NULL);
> >
> > node = fdt_path_offset(fdt, "/aliases");
> >
> > int offset = fdt_first_property_offset(fdt, node);
> >
> > while (offset >= 0) {
> > const struct fdt_property *prop;
> > prop = fdt_get_property_by_offset(fdt, offset, NULL);
> > if (prop != NULL) {
> > const char *name;
> >
> > name = fdt_string(fdt, fdt32_to_cpu(prop->nameoff));
> > if(strstr(name, "serial") != NULL) {
> > const char *serial;
> > serial = prop->data;
> >
> > arm_pl011_init_ctx(fdt, serial);
> > }
> > }
> >
> > offset = fdt_next_property_of

Re: [PATCH v3] Raspberrypi: updated the console interface.

[Niteesh]

I just looked at the dts files for rpi4, the uart 0, uart 1 are the same,
the additional 4 uarts are in different pins and can be used
simultaneously. They are all pl011 and are disabled by default, and are
enabled using overlays in linux. Do you want to handle then now or sometime
later?


On Mon, 30 Dec, 2019, 1:20 PM Niteesh,  wrote:

> On Mon, 30 Dec, 2019, 2:07 AM Christian Mauderer, 
> wrote:
>
>> I assume you want suggestions regarding this code rather than the
>> original patch?
>>
>> One suggestion: If you post code please try to use a mail program that
>> keeps the indentation. It's hard to read in this form. But that's most
>> likely not the suggestion you searched for ;-)
>>
>> On 29/12/2019 19:48, Niteesh wrote:
>> > I am not happy with my code at all, I can please provide some
>> suggestions.
>> >
>> > On Mon, Dec 30, 2019 at 12:17 AM Niteesh > > <mailto:gsnb...@gmail.com>> wrote:
>> >
>> > arm_pl011_context pl011_context;
>> > rpi_fb_context fb_context;
>>
>> Is it sure that we only ever have one UART of each type? Otherwise some
>> dynamic handling (allocating the memory for the context) might would be
>> necessary. I think the chip has only these two modules? In that case
>> this is OK for now.
>
> I just checked the uarts for rpi4, it has 6uarts not sure which model they
> are though.
> My idea is to call all the uart register functions, register_pl011,
> register_aux or register_xxx inside uart_probe which will see if they can
> handle that particular node. If not they just return. The FB is registered
> seperately in the console_initialise. Are you okay with or would like to
> change something?
>
>>
>> > char uart_instance[20];
>> >
>>
>> A global just to pass a name around? Would it be possible to search for
>> a more elegant solution?
>>
> I first was setting the name for the uarts from the fdt property itself.
> In fdt, the pl011 is uart0 and aux is uart1. So the correct path name is
> set from the fdt property itself. For eg: if the current node is uart0 it
> will be /dev/ttyS0 and ttyS1 if uart1. Is this approach fine?
>
>> >
>> > static void output_char_serial(char c)
>> > {
>> > arm_pl011_write_polled(&pl011_context.base, c);
>> > }
>> >
>> > void output_char_fb(char c)
>> > {
>> > fbcons_write_polled(&fb_context.base, c);
>> > }
>> >
>> >
>> > static void *get_reg_of_node(const void *fdt, int node)
>> > {
>> > int len;
>> > const uint32_t *val;
>> >
>> > val = fdt_getprop(fdt, node, "reg", &len);
>> > if (val == NULL || len < 4) {
>> > return NULL;
>> > }
>> >
>> > return (void *) fdt32_to_cpu(val[0]);
>> > }
>> >
>> > static void arm_pl011_init_ctx(
>> > const void *fdt,
>> > const char *serial
>> > )
>> > {
>> > arm_pl011_context *ctx = &pl011_context;
>> > int node;
>> >
>> > if (strcmp(serial, "uart0") == 0) {
>> >
>> > rtems_termios_device_context_initialize(&ctx->base, "UART");
>> > node = fdt_path_offset(fdt, serial);
>> > ctx->regs = get_reg_of_node(fdt, node);
>> > }
>> > }
>> >
>> > static void console_select( const char *console )
>> > {
>> > const char *opt;
>> >
>> > opt = rpi_cmdline_get_arg("--console=");
>> >
>> > if ( opt ) {
>> > if ( strncmp( opt, "fbcons", sizeof( "fbcons" ) - 1 ) == 0 ) {
>> > if ( rpi_video_is_initialized() > 0 ) {
>> > strcpy(uart_instance, "/dev/fbcons");
>> > BSP_output_char = output_char_fb;
>> > }
>> > }else{
>> >
>> > if ( console == NULL ){
>> > bsp_fatal( BSP_FATAL_CONSOLE_NO_DEV );
>> > }
>> > BSP_output_char = output_char_serial;
>> > strcpy(uart_instance, "/dev/ttyS0");
>> > }
>> > }
>> > }
>> >
>> > static void uart_probe(void)
>> > {
>> > const void *fdt;
>> > const char *console;
>> > int node;
>> >
>> > fdt = bsp_fdt_get();
>> > node = fdt_path_offset(fdt, "/chosen");
>

Re: What do you want to study in GSOC 2020?

[Niteesh]

On Mon, Dec 30, 2019 at 7:14 PM Christian Mauderer 
wrote:

> On 30/12/2019 07:25, Niteesh wrote:
> >
> >
> > On Mon, Dec 30, 2019 at 4:44 AM Peter Dufault  > <mailto:dufa...@hda.com>> wrote:
> >
> >
> > Niteesh, what do you want to study?  Go over what most interests you
> > most about working in a real-time environment like RTEMS, and not
> > about working on the RPI, and look at the earlier GSOC projects.
> > Propose an ideal project for yourself and get some feedback.
>
> Peter: Thanks for starting that discussion. I started to focus too much
> on the running topics about small stuff that can be done as a preparation.
>
> >
> >  I love learning about how the software and hardware interact, I have
> > been programming from 9th grade and have a wide variety of
> > interests(networking, app development). But recently I took a course
> > called nandtotetris were we build an 8bit computer from scratch, we
> > start with NAND gates and finally finish with a Tetris game.
>
> That sounds like a really nice course. Most likely is ended in a bigger
> pile of circuit boards to have a running processor ;-)
>
It is a free course on coursera
https://www.coursera.org/learn/build-a-computer/home/welcome
do check it out. It's completely simulated in software. But planning to
build it on PCB.

>
> > Low-level
> > software, systems programming, and operating systems are always quite
> > fascinating for me. While learning about operating systems, I came
> > across the concepts of real-time systems. Back then arduino was the only
> > hardware I was having while searching for an RTOS to play with, I came
> > across RTEMS. RTOS was harder for me to grasp but were always
> > interesting, being a critical part of a system, I always wanted to learn
> > how they worked from inside. That's what bought me to contributing to
> RTOS.
> > I wanted to contribute to core of RTEMS, but it was a bit complex for me
> > to understand, so I started with driver development for RTEMS.
>
> That's where I started too. But don't hesitate to pick a more complex
> topic if you are interested in it. From what I've seen you can read and
> understand existing code quite fast compared to some other GSoC students
> we had. So I would say that you have a good chance to manage complex
> topics too.
>
Thank you, it's quite good to hear.

> > After going through some of the previous GSOC projects, BSP development
> > and real-time tracing are what I find interesting. While also converting
> > the console driver of rpi to FDT based one, *Christian Mauderer
> > *explained how
> > FDT worked in FreeBSD and Linux, and RTEMS lacked that infrastructure, I
> > have no idea of how hard it would it, and if I am even capable of
> > developing it. But one proposal would be to build the FDT infrastructure
> > similar to FreeBSD or Linux and have the driver's probe and attach to
> > the hardware.
>
> We start to have more and more FDT based BSPs. So it would be great if
> our infrastructure would improve. But like I said: Don't hesitate to
> pick any other topic. Device drivers (and similar) are low hanging fruit
> where it is easy to get success and it isn't very likely to start long
> tedious discussions because you only touch one BSP. Therefore I tend to
> suggest them for GSoC. But GSoC isn't limited to that.
>
> So if you would like to work at any other topic like (for example)
> porting a new architecture, hacking on some scheduler, do something with
> the dynamic linking support, add stuff to the libdebugger, or basically
> anything else: Just ask whether someone knows a topic in that area or is
> interested in mentoring one you suggest. Most likely the mailing list
> will become quite a bit more active again in about a week.
>
Once I finish with the raspberry pi, I will try to port RTEMS for esp32. I
have that board,
It has quite a lot of features and really good documentation. It is based
on xtensa CPU.
https://devel.rtems.org/wiki/TBR/UserManual/SupportedCPUs and is under
RTEMS potential port.

>
> >
> > > On Dec 28, 2019, at 05:12 , Christian Mauderer  > <mailto:l...@c-mauderer.de>> wrote:
> > >
> > > On 28/12/2019 07:12, Niteesh wrote:
> > >>
> > >>
> > >> On Sat, 28 Dec, 2019, 3:51 AM Christian Mauderer,
> > mailto:l...@c-mauderer.de>
> > >> <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> wrote:
> > >>
> > >>On 27/12/2019 19:06, Niteesh wrote:
> > >>> Is there so

Re: [PATCH v3] Raspberrypi: updated the console interface.

[Niteesh]

On Mon, Dec 30, 2019 at 6:56 PM Christian Mauderer 
wrote:

> On 30/12/2019 09:21, Niteesh wrote:
> > I just looked at the dts files for rpi4, the uart 0, uart 1 are the
> > same, the additional 4 uarts are in different pins and can be used
> > simultaneously. They are all pl011 and are disabled by default, and are
> > enabled using overlays in linux. Do you want to handle then now or
> > sometime later?
>
> I think currently you only have a RPi3 to test so optimize for that
> case. I'm not even sure whether the RPi4 would be binary compatible?
>
> >
> >
> > On Mon, 30 Dec, 2019, 1:20 PM Niteesh,  > <mailto:gsnb...@gmail.com>> wrote:
> >
> > On Mon, 30 Dec, 2019, 2:07 AM Christian Mauderer,
> > mailto:l...@c-mauderer.de>> wrote:
> >
> > I assume you want suggestions regarding this code rather than the
> > original patch?
> >
> > One suggestion: If you post code please try to use a mail
> > program that
> > keeps the indentation. It's hard to read in this form. But
> > that's most
> > likely not the suggestion you searched for ;-)
> >
> > On 29/12/2019 19:48, Niteesh wrote:
> > > I am not happy with my code at all, I can please provide some
> > suggestions.
> > >
> > > On Mon, Dec 30, 2019 at 12:17 AM Niteesh  > <mailto:gsnb...@gmail.com>
> > > <mailto:gsnb...@gmail.com <mailto:gsnb...@gmail.com>>> wrote:
> > >
> > > arm_pl011_context pl011_context;
> > > rpi_fb_context fb_context;
> >
> > Is it sure that we only ever have one UART of each type?
> > Otherwise some
> > dynamic handling (allocating the memory for the context) might
> > would be
> > necessary. I think the chip has only these two modules? In that
> case
> > this is OK for now.
> >
> > I just checked the uarts for rpi4, it has 6uarts not sure which
> > model they are though.
> > My idea is to call all the uart register functions, register_pl011,
> > register_aux or register_xxx inside uart_probe which will see if
> > they can handle that particular node. If not they just return. The
> > FB is registered seperately in the console_initialise. Are you okay
> > with or would like to change something?
>
> That is OK. Handling for the multiple UARTS in RPi4 can be added later.
> It wouldn't be a huge change and it's a lot simpler if you already have
> a running support for the RPi3.
>
> >
> >
> > > char uart_instance[20];
> > >
> >
> > A global just to pass a name around? Would it be possible to
> > search for
> > a more elegant solution?
> >
> > I first was setting the name for the uarts from the fdt property
> > itself. In fdt, the pl011 is uart0 and aux is uart1. So the correct
> > path name is set from the fdt property itself. For eg: if the
> > current node is uart0 it will be /dev/ttyS0 and ttyS1 if uart1. Is
> > this approach fine?
>
> Is there a reason that you translate from uart0 to ttyS0? You could just
> name them tty so you would get ttyuart0 and ttyuart1 or
> ttyserial0 and ttyserial1.
>
I thought it is how we name the serial drivers.

> How do you go from the compatible string to the aliases in the fdt? Or
> do you search for the aliases and only check the compatible?
>

the register_uart function's search the aliases for a compatible device.

Is there any chance we can create names that can be used to parse the
> cmdline.txt directly? I found the namings ttyAMA0 and serial0 in there:
> https://elinux.org/RPi_cmdline.txt and
> https://www.raspberrypi.org/documentation/configuration/cmdline-txt.md

I really didn't get you, can you elaborate a bit more.

>
>
> >
> > >
> > > static void output_char_serial(char c)
> > > {
> > > arm_pl011_write_polled(&pl011_context.base, c);
> > > }
> > >
> > > void output_char_fb(char c)
> > > {
> > > fbcons_write_polled(&fb_context.base, c);
> > > }
> > >
> > >
> > > static void *get_reg_of_node(const void *fdt, int node)
> > > {
> > > int len;
> > > const uint32_t *val

Re: [PATCH v4] Raspberrypi: updated the console interface.

[Niteesh]

Just to make sure that console_initialize and uart_probe are being
called, I manually initialized the pl011 context to print something on
serial. But they never got called. Can you just make sure that if I am
missing something?

While going through the messages from devel-request, Joel mentioned about
qemu4 rsb package
how is it different from the official qemu?

On Mon, Dec 30, 2019 at 11:53 PM G S Niteesh  wrote:

> The patch updates the older console interface used by the BSP,
> to newer one. It also replaces the custom usart(PL011) driver
> with arm-pl011. The fb function's signatures where also changed
> to accommodate with interface update.
> Update #3034
> ---
>  bsps/arm/raspberrypi/console/console-config.c | 186 ++
>  bsps/arm/raspberrypi/console/console_select.c | 114 ---
>  bsps/arm/raspberrypi/console/fbcons.c |  78 
>  bsps/arm/raspberrypi/console/usart.c  | 167 
>  bsps/arm/raspberrypi/include/bsp/fbcons.h |  21 +-
>  .../arm/raspberrypi/include/bsp/raspberrypi.h |  48 ++---
>  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
>  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   8 +-
>  8 files changed, 220 insertions(+), 407 deletions(-)
>  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
>  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
>
> diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> index d2186c918b..021428ff4b 100644
> --- a/bsps/arm/raspberrypi/console/console-config.c
> +++ b/bsps/arm/raspberrypi/console/console-config.c
> @@ -19,50 +19,164 @@
>   */
>
>  #include 
> +#include 
>
> -#include 
>
> -#include 
> -#include 
> -#include 
> +#include 
>  #include 
> +#include 
> +#include 
>  #include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +arm_pl011_context pl011_context;
> +rpi_fb_context fb_context;
> +
> +static void output_char_serial(char c)
> +{
> +  arm_pl011_write_polled(&pl011_context.base, c);
> +}
> +
> +void output_char_fb(char c)
> +{
> +  fbcons_write_polled(&fb_context.base, c);
> +}
>
> -console_tbl Console_Configuration_Ports [] = {
> -{
> -  .sDeviceName = "/dev/ttyS0",
> -  .deviceType = SERIAL_CUSTOM,
> -  .pDeviceFns = &bcm2835_usart_fns,
> -  .deviceProbe = NULL,
> -  .pDeviceFlow = NULL,
> -  .ulCtrlPort1 = BCM2835_UART0_BASE,
> -  .ulCtrlPort2 = 0,
> -  .ulClock = USART0_DEFAULT_BAUD,
> -  .ulIntVector = BCM2835_IRQ_ID_UART
> -},
> -{
> -  .sDeviceName ="/dev/fbcons",
> -  .deviceType = SERIAL_CUSTOM,
> -  .pDeviceFns = &fbcons_fns,
> -  .deviceProbe = fbcons_probe,
> -  .pDeviceFlow = NULL,
> -},
> -};
> -
> -#define PORT_COUNT \
> -  (sizeof(Console_Configuration_Ports) \
> -/ sizeof(Console_Configuration_Ports [0]))
> -
> -unsigned long Console_Configuration_Count = PORT_COUNT;
> -
> -static void output_char(char c)
> +
> +static void *get_reg_of_node(const void *fdt, int node)
>  {
> -  const console_fns *con =
> -Console_Configuration_Ports [Console_Port_Minor].pDeviceFns;
> +  int len;
> +  const uint32_t *val;
> +
> +  val = fdt_getprop(fdt, node, "reg", &len);
> +  if (val == NULL || len < 4) {
> +return NULL;
> +  }
>
> -  con->deviceWritePolled((int) Console_Port_Minor, c);
> +  return (void *) fdt32_to_cpu(val[0]);
>  }
>
> -BSP_output_char_function_type BSP_output_char = output_char;
> +static void register_arm_pl011(
> +  const void *fdt,
> +  const char *serial
> +)
> +{
> +  arm_pl011_context *ctx = &pl011_context;
> +  int node;
> +
> +  if (strcmp(serial, "uart0") == 0) {
> +
> +rtems_termios_device_context_initialize(&ctx->base, "UART");
> +node = fdt_path_offset(fdt, serial);
> +ctx->regs = get_reg_of_node(fdt, node);
> +  }
> +
> +  rtems_termios_device_install(
> +"/dev/ttyuart0",
> +&arm_pl011_fns,
> +NULL,
> +&pl011_context.base
> +  );
> +}
> +
> +static void register_fb( void )
> +{
> +  if (fbcons_probe(&fb_context.base) == true) {
> +rtems_termios_device_install(
> +  "/dev/fbcons",
> +  &fbcons_fns,
> +  NULL,
> +  &fb_context.base);
> +  }
> +}
> +
> +static void console_select( const char *console )
> +{
> +  const char *opt;
> +
> +  opt = rpi_cmdline_get_arg("--console=");
> +
> +  if ( opt ) {
> +if ( 

Re: [PATCH v4] Raspberrypi: updated the console interface.

[Niteesh]

Any other suggestions with the code or are happy with it?

On Tue, Dec 31, 2019 at 1:13 AM Christian Mauderer 
wrote:

> On 30/12/2019 19:32, Niteesh wrote:
> > Just to make sure that console_initialize and uart_probe are being
> > called, I manually initialized the pl011 context to print something on
> > serial. But they never got called. Can you just make sure that if I am
> > missing something?
>
> I don't think that you are missing something but the executable is
> missing something: The functions are not linked into it.
>
> C linker can be an odd thing: It links only object files that are
> referenced. You seem to have no reference to console-config.c/o from
> anywhere else.
>
> RTEMS_SYSINIT_ITEM(
>   uart_probe,
>   RTEMS_SYSINIT_BSP_START,
>   RTEMS_SYSINIT_ORDER_LAST
> );
>
> will be only added to the linker set if the file is linked in anyway.
>
> That is a bit anoying. For the imx BSP there is a UART drain function
> that is called from somewhere else. Thats enough to bring the file in.
>
> I think you'll need to add a reference from somewhere or move that stuff
> into another file that is referenced.
>
> If you have some init function that has to be called in every case you
> can call it from some other c file where it would fit too.
>
> Otherwise it might is necessary to construct some odd stuff. I'm not
> sure whether we already had a case like this. Most likely it would be
> necessary to use a RTEMS_LINKER_ROSET_ITEM_REFERENCE for the
> SYSINIT_ITEM. Maybe to define a new RTEMS_SYSINIT_ITEM_REFERENCE or
> simmilar. This should be definitively a separate commit. Please ask
> again if you have to go that way.
>
> >
> > While going through the messages from devel-request, Joel mentioned
> > about qemu4 rsb package
> > how is it different from the official qemu?
> >
> > On Mon, Dec 30, 2019 at 11:53 PM G S Niteesh  > <mailto:gsnb...@gmail.com>> wrote:
> >
> > The patch updates the older console interface used by the BSP,
> > to newer one. It also replaces the custom usart(PL011) driver
> > with arm-pl011. The fb function's signatures where also changed
> > to accommodate with interface update.
> > Update #3034
> > ---
> >  bsps/arm/raspberrypi/console/console-config.c | 186
> ++
> >  bsps/arm/raspberrypi/console/console_select.c | 114 ---
> >  bsps/arm/raspberrypi/console/fbcons.c |  78 
> >  bsps/arm/raspberrypi/console/usart.c  | 167 
> >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  21 +-
> >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  48 ++---
> >  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
> >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   8 +-
> >  8 files changed, 220 insertions(+), 407 deletions(-)
> >  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
> >  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
> >
> > diff --git a/bsps/arm/raspberrypi/console/console-config.c
> > b/bsps/arm/raspberrypi/console/console-config.c
> > index d2186c918b..021428ff4b 100644
> > --- a/bsps/arm/raspberrypi/console/console-config.c
> > +++ b/bsps/arm/raspberrypi/console/console-config.c
> > @@ -19,50 +19,164 @@
> >   */
> >
> >  #include 
> > +#include 
> >
> > -#include 
> >
> > -#include 
> > -#include 
> > -#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +arm_pl011_context pl011_context;
> > +rpi_fb_context fb_context;
>
> These could be static.
>
> > +
> > +static void output_char_serial(char c)
> > +{
> > +  arm_pl011_write_polled(&pl011_context.base, c);
> > +}
> > +
> > +void output_char_fb(char c)
> > +{
> > +  fbcons_write_polled(&fb_context.base, c);
> > +}
> >
> > -console_tbl Console_Configuration_Ports [] = {
> > -{
> > -  .sDeviceName = "/dev/ttyS0",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = &bcm2835_usart_fns,
> > -  .deviceProbe = NULL,
> > -  .pDeviceFlow = NULL,
> > -  .ulCtrlP

Re: [PATCH v4] Raspberrypi: updated the console interface.

[Niteesh]

On Tue, Dec 31, 2019 at 1:13 AM Christian Mauderer 
wrote:

> On 30/12/2019 19:32, Niteesh wrote:
> > Just to make sure that console_initialize and uart_probe are being
> > called, I manually initialized the pl011 context to print something on
> > serial. But they never got called. Can you just make sure that if I am
> > missing something?
>
> I don't think that you are missing something but the executable is
> missing something: The functions are not linked into it.
>
> C linker can be an odd thing: It links only object files that are
> referenced. You seem to have no reference to console-config.c/o from
> anywhere else.
>
> RTEMS_SYSINIT_ITEM(
>   uart_probe,
>   RTEMS_SYSINIT_BSP_START,
>   RTEMS_SYSINIT_ORDER_LAST
> );
>
> will be only added to the linker set if the file is linked in anyway.
>
> That is a bit anoying. For the imx BSP there is a UART drain function
> that is called from somewhere else. Thats enough to bring the file in.
>
> I think you'll need to add a reference from somewhere or move that stuff
> into another file that is referenced.
>
> If you have some init function that has to be called in every case you
> can call it from some other c file where it would fit too.
>
> Otherwise it might is necessary to construct some odd stuff. I'm not
> sure whether we already had a case like this. Most likely it would be
> necessary to use a RTEMS_LINKER_ROSET_ITEM_REFERENCE for the
> SYSINIT_ITEM. Maybe to define a new RTEMS_SYSINIT_ITEM_REFERENCE or
> simmilar. This should be definitively a separate commit. Please ask
> again if you have to go that way.

I didn't understand the above part. So what I did was created a dummy
function in console-config.c
and referenced in places that I know we're going to be called. But still,
it didn't work.

>
>
>
> > While going through the messages from devel-request, Joel mentioned
> > about qemu4 rsb package
> > how is it different from the official qemu?
> >
> > On Mon, Dec 30, 2019 at 11:53 PM G S Niteesh  > <mailto:gsnb...@gmail.com>> wrote:
> >
> > The patch updates the older console interface used by the BSP,
> > to newer one. It also replaces the custom usart(PL011) driver
> > with arm-pl011. The fb function's signatures where also changed
> > to accommodate with interface update.
> > Update #3034
> > ---
> >  bsps/arm/raspberrypi/console/console-config.c | 186
> ++
> >  bsps/arm/raspberrypi/console/console_select.c | 114 ---
> >  bsps/arm/raspberrypi/console/fbcons.c |  78 
> >  bsps/arm/raspberrypi/console/usart.c  | 167 
> >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  21 +-
> >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  48 ++---
> >  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
> >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   8 +-
> >  8 files changed, 220 insertions(+), 407 deletions(-)
> >  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
> >  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
> >
> > diff --git a/bsps/arm/raspberrypi/console/console-config.c
> > b/bsps/arm/raspberrypi/console/console-config.c
> > index d2186c918b..021428ff4b 100644
> > --- a/bsps/arm/raspberrypi/console/console-config.c
> > +++ b/bsps/arm/raspberrypi/console/console-config.c
> > @@ -19,50 +19,164 @@
> >   */
> >
> >  #include 
> > +#include 
> >
> > -#include 
> >
> > -#include 
> > -#include 
> > -#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +arm_pl011_context pl011_context;
> > +rpi_fb_context fb_context;
>
> These could be static.
>
> > +
> > +static void output_char_serial(char c)
> > +{
> > +  arm_pl011_write_polled(&pl011_context.base, c);
> > +}
> > +
> > +void output_char_fb(char c)
> > +{
> > +  fbcons_write_polled(&fb_context.base, c);
> > +}
> >
> > -console_tbl Console_Configuration_Ports [] = {
> > -{
> > -  .sDeviceName = "/dev/ttyS0",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = &bcm2835_u

Re: [PATCH v4] Raspberrypi: updated the console interface.

[Niteesh]

It works now, the functions are getting called when used with fileio.exe.
The function bsp_start wants to print information about the board, but the
console
initialization function is called after bsp_start, assuming that the FDT
works it still
crash since the console still isn't initialized, one way of fixing this
would be to add uart_probe into
output_char just like in imx, or we could move the printing to somewhere
else.

On Tue, Dec 31, 2019 at 4:08 PM Christian Mauderer 
wrote:

>
>
> On 31/12/2019 11:37, Christian Mauderer wrote:
> > On 31/12/2019 06:11, Niteesh wrote:
> >> On Tue, Dec 31, 2019 at 1:13 AM Christian Mauderer  >> <mailto:l...@c-mauderer.de>> wrote:
> >>
> >> On 30/12/2019 19:32, Niteesh wrote:
> >> > Just to make sure that console_initialize and uart_probe are being
> >> > called, I manually initialized the pl011 context to print
> something on
> >> > serial. But they never got called. Can you just make sure that if
> I am
> >> > missing something?
> >>
> >> I don't think that you are missing something but the executable is
> >> missing something: The functions are not linked into it.
> >>
> >> C linker can be an odd thing: It links only object files that are
> >> referenced. You seem to have no reference to console-config.c/o from
> >> anywhere else.
> >>
> >> RTEMS_SYSINIT_ITEM(
> >>   uart_probe,
> >>   RTEMS_SYSINIT_BSP_START,
> >>   RTEMS_SYSINIT_ORDER_LAST
> >> );
> >>
> >> will be only added to the linker set if the file is linked in
> anyway.
> >>
> >> That is a bit anoying. For the imx BSP there is a UART drain
> function
> >> that is called from somewhere else. Thats enough to bring the file
> in.
> >>
> >> I think you'll need to add a reference from somewhere or move that
> stuff
> >> into another file that is referenced.
> >>
> >> If you have some init function that has to be called in every case
> you
> >> can call it from some other c file where it would fit too.
> >>
> >> Otherwise it might is necessary to construct some odd stuff. I'm not
> >> sure whether we already had a case like this. Most likely it would
> be
> >> necessary to use a RTEMS_LINKER_ROSET_ITEM_REFERENCE for the
> >> SYSINIT_ITEM. Maybe to define a new RTEMS_SYSINIT_ITEM_REFERENCE or
> >> simmilar. This should be definitively a separate commit. Please ask
> >> again if you have to go that way.
> >>
> >> I didn't understand the above part. So what I did was created a dummy
> >> function in console-config.c
> >> and referenced in places that I know we're going to be called. But
> >> still, it didn't work.
> >>
> >
> > That's a really mean bug to find:
> >
> > 1. My assumption was wrong. The file is linked in. Most likely due to
> > BSP_output_char which is defined in this file.
> >
> > 2. Please remove console-termios-init.c. It would define the same
> > console_initialize() function.
>
> Just to be clear: Remove it from the
> c/src/lib/libbsp/arm/raspberrypi/Makefile.am file.
>
> >
> > 3. The real proble just caused a warning which was a bit hard to spot:
> > The compile doesn't know RTEMS_SYSINIT_ITEM. It thinks it's a function
> > body and warns that it defaults the return type to int. In other words:
> > You missed to include . If you add that the
> > RTEMS_SYSINIT_ITEM works and uart_probe is linked in.
> >
> > 4. console_initialize is still not used. It is really hard to spot why:
> > Most of the tests only use the configuration:
> >
> > CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
> >
> > This is a simplified polled console driver. From the samples only
> > capture, fileio and pppd are using the normal console with:
> >
> > CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> >
> > So only for these three the console_initialize will be called.
> >
> > By the way: You can use objdump to analyze your elf-files. For example
> > to get a symbol table use:
> >
> > arm-rtems5-objdump -t path/to/ticker.exe
> >
> > To get the disassembled code with intermixed c-sources use
> >
> > arm-rtems5-objdump -dS path/to/ticker.exe
> >
> > That's very usefull to find whether a symbol is linked in or not.
> >
> >>
> >&

Re: [PATCH v4] Raspberrypi: updated the console interface.

[Niteesh]

Good news, The FDT works. For testing purposes, I used a different DTB file
provided by
raspberrpi foundation. It has a different structure than the DTB from
FreeBSD, so I modified the
initialization code a little bit, but anyhow it works, the registers are
initialized from the DTB file. But they are
virtual addresses we need to offset them before initializing the registers.

(gdb) p pl011_context
$23 = {base = {lock = {interrupt = {}, mutex = {_Queue =
{_Lock = {_next_ticket = 0,
_now_serving = 0}, _heads = 0x0, _owner = 0x0, _name = 0x0}}},
lock_acquire = 0x2095d1 ,
lock_release = 0x2095e1 },*
regs = 0x7e201000*, irq = 0,
  initial_baud = 0}
(gdb)

I will add the offset function, and send in the patch. I am also planning
to replace a manual search with
fdt_node_offset_by_compatible.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v4] Raspberrypi: updated the console interface.

[Niteesh]

How to turn off optimizations, while debugging some of the variables get
optimized out.

On Wed, Jan 1, 2020 at 12:02 PM Niteesh  wrote:

> Good news, The FDT works. For testing purposes, I used a different DTB
> file provided by
> raspberrpi foundation. It has a different structure than the DTB from
> FreeBSD, so I modified the
> initialization code a little bit, but anyhow it works, the registers are
> initialized from the DTB file. But they are
> virtual addresses we need to offset them before initializing the registers.
>
> (gdb) p pl011_context
> $23 = {base = {lock = {interrupt = {}, mutex = {_Queue =
> {_Lock = {_next_ticket = 0,
> _now_serving = 0}, _heads = 0x0, _owner = 0x0, _name = 0x0}}},
> lock_acquire = 0x2095d1 ,
> lock_release = 0x2095e1 },*
> regs = 0x7e201000*, irq = 0,
>   initial_baud = 0}
> (gdb)
>
> I will add the offset function, and send in the patch. I am also planning
> to replace a manual search with
> fdt_node_offset_by_compatible.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v5] Raspberrypi: updated the console interface.

[Niteesh]

Christian, did you take a look at this?

On Wed, 1 Jan, 2020, 2:45 PM G S Niteesh,  wrote:

> Replaced the older console api with newer FDT based
> console driver.
> Replaces the custom pl011 driver with RTEMS arm-pl011
> driver.
> ---
>  bsps/arm/raspberrypi/console/console-config.c | 161 +
>  bsps/arm/raspberrypi/console/console_select.c | 114 
>  bsps/arm/raspberrypi/console/fbcons.c |  78 
>  bsps/arm/raspberrypi/console/usart.c  | 167 --
>  bsps/arm/raspberrypi/include/bsp.h|   4 +
>  bsps/arm/raspberrypi/include/bsp/fbcons.h |  21 ++-
>  .../arm/raspberrypi/include/bsp/raspberrypi.h |  64 +++
>  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
>  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   7 +-
>  c/src/lib/libbsp/arm/raspberrypi/configure.ac |  13 ++
>  10 files changed, 228 insertions(+), 406 deletions(-)
>  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
>  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
>
> diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> index d2186c918b..c47021e54e 100644
> --- a/bsps/arm/raspberrypi/console/console-config.c
> +++ b/bsps/arm/raspberrypi/console/console-config.c
> @@ -19,50 +19,145 @@
>   */
>
>  #include 
> +#include 
> +#include 
>
> -#include 
>
> -#include 
> -#include 
> -#include 
> +#include 
>  #include 
> +#include 
> +#include 
>  #include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
>
> -console_tbl Console_Configuration_Ports [] = {
> -{
> -  .sDeviceName = "/dev/ttyS0",
> -  .deviceType = SERIAL_CUSTOM,
> -  .pDeviceFns = &bcm2835_usart_fns,
> -  .deviceProbe = NULL,
> -  .pDeviceFlow = NULL,
> -  .ulCtrlPort1 = BCM2835_UART0_BASE,
> -  .ulCtrlPort2 = 0,
> -  .ulClock = USART0_DEFAULT_BAUD,
> -  .ulIntVector = BCM2835_IRQ_ID_UART
> -},
> -{
> -  .sDeviceName ="/dev/fbcons",
> -  .deviceType = SERIAL_CUSTOM,
> -  .pDeviceFns = &fbcons_fns,
> -  .deviceProbe = fbcons_probe,
> -  .pDeviceFlow = NULL,
> -},
> -};
> -
> -#define PORT_COUNT \
> -  (sizeof(Console_Configuration_Ports) \
> -/ sizeof(Console_Configuration_Ports [0]))
> -
> -unsigned long Console_Configuration_Count = PORT_COUNT;
> +#include 
> +#include 
> +
> +arm_pl011_context pl011_context;
> +
> +rpi_fb_context fb_context;
> +
> +static void output_char_serial(char c)
> +{
> +  arm_pl011_write_polled(&pl011_context.base, c);
> +}
> +
> +void output_char_fb(char c)
> +{
> +  fbcons_write_polled(&fb_context.base, c);
> +}
> +
> +
> +static void *get_reg_of_node(const void *fdt, int node)
> +{
> +  int len;
> +  const uint32_t *val;
> +
> +  val = fdt_getprop(fdt, node, "reg", &len);
> +  if (val == NULL || len < 4) {
> +return NULL;
> +  }
> +
> +  return (void *) fdt32_to_cpu(val[0]);
> +}
> +
> +static void init_ctx_arm_pl011(
> +  const void *fdt,
> +  int node
> +)
> +{
> +  arm_pl011_context *ctx = &pl011_context;
> +  rtems_termios_device_context_initialize(&ctx->base, "UART");
> +  ctx->regs = BUS_TO_PHY(get_reg_of_node(fdt, node));
> +}
> +
> +static void register_fb( void )
> +{
> +  if (fbcons_probe(&fb_context.base) == true) {
> +rtems_termios_device_install(
> +  "/dev/fbcons",
> +  &fbcons_fns,
> +  NULL,
> +  &fb_context.base);
> +  }
> +}
> +
> +static void console_select( const char *console )
> +{
> +  const char *opt;
> +
> +  opt = rpi_cmdline_get_arg("--console=");
> +
> +  if ( opt ) {
> +if ( strncmp( opt, "fbcons", sizeof( "fbcons" ) - 1 ) == 0 ) {
> +  if ( rpi_video_is_initialized() > 0 ) {
> +BSP_output_char = output_char_fb;
> +link("/dev/fbcons", CONSOLE_DEVICE_NAME);
> +return ;
> +  }
> +}else{
> +  if ( console == NULL ){
> +bsp_fatal( BSP_FATAL_CONSOLE_NO_DEV );
> +  }
> +  link("/dev/ttyuart0", CONSOLE_DEVICE_NAME);
> +}
> +  }
> +  BSP_output_char = output_char_serial;
> +}
> +
> +static void uart_probe(void)
> +{
> +  const void *fdt;
> +  const char *console;
> +  int node;
> +
> +  fdt = bsp_fdt_get();
> +  node = fdt_path_offset(fdt, "/chosen");
> +
> +  console = fdt_getprop(fdt, node, "stdout-path", NULL);
> +
> +  node = fdt_node_offset_by_compat

Re: [PATCH v5] Raspberrypi: updated the console interface.

[Niteesh]

I have described my changes below, just let me know what you think? I will
send
in the patch once you are happy with it.
On Thu, Jan 2, 2020 at 10:07 PM Christian Mauderer 
wrote:

> There is a whitespace error:
>
> > git am ~/\[PATCH\ v5\]\ Raspberrypi:\ updated\ the\ console\
> interface..eml
> Applying: Raspberrypi: updated the console interface.
> /home/christian/rtems/rtems-bbb/.git/modules/rtems/rebase-apply/patch:732:
> trailing whitespace.
>  * @name Bus to Physical address translation
> warning: 1 line adds whitespace errors.
>
> The patch starts to get a good direction. Most of the points I found are
> only small stuff.
>
> On 01/01/2020 10:14, G S Niteesh wrote:
> > Replaced the older console api with newer FDT based
> > console driver.
> > Replaces the custom pl011 driver with RTEMS arm-pl011
> > driver.
> > ---
> >  bsps/arm/raspberrypi/console/console-config.c | 161 +
> >  bsps/arm/raspberrypi/console/console_select.c | 114 
> >  bsps/arm/raspberrypi/console/fbcons.c |  78 
> >  bsps/arm/raspberrypi/console/usart.c  | 167 --
> >  bsps/arm/raspberrypi/include/bsp.h|   4 +
> >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  21 ++-
> >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  64 +++
> >  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
> >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   7 +-
> >  c/src/lib/libbsp/arm/raspberrypi/configure.ac |  13 ++
> >  10 files changed, 228 insertions(+), 406 deletions(-)
> >  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
> >  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
> >
> > diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> > index d2186c918b..c47021e54e 100644
> > --- a/bsps/arm/raspberrypi/console/console-config.c
> > +++ b/bsps/arm/raspberrypi/console/console-config.c
> > @@ -19,50 +19,145 @@
> >   */
> >
> >  #include 
> > +#include 
> > +#include 
> >
> > -#include 
> >
> > -#include 
> > -#include 
> > -#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
>
> Why did you move the bspopts.h from top to bottom?
>
> >
> > -console_tbl Console_Configuration_Ports [] = {
> > -{
> > -  .sDeviceName = "/dev/ttyS0",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = &bcm2835_usart_fns,
> > -  .deviceProbe = NULL,
> > -  .pDeviceFlow = NULL,
> > -  .ulCtrlPort1 = BCM2835_UART0_BASE,
> > -  .ulCtrlPort2 = 0,
> > -  .ulClock = USART0_DEFAULT_BAUD,
> > -  .ulIntVector = BCM2835_IRQ_ID_UART
> > -},
> > -{
> > -  .sDeviceName ="/dev/fbcons",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = &fbcons_fns,
> > -  .deviceProbe = fbcons_probe,
> > -  .pDeviceFlow = NULL,
> > -},
> > -};
> > -
> > -#define PORT_COUNT \
> > -  (sizeof(Console_Configuration_Ports) \
> > -/ sizeof(Console_Configuration_Ports [0]))
> > -
> > -unsigned long Console_Configuration_Count = PORT_COUNT;
> > +#include 
> > +#include 
> > +
> > +arm_pl011_context pl011_context;
> > +
> > +rpi_fb_context fb_context;
> > +
> > +static void output_char_serial(char c)
> > +{
> > +  arm_pl011_write_polled(&pl011_context.base, c);
> > +}
> > +
> > +void output_char_fb(char c)
> > +{
> > +  fbcons_write_polled(&fb_context.base, c);
> > +}
> > +
> > +
> > +static void *get_reg_of_node(const void *fdt, int node)
> > +{
> > +  int len;
> > +  const uint32_t *val;
> > +
> > +  val = fdt_getprop(fdt, node, "reg", &len);
> > +  if (val == NULL || len < 4) {
> > +return NULL;
> > +  }
> > +
> > +  return (void *) fdt32_to_cpu(val[0]);
> > +}
>
> It would be good to make that function more widely available. Other
> drivers will need it too sooner or later. Please follow the convention
> used in imx to add the bsp-name as a prefix. So this will be
> raspberry_get_reg_of_node or bcm2835_get_reg_of_node (I think both
> prefixes are already used in the BSP).
>
using raspberry_get_reg_of_node, neither of them is being used anywhere.

> > +
> > +static void init_ctx_arm_pl011(
> > +  const

Re: [PATCH] bsp/raspberry: Enabled FDT support for console.

[Niteesh]

On Fri, Jan 3, 2020 at 2:26 AM Christian Mauderer 
wrote:

> Sorry, it seems I missed some parts in the last mail. Beneath that I
> caused a misunderstanding again.
>
> On 02/01/2020 20:08, G S Niteesh wrote:
> > Replaced the older console api with newer FDT based
> > console driver.
> > Replaces the custom pl011 driver with RTEMS arm-pl011
> > driver.
> > ---
> >  bsps/arm/raspberrypi/console/console-config.c | 156 
> >  bsps/arm/raspberrypi/console/console_select.c | 114 
> >  bsps/arm/raspberrypi/console/fbcons.c |  78 
> >  bsps/arm/raspberrypi/console/usart.c  | 167 --
> >  bsps/arm/raspberrypi/include/bsp.h|   6 +
> >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  17 +-
> >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  53 ++
> >  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
> >  bsps/arm/raspberrypi/start/bspstart.c |  15 ++
> >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   7 +-
> >  c/src/lib/libbsp/arm/raspberrypi/configure.ac |  13 ++
> >  11 files changed, 225 insertions(+), 406 deletions(-)
> >  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
> >  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
> >
> > diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> > index d2186c918b..c306db439b 100644
> > --- a/bsps/arm/raspberrypi/console/console-config.c
> > +++ b/bsps/arm/raspberrypi/console/console-config.c
> > @@ -19,50 +19,140 @@
> >   */
> >
> >  #include 
> > -
> > -#include 
> > +#include 
> > +#include 
> >
> >  #include 
> > -#include 
> > -#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +arm_pl011_context pl011_context;
> > +
> > +rpi_fb_context fb_context;
> > +
> > +static void output_char_serial(char c)
> > +{
> > +  arm_pl011_write_polled(&pl011_context.base, c);
> > +}
> > +
> > +void output_char_fb(char c)
> > +{
> > +  fbcons_write_polled(&fb_context.base, c);
> > +}
> > +
> > +static void init_ctx_arm_pl011(
> > +  const void *fdt,
> > +  int node
> > +)
> > +{
> > +  arm_pl011_context *ctx = &pl011_context;
> > +  rtems_termios_device_context_initialize(&ctx->base, "UART");
> > +  ctx->regs = raspberrypi_get_reg_of_node(fdt, node);
> > +}
> > +
> > +static void register_fb( void )
> > +{
> > +  if (fbcons_probe(&fb_context.base) == true) {
> > +rtems_termios_device_install(
> > +  "/dev/fbcons",
> > +  &fbcons_fns,
> > +  NULL,
> > +  &fb_context.base);
> > +  }
> > +}
> >
> > -console_tbl Console_Configuration_Ports [] = {
> > -{
> > -  .sDeviceName = "/dev/ttyS0",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = &bcm2835_usart_fns,
> > -  .deviceProbe = NULL,
> > -  .pDeviceFlow = NULL,
> > -  .ulCtrlPort1 = BCM2835_UART0_BASE,
> > -  .ulCtrlPort2 = 0,
> > -  .ulClock = USART0_DEFAULT_BAUD,
> > -  .ulIntVector = BCM2835_IRQ_ID_UART
> > -},
> > -{
> > -  .sDeviceName ="/dev/fbcons",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = &fbcons_fns,
> > -  .deviceProbe = fbcons_probe,
> > -  .pDeviceFlow = NULL,
> > -},
> > -};
> > -
> > -#define PORT_COUNT \
> > -  (sizeof(Console_Configuration_Ports) \
> > -/ sizeof(Console_Configuration_Ports [0]))
> > -
> > -unsigned long Console_Configuration_Count = PORT_COUNT;
> > +static void console_select( void )
> > +{
> > +  const char *opt;
> > +  const void *fdt;
> > +  const char *console;
> > +  int node;
> > +
> > +  fdt = bsp_fdt_get();
> > +  node = fdt_path_offset(fdt, "/chosen");
> > +
> > +  console = fdt_getprop(fdt, node, "stdout-path", NULL);
>
> Sorry that I missed that on your earlier patch:
>
> I had a look at all the "chosen" nodes in the dtb files here:
>
>
> https://github.com/raspberrypi/firmware/tree/0c01dbefba45a08c47f8538d5a071a0fba6b7e83/boot


I was using the dtb file from freeBSD, that one had the chosen node.
https://github.co

Re: [PATCH] bsp/raspberry: Enabled FDT support for console.

[Niteesh]

On Fri, Jan 3, 2020 at 1:51 PM Christian Mauderer 
wrote:

> On 03/01/2020 04:50, Niteesh wrote:
> > On Fri, Jan 3, 2020 at 2:26 AM Christian Mauderer  > <mailto:l...@c-mauderer.de>> wrote:
> >
> > Sorry, it seems I missed some parts in the last mail. Beneath that I
> > caused a misunderstanding again.
> >
> > On 02/01/2020 20:08, G S Niteesh wrote:
> > > Replaced the older console api with newer FDT based
> > > console driver.
> > > Replaces the custom pl011 driver with RTEMS arm-pl011
> > > driver.
> > > ---
> > >  bsps/arm/raspberrypi/console/console-config.c | 156
> 
> > >  bsps/arm/raspberrypi/console/console_select.c | 114 
> > >  bsps/arm/raspberrypi/console/fbcons.c |  78 
> > >  bsps/arm/raspberrypi/console/usart.c  | 167
> > --
> > >  bsps/arm/raspberrypi/include/bsp.h|   6 +
> > >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  17 +-
> > >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  53 ++
> > >  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
> > >  bsps/arm/raspberrypi/start/bspstart.c |  15 ++
> > >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   7 +-
> > >  c/src/lib/libbsp/arm/raspberrypi/configure.ac
> > <http://configure.ac> |  13 ++
> > >  11 files changed, 225 insertions(+), 406 deletions(-)
> > >  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
> > >  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
> > >
> > > diff --git a/bsps/arm/raspberrypi/console/console-config.c
> > b/bsps/arm/raspberrypi/console/console-config.c
> > > index d2186c918b..c306db439b 100644
> > > --- a/bsps/arm/raspberrypi/console/console-config.c
> > > +++ b/bsps/arm/raspberrypi/console/console-config.c
> > > @@ -19,50 +19,140 @@
> > >   */
> > >
> > >  #include 
> > > -
> > > -#include 
> > > +#include 
> > > +#include 
> > >
> > >  #include 
> > > -#include 
> > > -#include 
> > > +#include 
> > >  #include 
> > > +#include 
> > > +#include 
> > >  #include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +arm_pl011_context pl011_context;
> > > +
> > > +rpi_fb_context fb_context;
> > > +
> > > +static void output_char_serial(char c)
> > > +{
> > > +  arm_pl011_write_polled(&pl011_context.base, c);
> > > +}
> > > +
> > > +void output_char_fb(char c)
> > > +{
> > > +  fbcons_write_polled(&fb_context.base, c);
> > > +}
> > > +
> > > +static void init_ctx_arm_pl011(
> > > +  const void *fdt,
> > > +  int node
> > > +)
> > > +{
> > > +  arm_pl011_context *ctx = &pl011_context;
> > > +  rtems_termios_device_context_initialize(&ctx->base, "UART");
> > > +  ctx->regs = raspberrypi_get_reg_of_node(fdt, node);
> > > +}
> > > +
> > > +static void register_fb( void )
> > > +{
> > > +  if (fbcons_probe(&fb_context.base) == true) {
> > > +rtems_termios_device_install(
> > > +  "/dev/fbcons",
> > > +  &fbcons_fns,
> > > +  NULL,
> > > +  &fb_context.base);
> > > +  }
> > > +}
> > >
> > > -console_tbl Console_Configuration_Ports [] = {
> > > -{
> > > -  .sDeviceName = "/dev/ttyS0",
> > > -  .deviceType = SERIAL_CUSTOM,
> > > -  .pDeviceFns = &bcm2835_usart_fns,
> > > -  .deviceProbe = NULL,
> > > -  .pDeviceFlow = NULL,
> > > -  .ulCtrlPort1 = BCM2835_UART0_BASE,
> > > -  .ulCtrlPort2 = 0,
> > > -  .ulClock = USART0_DEFAULT_BAUD,
> > > -  .ulIntVector = BCM2835_IRQ_ID_UART
> > > -},
> > > -{
> > > -  .sDeviceName ="/dev/fbcons",
> > > -   

Re: [PATCH] bsp/raspberrypi: Updated the console API.

[Niteesh]

Great, please do have a look at the FDT patch I sent today.
I would like to work on something else now, do you have something
interesting
for me to do?

On Fri, Jan 3, 2020 at 3:39 PM Christian Mauderer 
wrote:

> Hello Niteesh,
>
> looks good to me. The UART works for a Pi1 and a Pi2. The Framebuffer
> console doesn't but it doesn't work either before this patch and as far
> as I can tell you took over the logic correctly. So I don't think this
> patch will break anything that isn't already broken.
>
> I'll give the patch some more days for others to review and if no one
> objects, I'll push it together with the "Enable FDT support" and my two
> patches that fix the SDRAM stuff.
>
> Best regards
>
> Christian
>
> On 03/01/2020 09:26, G S Niteesh wrote:
> > Replaces the legacy termios API with new termios API (#3034)
> > Replaces the custom PL011 serial driver with RTEMS arm-pl011.
> > Update #3034
> > ---
> >  bsps/arm/raspberrypi/console/console-config.c | 148 
> >  bsps/arm/raspberrypi/console/console_select.c | 114 
> >  bsps/arm/raspberrypi/console/fbcons.c |  78 
> >  bsps/arm/raspberrypi/console/usart.c  | 167 --
> >  bsps/arm/raspberrypi/include/bsp.h|   2 +
> >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  17 +-
> >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  54 ++
> >  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
> >  bsps/arm/raspberrypi/start/bspstart.c |  15 ++
> >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   6 +-
> >  10 files changed, 199 insertions(+), 407 deletions(-)
> >  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
> >  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
> >
> > diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> > index d2186c918b..4000fd1c50 100644
> > --- a/bsps/arm/raspberrypi/console/console-config.c
> > +++ b/bsps/arm/raspberrypi/console/console-config.c
> > @@ -19,50 +19,132 @@
> >   */
> >
> >  #include 
> > -
> > -#include 
> > +#include 
> > +#include 
> >
> >  #include 
> > -#include 
> > -#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +#define UART0 "/dev/ttyS0"
> > +#define FBCONS"/dev/fbcons"
> > +
> > +arm_pl011_context pl011_context;
> > +
> > +rpi_fb_context fb_context;
> > +
> > +static void output_char_serial(char c)
> > +{
> > +  arm_pl011_write_polled(&pl011_context.base, c);
> > +}
> > +
> > +void output_char_fb(char c)
> > +{
> > +  fbcons_write_polled(&fb_context.base, c);
> > +}
> >
> > -console_tbl Console_Configuration_Ports [] = {
> > -{
> > -  .sDeviceName = "/dev/ttyS0",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = &bcm2835_usart_fns,
> > -  .deviceProbe = NULL,
> > -  .pDeviceFlow = NULL,
> > -  .ulCtrlPort1 = BCM2835_UART0_BASE,
> > -  .ulCtrlPort2 = 0,
> > -  .ulClock = USART0_DEFAULT_BAUD,
> > -  .ulIntVector = BCM2835_IRQ_ID_UART
> > -},
> > -{
> > -  .sDeviceName ="/dev/fbcons",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = &fbcons_fns,
> > -  .deviceProbe = fbcons_probe,
> > -  .pDeviceFlow = NULL,
> > -},
> > -};
> > -
> > -#define PORT_COUNT \
> > -  (sizeof(Console_Configuration_Ports) \
> > -/ sizeof(Console_Configuration_Ports [0]))
> > -
> > -unsigned long Console_Configuration_Count = PORT_COUNT;
> > +static void init_ctx_arm_pl011(
> > +  const void *fdt,
> > +  int node
> > +)
> > +{
> > +  arm_pl011_context *ctx = &pl011_context;
> > +  rtems_termios_device_context_initialize(&ctx->base, "UART");
> > +  ctx->regs = raspberrypi_get_reg_of_node(fdt, node);
> > +}
> > +
> > +static void register_fb( void )
> > +{
> > +  if (fbcons_probe(&fb_context.base) == true) {
> > +rtems_termios_device_install(
> > +  FBCONS,
> > +  &fbcons_fns,
> > +  NULL,
> > +  &fb_context.base);
> > +  }
> > +}
> > +
> > +static void console_select( void )
&g

Re: [PATCH] bsp/raspberrypi: Updated the console API.

[Niteesh]

On Fri, Jan 3, 2020 at 3:48 PM Christian Mauderer 
wrote:

> On 03/01/2020 11:11, Niteesh wrote:
> > Great, please do have a look at the FDT patch I sent today.
>
> The FDT patch looks OK too. I thought it's clear when I said that I'll
> push it together with this one in a few days.
>

Sorry, I was reading that on mobile and somehow missed it.

> I would like to work on something else now, do you have something
> > interesting
> > for me to do?
>
> That depends on what you want to do. I think your original intention was
> to get the serial console running on the RPi3? So maybe add that?
>

I did try that, but qemu-system-aarch64 doesn't accept exe file formats, I
tried
converting it to .img file, but then it doesn't run. Is there some way to
convert to
get elf files as output instead of exe? Is it possible to convert exe to
elf, maybe we have
to do some symbol table and header manipulation?

It would be also great if you could write down some lines on how to
> start the BSP on qemu or on a real hardware for the manual. It doesn't
> have to be an extensive chapter. Some hints like "use objcopy like
> that..., start qemu like this, ..." can be already very helpful.
>

I will send in a documentation patch on how to run executables in qemu in a
couple of days.

Joel suggested a tester integration for the raspberry BSP on qemu in
> another mail thread.
>

By tester integration, you mean writing a tester.cfg which will automate
testing using
rtems-test right?

You might want to start to discuss your toppic for GSoC in some more
> details. Gedare gave some hints in the other mail thread too.
>

Won't there be any idea's list? because I am literally confused about what
to choose.
Everything seems interesting to me, I just fear if I would pick something
big, that I am
not capable of finishing.
I have gone through previous GSOC projects and have selected a few which I
found
quite interesting to me. I listed them in the other thread* What do you
want to study in GSOC 2020?*
have a look at it.
It is still not clear of what has been accomplished? Based on the feedback
and suggestions from
the community, I will choose, a particular project and start working on it.

But don't hesitate to pick any other topic that picks your eye. I'm not
> giving orders here. Take them just as some hints what could be possible
> from my point of view.
>
> >
> > On Fri, Jan 3, 2020 at 3:39 PM Christian Mauderer  > <mailto:l...@c-mauderer.de>> wrote:
> >
> > Hello Niteesh,
> >
> > looks good to me. The UART works for a Pi1 and a Pi2. The Framebuffer
> > console doesn't but it doesn't work either before this patch and as
> far
> > as I can tell you took over the logic correctly. So I don't think
> this
> > patch will break anything that isn't already broken.
> >
> > I'll give the patch some more days for others to review and if no one
> > objects, I'll push it together with the "Enable FDT support" and my
> two
> > patches that fix the SDRAM stuff.
> >
> > Best regards
> >
> > Christian
> >
> > On 03/01/2020 09:26, G S Niteesh wrote:
> > > Replaces the legacy termios API with new termios API (#3034)
> > > Replaces the custom PL011 serial driver with RTEMS arm-pl011.
> > > Update #3034
> > > ---
> > >  bsps/arm/raspberrypi/console/console-config.c | 148
> 
> > >  bsps/arm/raspberrypi/console/console_select.c | 114 
> > >  bsps/arm/raspberrypi/console/fbcons.c |  78 
> > >  bsps/arm/raspberrypi/console/usart.c  | 167
> > --
> > >  bsps/arm/raspberrypi/include/bsp.h|   2 +
> > >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  17 +-
> > >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  54 ++
> > >  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
> > >  bsps/arm/raspberrypi/start/bspstart.c |  15 ++
> > >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   6 +-
> > >  10 files changed, 199 insertions(+), 407 deletions(-)
> > >  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
> > >  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
> > >
> > > diff --git a/bsps/arm/raspberrypi/console/console-config.c
> > b/bsps/arm/raspberrypi/console/console-config.c
> > > index d2186c918b..4000fd1c50 100644
> > > --- a/bsps/arm/raspberrypi/console/console-config.c
> > > +++ b/bsps/

Re: [PATCH] bsp/raspberrypi: Updated the console API.

[Niteesh]

qemu-system-aarch64 doesn't support elf formats too. I tried running them
but
the qemu is stuck at 0x200. Should I change the cpu type to armv7, but by
default
Rpi3 should run 32bit applications, but not sure about qemu.

On Fri, Jan 3, 2020 at 6:01 PM Niteesh  wrote:

> On Fri, Jan 3, 2020 at 3:48 PM Christian Mauderer 
> wrote:
>
>> On 03/01/2020 11:11, Niteesh wrote:
>> > Great, please do have a look at the FDT patch I sent today.
>>
>> The FDT patch looks OK too. I thought it's clear when I said that I'll
>> push it together with this one in a few days.
>>
>
> Sorry, I was reading that on mobile and somehow missed it.
>
> > I would like to work on something else now, do you have something
>> > interesting
>> > for me to do?
>>
>> That depends on what you want to do. I think your original intention was
>> to get the serial console running on the RPi3? So maybe add that?
>>
>
> I did try that, but qemu-system-aarch64 doesn't accept exe file formats, I
> tried
> converting it to .img file, but then it doesn't run. Is there some way to
> convert to
> get elf files as output instead of exe? Is it possible to convert exe to
> elf, maybe we have
> to do some symbol table and header manipulation?
>
> It would be also great if you could write down some lines on how to
>> start the BSP on qemu or on a real hardware for the manual. It doesn't
>> have to be an extensive chapter. Some hints like "use objcopy like
>> that..., start qemu like this, ..." can be already very helpful.
>>
>
> I will send in a documentation patch on how to run executables in qemu in a
> couple of days.
>
> Joel suggested a tester integration for the raspberry BSP on qemu in
>> another mail thread.
>>
>
> By tester integration, you mean writing a tester.cfg which will automate
> testing using
> rtems-test right?
>
> You might want to start to discuss your toppic for GSoC in some more
>> details. Gedare gave some hints in the other mail thread too.
>>
>
> Won't there be any idea's list? because I am literally confused about what
> to choose.
> Everything seems interesting to me, I just fear if I would pick something
> big, that I am
> not capable of finishing.
> I have gone through previous GSOC projects and have selected a few which I
> found
> quite interesting to me. I listed them in the other thread* What do you
> want to study in GSOC 2020?*
> have a look at it.
> It is still not clear of what has been accomplished? Based on the feedback
> and suggestions from
> the community, I will choose, a particular project and start working on it.
>
> But don't hesitate to pick any other topic that picks your eye. I'm not
>> giving orders here. Take them just as some hints what could be possible
>> from my point of view.
>>
>> >
>> > On Fri, Jan 3, 2020 at 3:39 PM Christian Mauderer > > <mailto:l...@c-mauderer.de>> wrote:
>> >
>> > Hello Niteesh,
>> >
>> > looks good to me. The UART works for a Pi1 and a Pi2. The
>> Framebuffer
>> > console doesn't but it doesn't work either before this patch and as
>> far
>> > as I can tell you took over the logic correctly. So I don't think
>> this
>> > patch will break anything that isn't already broken.
>> >
>> > I'll give the patch some more days for others to review and if no
>> one
>> > objects, I'll push it together with the "Enable FDT support" and my
>> two
>> > patches that fix the SDRAM stuff.
>> >
>> > Best regards
>> >
>> > Christian
>> >
>> > On 03/01/2020 09:26, G S Niteesh wrote:
>> > > Replaces the legacy termios API with new termios API (#3034)
>> > > Replaces the custom PL011 serial driver with RTEMS arm-pl011.
>> > > Update #3034
>> > > ---
>> > >  bsps/arm/raspberrypi/console/console-config.c | 148
>> 
>> > >  bsps/arm/raspberrypi/console/console_select.c | 114 
>> > >  bsps/arm/raspberrypi/console/fbcons.c |  78 
>> > >  bsps/arm/raspberrypi/console/usart.c  | 167
>> > --
>> > >  bsps/arm/raspberrypi/include/bsp.h|   2 +
>> > >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  17 +-
>> > >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  54 ++
>&g

Re: What do you want to study in GSOC 2020?

[Niteesh]

I have gone through previous year works and selected a few topics which I
found
interesting.
1. Basic Support for Trace Compass #3696
<https://devel.rtems.org/ticket/3696>.
2. RTEMS testing tool project #2927 <https://devel.rtems.org/ticket/2927>.
3. Beagle BSP: Add a flattened device tree based initialization #3784
<https://devel.rtems.org/ticket/3784>.
4. BSPs for Simulators #2903 <https://devel.rtems.org/ticket/2903>.
5. Improve the Raspberry Pi BSP #2899 <https://devel.rtems.org/ticket/2899>.

I would like to know what are the future plans for these topics.
What is the current status of USB and ethernet in raspberrypi?
Does the beagle BSP require hardware or is it possible to emulate it?
Last year Vijay Kumar Banerjee worked on analysis and generation of gcov
reports.

On Thu, Jan 2, 2020 at 10:07 PM Gedare Bloom  wrote:

> On Mon, Dec 30, 2019 at 2:47 PM Christian Mauderer 
> wrote:
> >
> > On 30/12/2019 15:45, Niteesh wrote:
> > > On Mon, Dec 30, 2019 at 7:14 PM Christian Mauderer  > > <mailto:l...@c-mauderer.de>> wrote:
> > >
> > > On 30/12/2019 07:25, Niteesh wrote:
> > > >
> > > >
> > > > On Mon, Dec 30, 2019 at 4:44 AM Peter Dufault  > > <mailto:dufa...@hda.com>
> > > > <mailto:dufa...@hda.com <mailto:dufa...@hda.com>>> wrote:
> > > >
> > > >
> > > > Niteesh, what do you want to study?  Go over what most
> > > interests you
> > > > most about working in a real-time environment like RTEMS,
> and not
> > > > about working on the RPI, and look at the earlier GSOC
> projects.
> > > > Propose an ideal project for yourself and get some feedback.
> > >
> > > Peter: Thanks for starting that discussion. I started to focus too
> much
> > > on the running topics about small stuff that can be done as a
> > > preparation.
> > >
> > > >
> > > >  I love learning about how the software and hardware interact, I
> have
> > > > been programming from 9th grade and have a wide variety of
> > > > interests(networking, app development). But recently I took a
> course
> > > > called nandtotetris were we build an 8bit computer from scratch,
> we
> > > > start with NAND gates and finally finish with a Tetris game.
> > >
> > > That sounds like a really nice course. Most likely is ended in a
> bigger
> > > pile of circuit boards to have a running processor ;-)
> > >
> > > It is a free course on
> > > coursera https://www.coursera.org/learn/build-a-computer/home/welcome
> > > do check it out. It's completely simulated in software. But planning to
> > > build it on PCB.
> > >
> > >
> > > > Low-level
> > > > software, systems programming, and operating systems are always
> quite
> > > > fascinating for me. While learning about operating systems, I
> came
> > > > across the concepts of real-time systems. Back then arduino was
> > > the only
> > > > hardware I was having while searching for an RTOS to play with,
> I came
> > > > across RTEMS. RTOS was harder for me to grasp but were always
> > > > interesting, being a critical part of a system, I always wanted
> to
> > > learn
> > > > how they worked from inside. That's what bought me to
> contributing
> > > to RTOS.
> > > > I wanted to contribute to core of RTEMS, but it was a bit complex
> > > for me
> > > > to understand, so I started with driver development for RTEMS.
> > >
> > > That's where I started too. But don't hesitate to pick a more
> complex
> > > topic if you are interested in it. From what I've seen you can
> read and
> > > understand existing code quite fast compared to some other GSoC
> students
> > > we had. So I would say that you have a good chance to manage
> complex
> > > topics too.
> > >
> > > Thank you, it's quite good to hear.
> > >
> > > > After going through some of the previous GSOC projects, BSP
> > > development
> > > > and real-time tracing are what I find interesting. While also
> > > converting
> > > > the console driver of rpi to FDT based one, *Christian Mauderer
> > > > *explained how
> > > > FDT w

Re: [PATCH] bsp/raspberrypi: Updated the console API.

[Niteesh]

On Fri, Jan 3, 2020 at 7:32 PM Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

> Hi Niteesh,
> A few formatting suggestions:
>
>>
>> diff --git a/bsps/arm/raspberrypi/console/console-config.c
>> b/bsps/arm/raspberrypi/console/console-config.c
>> index d2186c918b..4000fd1c50 100644
>> --- a/bsps/arm/raspberrypi/console/console-config.c
>> +++ b/bsps/arm/raspberrypi/console/console-config.c
>> @@ -19,50 +19,132 @@
>>   */
>>
>>  #include 
>> -
>> -#include 
>>
> You removed it here and added it below
>
>> +#include 
>> +#include 
>>
>>  #include 
>> -#include 
>> -#include 
>>
> same here
>
>> +#include 
>>  #include 
>> +#include 
>>
> added here ^
>
>> +#include 
>>  #include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>
> here
>
Is there any particular reason for doing it, or is it just a preference?

> This is just a small change and I would suggest you wait for at least a day
> before sending a v2 of the patch so that you can add changes suggested
> by other people (if any). Congrats on getting it working ;-)
>
Thank you.

> Best,
> Vijay
>
>> +
>> +#define UART0 "/dev/ttyS0"
>> +#define FBCONS"/dev/fbcons"
>> +
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: What do you want to study in GSOC 2020?

[Niteesh]

On Fri, Jan 3, 2020 at 7:30 PM Christian Mauderer 
wrote:

> On 03/01/2020 13:49, Niteesh wrote:
> > I have gone through previous year works and selected a few topics which
> > I found
> > interesting.
> > 1. Basic Support for Trace Compass #3696
> > <https://devel.rtems.org/ticket/3696>.
>
> A basic support has been added last year and Sebastian extended that
> quite a bit because we had a customer who needed it. I'm not sure what
> the current state is and whether there are tasks left that could be done
> in a GSoC project.
>
> > 2. RTEMS testing tool project #2927 <https://devel.rtems.org/ticket/2927
> >.
>
> No idea what the status is. Chris?
>
> > 3. Beagle BSP: Add a flattened device tree based initialization #3784
> > <https://devel.rtems.org/ticket/3784>.
>
> That one is open. It would include adding some infrastructure for fdt
> based drivers. In theory you could do the same project for raspberry or
> any other board.
>
> Please note Gedares comment from the previous mail:
>
> > Infrastructure projects are nice (FDT, dynamic linking, debugger,
> > tracer) but need to be clearly defined ahead of time and discussed
> > thoroughly with the community, or you risk ending up in the "long
> > tedious discussions" when you should be coding.
>
>
> > 4. BSPs for Simulators #2903 <https://devel.rtems.org/ticket/2903>.
>
> That's always open.
>
> Some simulators are easy because the board is already supported and you
> only have to find out how to start it. For these a tester integration is
> a good target. But most likely that's only small stuff and should be
> only one part of a project.
>
> Other simulators are not supported yet. In that case you have to write
> some drivers which can be a good project size.
>
> > 5. Improve the Raspberry Pi BSP #2899 <
> https://devel.rtems.org/ticket/2899>.
>
> You already noted: The raspberry BSP isn't in the best shape. So it's
> quite open for improvement.
>
> I think that there is still some work getting it to run again. We don't
> have something with "*bcm*" in libbsd yet so most likely USB and
> Ethernet are not working yet. Could be still still be a nice task.
>

Why don't we use the driver's from other sources as a reference and create
our
own, for USB https://github.com/Chadderz121/csud this could be used as a
reference, U-boot, and Linux are good sources too. But is it worth the
effort for a
BSP like raspberry pi? There is also a c++ bare metal environment called
circle
https://github.com/rsta2/circle which supports USB(
https://github.com/rsta2/uspi)
and ethernet.

Christian, can you check out this https://github.com/0xabu/qemu/wiki it
partially supports
USB, can you give it a try?

>
> With the difficulties getting it to run on RPi3 or RPi4 that might could
> be also a project. It seems that they are aarch64. Also I was quite
> surprised about it I didn't find a aarch64 BSP. So that would be a new
> port.
>

Rpi3 looks for kernel7.img if it finds one, it boots into 32bit mode, so if
the, offset is the only difference
between rpi2 and rpi3 it should boot without any issues I'll try adding the
AUX uart driver
and see if it boots on Rpi3.

I would also like to discuss about the FDT infrastructure for RTEMS, I
would like to know what are
the requirements, what could be expected in a short span of 3months, what
could be used as a reference
and so on.

Note that an aarch64 port would most likely be observed with argus eyes
> because it has the potential to be a very important port. But don't let
> that keep you bag suggesting it.
>
> >
> > I would like to know what are the future plans for these topics.
> > What is the current status of USB and ethernet in raspberrypi?
> > Does the beagle BSP require hardware or is it possible to emulate it?
>
> I never used an emulator for Beagle. It seems that qemu supported it
> some when:
>
> https://www.cnx-software.com/2011/09/26/beagleboard-emulator-in-ubuntu-with-qemu/
>
> But I didn't find it in current qemu. So most likely it would need
> hardware.
>
> > Last year Vijay Kumar Banerjee worked on analysis and generation of gcov
> > reports.
> >
> > On Thu, Jan 2, 2020 at 10:07 PM Gedare Bloom  > <mailto:ged...@rtems.org>> wrote:
> >
> > On Mon, Dec 30, 2019 at 2:47 PM Christian Mauderer
> > mailto:l...@c-mauderer.de>> wrote:
> > >
> > > On 30/12/2019 15:45, Niteesh wrote:
> > > > On Mon, Dec 30, 2019 at 7:14 PM Christian Mauderer
> > mailto:l.

Re: What do you want to study in GSOC 2020?

[Niteesh]

Finally, I am able to load IMAGES into Rpi3 using u-boot. But didn't
check whether FDT works. I added the AUX driver from my bare-metal
project for testing. I'll replace it with NS16550 soon.
I loaded the fileio example and it prints the board information. Below
is the link to the screenshot
https://ibb.co/cJbFHqz
But it's stuck there, maybe an exception was raised because I didn't
modify the address for another device but not sure! Can you think of
something
which could have caused it?


On Fri, Jan 3, 2020 at 11:07 PM Niteesh  wrote:

> On Fri, Jan 3, 2020 at 7:30 PM Christian Mauderer 
> wrote:
>
>> On 03/01/2020 13:49, Niteesh wrote:
>> > I have gone through previous year works and selected a few topics which
>> > I found
>> > interesting.
>> > 1. Basic Support for Trace Compass #3696
>> > <https://devel.rtems.org/ticket/3696>.
>>
>> A basic support has been added last year and Sebastian extended that
>> quite a bit because we had a customer who needed it. I'm not sure what
>> the current state is and whether there are tasks left that could be done
>> in a GSoC project.
>>
>> > 2. RTEMS testing tool project #2927 <
>> https://devel.rtems.org/ticket/2927>.
>>
>> No idea what the status is. Chris?
>>
>> > 3. Beagle BSP: Add a flattened device tree based initialization #3784
>> > <https://devel.rtems.org/ticket/3784>.
>>
>> That one is open. It would include adding some infrastructure for fdt
>> based drivers. In theory you could do the same project for raspberry or
>> any other board.
>>
>> Please note Gedares comment from the previous mail:
>>
>> > Infrastructure projects are nice (FDT, dynamic linking, debugger,
>> > tracer) but need to be clearly defined ahead of time and discussed
>> > thoroughly with the community, or you risk ending up in the "long
>> > tedious discussions" when you should be coding.
>>
>>
>> > 4. BSPs for Simulators #2903 <https://devel.rtems.org/ticket/2903>.
>>
>> That's always open.
>>
>> Some simulators are easy because the board is already supported and you
>> only have to find out how to start it. For these a tester integration is
>> a good target. But most likely that's only small stuff and should be
>> only one part of a project.
>>
>> Other simulators are not supported yet. In that case you have to write
>> some drivers which can be a good project size.
>>
>> > 5. Improve the Raspberry Pi BSP #2899 <
>> https://devel.rtems.org/ticket/2899>.
>>
>> You already noted: The raspberry BSP isn't in the best shape. So it's
>> quite open for improvement.
>>
>> I think that there is still some work getting it to run again. We don't
>> have something with "*bcm*" in libbsd yet so most likely USB and
>> Ethernet are not working yet. Could be still still be a nice task.
>>
>
> Why don't we use the driver's from other sources as a reference and create
> our
> own, for USB https://github.com/Chadderz121/csud this could be used as a
> reference, U-boot, and Linux are good sources too. But is it worth the
> effort for a
> BSP like raspberry pi? There is also a c++ bare metal environment called
> circle
> https://github.com/rsta2/circle which supports USB(
> https://github.com/rsta2/uspi)
> and ethernet.
>
> Christian, can you check out this https://github.com/0xabu/qemu/wiki it
> partially supports
> USB, can you give it a try?
>
>>
>> With the difficulties getting it to run on RPi3 or RPi4 that might could
>> be also a project. It seems that they are aarch64. Also I was quite
>> surprised about it I didn't find a aarch64 BSP. So that would be a new
>> port.
>>
>
> Rpi3 looks for kernel7.img if it finds one, it boots into 32bit mode, so
> if the, offset is the only difference
> between rpi2 and rpi3 it should boot without any issues I'll try adding
> the AUX uart driver
> and see if it boots on Rpi3.
>
> I would also like to discuss about the FDT infrastructure for RTEMS, I
> would like to know what are
> the requirements, what could be expected in a short span of 3months, what
> could be used as a reference
> and so on.
>
> Note that an aarch64 port would most likely be observed with argus eyes
>> because it has the potential to be a very important port. But don't let
>> that keep you bag suggesting it.
>>
>> >
>> > I would like to know what are the future plans for these topics.
>> > What is the current statu

Re: What do you want to study in GSOC 2020?

[Niteesh]

On Sat, Jan 4, 2020 at 1:29 AM Christian Mauderer 
wrote:

> On 03/01/2020 18:37, Niteesh wrote:
> > On Fri, Jan 3, 2020 at 7:30 PM Christian Mauderer  > <mailto:l...@c-mauderer.de>> wrote:
> >
> > On 03/01/2020 13:49, Niteesh wrote:
> > > I have gone through previous year works and selected a few topics
> > which
> > > I found
> > > interesting.
> > > 1. Basic Support for Trace Compass #3696
> > > <https://devel.rtems.org/ticket/3696>.
> >
> > A basic support has been added last year and Sebastian extended that
> > quite a bit because we had a customer who needed it. I'm not sure
> what
> > the current state is and whether there are tasks left that could be
> done
> > in a GSoC project.
> >
> > > 2. RTEMS testing tool project #2927
> > <https://devel.rtems.org/ticket/2927>.
> >
> > No idea what the status is. Chris?
> >
> > > 3. Beagle BSP: Add a flattened device tree based
> initialization #3784
> > > <https://devel.rtems.org/ticket/3784>.
> >
> > That one is open. It would include adding some infrastructure for fdt
> > based drivers. In theory you could do the same project for raspberry
> or
> > any other board.
> >
> > Please note Gedares comment from the previous mail:
> >
> > > Infrastructure projects are nice (FDT, dynamic linking,
> debugger,
> > > tracer) but need to be clearly defined ahead of time and
> discussed
> > > thoroughly with the community, or you risk ending up in the
> "long
> > > tedious discussions" when you should be coding.
> >
> >
> > > 4. BSPs for Simulators #2903 <https://devel.rtems.org/ticket/2903
> >.
> >
> > That's always open.
> >
> > Some simulators are easy because the board is already supported and
> you
> > only have to find out how to start it. For these a tester
> integration is
> > a good target. But most likely that's only small stuff and should be
> > only one part of a project.
> >
> > Other simulators are not supported yet. In that case you have to
> write
> > some drivers which can be a good project size.
> >
> > > 5. Improve the Raspberry Pi BSP #2899
> > <https://devel.rtems.org/ticket/2899>.
> >
> > You already noted: The raspberry BSP isn't in the best shape. So it's
> > quite open for improvement.
> >
> > I think that there is still some work getting it to run again. We
> don't
> > have something with "*bcm*" in libbsd yet so most likely USB and
> > Ethernet are not working yet. Could be still still be a nice task.
> >
> >
> > Why don't we use the driver's from other sources as a reference and
> > create our
> > own, for USB https://github.com/Chadderz121/csud this could be used as a
> > reference, U-boot, and Linux are good sources too. But is it worth the
> > effort for a
> > BSP like raspberry pi? There is also a c++ bare metal environment called
> > circle
> > https://github.com/rsta2/circle which supports
> > USB(https://github.com/rsta2/uspi)
> > and ethernet.
>
> The reason for using libbsd is that its already there and therefore its
> easy to add for all chips that are supported (and raspberry is supported
> in FreeBSD).
>
> U-Boot and Linux can't be used most of the time due to license issues.
> Both have a GPL license which isn't usable in a lot of RTEMS
> applications (industrial, automotive, ...). There shouldn't be any GPL
> code in the core repository and we tend to avoid libraries if there are
> alternatives.
>
> >
> > Christian, can you check out this https://github.com/0xabu/qemu/wiki it
> > partially supports
> > USB, can you give it a try?
>
> RTEMS with libbsd doesn't yet have a USB support committed for the
> raspberry. Do you mean try it with Linux or Windows? Did you already
> test something? What do you want to find out?
>
Can you build this version of qemu and see if USB works properly? you don't
have to use RTEMS, you can use a lightweight linux distro and see if you can
talk to a usb device in qemu.

> >
> >
> > With the difficulties getting it to run on RPi3 or RPi4 that might
> could
> > be also a project. It seems that they are aarch64. Also I was quite
> > surprised about it I didn't find a aarch64 BSP. So that would be a
> >

Re: What do you want to study in GSOC 2020?

[Niteesh]

On Sat, Jan 4, 2020 at 3:34 AM Christian Mauderer 
wrote:

> On 03/01/2020 20:17, Niteesh wrote:
> > Finally, I am able to load IMAGES into Rpi3 using u-boot. But didn't
> > check whether FDT works. I added the AUX driver from my bare-metal
> > project for testing. I'll replace it with NS16550 soon.
> > I loaded the fileio example and it prints the board information. Below
> > is the link to the screenshot
> > https://ibb.co/cJbFHqz
>
> That's a great start.
>
> > But it's stuck there, maybe an exception was raised because I didn't
> > modify the address for another device but not sure! Can you think of
> > something
> > which could have caused it?
>
> Exceptions should print an exception frame. So I'm not sure whether that
> is the case. Do you have some JTAG adapter that would work with OpenOCD
> or simmilar?
>
I dont have a JTAG. I going to fallback to printfs. I going to stick printf
in various places
and see where it hangs.
Do you have any other ideas? Can we use GDB?

> >
> >
> > On Fri, Jan 3, 2020 at 11:07 PM Niteesh  > <mailto:gsnb...@gmail.com>> wrote:
> >
> > On Fri, Jan 3, 2020 at 7:30 PM Christian Mauderer
> > mailto:l...@c-mauderer.de>> wrote:
> >
> > On 03/01/2020 13:49, Niteesh wrote:
> > > I have gone through previous year works and selected a few
> > topics which
> > > I found
> > > interesting.
> > > 1. Basic Support for Trace Compass #3696
> > > <https://devel.rtems.org/ticket/3696>.
> >
> > A basic support has been added last year and Sebastian extended
> that
> > quite a bit because we had a customer who needed it. I'm not
> > sure what
> > the current state is and whether there are tasks left that could
> > be done
> > in a GSoC project.
> >
> > > 2. RTEMS testing tool project #2927
> > <https://devel.rtems.org/ticket/2927>.
> >
> > No idea what the status is. Chris?
> >
> > > 3. Beagle BSP: Add a flattened device tree based
> > initialization #3784
> > > <https://devel.rtems.org/ticket/3784>.
> >
> > That one is open. It would include adding some infrastructure
> > for fdt
> > based drivers. In theory you could do the same project for
> > raspberry or
> > any other board.
> >
> > Please note Gedares comment from the previous mail:
> >
> > > Infrastructure projects are nice (FDT, dynamic linking,
> > debugger,
> > > tracer) but need to be clearly defined ahead of time and
> > discussed
> > > thoroughly with the community, or you risk ending up in
> > the "long
> > > tedious discussions" when you should be coding.
> >
> >
> > > 4. BSPs for Simulators #2903
> > <https://devel.rtems.org/ticket/2903>.
> >
> > That's always open.
> >
> > Some simulators are easy because the board is already supported
> > and you
> > only have to find out how to start it. For these a tester
> > integration is
> > a good target. But most likely that's only small stuff and
> should be
> > only one part of a project.
> >
> > Other simulators are not supported yet. In that case you have to
> > write
> > some drivers which can be a good project size.
> >
> > > 5. Improve the Raspberry Pi BSP #2899
> > <https://devel.rtems.org/ticket/2899>.
> >
> > You already noted: The raspberry BSP isn't in the best shape. So
> > it's
> > quite open for improvement.
> >
> > I think that there is still some work getting it to run again.
> > We don't
> > have something with "*bcm*" in libbsd yet so most likely USB and
> > Ethernet are not working yet. Could be still still be a nice
> task.
> >
> >
> > Why don't we use the driver's from other sources as a reference and
> > create our
> > own, for USB https://github.com/Chadderz121/csud this could be used
> as a
> > reference, U-boot, and Linux are good sources too. But is it worth
> > the effort for a
> > BSP like raspberry pi? There is also a c++ ba

Re: What do you want to study in GSOC 2020?

[Niteesh]

I problem was in uart_probe, and console_select. I totally forgot about
console_select
changing back to pl011. The application starts without any issues
https://ibb.co/PZY5BWr
but *rtems_shell_wait_for_input *return unsuccessful, maybe it fails
because it calls
ioctl and I haven't provided a proper handler, what do you think?
Now, since I know everything works I'll add in a proper AUX driver(ns16550)
and test it again.
And also if you remember, there was this issue of printing garbage and
FATAL_SOURCE_EXCEPTION
while running examples in qemu, I have run the examples multiple times on
the board and no issues till now.

On Sat, Jan 4, 2020 at 8:47 AM Niteesh  wrote:

> On Sat, Jan 4, 2020 at 3:34 AM Christian Mauderer 
> wrote:
>
>> On 03/01/2020 20:17, Niteesh wrote:
>> > Finally, I am able to load IMAGES into Rpi3 using u-boot. But didn't
>> > check whether FDT works. I added the AUX driver from my bare-metal
>> > project for testing. I'll replace it with NS16550 soon.
>> > I loaded the fileio example and it prints the board information. Below
>> > is the link to the screenshot
>> > https://ibb.co/cJbFHqz
>>
>> That's a great start.
>>
>> > But it's stuck there, maybe an exception was raised because I didn't
>> > modify the address for another device but not sure! Can you think of
>> > something
>> > which could have caused it?
>>
>> Exceptions should print an exception frame. So I'm not sure whether that
>> is the case. Do you have some JTAG adapter that would work with OpenOCD
>> or simmilar?
>>
> I dont have a JTAG. I going to fallback to printfs. I going to stick
> printf in various places
> and see where it hangs.
> Do you have any other ideas? Can we use GDB?
>
>> >
>> >
>> > On Fri, Jan 3, 2020 at 11:07 PM Niteesh > > <mailto:gsnb...@gmail.com>> wrote:
>> >
>> > On Fri, Jan 3, 2020 at 7:30 PM Christian Mauderer
>> > mailto:l...@c-mauderer.de>> wrote:
>> >
>> > On 03/01/2020 13:49, Niteesh wrote:
>> > > I have gone through previous year works and selected a few
>> > topics which
>> > > I found
>> > > interesting.
>> > > 1. Basic Support for Trace Compass #3696
>> > > <https://devel.rtems.org/ticket/3696>.
>> >
>> > A basic support has been added last year and Sebastian extended
>> that
>> > quite a bit because we had a customer who needed it. I'm not
>> > sure what
>> > the current state is and whether there are tasks left that could
>> > be done
>> > in a GSoC project.
>> >
>> > > 2. RTEMS testing tool project #2927
>> > <https://devel.rtems.org/ticket/2927>.
>> >
>> > No idea what the status is. Chris?
>> >
>> > > 3. Beagle BSP: Add a flattened device tree based
>> > initialization #3784
>> > > <https://devel.rtems.org/ticket/3784>.
>> >
>> > That one is open. It would include adding some infrastructure
>> > for fdt
>> > based drivers. In theory you could do the same project for
>> > raspberry or
>> > any other board.
>> >
>> > Please note Gedares comment from the previous mail:
>> >
>> > > Infrastructure projects are nice (FDT, dynamic linking,
>> > debugger,
>> > > tracer) but need to be clearly defined ahead of time and
>> > discussed
>> > > thoroughly with the community, or you risk ending up in
>> > the "long
>> > > tedious discussions" when you should be coding.
>> >
>> >
>> > > 4. BSPs for Simulators #2903
>> > <https://devel.rtems.org/ticket/2903>.
>> >
>> > That's always open.
>> >
>> > Some simulators are easy because the board is already supported
>> > and you
>> > only have to find out how to start it. For these a tester
>> > integration is
>> > a good target. But most likely that's only small stuff and
>> should be
>> > only one part of a project.
>> >
>> > Other simulators are not supported yet. In that case you have to
>> > write
>> >   

Re: [PATCH] Updated docs to use the standalone SIS simulator, instead of GDB inbuilt SIS for the erc32 BSP.

[Niteesh]

Just a reminder, it's almost been a week since I sent the patch. I also
sent it a month ago, but it slipped from everyone's eyes.

On Thu, Jan 2, 2020 at 9:45 PM Gedare Bloom  wrote:

> looks good to me.
>
> On Fri, Dec 27, 2019 at 5:02 AM G S Niteesh  wrote:
> >
> > ---
> >  user/start/bsp-test.rst |   4 +-
> >  user/tools/tester.rst   | 144 
> >  2 files changed, 132 insertions(+), 16 deletions(-)
> >
> > diff --git a/user/start/bsp-test.rst b/user/start/bsp-test.rst
> > index 5278375..aefeeb9 100644
> > --- a/user/start/bsp-test.rst
> > +++ b/user/start/bsp-test.rst
> > @@ -21,7 +21,7 @@ Just run this command:
> >  .. code-block:: none
> >
> >  cd $HOME/quick-start/build/b-erc32
> > -rtems-test --rtems-bsp=erc32
> --rtems-tools=$HOME/quick-start/rtems/5 .
> > +rtems-test --rtems-bsp=erc32-sis
> --rtems-tools=$HOME/quick-start/rtems/5 .
> >
> >  This command should output something like this (omitted lines are
> denoted by
> >  ...).  In this output the base directory :file:`$HOME/quick-start` was
> replaced
> > @@ -30,7 +30,7 @@ by ``$BASE``.
> >  .. code-block:: none
> >
> >  RTEMS Testing - Tester, 5.0.not_released
> > - Command Line: $BASE/rtems/5/bin/rtems-test --rtems-bsp=erc32
> --rtems-tools=$BASE/rtems/5 .
> > + Command Line: $BASE/rtems/5/bin/rtems-test --rtems-bsp=erc32-sis
> --rtems-tools=$BASE/rtems/5 .
> >   Python: 2.7.15 (default, Jan 10 2019, 01:14:47) [GCC 4.2.1
> Compatible FreeBSD Clang 6.0.1 (tags/RELEASE_601/final 335540)]
> >  Host: FreeBSD-12.0-RELEASE-p2-amd64-64bit-ELF (FreeBSD
> Build_FreeBSD12 12.0-RELEASE-p2 FreeBSD 12.0-RELEASE-p2 GENERIC amd64 amd64)
> >  [  1/589] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   |
> sparc/erc32: dhrystone.exe
> > diff --git a/user/tools/tester.rst b/user/tools/tester.rst
> > index 609384b..c3c3fe2 100644
> > --- a/user/tools/tester.rst
> > +++ b/user/tools/tester.rst
> > @@ -109,39 +109,155 @@ the tests. Using the run with the ERC32 BSP the
> command is:
> >
> >  The run command is the GDB simulator without the GDB part.
> >
> > -Running the example using GDB:
> > +Running the example using SIS:
> > +
> > +.. code-block:: none
> > +
> > +$ sparc-rtems5-sis
> sparc-rtems5/c/erc32/testsuites/samples/hello/hello.exe
> > +SIS - SPARC/RISCV instruction simulator 2.20,  copyright Jiri
> Gaisler 2019
> > +Bug-reports to j...@gaisler.se
> > +ERC32 emulation enabled
> > +
> > +Loaded sparc-rtems5/c/erc32/testsuites/samples/hello.exe, entry
> 0x0200
> > +
> > +sis> run
> > +
> > +
> > +*** BEGIN OF TEST HELLO WORLD ***
> > +*** TEST VERSION: 5.0.0.c6d8589bb00a9d2a5a094c68c90290df1dc44807
> > +*** TEST STATE: EXPECTED-PASS
> > +*** TEST BUILD: RTEMS_POSIX_API
> > +*** TEST TOOLS: 7.5.0 20191114 (RTEMS 5, RSB
> 83fa79314dd87c0a8c78fd642b2cea3138be8dd6, Newlib 3e24fbf6f)
> > +Hello World
> > +
> > +*** END OF TEST HELLO WORLD ***
> > +
> > +
> > +*** FATAL ***
> > +fatal source: 0 (INTERNAL_ERROR_CORE)
> > +fatal code: 5 (INTERNAL_ERROR_THREAD_EXITTED)
> > +RTEMS version: 5.0.0.c6d8589bb00a9d2a5a094c68c90290df1dc44807
> > +RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB
> 83fa79314dd87c0a8c78fd642b2cea3138be8dd6, Newlib 3e24fbf6f)
> > +executing thread ID: 0x08a010001
> > +executing thread name: UI1
> > +cpu 0 in error mode (tt = 0x101)
> > +116401  02009ae0:  91d02000   ta  0x0
> > +
> > +sis> q
> > +
> > +The examples can also be run using GDB with SIS as the backend. SIS can
> be connected to
> > +gdb through a network socket using the gdb remote interface.
> > +
> > +Either start SIS with ``-gdb``, or issue the ``gdb`` command inside
> SIS, and connect
> > +gdb with ``target remote:1234``. The default port is ``1234``, the port
> can be changed
> > +using the ``-port`` option.
> > +
> > +Open a terminal and issue the command:
> > +
> > +.. code-block:: none
> > +
> > +$ sparc-rtems5-sis -gdb
> > +SIS - SPARC/RISCV instruction simulator 2.20,  copyright Jiri
> Gaisler 2019
> > +Bug-reports to j...@gaisler.se
> > +ERC32 emulation enabled
> > +
> > +gdb: listening on port 1234
> > +
> > +Now open another terminal and issue the command:
> >
> >  .. code-block:: none
> >
> >  $ sparc-rtems5-gdb
> sparc-rt

Raspberrypi3: AUX Uart driver

[Niteesh]

We could now run RTEMS on Rpi3. I tried examples from the samples section
and they run
fine. But still, a lot of functionality has to tested since it uses the
RPI2 BSP. To test these examples
I used a simple driver for the AUX.
The documentation from BCM link

(pg
no 10) states that


> *The implemented UART is not a 16650 compatible UART However as far as
> possible the first 8 control and status registers are laid out like a 16550
> UART.*


My question is can we use the existing ns16550 driver or should I create a
new one? I also checked the address of the registers the offsets don't seem
right to me, but someone should check and correct me if I am wrong.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] doc/raspberrypi: Added instructions for raspberrypi

[Niteesh]

I have added basic instructions, just let me know if you need any other
section.

On Sun, Jan 5, 2020 at 6:17 PM G S Niteesh  wrote:

> Added instructions to run examples on raspberrypi.
> ---
>  user/bsps/arm/raspberrypi.rst | 75 ++-
>  1 file changed, 74 insertions(+), 1 deletion(-)
>
> diff --git a/user/bsps/arm/raspberrypi.rst b/user/bsps/arm/raspberrypi.rst
> index 4ef75bd..653f8a7 100644
> --- a/user/bsps/arm/raspberrypi.rst
> +++ b/user/bsps/arm/raspberrypi.rst
> @@ -5,4 +5,77 @@
>  raspberrypi
>  ===
>
> -TODO.
> +This BSP support's `raspberrypi 1` and `raspberrypi 2` currently.
> +The support for `raspberrypi 3` is work under progress.
> +The default bootloader on the raspberrypi which is used to boot raspbian
> +or other OS can be also used to boot RTEMS. U-boot can also be used
> +but it a personal preferance.
> +
> +Setup up SD card
> +
> +
> +The raspberrypi's have an unconventional booting mechanism. The GPU
> +boots first, initializes itself, runs the bootloader and start the CPU.
> +The bootloader looks for a kernel image, by default the kernel images must
> +have name of form `kernel*.img` but this can be changed by adding
> `kernel=`
> +to config.txt.
> +
> +You must provide the required files for the GPU to proceed. These files
> +can be downloded from this link
> https://github.com/raspberrypi/firmware/tree/master/boot
> +.You can remove the kernel*.img if you want, but don't touch the other
> files.
> +
> +Copy these files in to a SD card with FAT filesystem.
> +
> +Kernel image
> +
> +
> +We will be running the hello.exe on raspberrypi 2. Other examples can be
> +found under testsuites.
> +
> +To create the kernel image:
> +
> +.. code-block:: none
> +
> + arm-rtems5-objcopy -Obinary hello.exe kernel.img
> +
> +Copy the kernel image to the SD card.
> +
> +Make sure you have these lines below in your config.txt.
> +
> +.. code-block:: none
> +
> + enable-uart=1
> + kernel_address=0x20
> + kernel=kernel.img
> +
> +Testing
> +---
> +
> +Qemu along with GDB can be used for debugging, but it only supports
> +``raspberrpi2`` and emulation is also incomplete. So some of the features
> +might not work as expected.
> +
> +Make sure you have latest version of qemu, older ones don't support
> +raspberrypi.
> +
> +.. code-block:: none
> +
> + qemu-system-arm -M raspi2 -m 1G -kernel hello.exe -serial mon:stdio
> -nographic -S -s
> +
> +This starts qemu and creates a socket at port ``1234`` for GDB to connect.
> +
> +In a new terminal, run GDB using
> +
> +.. code-block:: none
> +
> + arm-rtems5-gdb hello.exe
> + tar remote:1234
> + load
> +
> +This will connect GDB to qemu and loads the application.
> +
> +**Note**: Add ``set scheduler-locking on`` in GDB if you have any issues
> running
> +the examples.
> +
> +
> +
> --
> 2.17.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] doc/raspberrypi: Added instructions for raspberrypi

[Niteesh]

Do you want to add a build section or just add in a statement that states
"it was built
using xx version of RSB"?

On Mon, Jan 6, 2020 at 11:51 PM Gedare Bloom  wrote:

> On Mon, Jan 6, 2020 at 2:47 AM Christian Mauderer 
> wrote:
> >
> > Looks a lot better.
> >
> > On 05/01/2020 20:19, G S Niteesh wrote:
> > > Added instructions to run examples on raspberrypi.
> > > ---
> > >  user/bsps/arm/raspberrypi.rst | 74 ++-
> > >  1 file changed, 73 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/user/bsps/arm/raspberrypi.rst
> b/user/bsps/arm/raspberrypi.rst
> > > index 4ef75bd..7eccca5 100644
> > > --- a/user/bsps/arm/raspberrypi.rst
> > > +++ b/user/bsps/arm/raspberrypi.rst
> > > @@ -5,4 +5,76 @@
> > >  raspberrypi
> > >  ===
> > >
> > > -TODO.
> > > +This BSP supports `Raspberry Pi 1` and `Raspberry Pi 2` currently.
> > > +The support for `Raspberry Pi 3` is work under progress.
> > > +The default bootloader on the raspberrypi which is used to boot
> raspbian
> >
> > raspberrypi -> Raspberry Pi
> > raspbian -> Raspbian
> >
> > > +or other OS can be also used to boot RTEMS. U-boot can also be used.
> > > +
> > > +Setup SD card
> > > +
> > > +
> > > +The Raspberry Pis have an unconventional booting mechanism. The GPU
> > > +boots first, initializes itself, runs the bootloader and starts the
> CPU.
> > > +The bootloader looks for a kernel image, by default the kernel images
> must
> > > +have a name of the form `kernel*.img` but this can be changed by
> adding
> >
> > Please highlight all files in the same way. Other BSPs use the following
> > syntax:
> >
> > The ``ticker.exe`` elf file must be translated ...
> >
> > So here it is:
> >
> > `kernel*.img` -> ``kernel*.img``
> >
> > > +`kernel=` to config.txt.
> >
> > config.txt -> ``config.txt``
> >
> > > +
> > > +You must provide the required files for the GPU to proceed. These
> files
> > > +can be downloaded from this
> > > +`link <https://github.com/raspberrypi/firmware/tree/master/boot>`_.
> >
> > I would suggest:
> >
> > ... can be downloaded from
> > `the Raspberry Pi Firmware Repository
> > <https://github.com/raspberrypi/firmware/tree/master/boot>`_.
> >
> > I think you shouldn't break links so if this is too long you can
> > exceptionally break the 80 character rule. It's done for other links too.
> >
> > > +You can remove the kernel*.img if you want, but don't touch the other
> files.
> >
> > kernel*.img -> ``kernel*.img``
> >
> > > +
> > > +Copy these files in to a SD card with FAT filesystem.
> > > +
> > > +Kernel image
> > > +
> > > +
> > > +The following steps show how to run hello.exe on a Raspberry Pi 2.
> >
> > hello.exe -> ``hello.exe``
> >
> > > +The same instructions can be applied to Raspberry Pi 1 also.
> > > +Other executables can be processed in a similar way.
> > > +
> > > +To create the kernel image:
> > > +
> > > +.. code-block:: none
> > > +
> > > + arm-rtems5-objcopy -Obinary hello.exe kernel.img
> > > +
> > > +Copy the kernel image to the SD card.
> > > +
> > > +Make sure you have these lines below in your config.txt.
> > > +
> > > +.. code-block:: none
> > > +
> > > + enable-uart=1
> > > + kernel_address=0x20
> > > + kernel=kernel.img
> > > +
> > > +Testing
> > > +---
> >
> > Maybe change that chapter to "Emulation" or "Testing using QEMU". When
> > reading I had expected a hardware setup in this chapter after the
> > SD-card has been prepared in the previous one.
> >
> > > +
> > > +Qemu along with GDB can be used for debugging, but it only supports
> >
> > Please always use the capitalization that the project uses. In this case:
> >
> > Qemu -> QEMU
> >
> > > +``Raspberry Pi 2`` and the emulation is also incomplete. So some of
> the
> >
> > Again: One formatting for one phrase. So that would be:
> >
> > ``Raspberry Pi 2`` -> Raspberry Pi 2
> >
> > > +features might not work as expected.
> > > +
> > > +Make sure you have latest ve

Re: [PATCH v2] bsp/raspberrypi: Updated the console API.

[Niteesh]

Great, thank you it wouldn't have been possible without your help and
support.
And thanks for patiently answering my questions :)

On Tue, Jan 7, 2020 at 10:58 PM Christian Mauderer 
wrote:

> Pushed with a minor modification: Due to the header reorder it was
> necessary to include one extra header in bsp/fbcons.h. But that has been
> a hidden bug anyway.
>
> On 04/01/2020 20:50, G S Niteesh wrote:
> > Replaces the legacy termios API with new termios API (#3034)
> > Replaces the custom PL011 serial driver with RTEMS arm-pl011.
> > Update #3034
> > ---
> >  bsps/arm/raspberrypi/console/console-config.c | 143 +++
> >  bsps/arm/raspberrypi/console/console_select.c | 114 
> >  bsps/arm/raspberrypi/console/fbcons.c |  78 
> >  bsps/arm/raspberrypi/console/usart.c  | 167 --
> >  bsps/arm/raspberrypi/include/bsp.h|   2 +
> >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  17 +-
> >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  54 ++
> >  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
> >  bsps/arm/raspberrypi/start/bspstart.c |  15 ++
> >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   6 +-
> >  10 files changed, 197 insertions(+), 404 deletions(-)
> >  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
> >  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
> >
> > diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> > index d2186c918b..48c4c6a3ec 100644
> > --- a/bsps/arm/raspberrypi/console/console-config.c
> > +++ b/bsps/arm/raspberrypi/console/console-config.c
> > @@ -19,50 +19,133 @@
> >   */
> >
> >  #include 
> > +#include 
> > +#include 
> >
> >  #include 
> > +#include 
> >
> >  #include 
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> >
> > -console_tbl Console_Configuration_Ports [] = {
> > -{
> > -  .sDeviceName = "/dev/ttyS0",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = &bcm2835_usart_fns,
> > -  .deviceProbe = NULL,
> > -  .pDeviceFlow = NULL,
> > -  .ulCtrlPort1 = BCM2835_UART0_BASE,
> > -  .ulCtrlPort2 = 0,
> > -  .ulClock = USART0_DEFAULT_BAUD,
> > -  .ulIntVector = BCM2835_IRQ_ID_UART
> > -},
> > -{
> > -  .sDeviceName ="/dev/fbcons",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = &fbcons_fns,
> > -  .deviceProbe = fbcons_probe,
> > -  .pDeviceFlow = NULL,
> > -},
> > -};
> > -
> > -#define PORT_COUNT \
> > -  (sizeof(Console_Configuration_Ports) \
> > -/ sizeof(Console_Configuration_Ports [0]))
> > -
> > -unsigned long Console_Configuration_Count = PORT_COUNT;
> > +
> > +#define UART0 "/dev/ttyS0"
> > +#define FBCONS"/dev/fbcons"
> > +
> > +arm_pl011_context pl011_context;
> > +
> > +rpi_fb_context fb_context;
> > +
> > +static void output_char_serial(char c)
> > +{
> > +  arm_pl011_write_polled(&pl011_context.base, c);
> > +}
> > +
> > +void output_char_fb(char c)
> > +{
> > +  fbcons_write_polled(&fb_context.base, c);
> > +}
> > +
> > +static void init_ctx_arm_pl011(
> > +  const void *fdt,
> > +  int node
> > +)
> > +{
> > +  arm_pl011_context *ctx = &pl011_context;
> > +  rtems_termios_device_context_initialize(&ctx->base, "UART");
> > +  ctx->regs = raspberrypi_get_reg_of_node(fdt, node);
> > +}
> > +
> > +static void register_fb( void )
> > +{
> > +  if (fbcons_probe(&fb_context.base) == true) {
> > +rtems_termios_device_install(
> > +  FBCONS,
> > +  &fbcons_fns,
> > +  NULL,
> > +  &fb_context.base);
> > +  }
> > +}
> > +
> > +static void console_select( void )
> > +{
> > +  const char *opt;
> > +
> > +  opt = rpi_cmdline_get_arg("--console=");
> > +
> > +  if ( opt ) {
> > +if ( strncmp( opt, "fbcons", sizeof( "fbcons" ) - 1 ) == 0 ) {
> > +  if ( rpi_video_is_initialized() > 0 ) {
> > +BSP_output_char = output_char_fb;
> > +link(FBCONS, CONSOLE_DEVICE_NAME);
> > +ret

Re: [PATCH v2] doc/raspberrypi: Added instructions for raspberrypi

[Niteesh]

I didn't use the QEMU build from RSB, I built it from the source directly
for another project
I'll try QEMU from RSB, and will also add instructions for it in a couple
of days.

On Tue, Jan 7, 2020 at 1:00 AM Gedare Bloom  wrote:

> On Mon, Jan 6, 2020 at 11:25 AM Niteesh  wrote:
> >
> > Do you want to add a build section or just add in a statement that
> states "it was built
> > using xx version of RSB"?
> >
>
> Just a simple statement. Don't even  need to mention a specific
> version, if they use RSB to build QEMU it should just work, right?
>
> > On Mon, Jan 6, 2020 at 11:51 PM Gedare Bloom  wrote:
> >>
> >> On Mon, Jan 6, 2020 at 2:47 AM Christian Mauderer 
> wrote:
> >> >
> >> > Looks a lot better.
> >> >
> >> > On 05/01/2020 20:19, G S Niteesh wrote:
> >> > > Added instructions to run examples on raspberrypi.
> >> > > ---
> >> > >  user/bsps/arm/raspberrypi.rst | 74
> ++-
> >> > >  1 file changed, 73 insertions(+), 1 deletion(-)
> >> > >
> >> > > diff --git a/user/bsps/arm/raspberrypi.rst
> b/user/bsps/arm/raspberrypi.rst
> >> > > index 4ef75bd..7eccca5 100644
> >> > > --- a/user/bsps/arm/raspberrypi.rst
> >> > > +++ b/user/bsps/arm/raspberrypi.rst
> >> > > @@ -5,4 +5,76 @@
> >> > >  raspberrypi
> >> > >  ===
> >> > >
> >> > > -TODO.
> >> > > +This BSP supports `Raspberry Pi 1` and `Raspberry Pi 2` currently.
> >> > > +The support for `Raspberry Pi 3` is work under progress.
> >> > > +The default bootloader on the raspberrypi which is used to boot
> raspbian
> >> >
> >> > raspberrypi -> Raspberry Pi
> >> > raspbian -> Raspbian
> >> >
> >> > > +or other OS can be also used to boot RTEMS. U-boot can also be
> used.
> >> > > +
> >> > > +Setup SD card
> >> > > +
> >> > > +
> >> > > +The Raspberry Pis have an unconventional booting mechanism. The GPU
> >> > > +boots first, initializes itself, runs the bootloader and starts
> the CPU.
> >> > > +The bootloader looks for a kernel image, by default the kernel
> images must
> >> > > +have a name of the form `kernel*.img` but this can be changed by
> adding
> >> >
> >> > Please highlight all files in the same way. Other BSPs use the
> following
> >> > syntax:
> >> >
> >> > The ``ticker.exe`` elf file must be translated ...
> >> >
> >> > So here it is:
> >> >
> >> > `kernel*.img` -> ``kernel*.img``
> >> >
> >> > > +`kernel=` to config.txt.
> >> >
> >> > config.txt -> ``config.txt``
> >> >
> >> > > +
> >> > > +You must provide the required files for the GPU to proceed. These
> files
> >> > > +can be downloaded from this
> >> > > +`link <https://github.com/raspberrypi/firmware/tree/master/boot
> >`_.
> >> >
> >> > I would suggest:
> >> >
> >> > ... can be downloaded from
> >> > `the Raspberry Pi Firmware Repository
> >> > <https://github.com/raspberrypi/firmware/tree/master/boot>`_.
> >> >
> >> > I think you shouldn't break links so if this is too long you can
> >> > exceptionally break the 80 character rule. It's done for other links
> too.
> >> >
> >> > > +You can remove the kernel*.img if you want, but don't touch the
> other files.
> >> >
> >> > kernel*.img -> ``kernel*.img``
> >> >
> >> > > +
> >> > > +Copy these files in to a SD card with FAT filesystem.
> >> > > +
> >> > > +Kernel image
> >> > > +
> >> > > +
> >> > > +The following steps show how to run hello.exe on a Raspberry Pi 2.
> >> >
> >> > hello.exe -> ``hello.exe``
> >> >
> >> > > +The same instructions can be applied to Raspberry Pi 1 also.
> >> > > +Other executables can be processed in a similar way.
> >> > > +
> >> > > +To create the kernel image:
> >> > > +
> >> > > +.. code-block:: none
> >> > > +
> >> > 

Re: [PATCH v2] bsp/raspberrypi: Updated the console API.

[Niteesh]

You said that the FB was not working, was it because of this bug?
or else I want to take a look at it.

On Tue, Jan 7, 2020 at 11:03 PM Niteesh  wrote:

> Great, thank you it wouldn't have been possible without your help and
> support.
> And thanks for patiently answering my questions :)
>
> On Tue, Jan 7, 2020 at 10:58 PM Christian Mauderer 
> wrote:
>
>> Pushed with a minor modification: Due to the header reorder it was
>> necessary to include one extra header in bsp/fbcons.h. But that has been
>> a hidden bug anyway.
>>
>> On 04/01/2020 20:50, G S Niteesh wrote:
>> > Replaces the legacy termios API with new termios API (#3034)
>> > Replaces the custom PL011 serial driver with RTEMS arm-pl011.
>> > Update #3034
>> > ---
>> >  bsps/arm/raspberrypi/console/console-config.c | 143 +++
>> >  bsps/arm/raspberrypi/console/console_select.c | 114 
>> >  bsps/arm/raspberrypi/console/fbcons.c |  78 
>> >  bsps/arm/raspberrypi/console/usart.c  | 167 --
>> >  bsps/arm/raspberrypi/include/bsp.h|   2 +
>> >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  17 +-
>> >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  54 ++
>> >  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
>> >  bsps/arm/raspberrypi/start/bspstart.c |  15 ++
>> >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   6 +-
>> >  10 files changed, 197 insertions(+), 404 deletions(-)
>> >  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
>> >  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
>> >
>> > diff --git a/bsps/arm/raspberrypi/console/console-config.c
>> b/bsps/arm/raspberrypi/console/console-config.c
>> > index d2186c918b..48c4c6a3ec 100644
>> > --- a/bsps/arm/raspberrypi/console/console-config.c
>> > +++ b/bsps/arm/raspberrypi/console/console-config.c
>> > @@ -19,50 +19,133 @@
>> >   */
>> >
>> >  #include 
>> > +#include 
>> > +#include 
>> >
>> >  #include 
>> > +#include 
>> >
>> >  #include 
>> > -#include 
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> >
>> > -console_tbl Console_Configuration_Ports [] = {
>> > -{
>> > -  .sDeviceName = "/dev/ttyS0",
>> > -  .deviceType = SERIAL_CUSTOM,
>> > -  .pDeviceFns = &bcm2835_usart_fns,
>> > -  .deviceProbe = NULL,
>> > -  .pDeviceFlow = NULL,
>> > -  .ulCtrlPort1 = BCM2835_UART0_BASE,
>> > -  .ulCtrlPort2 = 0,
>> > -  .ulClock = USART0_DEFAULT_BAUD,
>> > -  .ulIntVector = BCM2835_IRQ_ID_UART
>> > -},
>> > -{
>> > -  .sDeviceName ="/dev/fbcons",
>> > -  .deviceType = SERIAL_CUSTOM,
>> > -  .pDeviceFns = &fbcons_fns,
>> > -  .deviceProbe = fbcons_probe,
>> > -  .pDeviceFlow = NULL,
>> > -},
>> > -};
>> > -
>> > -#define PORT_COUNT \
>> > -  (sizeof(Console_Configuration_Ports) \
>> > -/ sizeof(Console_Configuration_Ports [0]))
>> > -
>> > -unsigned long Console_Configuration_Count = PORT_COUNT;
>> > +
>> > +#define UART0 "/dev/ttyS0"
>> > +#define FBCONS"/dev/fbcons"
>> > +
>> > +arm_pl011_context pl011_context;
>> > +
>> > +rpi_fb_context fb_context;
>> > +
>> > +static void output_char_serial(char c)
>> > +{
>> > +  arm_pl011_write_polled(&pl011_context.base, c);
>> > +}
>> > +
>> > +void output_char_fb(char c)
>> > +{
>> > +  fbcons_write_polled(&fb_context.base, c);
>> > +}
>> > +
>> > +static void init_ctx_arm_pl011(
>> > +  const void *fdt,
>> > +  int node
>> > +)
>> > +{
>> > +  arm_pl011_context *ctx = &pl011_context;
>> > +  rtems_termios_device_context_initialize(&ctx->base, "UART");
>> > +  ctx->regs = raspberrypi_get_reg_of_node(fdt, node);
>> > +}
>> > +
>> > +static void register_fb( void )
>> > +{
>> > +  if (fbcons_probe(&fb_context.base) == true) {
>> > +rtems_termios_device_install(
>> > +  FBCONS,
>> > +  &fbcons_fns,
>> > 

Re: Raspberrypi3: AUX Uart driver

[Niteesh]

The only issue, I faced while using this driver is the baud divisor is
calculated
by CLOCK_FREQ/(BAUD_RATE * 16) (*ns16550-context.c:68)*
but it should BAUD_DIV = (CLOCK_FREQ/(8 * BAUD_RATE)) - 1, for Rpi3.
For testing, I assigned the baud divisor to 270 (115200 bits/s) in
ns16550-context.c,
and everything works fine.

For console selection, my plan is to search for the aux node using
compatible
property and if its status is enabled, then initialize the AUX uart and set
the BSP_output_char
to aux_output_char, else pl011_output_char. All this will be done inside
the uart_probe function,
except for the initialization of AUX which will be done in init_ctx_aux.
And finally, call the output char
function using *BSP_output_char. Do you have any neat way to do this?

And why don't we have a function similar to *of_device_is_available*, since
there will be more and more
FDT based boards, this will be really helpful.

On Sun, Jan 5, 2020 at 12:57 AM Christian Mauderer 
wrote:

> On 04/01/2020 09:32, Niteesh wrote:
> > We could now run RTEMS on Rpi3. I tried examples from the samples
> > section and they run
> > fine. But still, a lot of functionality has to tested since it uses the
> > RPI2 BSP. To test these examples
> > I used a simple driver for the AUX.
> > The documentation from BCM link
> > <
> https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
> > (pg
> > no 10) states that
> >
> >
> > *The implemented UART is not a 16650 compatible UART However as far
> > as possible the first 8 control and status registers are laid out
> > like a 16550 UART.*
>
> It also tells
>
> "Al 16550 register bits which are not supported can be written but
> will be ignored and read back as 0. All control bits for simple UART
> receive/transmit operations are available."
>
> So I would expect that not everything works like expected (for example
> setting DCD, DSR, DTR, RI - they are not there for the mini UART) but
> the basic stuff should work.
>
> >
> >
> > My question is can we use the existing ns16550 driver or should I create
> > a new one? I also checked the address of the registers the offsets don't
> > seem right to me, but someone should check and correct me if I am wrong.
>
> If you compare the registers in the existing driver
> (NS16550_RECEIVE_BUFFER, ... in ns16550_p.h) and the one in the BCM
> datasheet the registers look very similar (at least from the position /
> function). I haven't done a bit by bit comparison yet. Please note that
> you have to do a conversion between the defines and register addresses.
> The define gives you a register index for a 32bit register. So you have
> to multiply by 4 to get an address. The driver is designed that you
> provide a setRegister and getRegister function that can do this conversion.
>
> Where did you find differences?
>
> I would suggest to just try the driver.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] doc/raspberrypi: Added instructions for raspberrypi

[Niteesh]

I can't build QEMU using RSB, there seems to be a problem with GLib(see
attachment)
but I had no problem building it from the source. Should I just mention
build qemu from
source?

On Tue, Jan 7, 2020 at 11:12 PM Niteesh  wrote:

> I didn't use the QEMU build from RSB, I built it from the source directly
> for another project
> I'll try QEMU from RSB, and will also add instructions for it in a couple
> of days.
>
> On Tue, Jan 7, 2020 at 1:00 AM Gedare Bloom  wrote:
>
>> On Mon, Jan 6, 2020 at 11:25 AM Niteesh  wrote:
>> >
>> > Do you want to add a build section or just add in a statement that
>> states "it was built
>> > using xx version of RSB"?
>> >
>>
>> Just a simple statement. Don't even  need to mention a specific
>> version, if they use RSB to build QEMU it should just work, right?
>>
>> > On Mon, Jan 6, 2020 at 11:51 PM Gedare Bloom  wrote:
>> >>
>> >> On Mon, Jan 6, 2020 at 2:47 AM Christian Mauderer 
>> wrote:
>> >> >
>> >> > Looks a lot better.
>> >> >
>> >> > On 05/01/2020 20:19, G S Niteesh wrote:
>> >> > > Added instructions to run examples on raspberrypi.
>> >> > > ---
>> >> > >  user/bsps/arm/raspberrypi.rst | 74
>> ++-
>> >> > >  1 file changed, 73 insertions(+), 1 deletion(-)
>> >> > >
>> >> > > diff --git a/user/bsps/arm/raspberrypi.rst
>> b/user/bsps/arm/raspberrypi.rst
>> >> > > index 4ef75bd..7eccca5 100644
>> >> > > --- a/user/bsps/arm/raspberrypi.rst
>> >> > > +++ b/user/bsps/arm/raspberrypi.rst
>> >> > > @@ -5,4 +5,76 @@
>> >> > >  raspberrypi
>> >> > >  ===
>> >> > >
>> >> > > -TODO.
>> >> > > +This BSP supports `Raspberry Pi 1` and `Raspberry Pi 2` currently.
>> >> > > +The support for `Raspberry Pi 3` is work under progress.
>> >> > > +The default bootloader on the raspberrypi which is used to boot
>> raspbian
>> >> >
>> >> > raspberrypi -> Raspberry Pi
>> >> > raspbian -> Raspbian
>> >> >
>> >> > > +or other OS can be also used to boot RTEMS. U-boot can also be
>> used.
>> >> > > +
>> >> > > +Setup SD card
>> >> > > +
>> >> > > +
>> >> > > +The Raspberry Pis have an unconventional booting mechanism. The
>> GPU
>> >> > > +boots first, initializes itself, runs the bootloader and starts
>> the CPU.
>> >> > > +The bootloader looks for a kernel image, by default the kernel
>> images must
>> >> > > +have a name of the form `kernel*.img` but this can be changed by
>> adding
>> >> >
>> >> > Please highlight all files in the same way. Other BSPs use the
>> following
>> >> > syntax:
>> >> >
>> >> > The ``ticker.exe`` elf file must be translated ...
>> >> >
>> >> > So here it is:
>> >> >
>> >> > `kernel*.img` -> ``kernel*.img``
>> >> >
>> >> > > +`kernel=` to config.txt.
>> >> >
>> >> > config.txt -> ``config.txt``
>> >> >
>> >> > > +
>> >> > > +You must provide the required files for the GPU to proceed. These
>> files
>> >> > > +can be downloaded from this
>> >> > > +`link <https://github.com/raspberrypi/firmware/tree/master/boot
>> >`_.
>> >> >
>> >> > I would suggest:
>> >> >
>> >> > ... can be downloaded from
>> >> > `the Raspberry Pi Firmware Repository
>> >> > <https://github.com/raspberrypi/firmware/tree/master/boot>`_.
>> >> >
>> >> > I think you shouldn't break links so if this is too long you can
>> >> > exceptionally break the 80 character rule. It's done for other links
>> too.
>> >> >
>> >> > > +You can remove the kernel*.img if you want, but don't touch the
>> other files.
>> >> >
>> >> > kernel*.img -> ``kernel*.img``
>> >> >
>> >> > > +
>> >> > > +Copy these files in to a SD card with FAT filesystem.
>> >> > > +
>

Re: [PATCH v2] doc/raspberrypi: Added instructions for raspberrypi

[Niteesh]

I haven't tested it, but it should be possible if using u-boot. I wanted to
try
this out but didn't have the time due to my university's tight academics. I
currently use a setup in which the kernel images are transferred through
serial,
but it is really slow.

I will try this out, once I am free.

On Mon, Jan 13, 2020 at 12:18 AM Joel Sherrill 
wrote:

>
>
> On Sun, Jan 12, 2020, 9:51 AM Jiri Gaisler  wrote:
>
>> You should build devel/qemu4 with RSB, the older devel/qemu does not
>> build on newer systems ...
>>
>
> +1
>
> Also is there anyway to boot RTEMS executables from the network? Manually
> replacing the kernel image in the SD is not conducive to automated testing.
>
> If you don't know how to do that, the doc looks ok without assuming the
> recommended changes happen. It would just be nice to know how to automate
> testing the Pi's.
>
>> Jiri.
>>
>>
>> On 1/12/20 4:48 PM, Niteesh wrote:
>>
>> I can't build QEMU using RSB, there seems to be a problem with GLib(see
>> attachment)
>> but I had no problem building it from the source. Should I just mention
>> build qemu from
>> source?
>>
>> On Tue, Jan 7, 2020 at 11:12 PM Niteesh  wrote:
>>
>>> I didn't use the QEMU build from RSB, I built it from the source
>>> directly for another project
>>> I'll try QEMU from RSB, and will also add instructions for it in a
>>> couple of days.
>>>
>>> On Tue, Jan 7, 2020 at 1:00 AM Gedare Bloom  wrote:
>>>
>>>> On Mon, Jan 6, 2020 at 11:25 AM Niteesh  wrote:
>>>> >
>>>> > Do you want to add a build section or just add in a statement that
>>>> states "it was built
>>>> > using xx version of RSB"?
>>>> >
>>>>
>>>> Just a simple statement. Don't even  need to mention a specific
>>>> version, if they use RSB to build QEMU it should just work, right?
>>>>
>>>> > On Mon, Jan 6, 2020 at 11:51 PM Gedare Bloom 
>>>> wrote:
>>>> >>
>>>> >> On Mon, Jan 6, 2020 at 2:47 AM Christian Mauderer <
>>>> l...@c-mauderer.de> wrote:
>>>> >> >
>>>> >> > Looks a lot better.
>>>> >> >
>>>> >> > On 05/01/2020 20:19, G S Niteesh wrote:
>>>> >> > > Added instructions to run examples on raspberrypi.
>>>> >> > > ---
>>>> >> > >  user/bsps/arm/raspberrypi.rst | 74
>>>> ++-
>>>> >> > >  1 file changed, 73 insertions(+), 1 deletion(-)
>>>> >> > >
>>>> >> > > diff --git a/user/bsps/arm/raspberrypi.rst
>>>> b/user/bsps/arm/raspberrypi.rst
>>>> >> > > index 4ef75bd..7eccca5 100644
>>>> >> > > --- a/user/bsps/arm/raspberrypi.rst
>>>> >> > > +++ b/user/bsps/arm/raspberrypi.rst
>>>> >> > > @@ -5,4 +5,76 @@
>>>> >> > >  raspberrypi
>>>> >> > >  ===
>>>> >> > >
>>>> >> > > -TODO.
>>>> >> > > +This BSP supports `Raspberry Pi 1` and `Raspberry Pi 2`
>>>> currently.
>>>> >> > > +The support for `Raspberry Pi 3` is work under progress.
>>>> >> > > +The default bootloader on the raspberrypi which is used to boot
>>>> raspbian
>>>> >> >
>>>> >> > raspberrypi -> Raspberry Pi
>>>> >> > raspbian -> Raspbian
>>>> >> >
>>>> >> > > +or other OS can be also used to boot RTEMS. U-boot can also be
>>>> used.
>>>> >> > > +
>>>> >> > > +Setup SD card
>>>> >> > > +
>>>> >> > > +
>>>> >> > > +The Raspberry Pis have an unconventional booting mechanism. The
>>>> GPU
>>>> >> > > +boots first, initializes itself, runs the bootloader and starts
>>>> the CPU.
>>>> >> > > +The bootloader looks for a kernel image, by default the kernel
>>>> images must
>>>> >> > > +have a name of the form `kernel*.img` but this can be changed
>>>> by adding
>>>> >> >
>>>> >> > Please highlight all files in the same way. Other BSPs use the
>&g

Re: Raspberrypi3: AUX Uart driver

[Niteesh]

On Sun, Jan 12, 2020 at 11:42 PM Christian Mauderer 
wrote:

> Hello Niteesh,
>
> On 12/01/2020 16:06, Niteesh wrote:
> > The only issue, I faced while using this driver is the baud divisor is
> > calculated
> > by CLOCK_FREQ/(BAUD_RATE * 16) (*ns16550-context.c:68)*
> > but it should BAUD_DIV = (CLOCK_FREQ/(8 * BAUD_RATE)) - 1, for Rpi3.
> > For testing, I assigned the baud divisor to 270 (115200 bits/s) in
> > ns16550-context.c,
> > and everything works fine.
>
> Sounds great. In NS16550_GetBaudDivisor there is already a case where
> the baudDivisor is calculated differently (depending on
> ctx->has_precision_clock_synthesizer and
> ctx->has_fractional_divider_register). If none of the two cases are ok
> for the controller you could just add another one.
>
Can we pass in a function, which gets called, won't this be more flexible?
because
in the future if we have some other board that has a different calculation
for the baud rate
the function will take care of it.

> >
> > For console selection, my plan is to search for the aux node using
> > compatible
> > property and if its status is enabled, then initialize the AUX uart and
> > set the BSP_output_char
> > to aux_output_char, else pl011_output_char. All this will be done inside
> > the uart_probe function,
> > except for the initialization of AUX which will be done in init_ctx_aux.
> > And finally, call the output char
> > function using *BSP_output_char. Do you have any neat way to do this?
>
> I don't have an example for a similar case at hand. So: No, no neat way
> that I can tell you.
>
> Before you start to write code: Please take a look at the different
> beagle variants what is possible. Is there a variant where AUX uart
> would be there but shouldn't be used as a console (one of the Zeros
> maybe or the compute module?). How does Raspbian or FreeBSD decide which
> port should be used? Maybe they decide based on the commandline.txt? In
> such a case it would be better to just initialize all active (in the
> fdt) serial ports and decide based on the commandline too.
>

The Documentation says the following:
*By default, on Raspberry Pis equipped with the wireless/Bluetooth*
*module (Raspberry Pi 3 and Raspberry Pi Zero W), **the PL011 UART is*
*connected to the Bluetooth module, while the mini UART is used as the
primary UART and*


*will have a Linux console on it. On all other models, the PL011 is used as
the primary UART.*
*In Linux device terms, by default, /dev/ttyS0 refers to the mini UART, and
/dev/ttyAMA0 refers*
*to the PL011. The primary UART is the one assigned to the Linux console,
which depends on*
*the Raspberry Pi model as described above. There are also symlinks:
/dev/serial0, which always*
*refers to the primary UART (if enabled), and /dev/serial1, which similarly
always refers to the secondary UART (if enabled).*

I checked in all the DTB files, by decompiling them (files are from
https://github.com/raspberrypi/firmware/tree/master/boot).
In all board with support for wireless and bluetooth, the AuX is enabled
and serial0 points to it. So we could use serial0
to find the correct UART port. I think this is solid enough. So, should I
use this approach?

Or if using the command line, then we need to move the link to
CONSOLE_DEVICE to console_initialize, and parse the
command line twice. If this is no problem, then we could use this approach
also.

> >
> > And why don't we have a function similar to *of_device_is_available*,
> > since there will be more and more
> > FDT based boards, this will be really helpful.
>
> I agree that it would be helpful. Seems that you just found a function
> that should be in a FDT framework.
>
> RTEMS currently only has the basic libfdt functions and some RTEMS
> specific ones. The of_... functions belong to the FreeBSD "Open Firmware
> Bus" which is an abstraction layer on top of FDT. It would be great to
> identify useful ones and port them or provide an RTEMS implementation.
> Like already discussed this could be part of a GSoC project.
>
> Best regards
>
> Christian
>
> >
> > On Sun, Jan 5, 2020 at 12:57 AM Christian Mauderer  > <mailto:l...@c-mauderer.de>> wrote:
> >
> > On 04/01/2020 09:32, Niteesh wrote:
> > > We could now run RTEMS on Rpi3. I tried examples from the samples
> > > section and they run
> > > fine. But still, a lot of functionality has to tested since it
> > uses the
> > > RPI2 BSP. To test these examples
> > > I used a simple driver for the AUX.
> > > The documentation from BCM link
> > >
> > <
> https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Pe

Re: Raspberrypi3: AUX Uart driver

[Niteesh]

The following questions are not related to uart, but they kept bugging me
for a while, and want to clear them

1) If the linker places the text section at 0x20 what happens all the
memory below that? Are they left empty
or are they used for things like stack and ISR table?
2) According to the docs, the cpu start executing instruction from
kernel_address(0x20) then why is the
start address at 0x200080? I looked the dump 0x20 -
0x200040(bsp_section_start_begin)
contains low level initialization like cache and mmu setup, which is then
followed by the vector table. In OS environment
the loader would load the elf file and read the start address and jump to
it, but here we only have a binary file, then
why do we care about the start address?
3) Does the loader(start.elf) start placing the image from address 0, for
rpi the RAM starts at address 0x0 so,
does the loader copy word by word from the binary file to the RAM?

English is not my native language, and it is really hard for me to express
my question's so please if you don't understand the question
do let me know.

On Mon, Jan 13, 2020 at 1:56 AM Niteesh  wrote:

> On Sun, Jan 12, 2020 at 11:42 PM Christian Mauderer 
> wrote:
>
>> Hello Niteesh,
>>
>> On 12/01/2020 16:06, Niteesh wrote:
>> > The only issue, I faced while using this driver is the baud divisor is
>> > calculated
>> > by CLOCK_FREQ/(BAUD_RATE * 16) (*ns16550-context.c:68)*
>> > but it should BAUD_DIV = (CLOCK_FREQ/(8 * BAUD_RATE)) - 1, for Rpi3.
>> > For testing, I assigned the baud divisor to 270 (115200 bits/s) in
>> > ns16550-context.c,
>> > and everything works fine.
>>
>> Sounds great. In NS16550_GetBaudDivisor there is already a case where
>> the baudDivisor is calculated differently (depending on
>> ctx->has_precision_clock_synthesizer and
>> ctx->has_fractional_divider_register). If none of the two cases are ok
>> for the controller you could just add another one.
>>
> Can we pass in a function, which gets called, won't this be more flexible?
> because
> in the future if we have some other board that has a different calculation
> for the baud rate
> the function will take care of it.
>
>> >
>> > For console selection, my plan is to search for the aux node using
>> > compatible
>> > property and if its status is enabled, then initialize the AUX uart and
>> > set the BSP_output_char
>> > to aux_output_char, else pl011_output_char. All this will be done inside
>> > the uart_probe function,
>> > except for the initialization of AUX which will be done in init_ctx_aux.
>> > And finally, call the output char
>> > function using *BSP_output_char. Do you have any neat way to do this?
>>
>> I don't have an example for a similar case at hand. So: No, no neat way
>> that I can tell you.
>>
>> Before you start to write code: Please take a look at the different
>> beagle variants what is possible. Is there a variant where AUX uart
>> would be there but shouldn't be used as a console (one of the Zeros
>> maybe or the compute module?). How does Raspbian or FreeBSD decide which
>> port should be used? Maybe they decide based on the commandline.txt? In
>> such a case it would be better to just initialize all active (in the
>> fdt) serial ports and decide based on the commandline too.
>>
>
> The Documentation says the following:
> *By default, on Raspberry Pis equipped with the wireless/Bluetooth*
> *module (Raspberry Pi 3 and Raspberry Pi Zero W), **the PL011 UART is*
> *connected to the Bluetooth module, while the mini UART is used as the
> primary UART and*
>
>
> *will have a Linux console on it. On all other models, the PL011 is used
> as the primary UART.*
> *In Linux device terms, by default, /dev/ttyS0 refers to the mini UART,
> and /dev/ttyAMA0 refers*
> *to the PL011. The primary UART is the one assigned to the Linux console,
> which depends on*
> *the Raspberry Pi model as described above. There are also symlinks:
> /dev/serial0, which always*
> *refers to the primary UART (if enabled), and /dev/serial1, which
> similarly always refers to the secondary UART (if enabled).*
>
> I checked in all the DTB files, by decompiling them (files are from
> https://github.com/raspberrypi/firmware/tree/master/boot).
> In all board with support for wireless and bluetooth, the AuX is enabled
> and serial0 points to it. So we could use serial0
> to find the correct UART port. I think this is solid enough. So, should I
> use this approach?
>
> Or if using the command line, then we need to move the link to
> CONSOLE_DEVICE to console_initialize, and parse the
> command line 

Re: Raspberrypi3: AUX Uart driver

[Niteesh]

On Mon, Jan 13, 2020 at 1:38 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> On 12/01/2020 21:26, Niteesh wrote:
> > On Sun, Jan 12, 2020 at 11:42 PM Christian Mauderer  > <mailto:l...@c-mauderer.de>> wrote:
> >
> > Hello Niteesh,
> >
> > On 12/01/2020 16:06, Niteesh wrote:
> > > The only issue, I faced while using this driver is the baud
> divisor is
> > > calculated
> > > by CLOCK_FREQ/(BAUD_RATE * 16) (*ns16550-context.c:68)*
> > > but it should BAUD_DIV = (CLOCK_FREQ/(8 * BAUD_RATE)) - 1, for
> Rpi3.
> > > For testing, I assigned the baud divisor to 270 (115200 bits/s) in
> > > ns16550-context.c,
> > > and everything works fine.
> >
> > Sounds great. In NS16550_GetBaudDivisor there is already a case where
> > the baudDivisor is calculated differently (depending on
> > ctx->has_precision_clock_synthesizer and
> > ctx->has_fractional_divider_register). If none of the two cases are
> ok
> > for the controller you could just add another one.
> >
> > Can we pass in a function, which gets called, won't this be more
> > flexible? because
> > in the future if we have some other board that has a different
> > calculation for the baud rate
> > the function will take care of it.
>
> It's possible. Please make sure to be compatible with the current API.
> For example if the pointer is NULL you should call the legacy function
> instead.
>

I will be adding an extra field, a function pointer to ns16550_context,
the prototype of the function would be *uint32_t calculate_baud_divisor(
ns16550_context * )*
This is will calculate the baud divisor using its own formula and the
initial baud.
If this function is not NULL then it would be called inside
*NS16550_GetBaudDivisor* function,

>
> > >
> > > For console selection, my plan is to search for the aux node using
> > > compatible
> > > property and if its status is enabled, then initialize the AUX
> > uart and
> > > set the BSP_output_char
> > > to aux_output_char, else pl011_output_char. All this will be done
> > inside
> > > the uart_probe function,
> > > except for the initialization of AUX which will be done in
> > init_ctx_aux.
> > > And finally, call the output char
> > > function using *BSP_output_char. Do you have any neat way to do
> this?
> >
> > I don't have an example for a similar case at hand. So: No, no neat
> way
> > that I can tell you.
> >
> > Before you start to write code: Please take a look at the different
> > beagle variants what is possible. Is there a variant where AUX uart
> > would be there but shouldn't be used as a console (one of the Zeros
> > maybe or the compute module?). How does Raspbian or FreeBSD decide
> which
> > port should be used? Maybe they decide based on the commandline.txt?
> In
> > such a case it would be better to just initialize all active (in the
> > fdt) serial ports and decide based on the commandline too.
> >
> >
> > The Documentation says the following:
> > *By default, on Raspberry Pis equipped with the wireless/Bluetooth*
> > *module (Raspberry Pi 3 and Raspberry Pi Zero W), **the PL011 UART is*
> > *connected to the Bluetooth module, while the mini UART is used as the
> > primary UART and*
> > *will have a Linux console on it. On all other models, the PL011 is used
> > as the primary UART.
> >
> > *
> > *In Linux device terms, by default, /dev/ttyS0 refers to the mini UART,
> > and /dev/ttyAMA0 refers*
> > *to the PL011. The primary UART is the one assigned to the Linux
> > console, which depends on*
> > *the Raspberry Pi model as described above. There are also symlinks:
> > /dev/serial0, which always*
> > *refers to the primary UART (if enabled), and /dev/serial1, which
> > similarly always refers to the secondary UART (if enabled).*
> > *
> > *
> > I checked in all the DTB files, by decompiling them (files are
> > from https://github.com/raspberrypi/firmware/tree/master/boot).
> > In all board with support for wireless and bluetooth, the AuX is enabled
> > and serial0 points to it. So we could use serial0
> > to find the correct UART port. I think this is solid enough. So, should
> > I use this approach?
>
> Sounds OK. If possible please initialize the other UART too if it is
> enabled in the FDT. Although we don't support bluetooth yet maybe there
> w

Re: Raspberrypi3: AUX Uart driver

[Niteesh]

The ns16550_context already has a field named baud_divisor, so if the user
passes
value for it, then we can skip the GetBaudDivisor function and use that
value instead.

Is this approach okay?

On Mon, Jan 13, 2020 at 3:46 PM Niteesh  wrote:

> On Mon, Jan 13, 2020 at 1:38 PM Christian Mauderer <
> christian.maude...@embedded-brains.de> wrote:
>
>> On 12/01/2020 21:26, Niteesh wrote:
>> > On Sun, Jan 12, 2020 at 11:42 PM Christian Mauderer > > <mailto:l...@c-mauderer.de>> wrote:
>> >
>> > Hello Niteesh,
>> >
>> > On 12/01/2020 16:06, Niteesh wrote:
>> > > The only issue, I faced while using this driver is the baud
>> divisor is
>> > > calculated
>> > > by CLOCK_FREQ/(BAUD_RATE * 16) (*ns16550-context.c:68)*
>> > > but it should BAUD_DIV = (CLOCK_FREQ/(8 * BAUD_RATE)) - 1, for
>> Rpi3.
>> > > For testing, I assigned the baud divisor to 270 (115200 bits/s) in
>> > > ns16550-context.c,
>> > > and everything works fine.
>> >
>> > Sounds great. In NS16550_GetBaudDivisor there is already a case
>> where
>> > the baudDivisor is calculated differently (depending on
>> > ctx->has_precision_clock_synthesizer and
>> > ctx->has_fractional_divider_register). If none of the two cases are
>> ok
>> > for the controller you could just add another one.
>> >
>> > Can we pass in a function, which gets called, won't this be more
>> > flexible? because
>> > in the future if we have some other board that has a different
>> > calculation for the baud rate
>> > the function will take care of it.
>>
>> It's possible. Please make sure to be compatible with the current API.
>> For example if the pointer is NULL you should call the legacy function
>> instead.
>>
>
> I will be adding an extra field, a function pointer to ns16550_context,
> the prototype of the function would be *uint32_t calculate_baud_divisor(
> ns16550_context * )*
> This is will calculate the baud divisor using its own formula and the
> initial baud.
> If this function is not NULL then it would be called inside
> *NS16550_GetBaudDivisor* function,
>
> >
>> > >
>> > > For console selection, my plan is to search for the aux node using
>> > > compatible
>> > > property and if its status is enabled, then initialize the AUX
>> > uart and
>> > > set the BSP_output_char
>> > > to aux_output_char, else pl011_output_char. All this will be done
>> > inside
>> > > the uart_probe function,
>> > > except for the initialization of AUX which will be done in
>> > init_ctx_aux.
>> > > And finally, call the output char
>> > > function using *BSP_output_char. Do you have any neat way to do
>> this?
>> >
>> > I don't have an example for a similar case at hand. So: No, no neat
>> way
>> > that I can tell you.
>> >
>> > Before you start to write code: Please take a look at the different
>> > beagle variants what is possible. Is there a variant where AUX uart
>> > would be there but shouldn't be used as a console (one of the Zeros
>> > maybe or the compute module?). How does Raspbian or FreeBSD decide
>> which
>> > port should be used? Maybe they decide based on the
>> commandline.txt? In
>> > such a case it would be better to just initialize all active (in the
>> > fdt) serial ports and decide based on the commandline too.
>> >
>> >
>> > The Documentation says the following:
>> > *By default, on Raspberry Pis equipped with the wireless/Bluetooth*
>> > *module (Raspberry Pi 3 and Raspberry Pi Zero W), **the PL011 UART is*
>> > *connected to the Bluetooth module, while the mini UART is used as the
>> > primary UART and*
>> > *will have a Linux console on it. On all other models, the PL011 is used
>> > as the primary UART.
>> >
>> > *
>> > *In Linux device terms, by default, /dev/ttyS0 refers to the mini UART,
>> > and /dev/ttyAMA0 refers*
>> > *to the PL011. The primary UART is the one assigned to the Linux
>> > console, which depends on*
>> > *the Raspberry Pi model as described above. There are also symlinks:
>> > /dev/serial0, which always*
>> > *refers to the primary UART (if enabled), and /dev/serial1, which
>> > similarly always r

Re: Raspberrypi3: AUX Uart driver

[Niteesh]

On Tue, Jan 14, 2020 at 1:57 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> On 13/01/2020 19:04, Niteesh wrote:
> > The ns16550_context already has a field named baud_divisor, so if the
> > user passes
> > value for it, then we can skip the GetBaudDivisor function and use that
> > value instead.
> >
> > Is this approach okay?
>
> Is the driver still able to handle different baud rates with this? Does
> the ioctl call for setting the baudrate work?

I didn't think about this, it won't work if we are using this method.
ns16550_set_attributes
calls ns16550_GetBaudDivisor, then I think we will have to stick with the
old method.

>
>
Best regards
>
> Christian
>
> >
> > On Mon, Jan 13, 2020 at 3:46 PM Niteesh  > <mailto:gsnb...@gmail.com>> wrote:
> >
> > On Mon, Jan 13, 2020 at 1:38 PM Christian Mauderer
> >  > <mailto:christian.maude...@embedded-brains.de>> wrote:
> >
> > On 12/01/2020 21:26, Niteesh wrote:
> > > On Sun, Jan 12, 2020 at 11:42 PM Christian Mauderer
> > mailto:l...@c-mauderer.de>
> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>
> wrote:
> > >
> > > Hello Niteesh,
> > >
> > > On 12/01/2020 16:06, Niteesh wrote:
> > > > The only issue, I faced while using this driver is the
> > baud divisor is
> > > > calculated
> > > > by CLOCK_FREQ/(BAUD_RATE * 16) (*ns16550-context.c:68)*
> > > > but it should BAUD_DIV = (CLOCK_FREQ/(8 * BAUD_RATE)) -
> > 1, for Rpi3.
> > > > For testing, I assigned the baud divisor to 270 (115200
> > bits/s) in
> > > > ns16550-context.c,
> > > > and everything works fine.
> > >
> > > Sounds great. In NS16550_GetBaudDivisor there is already a
> > case where
> > > the baudDivisor is calculated differently (depending on
> > > ctx->has_precision_clock_synthesizer and
> > > ctx->has_fractional_divider_register). If none of the two
> > cases are ok
> > > for the controller you could just add another one.
> > >
> > > Can we pass in a function, which gets called, won't this be
> more
> > > flexible? because
> > > in the future if we have some other board that has a different
> > > calculation for the baud rate
> > > the function will take care of it.
> >
> > It's possible. Please make sure to be compatible with the
> > current API.
> > For example if the pointer is NULL you should call the legacy
> > function
> > instead.
> >
> >
> > I will be adding an extra field, a function pointer to
> ns16550_context,
> > the prototype of the function would be *uint32_t
> > calculate_baud_divisor( ns16550_context * )*
> > This is will calculate the baud divisor using its own formula and
> > the initial baud.
> > If this function is not NULL then it would be called inside
> > *NS16550_GetBaudDivisor* function,
> > *
> > *
> >
> > >
> > > >
> > > > For console selection, my plan is to search for the aux
> > node using
> > > > compatible
> > > > property and if its status is enabled, then initialize
> > the AUX
> > > uart and
> > > > set the BSP_output_char
> > > > to aux_output_char, else pl011_output_char. All this
> > will be done
> > > inside
> > > > the uart_probe function,
> > > > except for the initialization of AUX which will be done
> in
> > > init_ctx_aux.
> > > > And finally, call the output char
> > > > function using *BSP_output_char. Do you have any neat
> > way to do this?
> > >
> > > I don't have an example for a similar case at hand. So:
> > No, no neat way
> > > that I can tell you.
> > >
> > > Before you start to write code: Please take a look at the
> > different
>

Re: Raspberrypi3: AUX Uart driver

[Niteesh]

I am finished with code, I tested it in QEMU emulator raspi2but it doesn't
work
when testing on real rpi3. I don't know if the problem is with loading the
FDT
or with my code?
How do I send the code, so that you can take a look at it?

On Tue, Jan 14, 2020 at 8:04 PM Niteesh  wrote:

> On Tue, Jan 14, 2020 at 1:57 PM Christian Mauderer <
> christian.maude...@embedded-brains.de> wrote:
>
>> On 13/01/2020 19:04, Niteesh wrote:
>> > The ns16550_context already has a field named baud_divisor, so if the
>> > user passes
>> > value for it, then we can skip the GetBaudDivisor function and use that
>> > value instead.
>> >
>> > Is this approach okay?
>>
>> Is the driver still able to handle different baud rates with this? Does
>> the ioctl call for setting the baudrate work?
>
> I didn't think about this, it won't work if we are using this method.
> ns16550_set_attributes
> calls ns16550_GetBaudDivisor, then I think we will have to stick with the
> old method.
>
>>
>>
> Best regards
>>
>> Christian
>>
>> >
>> > On Mon, Jan 13, 2020 at 3:46 PM Niteesh > > <mailto:gsnb...@gmail.com>> wrote:
>> >
>> > On Mon, Jan 13, 2020 at 1:38 PM Christian Mauderer
>> > > > <mailto:christian.maude...@embedded-brains.de>> wrote:
>> >
>> > On 12/01/2020 21:26, Niteesh wrote:
>> > > On Sun, Jan 12, 2020 at 11:42 PM Christian Mauderer
>> > mailto:l...@c-mauderer.de>
>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>
>> wrote:
>> > >
>> > > Hello Niteesh,
>> > >
>> > > On 12/01/2020 16:06, Niteesh wrote:
>> > > > The only issue, I faced while using this driver is the
>> > baud divisor is
>> > > > calculated
>> > > > by CLOCK_FREQ/(BAUD_RATE * 16) (*ns16550-context.c:68)*
>> > > > but it should BAUD_DIV = (CLOCK_FREQ/(8 * BAUD_RATE)) -
>> > 1, for Rpi3.
>> > > > For testing, I assigned the baud divisor to 270 (115200
>> > bits/s) in
>> > > > ns16550-context.c,
>> > > > and everything works fine.
>> > >
>> > > Sounds great. In NS16550_GetBaudDivisor there is already a
>> > case where
>> > > the baudDivisor is calculated differently (depending on
>> > > ctx->has_precision_clock_synthesizer and
>> > > ctx->has_fractional_divider_register). If none of the two
>> > cases are ok
>> > > for the controller you could just add another one.
>> > >
>> > > Can we pass in a function, which gets called, won't this be
>> more
>> > > flexible? because
>> > > in the future if we have some other board that has a different
>> > > calculation for the baud rate
>> > > the function will take care of it.
>> >
>> > It's possible. Please make sure to be compatible with the
>> > current API.
>> > For example if the pointer is NULL you should call the legacy
>> > function
>> > instead.
>> >
>> >
>> > I will be adding an extra field, a function pointer to
>> ns16550_context,
>> > the prototype of the function would be *uint32_t
>> > calculate_baud_divisor( ns16550_context * )*
>> > This is will calculate the baud divisor using its own formula and
>> > the initial baud.
>> > If this function is not NULL then it would be called inside
>> > *NS16550_GetBaudDivisor* function,
>> > *
>> > *
>> >
>> > >
>> > > >
>> > > > For console selection, my plan is to search for the aux
>> > node using
>> > > > compatible
>> > > > property and if its status is enabled, then initialize
>> > the AUX
>> > > uart and
>> > > > set the BSP_output_char
>> > > > to aux_output_char, else pl011_output_char. All this
>> > will be done
>> > > inside
>> > >