Re: Raspberry Pi test report

2020-01-21 Thread Christian Mauderer 
On 21/01/2020 00:30, Chris Johns wrote:
> On 21/1/20 10:20 am, Alan Cudmore wrote:
>> As it turns out the latest RTEMS master may need some of the dtb
>> and/or overlay files in the raspberry pi SD card. But the updated
>> instructions that Niteesh submitted for the raspberrypi BSP should
>> still be valid.
> 
> Great.
> 
>> Either way, we should be able to automate it. A firmware release on
>> Github is ~180 megabytes. If you clone the whole repository, it's 10+
>> Gigabytes, probably because you get every binary release.
> 
> Ouch. If we list the needed files, even if there is a few, I can fetch them 
> from
> github and avoid a full clone. We would need to settle on a specific hash or
> version but that is not a bad thing.

If I remember correctly to support all variants of RPi it should be
basically everything from this folder:

https://github.com/raspberrypi/firmware/tree/1.20200114/boot

except for kernel*.img and overlays. There is a description what the
files are for here:

https://www.raspberrypi.org/documentation/configuration/boot_folder.md

Beneath that we need a "config.txt" with the following content (assuming
our rtems application is called "rtems.img"):

kernel=rtems.img
kernel_address=0x0020

> 
>> I'm trying to troubleshoot the RPi 2 SMP a little bit now. Non SMP
>> code seems to work on the Pi 2, but when you have an example with
>> #define CONFIGURE_MAXIMUM_PROCESSORS 4
>> it crashes during initialization.
> 
> Awesome and all the best. I am sure you will figure it out.
> 
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
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: GSOC: Adding FDT infrastructure to RTEMS

2020-01-21 Thread Christian Mauderer 
Hello Niteesh,

great that you pick up that project.

On 20/01/2020 18:38, Niteesh wrote:
> This is what I have understood till now, please correct me if I am wrong
> All this explanation is in context with FreeBSD.

Note that this stuff in FreeBSD is quite universal and tend to be a bit
more complex than would be absolutely necessary. I think a first
implementation for RTEMS can be a lot simpler.

> The drivers register themselves using* EARLY_DRIVER_MODULE*, this done with
> the help of linker sets right?

I'm not entirely sure whether it's linker set in FreeBSD but in libbsd
we use linker sets for that.

> Where all the data structures for the
> drivers stored things like
> compatible strings etc. Is it also in linkerset?

In the simplest form (the one that would be the right target for a first
draft) the strings are just written as constants in the driver source.
For example take a look at freebsd/sys/arm/ti/am335x/am335x_usbss.c. The
usbss_probe just has the following line:

if (!ofw_bus_is_compatible(dev, "ti,am33xx-usb"))
return (ENXIO);

The relevant convenient function here is ofw_bus_is_compatible.
Something like that would be great for RTEMS too.

> At some point during initialization, the *ofwbus(fdtbus) *is
> initialized, it is attached to some kind of
> bus not sure which one, is it *nexus or newbus*? To which another
> abstract bus called *simplebus *is
> attached, all peripherals are then attached to this bus.

Correct. FreeBSD uses a bus system for all hardware. It can have
different connections and different order depending on the board. All of
them are connected sooner or later to a Nexus. That's the first bus in
the system.

Don't go too deep into the different bus systems. I don't think that you
would need more than one "bus" for the project. Maybe it's not even
necessary to copy the bus structure but just use a similar interface
instead.

> I couldn't find anything called *fdtbus*, in the FreeBSD code, All I
> could find was *ofwbus*, but all reference
> talk only about *fdtbus*, am I missing something?

The "open firmware bus" is the one that parses the FDT. That's the
relevant one for you. I'm not sure where the term "fdtbus" comes from.
Maybe it's an old one?

> After *simplebus* init is done, the *ofwbus_attach(ofwbus.c:137) *goes
> through all nodes and attaches
> them to *simplebus*.
OK.

> But I am really sure of what happens after, it
> would be really helpful if someone could
> explain it or at least provide some resources.

Basically the FreeBSD bus systems provide an abstracted view to
information about the devices. Each bus loops through the connected
devices (for ofwbus this means looping through all active nodes in the fdt).

For each device the probe of all (relevant) drivers is called to check
whether the driver want's to drive the device. If it wants the device
and no better driver is found (depends on the return value of probe) the
attach of the driver will be called. From there it's more or less the
responsibility of the driver what it want's to do.

The driver can ask the bus systems for resources like interrupts, pins
or memory. The bus will then look up the resource in it's information
source - for the ofwbus it will look in the fdt - and return the
resource. That stuff is done with "bus_alloc_resource_any" functions and
similar.

> 
> The resources that I used:
> https://www.bsdcan.org/2010/schedule/attachments/136_FreeBSD_FDT-slides.pdf
> https://www.semihalf.com/pub/bsdcan/2010_FreeBSD_FDT-paper.pdf
> Man pages from FreeBSD.
> 
> 
> On Mon, Jan 20, 2020 at 10:30 PM Niteesh  > wrote:
> 
> I interested in adding FDT infrastructure similar to FreeBSD and
> Linux to
> RTEMS as a GSOC project. I have very little knowledge of how all
> this works,
> but I have started learning by digging into FreeBSD code, using online
> forums and also thanks to Christian for patiently answering all my
> questions.
> 
> My plan is to add a subsystem, which will parse the DTB file and
> initialize all active
> devices present in the system. It will ask for drivers that can
> handle the devices and
> the best driver is selected and attached to the driver.
> As I told before, I have very little idea of the complexity, I have
> no idea of what problems
> I would face?
> 
> I will discuss what I have learned till now in a following mail,
> please correct me if I 
> am wrong.
> 
> What do you guys think about this? what all should be implemented in
> a GSOC timeline?
> I know this is not very detailed, but I will create a more detailed
> proposal based
> on your comments soon.
> 
> Thank you,
> Niteesh
> 
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
D

Re: Requirement Document generator tool

2020-01-21 Thread Christian Mauderer 
On 20/01/2020 22:37, Chris Johns wrote:
> On 14/1/20 7:18 pm, Christian Mauderer wrote:
>> On 13/01/2020 18:03, Joel Sherrill wrote:
>>>
>>>
>>> On Mon, Jan 13, 2020 at 10:04 AM Christian Mauderer
>>> >> > wrote:
>>>
>>> Hello Jose,
>>>
>>> On 10/01/2020 17:33, Jose Valdez wrote:
>>> > Hello,
>>> >
>>> > Regarding this topic and to start to define the python tools that
>>> are more appropriate for the RTEMS community python developments, I
>>> would like to propose the following tools (to be placed in RTEMS
>>> Software Engineering manual):
>>> >
>>> > Python language version: 3.6 (minimum version for Doorstop 2.0.post2)
>>> > Python coding style/standard - Google (as suggested by Gedare)
>>> > Python documentation style - Google docstrings (to be in
>>> accordance with coding style. Note it is supported by sphinx)
>>> > Python test approach - unittest (seems to be the standard used by
>>> python)
>>> > Python static analysis - pylint (recommended by Google style, see
>>> http://google.github.io/styleguide/pyguide.html) and mypy (catch
>>> additional errors) Python code coverage - Coverage.py (seems to be
>>> the standard used by python)
>>> > Python third party packages - For now we are using: paramiko,
>>> pyserial, pexpect, gitpython, but the list is expected to be
>>> changed. I think here any third package is allowed, as long as the
>>> license of the package complies with RTEMS project license.
>>>
>>> To be future-proof: python3 compatibility would be nearly a must-have
>>> for any new library.
>>>
>>>
>>> We discussed this somewhere earlier and I thought we decided that if
>>> it was a core tool required for a "normal user", then it would have to
>>> be Python 2.x and 3.x compatible. Tools for "requirements user" or
>>> "pre-qualification user" (pick a name for this role), can be 3.x only 
>>> mainly because there was so much infrastructure required for the
>>> "requirements user" that already needed Python 3.x.
> 
> Yes this is correct. Python is used in the rtems-tools repo and any program in
> the rtems-tools repo needs to support Python 2 and Python 3 no matter what 
> role
> it performs. The rtems-tools repo is not the same as doorstop or similar tools
> used to develop RTEMS, they are user tools used to develop application to run 
> on
> RTEMS.

Does that mean you don't want to have any pre-qualification tools in the
rtems-tools repo? If yes: Where else?

I fully agree that every tool that is thought for every day use for 99%
of the RTEMS users should have Python 2 and 3 support. With no official
Python 2 support since this year I don't think that this would be a good
requirement for new specialized areas like pre-qualification. I think
you agree there?

On the other hand I wouldn't know a better place then rtems-tools for
everything produced through the pre-qualification effort. So I'm not a
fan of saying: Everything in rtems-tools should be Python 2 + 3.

> 
> It is not clear to me what role the original python specification Jose listed 
> is
> for. I will restrict my comments to rtems-tools or more generally any tool
> installed into the user's tools prefix for use when developing RTEMS 
> applications.
> 
> For a user focused tool:
> 
> - Python is 2 and 3
> - No external third party packages, all support needs to be internal.

What about stuff like pygdb (which is already used in rtems-tools)?

> - Fully portable for all supported host platforms, that is Windows, MacOS,
> FreeBSD and Linux.
> 
> The second item is important. If user installed tools start to depend on 3rd
> party packages the deployment complexity for us rises and the process becomes
> complex.
> 
> While on the topic of 3rd party packages I do not agree with Jose's view any
> package can be used if the license it suitable. Package complexity, it's
> dependencies and portability need to be considered, for example gitpython uses
> gitdb and this is python code to directly read and write a git repo. I would 
> not
> like any of our repo's being modified by that code so I would prefer we do not
> use it. If we need to extract data I prefer the solution in the rtems-tools
> toolkit so we should also consider using existing support first.

OK. So rule for third party is:

For everything that is used by 99% of our users: Basically don't use any
third party. Exceptions for that user group have to be discussed (and
are most likely rejected) on the mailing list.

For special use cases:
- Should be avoided if a build-in can be used instead.
- Only if there isn't another package for the same purpose already in use.
- Open source license that is not putting restrictions on our code (like
a code generator that would put the generated code under GPL).
- Portable to all mayor host systems (for RTEMS that's Windows, Linux,
FreeBSD, MacOS).
- Libraries that touch critical infrastructure would ha

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

2020-01-21 Thread Christian Mauderer 
On 21/01/2020 00:33, Chris Johns wrote:
> On 29/12/19 8:03 pm, Christian Mauderer wrote:
>> - You can use a real hardware debugger for it. That's what I currently
>> do - also qemu + gdb could be more powerfull. For that you basically
>> connect the Alt4 pins (see https://pinout.xyz/pinout/jtag) to a hardware
>> debugger (something supported by OpenOCD, Segger J-Link, ...) add
>> "gpio=22-27=a4" to your config.txt and load a very minimal kernel that
>> does just an endless loop. Note that I had some trouble debugging more
>> than one core with my debugger.
> 
> This is really valuable information, thank you. It would be nice to see it in
> the BSP section of the user manual :)
> 
> Chris
> 

You can find that stuff with not too much search on a lot of different
web sites. Therefore I didn't think about adding it to the manual. But I
can add a short note in the next days.

Best regards

Christian
-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
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: [PATCH v2] Raspberrypi: updated the console interface.

2020-01-21 Thread Niteesh 
I have sent a new patch for the AUX UART driver, can you
please take a look at it?

https://www.mail-archive.com/devel@rtems.org/msg21615.html
https://www.mail-archive.com/devel@rtems.org/msg21614.html

On Tue, Jan 21, 2020 at 2:42 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> On 21/01/2020 00:33, Chris Johns wrote:
> > On 29/12/19 8:03 pm, Christian Mauderer wrote:
> >> - You can use a real hardware debugger for it. That's what I currently
> >> do - also qemu + gdb could be more powerfull. For that you basically
> >> connect the Alt4 pins (see https://pinout.xyz/pinout/jtag) to a
> hardware
> >> debugger (something supported by OpenOCD, Segger J-Link, ...) add
> >> "gpio=22-27=a4" to your config.txt and load a very minimal kernel that
> >> does just an endless loop. Note that I had some trouble debugging more
> >> than one core with my debugger.
> >
> > This is really valuable information, thank you. It would be nice to see
> it in
> > the BSP section of the user manual :)
> >
> > Chris
> >
>
> You can find that stuff with not too much search on a lot of different
> web sites. Therefore I didn't think about adding it to the manual. But I
> can add a short note in the next days.
>
> Best regards
>
> Christian
> --
> 
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> 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: Cheap Small PC for RTEMS testing

2020-01-21 Thread Joel Sherrill 
On Mon, Jan 20, 2020 at 5:33 PM Chris Johns  wrote:

> On 14/1/20 9:40 am, Joel Sherrill wrote:
> > I was looking for a recommendation as a cheap test PC option.
> >
> > I was considering the Minnowboard but it looks like minnowboard.org
> >  is dead which makes me a bit vervois. It has
> 64-bit
> > BIOS. Did we ever get far enough where this might work?
>
> No as it only has UEFI booting.
>
> > https://store.netgate.com/Turbot4.aspx
>
> It may have the same problem as the Minnow boards, ie UEFI booting only.
>
> > Does anyone have any recommendation? Doesn't have to be fancy. Just a
> UART for
> > console and no development required to make the PC work with RTEMS. :)
>
> I have an old ITX board. It is sooo sloo net booting.
>

We have an old Winsystems board of similar size which has a PC104 slot.
It has a MultiIO card on it which according to Lou is still available.
But it can be slow booting also.

I was looking at the PCs here which list COM ports. I got far enough with
one to look at the manual for the BIOS screens. Couldn't quite convince
myself it had legacy boot. Maybe you will have more luck.



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

Re: Requirement Document generator tool

2020-01-21 Thread Gedare Bloom 
On Tue, Jan 21, 2020 at 2:10 AM Christian Mauderer
 wrote:
>
> On 20/01/2020 22:37, Chris Johns wrote:
> > On 14/1/20 7:18 pm, Christian Mauderer wrote:
> >> On 13/01/2020 18:03, Joel Sherrill wrote:
> >>>
> >>>
> >>> On Mon, Jan 13, 2020 at 10:04 AM Christian Mauderer
> >>>  >>> > wrote:
> >>>
> >>> Hello Jose,
> >>>
> >>> On 10/01/2020 17:33, Jose Valdez wrote:
> >>> > Hello,
> >>> >
> >>> > Regarding this topic and to start to define the python tools that
> >>> are more appropriate for the RTEMS community python developments, I
> >>> would like to propose the following tools (to be placed in RTEMS
> >>> Software Engineering manual):
> >>> >
> >>> > Python language version: 3.6 (minimum version for Doorstop 
> >>> 2.0.post2)
> >>> > Python coding style/standard - Google (as suggested by Gedare)
> >>> > Python documentation style - Google docstrings (to be in
> >>> accordance with coding style. Note it is supported by sphinx)
> >>> > Python test approach - unittest (seems to be the standard used by
> >>> python)
> >>> > Python static analysis - pylint (recommended by Google style, see
> >>> http://google.github.io/styleguide/pyguide.html) and mypy (catch
> >>> additional errors) Python code coverage - Coverage.py (seems to be
> >>> the standard used by python)
> >>> > Python third party packages - For now we are using: paramiko,
> >>> pyserial, pexpect, gitpython, but the list is expected to be
> >>> changed. I think here any third package is allowed, as long as the
> >>> license of the package complies with RTEMS project license.
> >>>
> >>> To be future-proof: python3 compatibility would be nearly a must-have
> >>> for any new library.
> >>>
> >>>
> >>> We discussed this somewhere earlier and I thought we decided that if
> >>> it was a core tool required for a "normal user", then it would have to
> >>> be Python 2.x and 3.x compatible. Tools for "requirements user" or
> >>> "pre-qualification user" (pick a name for this role), can be 3.x only
> >>> mainly because there was so much infrastructure required for the
> >>> "requirements user" that already needed Python 3.x.
> >
> > Yes this is correct. Python is used in the rtems-tools repo and any program 
> > in
> > the rtems-tools repo needs to support Python 2 and Python 3 no matter what 
> > role
> > it performs. The rtems-tools repo is not the same as doorstop or similar 
> > tools
> > used to develop RTEMS, they are user tools used to develop application to 
> > run on
> > RTEMS.
>
> Does that mean you don't want to have any pre-qualification tools in the
> rtems-tools repo? If yes: Where else?
>

Maybe we need a new repo, e.g., 'rtems-devtools.git' to hold
developer-only tooling.

> I fully agree that every tool that is thought for every day use for 99%
> of the RTEMS users should have Python 2 and 3 support. With no official
> Python 2 support since this year I don't think that this would be a good
> requirement for new specialized areas like pre-qualification. I think
> you agree there?
>
> On the other hand I wouldn't know a better place then rtems-tools for
> everything produced through the pre-qualification effort. So I'm not a
> fan of saying: Everything in rtems-tools should be Python 2 + 3.
>
> >
> > It is not clear to me what role the original python specification Jose 
> > listed is
> > for. I will restrict my comments to rtems-tools or more generally any tool
> > installed into the user's tools prefix for use when developing RTEMS 
> > applications.
> >
> > For a user focused tool:
> >
> > - Python is 2 and 3
> > - No external third party packages, all support needs to be internal.
>
> What about stuff like pygdb (which is already used in rtems-tools)?
>
> > - Fully portable for all supported host platforms, that is Windows, MacOS,
> > FreeBSD and Linux.
> >
> > The second item is important. If user installed tools start to depend on 3rd
> > party packages the deployment complexity for us rises and the process 
> > becomes
> > complex.
> >
> > While on the topic of 3rd party packages I do not agree with Jose's view any
> > package can be used if the license it suitable. Package complexity, it's
> > dependencies and portability need to be considered, for example gitpython 
> > uses
> > gitdb and this is python code to directly read and write a git repo. I 
> > would not
> > like any of our repo's being modified by that code so I would prefer we do 
> > not
> > use it. If we need to extract data I prefer the solution in the rtems-tools
> > toolkit so we should also consider using existing support first.
>
> OK. So rule for third party is:
>
> For everything that is used by 99% of our users: Basically don't use any
> third party. Exceptions for that user group have to be discussed (and
> are most likely rejected) on the mailing list.
>
> For special use cases:
> - Should be avoided if a build-in can

Re: RTEMS Project projects?

2020-01-21 Thread Gedare Bloom 
On Mon, Jan 20, 2020 at 2:11 PM Joel Sherrill  wrote:
>
>
>
> On Mon, Jan 20, 2020 at 2:56 PM Chris Johns  wrote:
>>
>> On 21/1/20 4:15 am, Gedare Bloom wrote:
>> > Maybe just a hierarchical picture could be provided.
>
>
> I'd be thrilled to hear we have enough organizational structure to need a 
> figure. :)
>
> Seriously, it couldn't hurt. We now have a number of separate repositories:
> rtems, rtems-libbsd, rtems-tools, rtems-libbsd, the release tools.
>
> That ignores web infrastructure, buildbot, Trac, etc.
>
> It can't do anything but help to get our hands around it all.
>
>>
>> >
>> > I'd also be OK with new "projects" using a different noun, such as "effort"
>> >
>> > As with Chris, I would not change established language (such as for
>> > RTEMS Tools Project). Nice Qualification is still getting off the
>> > ground, the language around it could change.
>>
>> Do we need to diverge from what we have? Is there some standards thing 
>> related
>> to the language I do not understand?
>
>
> I don't think there is any reason to move to sub-projects. The RTEMS Project 
> is
> just a higher level use of the term. It encompasses all individual projects, 
> tasks,
> tickets, processes, servers, etc.
>
Sorry, "language" is ambiguous, I did not mean "programming language"
I meant how we refer to the qualification effort/project. It can be
called something other than a "project" if so decided. But, I don't
see it as a strong need. We have "RTEMS Project" as an umbrella that
everything else falls under (in the open-source community
perspective).

If there are activities outside the scope of the RTEMS Project, i.e.,
in a closed/proprietary way, it would be mildly inappropriate to call
those "RTEMS Xyz Project"

> --joel
>
>>
>>
>> Chris
>>
>> >
>> > Gedare
>> >
>> > On Sun, Jan 19, 2020 at 10:29 PM Chris Johns  wrote:
>> >>
>> >> On 3/1/20 11:30 pm, Sebastian Huber wrote:
>> >>> I work currently on the first chapters of the RTEMS Software Engineering 
>> >>> manual.
>> >>> I came across the term "RTEMS Qualifaction Project" and also "RTEMS
>> >>> Documentation Project". What the "RTEMS Project" is, is more or less 
>> >>> clear.
>> >>
>> >> Clear to whom? Yes to you and I and it should be after all these years. To
>> >> someone new it may not be as clear at all.
>> >>
>> >>> It
>> >>> is the community, infrastructure, and the free and open RTEMS itself. 
>> >>> But, do we
>> >>> really have to emphasize that there are in addition an "RTEMS 
>> >>> Qualifaction
>> >>> Project" and an "RTEMS Documentation Project"?
>> >>
>> >> I am fine with project, it is in common use. Webster defines it as "To 
>> >> form a
>> >> project; to scheme." and this seems to fit how we are using it.
>> >>
>> >>> For me these are merely
>> >>> activities and components inside the RTEMS Project. What would be the 
>> >>> mission
>> >>> statement of the projects?
>> >>
>> >> These things are not precise. KDE refers to itself as a community and 
>> >> encourages
>> >> new users to start projects, Fedora is a project and talks about roles 
>> >> users can
>> >> take.
>> >>
>> >>> What about overlaps?
>> >>
>> >> There is overlap.
>> >>
>> >>> There is currently an RTEMS pre-qualification activity according to ECSS
>> >>> standards ongoing. So, a general term for this activity is useful. I am 
>> >>> not sure
>> >>> if we should name this "RTEMS Qualification Project". I would name it
>> >>> "pre-qualification activity in the RTEMS Project" and short 
>> >>> "pre-qualification
>> >>> activity".
>> >>
>> >> I am not in favor of this. The RTEMS Tools Project is in lots of places, 
>> >> too
>> >> many to change.
>> >>
>> >> The splitting up of these activities into projects helps us attract new 
>> >> users
>> >> who may think RTEMS is too complex and not accessible for them. Maybe 
>> >> focusing
>> >> on a smaller activity or project may be a way to get started.
>> >>
>> >> Chris
>> >> ___
>> >> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Queries related to PRU drivers

2020-01-21 Thread Utkarsh Rai 
I have been waiting for my JTAG to arrive so that I can debug mmap
related issues, meanwhile I have been going through the implementation of
the PRU drivers on freebsd and linux and have few questions.

1. This

method  will fail without a file in /dev,  how are the drivers registered
in /dev in rtems?

2. As far as I could understand freebsd uses uio framework for
communication between PRU and the kernel , how is that implemented for the
RTEMS ?

3. On a side note, building rtems application through waf is very erratic
on my system( waf configure at times fails with 'could not find
' header) . What other build system can be
useful for building rtems applications?

I am sorry if my questions seem a bit naive, I am new to open source
development and I would be grateful for any help.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Raspberry Pi test report

2020-01-21 Thread Christian Mauderer 
Does the same error occur on the Pi2 Qemu? In that case you could use it
for proper debugging.

On 21/01/2020 03:35, Alan Cudmore wrote:
> I don't really have a debug setup.. I'm just using printk for now. But
> I have a pretty efficient setup where I can add a few printk
> statements, rebuild and copy the smp01.exe sample over to the SD card.
> I use this board:
> https://www.adafruit.com/product/3589
> It lets me connect the serial port using a USB cable, and it also
> supplies power and provides a switch. I can pop the SD card in, flip
> the switch and watch the UART output.
> (Edit, make, objcopy, move card to pi, and flip the power switch).
> The board provides plenty of power for the single core models through
> the host USB port. I should double check that it's providing enough
> power for the Pi2 before I spend too much time!
> 
> Here is an example of my latest output where the SMP initialization is
> not completing:
> RTEMS RPi 2B 1.1 (1GB) [00a21041]
> in _SMP_Handler_initialize
> in _SMP_Handler_initialize, max processors = 4
> in _SMP_Handler_initialize - calling _CPU_SMP_Initialize
> in _CPU_SMP_Initialize
> in _SMP_Handler_initialize - _SMP_Processor_maximum = 4
> in _SMP_Handler_initialize - calling _SMP_Start_processors
> In _SMP_Start_processors
> In _SMP_Start_processors - index = 0
> In _SMP_Start_processors - index = 1
> In _SMP_Start_processors - calling _CPU_SMP_Start_processor
> in _CPU_SMP_Start_processor
> in _CPU_SMP_Start_processor - wait for secondary processor to complete
> in Per_CPU_State_wait_for_non_initial_state
>  CPU state = 0
> in Per_CPU_State_wait_for_non_initial_state - about to call
> _CPU_SMP_Processor_event_receive in while loop
> in Per_CPU_State_wait_for_non_initial_state - after
> _CPU_SMP_Processor_event_receive in while loop
>  CPU state  after = 0
> in Per_CPU_State_wait_for_non_initial_state - about to call
> _CPU_SMP_Processor_event_receive in while loop
> 
> 
> Alan
> 
> On Mon, Jan 20, 2020 at 9:03 PM Niteesh  wrote:
>>
>> What is your debugging setup? It would be really helpful for my future works 
>> on Rpi3.
>>
>> Thanks,
>> Niteesh
>>
>> On Tue, 21 Jan, 2020, 7:23 AM Alan Cudmore,  wrote:
>>>
>>> A little more information on my Raspberry Pi 2 SMP tests:
>>>
>>> The BSP startup is getting to this loop:
>>> https://git.rtems.org/rtems/tree/cpukit/score/src/percpustatewait.c#n49
>>> (In the function _Per_CPU_State_wait_for_non_initial_state)
>>> In the while loop on line 49, the CPU state is PER_CPU_STATE_INITIAL (0).
>>> The while loop calls _CPU_SMP_Processor_event_receive() and returns,
>>> but the state is still 0
>>> It calls _CPU_SMP_Processor_event_receive() again and does not return.
>>>
>>> I'm reading up on the defines in percpu.h (comments for the defines
>>> are very helpful by the way)
>>> Based on what I can tell in the comments, the boot CPU will wait in
>>> PER_CPU_STATE_INITIAL
>>> until the secondary processors complete their primary initialization
>>> and transition to
>>> PER_CPU_STATE_READY_TO_START_MULTITASKING.
>>>
>>> Next is to figure out why the secondary processors are not
>>> transitioning or possibly why events are not occurring?
>>>
>>> Alan
>>>
>>> On Mon, Jan 20, 2020 at 6:25 PM Chris Johns  wrote:

 On 21/1/20 10:20 am, Alan Cudmore wrote:
> As it turns out the latest RTEMS master may need some of the dtb
> and/or overlay files in the raspberry pi SD card. But the updated
> instructions that Niteesh submitted for the raspberrypi BSP should
> still be valid.

 Great.

> Either way, we should be able to automate it. A firmware release on
> Github is ~180 megabytes. If you clone the whole repository, it's 10+
> Gigabytes, probably because you get every binary release.

 Ouch. If we list the needed files, even if there is a few, I can fetch 
 them from
 github and avoid a full clone. We would need to settle on a specific hash 
 or
 version but that is not a bad thing.

> I'm trying to troubleshoot the RPi 2 SMP a little bit now. Non SMP
> code seems to work on the Pi 2, but when you have an example with
> #define CONFIGURE_MAXIMUM_PROCESSORS 4
> it crashes during initialization.

 Awesome and all the best. I am sure you will figure it out.

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

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

2020-01-21 Thread Christian Mauderer 
Hello Niteesh,

yes, sorry. At work I only put a limited time to the mailing list as
long as the patches are not work related and privately I'm currently
quite busy with another project (will be better after 01.02.). Therefore
I didn't have a look yet. I'll take a look at the patches. I think there
is also still a documentation patch outstanding. I'll give some feedback
there too.

Best regards

Christian

On 21/01/2020 13:17, Niteesh wrote:
> I have sent a new patch for the AUX UART driver, can you
> please take a look at it?
> 
> https://www.mail-archive.com/devel@rtems.org/msg21615.html
> https://www.mail-archive.com/devel@rtems.org/msg21614.html
> 
> On Tue, Jan 21, 2020 at 2:42 PM Christian Mauderer
>  > wrote:
> 
> On 21/01/2020 00:33, Chris Johns wrote:
> > On 29/12/19 8:03 pm, Christian Mauderer wrote:
> >> - You can use a real hardware debugger for it. That's what I
> currently
> >> do - also qemu + gdb could be more powerfull. For that you basically
> >> connect the Alt4 pins (see https://pinout.xyz/pinout/jtag) to a
> hardware
> >> debugger (something supported by OpenOCD, Segger J-Link, ...) add
> >> "gpio=22-27=a4" to your config.txt and load a very minimal kernel
> that
> >> does just an endless loop. Note that I had some trouble debugging
> more
> >> than one core with my debugger.
> >
> > This is really valuable information, thank you. It would be nice
> to see it in
> > the BSP section of the user manual :)
> >
> > Chris
> >
> 
> You can find that stuff with not too much search on a lot of different
> web sites. Therefore I didn't think about adding it to the manual. But I
> can add a short note in the next days.
> 
> Best regards
> 
> Christian
> -- 
> 
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> 
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> 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 Pi test report

2020-01-21 Thread Alan Cudmore 
I can try QEMU. Is there a quick pointer to the QEMU parameters needed
to run a Pi2 image?
Alan

On Tue, Jan 21, 2020 at 3:22 PM Christian Mauderer  wrote:
>
> Does the same error occur on the Pi2 Qemu? In that case you could use it
> for proper debugging.
>
> On 21/01/2020 03:35, Alan Cudmore wrote:
> > I don't really have a debug setup.. I'm just using printk for now. But
> > I have a pretty efficient setup where I can add a few printk
> > statements, rebuild and copy the smp01.exe sample over to the SD card.
> > I use this board:
> > https://www.adafruit.com/product/3589
> > It lets me connect the serial port using a USB cable, and it also
> > supplies power and provides a switch. I can pop the SD card in, flip
> > the switch and watch the UART output.
> > (Edit, make, objcopy, move card to pi, and flip the power switch).
> > The board provides plenty of power for the single core models through
> > the host USB port. I should double check that it's providing enough
> > power for the Pi2 before I spend too much time!
> >
> > Here is an example of my latest output where the SMP initialization is
> > not completing:
> > RTEMS RPi 2B 1.1 (1GB) [00a21041]
> > in _SMP_Handler_initialize
> > in _SMP_Handler_initialize, max processors = 4
> > in _SMP_Handler_initialize - calling _CPU_SMP_Initialize
> > in _CPU_SMP_Initialize
> > in _SMP_Handler_initialize - _SMP_Processor_maximum = 4
> > in _SMP_Handler_initialize - calling _SMP_Start_processors
> > In _SMP_Start_processors
> > In _SMP_Start_processors - index = 0
> > In _SMP_Start_processors - index = 1
> > In _SMP_Start_processors - calling _CPU_SMP_Start_processor
> > in _CPU_SMP_Start_processor
> > in _CPU_SMP_Start_processor - wait for secondary processor to complete
> > in Per_CPU_State_wait_for_non_initial_state
> >  CPU state = 0
> > in Per_CPU_State_wait_for_non_initial_state - about to call
> > _CPU_SMP_Processor_event_receive in while loop
> > in Per_CPU_State_wait_for_non_initial_state - after
> > _CPU_SMP_Processor_event_receive in while loop
> >  CPU state  after = 0
> > in Per_CPU_State_wait_for_non_initial_state - about to call
> > _CPU_SMP_Processor_event_receive in while loop
> >
> >
> > Alan
> >
> > On Mon, Jan 20, 2020 at 9:03 PM Niteesh  wrote:
> >>
> >> What is your debugging setup? It would be really helpful for my future 
> >> works on Rpi3.
> >>
> >> Thanks,
> >> Niteesh
> >>
> >> On Tue, 21 Jan, 2020, 7:23 AM Alan Cudmore,  wrote:
> >>>
> >>> A little more information on my Raspberry Pi 2 SMP tests:
> >>>
> >>> The BSP startup is getting to this loop:
> >>> https://git.rtems.org/rtems/tree/cpukit/score/src/percpustatewait.c#n49
> >>> (In the function _Per_CPU_State_wait_for_non_initial_state)
> >>> In the while loop on line 49, the CPU state is PER_CPU_STATE_INITIAL (0).
> >>> The while loop calls _CPU_SMP_Processor_event_receive() and returns,
> >>> but the state is still 0
> >>> It calls _CPU_SMP_Processor_event_receive() again and does not return.
> >>>
> >>> I'm reading up on the defines in percpu.h (comments for the defines
> >>> are very helpful by the way)
> >>> Based on what I can tell in the comments, the boot CPU will wait in
> >>> PER_CPU_STATE_INITIAL
> >>> until the secondary processors complete their primary initialization
> >>> and transition to
> >>> PER_CPU_STATE_READY_TO_START_MULTITASKING.
> >>>
> >>> Next is to figure out why the secondary processors are not
> >>> transitioning or possibly why events are not occurring?
> >>>
> >>> Alan
> >>>
> >>> On Mon, Jan 20, 2020 at 6:25 PM Chris Johns  wrote:
> 
>  On 21/1/20 10:20 am, Alan Cudmore wrote:
> > As it turns out the latest RTEMS master may need some of the dtb
> > and/or overlay files in the raspberry pi SD card. But the updated
> > instructions that Niteesh submitted for the raspberrypi BSP should
> > still be valid.
> 
>  Great.
> 
> > Either way, we should be able to automate it. A firmware release on
> > Github is ~180 megabytes. If you clone the whole repository, it's 10+
> > Gigabytes, probably because you get every binary release.
> 
>  Ouch. If we list the needed files, even if there is a few, I can fetch 
>  them from
>  github and avoid a full clone. We would need to settle on a specific 
>  hash or
>  version but that is not a bad thing.
> 
> > I'm trying to troubleshoot the RPi 2 SMP a little bit now. Non SMP
> > code seems to work on the Pi 2, but when you have an example with
> > #define CONFIGURE_MAXIMUM_PROCESSORS 4
> > it crashes during initialization.
> 
>  Awesome and all the best. I am sure you will figure it out.
> 
>  Chris
> >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Raspberry Pi test report

2020-01-21 Thread Christian Mauderer 
I think the not yet merged patch from Niteesh is a good reference:

https://lists.rtems.org/pipermail/devel/2020-January/056860.html

On 21/01/2020 21:31, Alan Cudmore wrote:
> I can try QEMU. Is there a quick pointer to the QEMU parameters needed
> to run a Pi2 image?
> Alan
> 
> On Tue, Jan 21, 2020 at 3:22 PM Christian Mauderer  wrote:
>>
>> Does the same error occur on the Pi2 Qemu? In that case you could use it
>> for proper debugging.
>>
>> On 21/01/2020 03:35, Alan Cudmore wrote:
>>> I don't really have a debug setup.. I'm just using printk for now. But
>>> I have a pretty efficient setup where I can add a few printk
>>> statements, rebuild and copy the smp01.exe sample over to the SD card.
>>> I use this board:
>>> https://www.adafruit.com/product/3589
>>> It lets me connect the serial port using a USB cable, and it also
>>> supplies power and provides a switch. I can pop the SD card in, flip
>>> the switch and watch the UART output.
>>> (Edit, make, objcopy, move card to pi, and flip the power switch).
>>> The board provides plenty of power for the single core models through
>>> the host USB port. I should double check that it's providing enough
>>> power for the Pi2 before I spend too much time!
>>>
>>> Here is an example of my latest output where the SMP initialization is
>>> not completing:
>>> RTEMS RPi 2B 1.1 (1GB) [00a21041]
>>> in _SMP_Handler_initialize
>>> in _SMP_Handler_initialize, max processors = 4
>>> in _SMP_Handler_initialize - calling _CPU_SMP_Initialize
>>> in _CPU_SMP_Initialize
>>> in _SMP_Handler_initialize - _SMP_Processor_maximum = 4
>>> in _SMP_Handler_initialize - calling _SMP_Start_processors
>>> In _SMP_Start_processors
>>> In _SMP_Start_processors - index = 0
>>> In _SMP_Start_processors - index = 1
>>> In _SMP_Start_processors - calling _CPU_SMP_Start_processor
>>> in _CPU_SMP_Start_processor
>>> in _CPU_SMP_Start_processor - wait for secondary processor to complete
>>> in Per_CPU_State_wait_for_non_initial_state
>>>  CPU state = 0
>>> in Per_CPU_State_wait_for_non_initial_state - about to call
>>> _CPU_SMP_Processor_event_receive in while loop
>>> in Per_CPU_State_wait_for_non_initial_state - after
>>> _CPU_SMP_Processor_event_receive in while loop
>>>  CPU state  after = 0
>>> in Per_CPU_State_wait_for_non_initial_state - about to call
>>> _CPU_SMP_Processor_event_receive in while loop
>>>
>>>
>>> Alan
>>>
>>> On Mon, Jan 20, 2020 at 9:03 PM Niteesh  wrote:

 What is your debugging setup? It would be really helpful for my future 
 works on Rpi3.

 Thanks,
 Niteesh

 On Tue, 21 Jan, 2020, 7:23 AM Alan Cudmore,  wrote:
>
> A little more information on my Raspberry Pi 2 SMP tests:
>
> The BSP startup is getting to this loop:
> https://git.rtems.org/rtems/tree/cpukit/score/src/percpustatewait.c#n49
> (In the function _Per_CPU_State_wait_for_non_initial_state)
> In the while loop on line 49, the CPU state is PER_CPU_STATE_INITIAL (0).
> The while loop calls _CPU_SMP_Processor_event_receive() and returns,
> but the state is still 0
> It calls _CPU_SMP_Processor_event_receive() again and does not return.
>
> I'm reading up on the defines in percpu.h (comments for the defines
> are very helpful by the way)
> Based on what I can tell in the comments, the boot CPU will wait in
> PER_CPU_STATE_INITIAL
> until the secondary processors complete their primary initialization
> and transition to
> PER_CPU_STATE_READY_TO_START_MULTITASKING.
>
> Next is to figure out why the secondary processors are not
> transitioning or possibly why events are not occurring?
>
> Alan
>
> On Mon, Jan 20, 2020 at 6:25 PM Chris Johns  wrote:
>>
>> On 21/1/20 10:20 am, Alan Cudmore wrote:
>>> As it turns out the latest RTEMS master may need some of the dtb
>>> and/or overlay files in the raspberry pi SD card. But the updated
>>> instructions that Niteesh submitted for the raspberrypi BSP should
>>> still be valid.
>>
>> Great.
>>
>>> Either way, we should be able to automate it. A firmware release on
>>> Github is ~180 megabytes. If you clone the whole repository, it's 10+
>>> Gigabytes, probably because you get every binary release.
>>
>> Ouch. If we list the needed files, even if there is a few, I can fetch 
>> them from
>> github and avoid a full clone. We would need to settle on a specific 
>> hash or
>> version but that is not a bad thing.
>>
>>> I'm trying to troubleshoot the RPi 2 SMP a little bit now. Non SMP
>>> code seems to work on the Pi 2, but when you have an example with
>>> #define CONFIGURE_MAXIMUM_PROCESSORS 4
>>> it crashes during initialization.
>>
>> Awesome and all the best. I am sure you will figure it out.
>>
>> Chris
>>>
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinf

Re: How does the dynamic loader (libdl) hook in to gdb?

2020-01-21 Thread dufault 



> On Jan 20, 2020, at 17:37 , Chris Johns  wrote:
> 
> Hi Peter,
> 
> Happy new year.
> 
> On 17/1/20 9:01 am, Peter Dufault wrote:
>> I'm trying to hook the SLAC / Til Straumann PowerPC remote debugger stub in 
>> to what's loaded by "libdl" via "dlopen()".  *I know* this should be 
>> integrated into "libdebugger", and I do keep my eye on that, but I need to 
>> keep what is working working and working well.
>> 
>> The "libdl" code has support for GDB both finding out when shared libraries 
>> are loaded and resolving the new symbols in "rtl-debugger.c".  It's based on 
>> NetBSD and Android.  I don't know how to get this code to kick in.
> 
> You need a patch for GDB that enables the needed functionality in an RTEMS 
> build
> of GDB. Have a look at the 2013 GSoC project's work ...
> 
> https://lists.rtems.org/pipermail/devel/2013-September/004644.html
> 
> The patch was never merged into gdb and as GDB has changed to C++ I doubt it
> will apply cleanly so it needs to be reworked and submitted.

I am trying to avoid changing GDB.  I think I have, but I need a little more 
time to verify it and add the last few hooks.  I don't have access to my 
work-in-progress when at HDA (it will be available for merge) but roughly:
- I've modified the SLAC debugger stub to support 
"qXfer:libraries:read:annex:offset,length" in order to read back what SVR4 
style libraries are loaded.  This expects an exact ordered list of certain 
sections (without names) returned in XML.
- I've modified "libdl" to generate a report of the sections that GDB expects 
to receive in response the that query.  It's almost what is present to support 
the special RTEMS target stub, but you've collapsed the number of sections 
reported.  The stub needs to report sections such as (something like) 
".rdonly-rela" in addition to ".rdonly" (sorry, not looking at the code).  This 
was straight-forward.
- After loading a library I can do "info sharedlibrary" in "gdb" and it will 
request the loaded libraries from the stub and then I can access the symbols.
- The final step will be to do sort of what GDB does for in-process 
run-time-linker support: Add a special GDB-stub-only breakpoint that GDB 
doesn't know about in the "_rtld_debug_state()" function that "libdl" calls 
whenever it loads or unloads a library.  The SLAC stub will then send an 
asynchronous stop message to GDB that the libraries have changed, and GDB will 
read back the info using the "qXfer:libraries" command.  Yes, I added GDB 
non-stop support to the SLAC remote debugger, and it works well.  I had to do 
that because the SLAC stub already supported a custom non-stop mode and I 
didn't want a regression.  All of this, once tested more, will be available or 
if someone really wants it I'll send it right now.

(...)

>  Also I am not sure what happens
> with the extra sections that have been added since this work was done, for
> example on the PowerPC the small data allocations. You would need to chase 
> down
> what happens here.

I think this will work unchanged with the approach I'm using.  However, the 
small data allocations for PowerPC definitely have a bug associated with how 
much space is allocated that ends up trashing the heap. This has nothing to do 
with reading back the symbols, it's a "libdl" bug that I plan to document.  I 
tried to characterize it (without a debugger working well after loading new 
items) but gave up and compiled the application with "-mno-sdata".  I plan to 
get back to that as time permits once GDB is working properly with the loaded 
libraries.  I think it does not allocate enough space for where it loads items, 
"malloc walk" will detect the corruption but I deferred debugging it for now.

A final point about debugging "libdl": the heap allocation lock in "libdl" 
makes it tough to debug using a network debugger since at least the old network 
stack uses the heap.  It took me a little while to figure that out.

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering

This email is delivered through the public internet using protocols subject to 
interception and tampering.

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

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

2020-01-21 Thread Christian Mauderer 
Hello Niteesh,

you had two different "v3" patches. Therefore I missed this one. I
thought there was still a review comment from Gedare pending (which he
added at the v2 patch but after the first v3 has been sent).

On 12/01/2020 19:47, G S Niteesh wrote:
> Added instructions to run examples on raspberrypi.
> ---
>  user/bsps/arm/raspberrypi.rst | 85 ++-
>  1 file changed, 84 insertions(+), 1 deletion(-)
> 
> diff --git a/user/bsps/arm/raspberrypi.rst b/user/bsps/arm/raspberrypi.rst
> index 4ef75bd..8e4b38c 100644
> --- a/user/bsps/arm/raspberrypi.rst
> +++ b/user/bsps/arm/raspberrypi.rst
> @@ -5,4 +5,87 @@
>  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 Raspberry Pi which is used to boot 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
> +`kernel=` to ``config.txt``.
> +
> +You must provide the required files for the GPU to proceed. These files
> +can be downloaded from
> +`the Raspberry Pi Firmware Repository 
> `_.
> +You can remove the ``kernel*.img`` files if you want too, but don't touch 
> the other files.

This line seems a bit long. Please break at 80 chars. The link above it
is OK to violate that rule because it would most likely not work with a
line break.

> +
> +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.
> +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 using QEMU
> +--
> +
> +QEMU can be built using RSB. Navigate to ``/rtems``
> +and run this command.
> +
> +.. code-block:: none
> +
> + ../source-builder/sb-set-builder --prefix= 
> devel/qemu4.bset
> +
> +**Note**: Replace  and  with the 
> correct
> +path of the directories. For example, if you used quick-start section as 
> your reference, these
> +two will be ``$HOME/quick-start/src/rsb`` and ``$HOME/quick-start/rtems/5`` 
> respectively,

Again: Please use a 80 char limit (except for the code block).

> +
> +QEMU along with GDB can be used for debugging, but it only supports
> +Raspberry Pi 2 and the emulation is also incomplete. So some of the
> +features might not work as expected.
> +
> +Make sure your version of QEMU > v2.6, because older ones don't support

"...of QEMU is newer than v2.6 ..."

For most readers it's much faster to read a text without cryptic
abbreviations.

> +Raspberry Pi's.

I have to be honest: I'm not sure here. As far as I know the apostroph
(') is a sign that you left something out. I'm not sure whether there
are cases in English where you use it other than that case. But I would
say that you didn't leave anything out in "Pi's" and therefore the
plural should be "Pis" even if it looks odd.

Some comment from a native speaker?

> +
> +.. 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 ``localhost: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 will load the application.
> +
> +**Note**: Add ``set scheduler-locking on`` in GDB if you have any issues
> +running the examples.
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] libchip/ns16550: Allow user calculate baud divisor

2020-01-21 Thread Christian Mauderer 
On 17/01/2020 15:50, G S Niteesh wrote:
> This patch will allow the user to pass a function to calculate
> the baud divisor.
> This is will allow for more flexibility, since for some BSP's
> like raspberrypi, the calculate of baud divisor is different
> from what is in the current driver.
> ---
>  bsps/include/libchip/ns16550.h   | 9 +++--
>  bsps/shared/dev/serial/ns16550-context.c | 2 ++
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/bsps/include/libchip/ns16550.h b/bsps/include/libchip/ns16550.h
> index f053c8767f9..a08c58b7b6e 100644
> --- a/bsps/include/libchip/ns16550.h
> +++ b/bsps/include/libchip/ns16550.h
> @@ -60,7 +60,11 @@ typedef uint8_t (*ns16550_get_reg)(uintptr_t port, uint8_t 
> reg);
>  
>  typedef void (*ns16550_set_reg)(uintptr_t port, uint8_t reg, uint8_t value);
>  
> -typedef struct {
> +typedef struct ns16550_context ns16550_context;
> +
> +typedef uint32_t (*ns16550_calculate_baud_divisor)(ns16550_context *ctx, 
> uint32_t baud);
> +
> +struct ns16550_context{
>rtems_termios_device_context base;
>ns16550_get_reg get_reg;
>ns16550_set_reg set_reg;
> @@ -70,6 +74,7 @@ typedef struct {
>uint32_t initial_baud;
>bool has_fractional_divider_register;
>bool has_precision_clock_synthesizer;
> +  ns16550_calculate_baud_divisor calculate_baud_divisor;

Can you add the field to the end of the structure? In C there are two
possibilities to initialize structures: With named fields and just by
order. If you add the field to the end you have backwards compatibility
for both variants.

>uint8_t modem_control;
>uint8_t line_control;
>uint32_t baud_divisor;
> @@ -78,7 +83,7 @@ typedef struct {
>size_t out_current;
>const char *out_buf;
>rtems_termios_tty *tty;
> -} ns16550_context;
> +};
>  
>  extern const rtems_termios_device_handler ns16550_handler_interrupt;
>  extern const rtems_termios_device_handler ns16550_handler_polled;
> diff --git a/bsps/shared/dev/serial/ns16550-context.c 
> b/bsps/shared/dev/serial/ns16550-context.c
> index ce55b8309cc..dbf6c64af4a 100644
> --- a/bsps/shared/dev/serial/ns16550-context.c
> +++ b/bsps/shared/dev/serial/ns16550-context.c
> @@ -112,6 +112,8 @@ static uint32_t NS16550_GetBaudDivisor(ns16550_context 
> *ctx, uint32_t baud)
>NS16550_FRACTIONAL_DIVIDER,
>fractionalDivider
>  );
> +  } else if (ctx->calculate_baud_divisor != NULL) {
> +baudDivisor = ctx->calculate_baud_divisor(ctx, baud);
>}
>  
>return baudDivisor;
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] bsp/raspberrypi: Mini UART driver

2020-01-21 Thread Christian Mauderer 
>From a first look this seems to be OK. But I didn't test it yet on
hardware. I'll try to do that in the next days.

On 17/01/2020 15:50, G S Niteesh wrote:
> This patch adds driver for Mini UART present in Raspberry Pi 3
> and above, this UART is currently used as the primary UART in
> these models.
> The Mini UART is similar to ns16550, this driver is built
> upon libchip/ns16550.
> ---
>  bsps/arm/raspberrypi/console/console-config.c | 117 --
>  bsps/arm/raspberrypi/include/bsp/usart.h  |   1 +
>  2 files changed, 109 insertions(+), 9 deletions(-)
> 
> diff --git a/bsps/arm/raspberrypi/console/console-config.c 
> b/bsps/arm/raspberrypi/console/console-config.c
> index 48c4c6a3ec7..720033cb295 100644
> --- a/bsps/arm/raspberrypi/console/console-config.c
> +++ b/bsps/arm/raspberrypi/console/console-config.c
> @@ -24,6 +24,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -34,35 +35,103 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
> -
> -#define UART0 "/dev/ttyS0"
> +/**
> + * UART0 - PL011
> + * UART1 - Mini UART
> + */
> +#define PL011 "/dev/ttyAMA0"
> +#define MINIUART  "/dev/ttyS0"
>  #define FBCONS"/dev/fbcons"
>  
>  arm_pl011_context pl011_context;
> +ns16550_context mini_uart_context;
>  
>  rpi_fb_context fb_context;
>  
> -static void output_char_serial(char c)
> +static void output_char_pl011(char c)
>  {
>arm_pl011_write_polled(&pl011_context.base, c);
>  }
>  
> +static void output_char_mini_uart(char c)
> +{
> +  ns16550_polled_putchar(&mini_uart_context.base, c);
> +}
> +
>  void output_char_fb(char c)
>  {
>fbcons_write_polled(&fb_context.base, c);
>  }
>  
> +static uint8_t mini_uart_get_reg(uintptr_t port, uint8_t index)
> +{
> +  volatile uint32_t *val = (volatile uint32_t *)port + index;
> +  return (uint8_t) *val;
> +}
> +
> +static void mini_uart_set_reg(uintptr_t port, uint8_t index, uint8_t val)
> +{
> +  volatile uint32_t *reg = (volatile uint32_t *)port + index;
> +  *reg = val;
> +}
> +
>  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");
> +  rtems_termios_device_context_initialize(&ctx->base, "PL011UART");
>ctx->regs = raspberrypi_get_reg_of_node(fdt, node);
>  }
>  
> +static uint32_t calculate_baud_divisor(
> +  ns16550_context *ctx,
> +  uint32_t baud
> +)
> +{
> +  uint32_t baudDivisor = (ctx->clock / (8 * baud)) - 1;
> +  return baudDivisor;
> +}
> +
> +static void init_ctx_mini_uart(
> +  const void *fdt,
> +  int node
> +)
> +{
> +  const char *status;
> +  int len;
> +  ns16550_context *ctx;
> +
> +  memset(&mini_uart_context, 0, sizeof(mini_uart_context));
> +  ctx = &mini_uart_context;
> +
> +  rtems_termios_device_context_initialize(&ctx->base, "MiniUART");
> +
> +  status = fdt_getprop(fdt, node, "status", &len);
> +  if ( status == NULL || strcmp(status, "disabled" ) == 0){
> +return ;
> +  }
> +
> +  ctx->port = (uintptr_t) raspberrypi_get_reg_of_node(fdt, node);
> +  ctx->initial_baud = MINI_UART_DEFAULT_BAUD;
> +  ctx->clock = BCM2835_CLOCK_FREQ;
> +  ctx->calculate_baud_divisor = calculate_baud_divisor;
> +  ctx->get_reg = mini_uart_get_reg;
> +  ctx->set_reg = mini_uart_set_reg;
> +
> +  rtems_gpio_bsp_select_specific_io(0, 14, RPI_ALT_FUNC_5, NULL);
> +  rtems_gpio_bsp_select_specific_io(0, 15, RPI_ALT_FUNC_5, NULL);
> +  rtems_gpio_bsp_set_resistor_mode(0, 14, NO_PULL_RESISTOR);
> +  rtems_gpio_bsp_set_resistor_mode(0, 15, NO_PULL_RESISTOR);
> +
> +  BCM2835_REG(AUX_ENABLES) |= 0x1;
> +  ns16550_probe(&ctx->base);
> +}
> +
>  static void register_fb( void )
>  {
>if (fbcons_probe(&fb_context.base) == true) {
> @@ -87,16 +156,27 @@ static void console_select( void )
>  link(FBCONS, CONSOLE_DEVICE_NAME);
>  return ;
>}
> +} else if ( strncmp( opt, MINIUART, sizeof(MINIUART) - 1 ) == 0) {
> +  BSP_output_char = output_char_mini_uart;
> +  link(MINIUART, CONSOLE_DEVICE_NAME);
> +} else if ( strncmp( opt, PL011, sizeof(PL011) - 1 ) == 0) {
> +  BSP_output_char = output_char_pl011;
> +  link(PL011, CONSOLE_DEVICE_NAME);
>  }
>}
> -  BSP_output_char = output_char_serial;
> -  link(UART0, CONSOLE_DEVICE_NAME);
> +  /**
> +   * If no command line option was given, default to PL011.
> +   */
> +  BSP_output_char = output_char_pl011;
> +  link(PL011, CONSOLE_DEVICE_NAME);
>  }
>  
>  static void uart_probe(void)
>  {
>static bool initialized = false;
>const void *fdt;
> +  const char *console;
> +  int len;
>int node;
>  
>if ( initialized ) {
> @@ -104,17 +184,29 @@ static void uart_probe(void)
>}
>  
>fdt = bsp_fdt_get();
> -  node = fdt_node_offset_by_compatible(fdt, -1, "brcm,bcm2835-pl011");
>  
> +  node = fdt_node_offset_by_compatible(fdt, -1, "brcm,bcm2835-pl011");
>init_ctx_arm_pl011(fdt, node);
>  
> +  node = fdt_node_offset_by_

Re: Raspberry Pi test report

2020-01-21 Thread Niteesh 
On Wed, Jan 22, 2020 at 2:18 AM Christian Mauderer 
wrote:

> I think the not yet merged patch from Niteesh is a good reference:
>
> https://lists.rtems.org/pipermail/devel/2020-January/056860.htm
> l


The above instructions are not valid anymore, you have to provide a DTB
file.
You need to execute two more commands before running the executable
1)  restore dtb_file_name.dtb binary 0x2ef0
2) set $r2 = 0x2ef0

>
>
On 21/01/2020 21:31, Alan Cudmore wrote:
> > I can try QEMU. Is there a quick pointer to the QEMU parameters needed
> > to run a Pi2 image?
> > Alan
> >
> > On Tue, Jan 21, 2020 at 3:22 PM Christian Mauderer 
> wrote:
> >>
> >> Does the same error occur on the Pi2 Qemu? In that case you could use it
> >> for proper debugging.
> >>
> >> On 21/01/2020 03:35, Alan Cudmore wrote:
> >>> I don't really have a debug setup.. I'm just using printk for now. But
> >>> I have a pretty efficient setup where I can add a few printk
> >>> statements, rebuild and copy the smp01.exe sample over to the SD card.
> >>> I use this board:
> >>> https://www.adafruit.com/product/3589
> >>> It lets me connect the serial port using a USB cable, and it also
> >>> supplies power and provides a switch. I can pop the SD card in, flip
> >>> the switch and watch the UART output.
> >>> (Edit, make, objcopy, move card to pi, and flip the power switch).
> >>> The board provides plenty of power for the single core models through
> >>> the host USB port. I should double check that it's providing enough
> >>> power for the Pi2 before I spend too much time!
> >>>
> >>> Here is an example of my latest output where the SMP initialization is
> >>> not completing:
> >>> RTEMS RPi 2B 1.1 (1GB) [00a21041]
> >>> in _SMP_Handler_initialize
> >>> in _SMP_Handler_initialize, max processors = 4
> >>> in _SMP_Handler_initialize - calling _CPU_SMP_Initialize
> >>> in _CPU_SMP_Initialize
> >>> in _SMP_Handler_initialize - _SMP_Processor_maximum = 4
> >>> in _SMP_Handler_initialize - calling _SMP_Start_processors
> >>> In _SMP_Start_processors
> >>> In _SMP_Start_processors - index = 0
> >>> In _SMP_Start_processors - index = 1
> >>> In _SMP_Start_processors - calling _CPU_SMP_Start_processor
> >>> in _CPU_SMP_Start_processor
> >>> in _CPU_SMP_Start_processor - wait for secondary processor to complete
> >>> in Per_CPU_State_wait_for_non_initial_state
> >>>  CPU state = 0
> >>> in Per_CPU_State_wait_for_non_initial_state - about to call
> >>> _CPU_SMP_Processor_event_receive in while loop
> >>> in Per_CPU_State_wait_for_non_initial_state - after
> >>> _CPU_SMP_Processor_event_receive in while loop
> >>>  CPU state  after = 0
> >>> in Per_CPU_State_wait_for_non_initial_state - about to call
> >>> _CPU_SMP_Processor_event_receive in while loop
> >>>
> >>>
> >>> Alan
> >>>
> >>> On Mon, Jan 20, 2020 at 9:03 PM Niteesh  wrote:
> 
>  What is your debugging setup? It would be really helpful for my
> future works on Rpi3.
> 
>  Thanks,
>  Niteesh
> 
>  On Tue, 21 Jan, 2020, 7:23 AM Alan Cudmore, 
> wrote:
> >
> > A little more information on my Raspberry Pi 2 SMP tests:
> >
> > The BSP startup is getting to this loop:
> >
> https://git.rtems.org/rtems/tree/cpukit/score/src/percpustatewait.c#n49
> > (In the function _Per_CPU_State_wait_for_non_initial_state)
> > In the while loop on line 49, the CPU state is PER_CPU_STATE_INITIAL
> (0).
> > The while loop calls _CPU_SMP_Processor_event_receive() and returns,
> > but the state is still 0
> > It calls _CPU_SMP_Processor_event_receive() again and does not
> return.
> >
> > I'm reading up on the defines in percpu.h (comments for the defines
> > are very helpful by the way)
> > Based on what I can tell in the comments, the boot CPU will wait in
> > PER_CPU_STATE_INITIAL
> > until the secondary processors complete their primary initialization
> > and transition to
> > PER_CPU_STATE_READY_TO_START_MULTITASKING.
> >
> > Next is to figure out why the secondary processors are not
> > transitioning or possibly why events are not occurring?
> >
> > Alan
> >
> > On Mon, Jan 20, 2020 at 6:25 PM Chris Johns 
> wrote:
> >>
> >> On 21/1/20 10:20 am, Alan Cudmore wrote:
> >>> As it turns out the latest RTEMS master may need some of the dtb
> >>> and/or overlay files in the raspberry pi SD card. But the updated
> >>> instructions that Niteesh submitted for the raspberrypi BSP should
> >>> still be valid.
> >>
> >> Great.
> >>
> >>> Either way, we should be able to automate it. A firmware release on
> >>> Github is ~180 megabytes. If you clone the whole repository, it's
> 10+
> >>> Gigabytes, probably because you get every binary release.
> >>
> >> Ouch. If we list the needed files, even if there is a few, I can
> fetch them from
> >> github and avoid a full clone. We wou

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

2020-01-21 Thread Niteesh 
On Wed, Jan 22, 2020 at 2:30 AM Christian Mauderer 
wrote:

> Hello Niteesh,
>
> you had two different "v3" patches. Therefore I missed this one. I
> thought there was still a review comment from Gedare pending (which he
> added at the v2 patch but after the first v3 has been sent).


I have added instruction about installing QEMU from RSB as he said.



On 12/01/2020 19:47, G S Niteesh wrote:
> > Added instructions to run examples on raspberrypi.
> > ---
> >  user/bsps/arm/raspberrypi.rst | 85 ++-
> >  1 file changed, 84 insertions(+), 1 deletion(-)
> >
> > diff --git a/user/bsps/arm/raspberrypi.rst
> b/user/bsps/arm/raspberrypi.rst
> > index 4ef75bd..8e4b38c 100644
> > --- a/user/bsps/arm/raspberrypi.rst
> > +++ b/user/bsps/arm/raspberrypi.rst
> > @@ -5,4 +5,87 @@
> >  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 Raspberry Pi which is used to boot
> 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
> > +`kernel=` to ``config.txt``.
> > +
> > +You must provide the required files for the GPU to proceed. These files
> > +can be downloaded from
> > +`the Raspberry Pi Firmware Repository <
> https://github.com/raspberrypi/firmware/tree/master/boot>`_.
> > +You can remove the ``kernel*.img`` files if you want too, but don't
> touch the other files.
>
> This line seems a bit long. Please break at 80 chars. The link above it
> is OK to violate that rule because it would most likely not work with a
> line break.
>
> > +
> > +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.
> > +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 using QEMU
> > +--
> > +
> > +QEMU can be built using RSB. Navigate to ``/rtems``
> > +and run this command.
> > +
> > +.. code-block:: none
> > +
> > + ../source-builder/sb-set-builder --prefix=
> devel/qemu4.bset
> > +
> > +**Note**: Replace  and  with
> the correct
> > +path of the directories. For example, if you used quick-start section
> as your reference, these
> > +two will be ``$HOME/quick-start/src/rsb`` and
> ``$HOME/quick-start/rtems/5`` respectively,
>
> Again: Please use a 80 char limit (except for the code block).
>
> > +
> > +QEMU along with GDB can be used for debugging, but it only supports
> > +Raspberry Pi 2 and the emulation is also incomplete. So some of the
> > +features might not work as expected.
> > +
> > +Make sure your version of QEMU > v2.6, because older ones don't support
>
> "...of QEMU is newer than v2.6 ..."
>
> For most readers it's much faster to read a text without cryptic
> abbreviations.
>
> > +Raspberry Pi's.
>
> I have to be honest: I'm not sure here. As far as I know the apostroph
> (') is a sign that you left something out. I'm not sure whether there
> are cases in English where you use it other than that case. But I would
> say that you didn't leave anything out in "Pi's" and therefore the
> plural should be "Pis" even if it looks odd.

Some comment from a native speaker?
>

And we also have to add instructions for including the DTB file. I'll make
the
changes you mentioned and also add instructions for including DTB.
I'll send in the patch, once we get a confirmation from a native speaker,
anyhow
I googled, and I think it should be Pis. The *'s *symbolizes
possessiveness.

>
> > +
> > +.. 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 ``localhost: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 will load the application.
> > +
> > +**Note**: Add ``set scheduler-locking on`` in GDB if you have any issues
> > +running the examples.

Re: Requirement Document generator tool

2020-01-21 Thread Chris Johns 
On 21/1/20 8:10 pm, Christian Mauderer wrote:
> On 20/01/2020 22:37, Chris Johns wrote:
>> On 14/1/20 7:18 pm, Christian Mauderer wrote:
>>> On 13/01/2020 18:03, Joel Sherrill wrote:
 On Mon, Jan 13, 2020 at 10:04 AM Christian Mauderer
 >>> > wrote:

 Hello Jose,

 On 10/01/2020 17:33, Jose Valdez wrote:
 > Hello,
 >
 > Regarding this topic and to start to define the python tools that
 are more appropriate for the RTEMS community python developments, I
 would like to propose the following tools (to be placed in RTEMS
 Software Engineering manual):
 >
 > Python language version: 3.6 (minimum version for Doorstop 2.0.post2)
 > Python coding style/standard - Google (as suggested by Gedare)
 > Python documentation style - Google docstrings (to be in
 accordance with coding style. Note it is supported by sphinx)
 > Python test approach - unittest (seems to be the standard used by
 python)
 > Python static analysis - pylint (recommended by Google style, see
 http://google.github.io/styleguide/pyguide.html) and mypy (catch
 additional errors) Python code coverage - Coverage.py (seems to be
 the standard used by python)
 > Python third party packages - For now we are using: paramiko,
 pyserial, pexpect, gitpython, but the list is expected to be
 changed. I think here any third package is allowed, as long as the
 license of the package complies with RTEMS project license.

 To be future-proof: python3 compatibility would be nearly a must-have
 for any new library.


 We discussed this somewhere earlier and I thought we decided that if
 it was a core tool required for a "normal user", then it would have to
 be Python 2.x and 3.x compatible. Tools for "requirements user" or
 "pre-qualification user" (pick a name for this role), can be 3.x only 
 mainly because there was so much infrastructure required for the
 "requirements user" that already needed Python 3.x.
>>
>> Yes this is correct. Python is used in the rtems-tools repo and any program 
>> in
>> the rtems-tools repo needs to support Python 2 and Python 3 no matter what 
>> role
>> it performs. The rtems-tools repo is not the same as doorstop or similar 
>> tools
>> used to develop RTEMS, they are user tools used to develop application to 
>> run on
>> RTEMS.
> 
> Does that mean you don't want to have any pre-qualification tools in the
> rtems-tools repo?

This is not what I am saying. All I am doing is listing what is currently needed
when a tool is added to rtems-tools. If a pre-qual tool meets the requirements
for inclusion in the tools repo then it can be added.

> If yes: Where else?

I do not know. I am not sure what these tools are to do, what interfaces they
provide to their users, their complexity and who are the maintainers. Until
these questions are answered I cannot say.

> I fully agree that every tool that is thought for every day use for 99%
> of the RTEMS users should have Python 2 and 3 support. With no official
> Python 2 support since this year I don't think that this would be a good
> requirement for new specialized areas like pre-qualification. I think
> you agree there?

I believe Joel has looked at Python 3 on long life operating systems like CentOS
and it can be installed and made to work. I am sure there will be cases we have
missed and this assumption may not hold.

My experience with Python 2 and 3 is most things we would use can be handled by
future imports. With a little care programs can be portable. Doorstop has not
been written this way so we have said Python 3 is required when developing
RTEMS. It was never made a requirement for users.

> On the other hand I wouldn't know a better place then rtems-tools for
> everything produced through the pre-qualification effort. So I'm not a
> fan of saying: Everything in rtems-tools should be Python 2 + 3.

Let me put you in the position of the rtems-tools maintainer and Python 3 is
mandated plus a number of new pre-qual tools with a variable number of packages
are added.

How would you manage these new dependencies the RSB would encounter?

How would you manage the errors at runtime the python programs throw if a
dependent package is not install?

How would you manage the deployment of tools as binary packages by those users
who want to do this? We have users doing this now.

Is the increase in on-boarding complexity for new RTEMS users warranted for a
very small and highly skill section of the user community?

The current rtems-tools model combined with the RSB currently handle these
things. That is, the dependencies for the RSB are simple, small and known. The
RTEMS tools once built can be copied to a new machine (the tar packaging options
in the RSB have been present from the start).

The exper

[PATCH v2 1/2] libchip/ns16550: Allow user calculate baud divisor

2020-01-21 Thread G S Niteesh 
This patch will allow the user to pass a function to calculate
the baud divisor.
This will allow for more flexibility, since for some BSPs
like raspberrypi, the calculation of baud divisor is different
from what is in the current driver.
---
 bsps/include/libchip/ns16550.h   | 9 +++--
 bsps/shared/dev/serial/ns16550-context.c | 2 ++
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/bsps/include/libchip/ns16550.h b/bsps/include/libchip/ns16550.h
index f053c8767f9..b45331a4039 100644
--- a/bsps/include/libchip/ns16550.h
+++ b/bsps/include/libchip/ns16550.h
@@ -60,7 +60,11 @@ typedef uint8_t (*ns16550_get_reg)(uintptr_t port, uint8_t 
reg);
 
 typedef void (*ns16550_set_reg)(uintptr_t port, uint8_t reg, uint8_t value);
 
-typedef struct {
+typedef struct ns16550_context ns16550_context;
+
+typedef uint32_t (*ns16550_calculate_baud_divisor)(ns16550_context *ctx, 
uint32_t baud);
+
+struct ns16550_context{
   rtems_termios_device_context base;
   ns16550_get_reg get_reg;
   ns16550_set_reg set_reg;
@@ -78,7 +82,8 @@ typedef struct {
   size_t out_current;
   const char *out_buf;
   rtems_termios_tty *tty;
-} ns16550_context;
+  ns16550_calculate_baud_divisor calculate_baud_divisor;
+};
 
 extern const rtems_termios_device_handler ns16550_handler_interrupt;
 extern const rtems_termios_device_handler ns16550_handler_polled;
diff --git a/bsps/shared/dev/serial/ns16550-context.c 
b/bsps/shared/dev/serial/ns16550-context.c
index ce55b8309cc..dbf6c64af4a 100644
--- a/bsps/shared/dev/serial/ns16550-context.c
+++ b/bsps/shared/dev/serial/ns16550-context.c
@@ -112,6 +112,8 @@ static uint32_t NS16550_GetBaudDivisor(ns16550_context 
*ctx, uint32_t baud)
   NS16550_FRACTIONAL_DIVIDER,
   fractionalDivider
 );
+  } else if (ctx->calculate_baud_divisor != NULL) {
+baudDivisor = ctx->calculate_baud_divisor(ctx, baud);
   }
 
   return baudDivisor;
-- 
2.17.1

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

[PATCH v2 2/2] bsp/raspberrypi: Mini UART driver

2020-01-21 Thread G S Niteesh 
This patch adds driver for Mini UART present in Raspberry Pi 3
and above, this UART is currently used as the primary UART in
these models.
The Mini UART is similar to ns16550, this driver is built
upon libchip/ns16550.
---
 bsps/arm/raspberrypi/console/console-config.c | 117 --
 bsps/arm/raspberrypi/include/bsp/usart.h  |   1 +
 2 files changed, 109 insertions(+), 9 deletions(-)

diff --git a/bsps/arm/raspberrypi/console/console-config.c 
b/bsps/arm/raspberrypi/console/console-config.c
index 48c4c6a3ec7..720033cb295 100644
--- a/bsps/arm/raspberrypi/console/console-config.c
+++ b/bsps/arm/raspberrypi/console/console-config.c
@@ -24,6 +24,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -34,35 +35,103 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
-
-#define UART0 "/dev/ttyS0"
+/**
+ * UART0 - PL011
+ * UART1 - Mini UART
+ */
+#define PL011 "/dev/ttyAMA0"
+#define MINIUART  "/dev/ttyS0"
 #define FBCONS"/dev/fbcons"
 
 arm_pl011_context pl011_context;
+ns16550_context mini_uart_context;
 
 rpi_fb_context fb_context;
 
-static void output_char_serial(char c)
+static void output_char_pl011(char c)
 {
   arm_pl011_write_polled(&pl011_context.base, c);
 }
 
+static void output_char_mini_uart(char c)
+{
+  ns16550_polled_putchar(&mini_uart_context.base, c);
+}
+
 void output_char_fb(char c)
 {
   fbcons_write_polled(&fb_context.base, c);
 }
 
+static uint8_t mini_uart_get_reg(uintptr_t port, uint8_t index)
+{
+  volatile uint32_t *val = (volatile uint32_t *)port + index;
+  return (uint8_t) *val;
+}
+
+static void mini_uart_set_reg(uintptr_t port, uint8_t index, uint8_t val)
+{
+  volatile uint32_t *reg = (volatile uint32_t *)port + index;
+  *reg = val;
+}
+
 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");
+  rtems_termios_device_context_initialize(&ctx->base, "PL011UART");
   ctx->regs = raspberrypi_get_reg_of_node(fdt, node);
 }
 
+static uint32_t calculate_baud_divisor(
+  ns16550_context *ctx,
+  uint32_t baud
+)
+{
+  uint32_t baudDivisor = (ctx->clock / (8 * baud)) - 1;
+  return baudDivisor;
+}
+
+static void init_ctx_mini_uart(
+  const void *fdt,
+  int node
+)
+{
+  const char *status;
+  int len;
+  ns16550_context *ctx;
+
+  memset(&mini_uart_context, 0, sizeof(mini_uart_context));
+  ctx = &mini_uart_context;
+
+  rtems_termios_device_context_initialize(&ctx->base, "MiniUART");
+
+  status = fdt_getprop(fdt, node, "status", &len);
+  if ( status == NULL || strcmp(status, "disabled" ) == 0){
+return ;
+  }
+
+  ctx->port = (uintptr_t) raspberrypi_get_reg_of_node(fdt, node);
+  ctx->initial_baud = MINI_UART_DEFAULT_BAUD;
+  ctx->clock = BCM2835_CLOCK_FREQ;
+  ctx->calculate_baud_divisor = calculate_baud_divisor;
+  ctx->get_reg = mini_uart_get_reg;
+  ctx->set_reg = mini_uart_set_reg;
+
+  rtems_gpio_bsp_select_specific_io(0, 14, RPI_ALT_FUNC_5, NULL);
+  rtems_gpio_bsp_select_specific_io(0, 15, RPI_ALT_FUNC_5, NULL);
+  rtems_gpio_bsp_set_resistor_mode(0, 14, NO_PULL_RESISTOR);
+  rtems_gpio_bsp_set_resistor_mode(0, 15, NO_PULL_RESISTOR);
+
+  BCM2835_REG(AUX_ENABLES) |= 0x1;
+  ns16550_probe(&ctx->base);
+}
+
 static void register_fb( void )
 {
   if (fbcons_probe(&fb_context.base) == true) {
@@ -87,16 +156,27 @@ static void console_select( void )
 link(FBCONS, CONSOLE_DEVICE_NAME);
 return ;
   }
+} else if ( strncmp( opt, MINIUART, sizeof(MINIUART) - 1 ) == 0) {
+  BSP_output_char = output_char_mini_uart;
+  link(MINIUART, CONSOLE_DEVICE_NAME);
+} else if ( strncmp( opt, PL011, sizeof(PL011) - 1 ) == 0) {
+  BSP_output_char = output_char_pl011;
+  link(PL011, CONSOLE_DEVICE_NAME);
 }
   }
-  BSP_output_char = output_char_serial;
-  link(UART0, CONSOLE_DEVICE_NAME);
+  /**
+   * If no command line option was given, default to PL011.
+   */
+  BSP_output_char = output_char_pl011;
+  link(PL011, CONSOLE_DEVICE_NAME);
 }
 
 static void uart_probe(void)
 {
   static bool initialized = false;
   const void *fdt;
+  const char *console;
+  int len;
   int node;
 
   if ( initialized ) {
@@ -104,17 +184,29 @@ static void uart_probe(void)
   }
 
   fdt = bsp_fdt_get();
-  node = fdt_node_offset_by_compatible(fdt, -1, "brcm,bcm2835-pl011");
 
+  node = fdt_node_offset_by_compatible(fdt, -1, "brcm,bcm2835-pl011");
   init_ctx_arm_pl011(fdt, node);
 
+  node = fdt_node_offset_by_compatible(fdt, -1, "brcm,bcm2835-aux-uart");
+  init_ctx_mini_uart(fdt, node);
+
+  node = fdt_path_offset(fdt, "/aliases");
+  console = fdt_getprop(fdt, node, "serial0", &len);
+
+  if ( strcmp(console, "/soc/serial@7e215040" ) == 0) {
+BSP_output_char = output_char_mini_uart;
+  }else {
+BSP_output_char = output_char_pl011;
+  }
+
   initialized = true;
 }
 
 static void output_char(char c)
 {
   uart_probe();
-  output_char_serial(c);
+  (*BSP_output_char)(c);
 }
 
 rtems_status_co