Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

[Pavel Pisa]

n. So it would
lead to much more acrobation between eggs and some gap time,
where none message is offered in the link arbitration even that
there are pending user requests will be inevitable in some
scenarios after some number of messages sent. That cannot
be on the bus side worse that considering fixed order according
to index. May be, it can be found that overhead does not worth
that. But we preserve API in variants in all cases...

2) use of the CAN bus in applications requiring maximal bus
transparency with minimal latency and SW load. This is
totally opposite of the general CAN bus subsystem for
general purpose RTOS. The API in this case should allocated
Tx and Rx controller objects for the individual purposes/CAN IDs.
Rx side SW processing can be considered as alternative and proposed
framework allows to setup queues, but it has overhead and under
extreme load it can lost some messages if HW is not performant enough.
On Tx side it is even more problematic.

But if this type of use of RTEMS for example for Autosar or Simulink
generated code is considered then it is possible to extend actual
proposed API by IOCTLs which allows to reserve some controller
objects for specific purposes and allows to access them directly
for minimal overhead and use under direct application control or attach
separated controller side "canque_ends_dev_t" to such objects and
propagate them to some clients to standard CAN read and write API.

So I think that the proposed framework provides what is expected
bu most of general purpose CAN/CAN FD framework users, tries to
perpare a little even for come of CAN XL, solves problems which
may be practically unsolved by all other generic approaches still.
And we have some clue how to extend support for most/all other
controllers and even some open doors to offer even ECU style
API for applications which benefit from direct controller
buffers use/allocation which is possible on controllers
with abundant number of buffers (not case of SJA1000
and very limited on CTU CAN FD - max 8 can be configured
to silicon under actual registers map).  

I understand that the text is long but you have asked for
it in the fact and I provide complete thought dump
to analyes it.

I would be happy if you and or others find time to look
into actual code implementation to identify what could
be issue for mainlining as soon as possible because
after May 24 changes do not propagate into Michal Lenc's
thesis text which can be alternative and more in depth
documentation and analysis than what fits into official
RTEMS one. The full document has already 47 pages and
34 of the actual text without content and appendices.
Document includes benchmarks under RTEMS load by HTTP
traffic, priority inversion prevention confirmation
by measurements with performance data etc.
It will be published on CTU in May or June
  https://dspace.cvut.cz/
and links will be added to
  https://canbus.pages.fel.cvut.cz/
same as for much shorter iCC article and presentation.

Best wishes,

Pavel
--
Pavel Pisa

phone:      +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
personal:   http://cmp.felk.cvut.cz/~pisa
company:https://pikron.com/ PiKRON s.r.o.
Kankovskeho 1235, 182 00 Praha 8, Czech Republic
projects:   https://www.openhub.net/accounts/ppisa
social: https://social.kernel.org/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
RISC-V education: https://comparch.edu.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

[Pavel Pisa]

ode on some
experimental automotive ECU autotuning system. iMX6 with FlexCAN
is used in Elektroline.cz, where I provide some consultations.

I have been architect of rapid prototyping platforms developed
for Porsche Enginering Services based on TMS570LS3137 and we have
implemented there TTCAN like synchronous messages exchange there
with no timing and communication schedule execution dependency on CPU.
The actual proposed CAN subsystem proposal is not optimized
for such use, but is is very special and needs intercation
of application with lower levels or provide API to setup schedule
and update send data. I can think how to pas that by set of additional
IOCTLs. But RTEMS need some common CAN/CAN FD stack with
common functionality found on other systems.

So all in all I hope I have some idea what could appear in
CAN controllers ZOO... But yes, we can overlook something
and that is why I keep Oliver Hartkopp (SocketCAN architect)
in the loop to be opponent to our decision if he thinks that
our choices could lead to problems. Even decision/compromise
if SocketCAN (and LibBSD) dependency or simpler approach should
be our direction on simpler operating system as RTEMS is, has been
discussed with him and forwarded to the list

https://lists.rtems.org/pipermail/devel/2022-June/071972.html

when Prashanth S has started his GSoC. That effort did not solve
CAN driver design even that I have provided input into that GSOC
project how to develop stack in the LinCAN queues direction or other
reasonably usable FIFOs. The implemented buffers has been mess.
But I hope that some part of his BeagleBoneBlack D-CAN support
can be reused for D-CAN implementation based on our effort one day.

> Regarding the device names "/dev/can0" and similar: Currently that
> seems to be a fixed scheme, correct?

Not really, the CAN subsystem provides function 

  int can_bus_register( struct can_bus *bus, const char *bus_path );

so it is on the user, BSP integrator etc to decide naming scheme.
Some scheme is not part of the  libcandrv.a. We use simple
unique numbers generator in the test application during interfaces
registration

 Atomic_Uint idx = _Atomic_Fetch_add_uint(
_sqn,
1,
ATOMIC_ORDER_SEQ_CST
  );

> In my experience, sometimes it 
> can be useful to use longer names instead. For example
> "/dev/can_ctufd0". That's especially interesting if a system is
> initialized dynamically.

Understand

> For example if you have a USB to CAN adapter 
> that is enumerated more or less randomly during startup. Is that
> supported or are there some fixed assumptions that a can device is
> always called "/dev/canX"?

The /dev/canX is standard and simplest scheme used on many systems.
But internals of the project do not prevent to use PCI topological
address as part of the pah name.

Best wishes,

Pavel

PS: Michal Lenc has succeed with this weekend experiment to add support
of proposed RTEMS CAN interface into evolving yet toy Rapid Prototyping
tool
  https://github.com/robertobucher/pysimCoder
on base of experimental RTEMS target templates.

PS2: I have tested to build complete OrtCAN CANopen code against proposed
   CAN subsystem as well. It builds but I need to prepare top level
   application to link it successfully.
 
--
Pavel Pisa

phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
personal:   http://cmp.felk.cvut.cz/~pisa
company:https://pikron.com/ PiKRON s.r.o.
Kankovskeho 1235, 182 00 Praha 8, Czech Republic
projects:   https://www.openhub.net/accounts/ppisa
social: https://social.kernel.org/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
RISC-V education: https://comparch.edu.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

[Pavel Pisa]

Dear RTEMS and CAN community,

I want to report another update in Michal Lenc work
on the generic CAN/CAN FD RTEMS stack.
The Sphinx and Doxygen documentation is generated by CI
on our faculty GitLab server. Links to RTEMS CAN resources
in the section

CAN/CAN FD Subsystem and Drivers for RTEMS
https://canbus.pages.fel.cvut.cz/#cancan-fd-subsystem-and-drivers-for-rtems

Repository https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd
Manual 
https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html
Doxygen 
https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/index.html

CAN/CAN FD frame and header described there

https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/structcan__frame.html

Feedback from everybody is welcomed. It would be especially
welcomed if Oliver has some remarks to can_frame_header
and can_frame field names because changes of these
start to be more painfull when/if project is accepted
into RTEMS mainline. Oliver is not probably on RTEMS
list, but I would forward reply there if it will not pass.

I have done initial update of our CAN/CANopen
framework from2003 year to be prepared to work with
new RTEMS solution. Only classic CAN frames for now,
FD is ignored 

  https://ortcan.sourceforge.net/
  https://sourceforge.net/p/ortcan/ortcan-vca/commit_browser

Best wishes,

Pavel
--
Pavel Pisa

phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
personal:   http://cmp.felk.cvut.cz/~pisa
company:https://pikron.com/ PiKRON s.r.o.
Kankovskeho 1235, 182 00 Praha 8, Czech Republic
projects:   https://www.openhub.net/accounts/ppisa
social: https://social.kernel.org/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
RISC-V education: https://comparch.edu.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home



On Friday 05 of April 2024 12:38:28 Pavel Pisa wrote:
> Hello everybody,
>
> Michal Lenc has updated the project to switch from RTEMS
> semaphores allocated with object ID to self-contained
> ones according to the previous response that self-contained
> objects are preferred. Se actual state in the repo
>
>   https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd
>
> The both cases of switching to self-contained objects
> (interrupt_lock -> rtems_lock )
> (rtems_semaphore_create -> rtems_binary_semaphore_init)
> seems to cause measurable increase of overhead in the
> performace testing of the virtual CAN interface
> on Zynq platform. The real communication performance
> does not changed significantly when actual frame sending
> time on the wire is in the loop. But that is the first
> glimpse result only, we may find time for more evaluation
> and even integration of RTEMS to our continuous tests
> setup some day.
>
> Michal Lenc's thesis submission deadline is approaching
> and we would like to have some feedback to start preparation
> of proposal to integrate code into official RTEMS cpukit.
>
> We will be both available at Embedded World Exhibition
> and I will even present the article about CAN/CAN FD
> latency in Linux kernel at the ewC conference
>
>  April 9, 4:00 PM - 5:45 PM
>  Session 2.3 CONNECTIVITY SOLUTIONS
>  Continuous CAN Bus Subsystem Latency Evaluation and Stress Testing
>  on GNU/Linux-Based Systems
>  https://canbus.pages.fel.cvut.cz/#can-bus-channels-mutual-latency-testing
>
> We will take some species from our hardware ZOO and will
> show them on https://www.osadl.org/ booth OSADL booth in hall 4, booth
> 4-168 so if you want to contact us, you can stop there. We will have
> Linux, RTEMS booted MZ_APO kits there and some other
> Linux, NuttX ARM and RISC-V boards. Even if we are
> not presnet at the moment on the booth, OSADL colleagues will have
> contact to us. If there is some RTEMS meeting, we will try
> to reserve time.
>
> Best wishes,
>
> Pavel
> --
> Pavel Pisa
> phone:  +420 603531357
> e-mail: p...@cmp.felk.cvut.cz
> Department of Control Engineering FEE CVUT
> Karlovo namesti 13, 121 35, Prague 2
> university: http://control.fel.cvut.cz/
> personal:   http://cmp.felk.cvut.cz/~pisa
> social: https://social.kernel.org/ppisa
> projects:   https://www.openhub.net/accounts/ppisa
> CAN related:http://canbus.pages.fel.cvut.cz/
> RISC-V education: https://comparch.edu.cvut.cz/
> Open Technologies Research Education and Exchange Services
> https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
>
> On Wednesday 13 of March 2024 17:01:30 Michal Lenc wrote:
> &

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - Embedded World

[Pavel Pisa]

Hello everybody,

Michal Lenc has updated the project to switch from RTEMS
semaphores allocated with object ID to self-contained
ones according to the previous response that self-contained
objects are preferred. Se actual state in the repo 

  https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd

The both cases of switching to self-contained objects
(interrupt_lock -> rtems_lock )
(rtems_semaphore_create -> rtems_binary_semaphore_init) 
seems to cause measurable increase of overhead in the
performace testing of the virtual CAN interface
on Zynq platform. The real communication performance
does not changed significantly when actual frame sending
time on the wire is in the loop. But that is the first
glimpse result only, we may find time for more evaluation
and even integration of RTEMS to our continuous tests
setup some day.

Michal Lenc's thesis submission deadline is approaching
and we would like to have some feedback to start preparation
of proposal to integrate code into official RTEMS cpukit.

We will be both available at Embedded World Exhibition
and I will even present the article about CAN/CAN FD
latency in Linux kernel at the ewC conference

 April 9, 4:00 PM - 5:45 PM
 Session 2.3 CONNECTIVITY SOLUTIONS
 Continuous CAN Bus Subsystem Latency Evaluation and Stress Testing
 on GNU/Linux-Based Systems
 https://canbus.pages.fel.cvut.cz/#can-bus-channels-mutual-latency-testing

We will take some species from our hardware ZOO and will
show them on https://www.osadl.org/ booth OSADL booth in hall 4, booth 4-168
so if you want to contact us, you can stop there. We will have
Linux, RTEMS booted MZ_APO kits there and some other
Linux, NuttX ARM and RISC-V boards. Even if we are
not presnet at the moment on the booth, OSADL colleagues will have
contact to us. If there is some RTEMS meeting, we will try
to reserve time.

Best wishes,

Pavel
--
Pavel Pisa
phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
personal:   http://cmp.felk.cvut.cz/~pisa
social: https://social.kernel.org/ppisa
projects:   https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
RISC-V education: https://comparch.edu.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home





On Wednesday 13 of March 2024 17:01:30 Michal Lenc wrote:
> Dear RTEMS developers,
>
> we have made a progress with our CAN stack and virtual/CTU CAN FD
> controller tests using standard x86-64 QEMU. We can now provide scripts
> that build the stack and our applications on i386-pc686 target and run
> RTEMS in QEMU. The actual CAN stack can still be found in our university
> GitLab
>
> https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd
>
> and following steps build and run RTEMS in QEMU:
>
> $ export PATH=$PATH:/opt/rtems/6/bin
>
> $ cd targets/i386_pc686
>
> $ ./setup-host-socketcan
>
> $ ./qemu-i386-pc686-2x-ctu-pci-build
>
> $ ./qemu-i386-pc686-2x-ctu-pci-run
>
> Support for i386_pc686 BSP is located in /opt/rtems/6 in this case. You
> can use following script to compile the BSP with required configuration
> setting.
>
> $ ./i386-rtems-sys.cfg (you might need to change RTEMS_DIR variable
> based on your location of RTEMS source code directory)
>
> RTEMS terminal in QEMU should come up after executing run command. You
> can try applications for both virtual controller and CTU CAN FD
> controller. The controllers have to be initialized and register which is
> done by
>
> can_register -t [target]
>
> command (target is either virtual or ctucanfd). Registered devices are
> assigned to test applications with can_set_test_dev [dev0] [dev1]
> command, where dev0 and dev1 are paths to character devices. Then test
> applications are can_1w (one way) and can_2w (two way). For example for
> CTU CAN FD
>
> # this registers two CTU CAN FD controllers under dev/can0 and dev/can1
>
> SHLL [/] # can_register -t ctucanfd
>
> # assign dev/can0 and dev/can1 to test applications
>
> SHLL [/] # can_set_test_dev /dev/can0 /dev/can1
>
> # run test applications
>
> SHLL [/] # can_1w
>
> SHLL [/] # can_2w
>
> All those steps are also described in project README or you can use help
> app command in RTEMS terminal to get further description of commands and
> their arguments.
>
> We want to rewrite some other controllers for our CAN stack to provide
> further tests and widen the support (SJA1000 would probably be the first
> one on our list), but currently the priority is the full completion of
> the stack itself (error reports, all required IOCTLs, etc.).
>
> Best wishes,
>
> Mic

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch (LinCAN inspired)

[Pavel Pisa]

Hello Gedare,

thanks for feedback.

On Tuesday 05 of March 2024 22:54:35 Gedare Bloom wrote:
> On Thu, Feb 29, 2024 at 6:40 AM Pavel Pisa  wrote:
> > On Tuesday 27 of February 2024 22:27:43 Gedare Bloom wrote:
> > > On Mon, Feb 12, 2024 at 8:03 AM Pavel Pisa  wrote:
> > > >
> > > >  https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd
> > > >
> On a quick review, my recommendation would be to switch to using the
> rtems_mutex mechanism of the self-contained objects, see
> https://docs.rtems.org/branches/master/c-user/self_contained_objects.html
>
> I believe this will be a more suitable solution than the more general
> interrupt lock. It should be relatively straightforward to implement
> this replacement for both the qends and the fifo structures. Each may
> embed its own rtems_mutex. I see you already use a
> rtems_mutex_recursive to protect the can_bus structure. I would avoid
> a design that allows recursive access if possible. I did not see if
> you acquire the lock during interrupt service routines.
>
> Since you have the interrupt_lock mechanism implemented, may be it
> would be a nice experiment to evaluate the performance vs the
> self-contained rtems_mutex.

I agree with switch to self-contained rtems_mutex_lock
and probably we try even rtems_binary_semaphore_post
for notification. In the fact, this was my question
in RFC whether consider self-contained objects
for synchronization.

By switch of queues protection to mutexes, we lose option
to fill it directly from interrupt and implement driver
Rx and Tx in interrupts. This could be problem on very slow
targets with really short Rx FIFO. But that is not case
of CTU CAN FD and even SJA1000 has 128 bytes HW FIFO.
The code locking by interrupt disable is for really short
time, so it should not be a problem.

But we have decided to use chip dedicated thread on RTEMS
from start to allow its priority setup even somewhere
in middle to allow if there are even some more timing
critical tasks running.

On Linux kernel, we have used interrupt disabling spinlock
to allow write LinCAN Rx and Tx handles directly in interrupt
service routine. But that locking mechanism automatically
switches to priority aware RT mutexes on the fully preemptive
kernel.

Anyway, we switch to rtems_mutex_lock on RTEMS, it makes
code even simpler and do timing before and after switch
ho have idea about behavior on Zynq target (which falls into
middle or lower performance range today so it is appropriate
for assessment if overhead is significant).

Best wishes,


Pavel
-- 
Pavel Pisa
phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
personal:   http://cmp.felk.cvut.cz/~pisa
social: https://social.kernel.org/ppisa
projects:   https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
RISC-V education: https://comparch.edu.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch (LinCAN inspired)

[Pavel Pisa]

Hello Gedare

On Tuesday 27 of February 2024 22:27:43 Gedare Bloom wrote:
> On Mon, Feb 12, 2024 at 8:03 AM Pavel Pisa  wrote:
> > Michal Lenc works on a new generic CAN/CAN FD subsystem for RTEMS under
> > my supervision. The project has reached a phase where we will be very
> > grateful for the review and pointing to required changes to start a
> > discussion of possible inclusion into the RTEMS mainline. The project is
> > currently being developed as a separate RTEMS application based on the
> > OMK build
> >
> >  https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd
> >
> > But long-term intention is to move
> >
> > 
> > https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd/-/tree/master/lib/can
> >drv
> >
> > directory into RTEMS cpukit/dev/can directory and corresponding include
> > files into cpukit/include/dev/can directory.
>
> Thanks. I will review this design and code, but it will be a few weeks
> before I can do that. The directory location is a suitable choice.

Thanks. I consider critical to discuse if queues access protection
by rtems_interrupt_lock_acquire is appropriate etc. I.e., I see
rtems_semaphore_obtain problematic because it would exhaust
fixed configures resources easily. I am not sure, if there is
rtems core / "kernel" equivalent to contained objects as are used
for "userspace" pthread_mutex_lock etc... There are more such architectural
questions where feedback from you, Joel, Sebastian and or Chis
with deeper knowledge would help. This discussion should continue
in public list or as issues setup for RTEMS CAN FD subsystem.

> > We have reached a state where the virtual interface has been tested on an
> > MZ_APO Xilinx/AMD Zynq-based board and an LX_CPU/LX_RoCoN NXP
> > LPC4088-based board. The communication with a complete CAN interface has
> > been successfully tested on the MZ_APO Xilinx/AMD Zynq board with CTU CAN
> > FD IP cores implemented in FPGA.
> >
> > Building on other RTEMS BSP should be possible by changing a single
> > definition in the config.target file
> >
> >   RTEMS_MAKEFILE_PATH=/opt/rtems/6/arm-rtems6/xilinx_zynq_zedboard
>
> When ported to cpukit, this would become part of the spec/build opts.

For sure, but we want to have easy way to build code against different
targets when it is still standalone.

> > Michal Lenc will submit work as his Master's Thesis this May
> > so I hope that Gedare would be willing to take the thesis
> > reviewer role as we have already discussed.
>
> Indeed I will. I think this work is exciting and needed.

Thanks for confirmation. There is limited time window when
we can steer his work direction. When he finishes then I hope
that he will be helpfull and I want to keep an eye on the
project and maintain it as I have done 20 years with LinCAN
and helped SocketCAN etc., but the resources for deeper redesign
will be limited until some another studnet is found or me or
some company has funded project which would be willing to invest
even into infrastructural work.


You have asked bout XCAN in an another thread, so I reply there
even to inform the public. XCAN is AMD/XilinX controller integrated
onto Zynq chips.

I remember that there has been invested into the driver
at German Aerospace Center. Carlo Brokering has worked
on it based on the Prashanth S work on Beagle Bone in the frame
of GSoC. But the work on infrastructure and FIFOs was not
finished from any side even that I have provided our LinCAN
sources etc. and later the result has be removed as broken
from mainline. 

https://lists.rtems.org/pipermail/devel/2023-March/074504.html

We have XCAN on our Zynq board routed to CTU CAN FD,
so it can be tested but porting to new infrastructure
hardly fits to Michal Lenc's thesis plan.

Another interesting platform and controllers would
be xilinx-zynqmp and xilinx-versal. These have
advantage that CAN FD controller emulation is included
in QEMU mainline.

For our project testing for developers without HW, we plan
to add support for PCI mapped CTU CAN FD on some x86 RTEMS
BSP, because we have that support included in QEMU mainline.

I have tried to provide even platform bus (AMBA) mapping
for Xilinx Zynq as an experimental patch for QEMU

  
https://github.com/ppisa/qemu/commit/2bcfd7b8dfd7d657ada2f8ec2b972f6469b33c94

Mmaped IO works but interrupt mapping is not working
and I am not sure how it should be done correctly for
dynamically plugable sysbus device yet.

Best wishes,

Pavel
-- 
Pavel Pisa
phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
personal:   http://cmp.felk.cvut.cz/~pisa
social: https://social.kernel.org/

[RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch (LinCAN inspired)

[Pavel Pisa]

eferred alternative is my uLUt
solution, which we use on bare metal embedded systems, Linux
RTEMS and NuttX, but it would require introducing lot of
code and complex macros into RTEMS cpukit.

We are looking for feedback and cooperation. If the solution
passes the demands of the RTEMS core community, then it would
worth to port support for other controllers on this base.
We can open a GSoC project for it.

If the solution is acceptable, we should set up a page on RTEMS devel.
The preliminary wiki is at our faculty GitLab. But it is hard to
enable for general editing access. We can move even on GitHub.

Michal Lenc will submit work as his Master's Thesis this May
so I hope that Gedare would be willing to take the thesis
reviewer role as we have already discussed.

We will present our CAN latency testing project at the embedded world
Conference 2024 as well as on OSADL booth https://www.osadl.org/
in Nuremberg from April 9 to 11. There is an option to meet and discuss
RTEMS CAN and other projects in person. Our latency testing
focuses on Linux SocketCAN, but long ago, we tested LinCAN
on Linux and even original MSM CAN on RTEMS. I plan to add RTEMS
to our actual latency tester project in the frame of some another
future student project.

Best wishes,

    Pavel

Pavel Pisa
phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
personal:   http://cmp.felk.cvut.cz/~pisa
social: https://social.kernel.org/ppisa
projects:   https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
RISC-V education: https://comparch.edu.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 47/47] bsp/tms570: Update README

[Pavel Pisa]

Hello Sebastian and others,

I have found a little more time to look at the patches again.
So some minor comments to README, to help potential users
find relevant information

On Thursday 21 of December 2023 15:38:20 Sebastian Huber wrote:
> From: Tyler Miller 
>
> ---
>  bsps/arm/tms570/README | 134 +++--
>  1 file changed, 63 insertions(+), 71 deletions(-)
>
> diff --git a/bsps/arm/tms570/README b/bsps/arm/tms570/README
> index 200f8077cf..0146bcc8e9 100644
> --- a/bsps/arm/tms570/README
> +++ b/bsps/arm/tms570/README
...
> @@ -1,7 +1,13 @@
> -Development Board: TMS570LS31x Hercules Development Kit from TI
> @@ -98,36 +94,31 @@ For ETHERNET, the lwIP port for TMS570LS3137 has been
> developed at Industrial Informatics Group of Czech Technical University
>  in Prague and development versions are available on SourceForge.
>
> -The RTEMS and TMS570 support is included in uLAN project lwIP
> -repository for now
> +RTEMS and TMS570 support is included in uLAN project lwIP
> +repository
>
>https://sourceforge.net/p/ulan/lwip-omk/
>
> -But other place should be found when RTEMS lwIP
> -integration with read, write, close etc. functions
> -is implemented in future.
> +This port has been consolidated with other RTEMS-LWIP ports here:
> +
> +https://git.rtems.org/rtems-lwip/tree/uLan/ports

The link/directory is no longer valid.

The RTEMS LwIP project has been consolidated by Kinsey
Moore, so the misleading original naming (which I have
objections earlier) is resolved. Actual location
of TMS570 LwIP support is

  https://git.rtems.org/rtems-lwip/tree/rtemslwip/tms570

The origin of LwIP RTEMS porting is mine and Roman
Bartosinki work (https://sourceforge.net/p/ulan/lwip-omk/)
paid by PiKRON s.r.o. and Alvat s.r.o. for NXP LPC
and Premysl Houdek's and mine work on RTEMS support
based on our previous referenced system-less OMK support.

  https://sourceforge.net/p/ulan/lwip-omk/

I would probably send another separate patch later to
correct/precise origin of TMS570 RTEMS work at Czech Technical
University in Prague, because original group, for which
I have had worked for 20 years, is no longer organized under
our department (https://control.fel.cvut.cz/) and even when
I worked for it on TMS570 ECU design for Porsche ECU,
we have been forced to use FreeRTOS and RTEMS has never been
in the interrest of the group head and all work on RTEMS has
been my own time contribution a Premysl Houdek GSoC
and diploma thesis projects.
 
So the origin should point to our faculty and department.

Or may it be to the guidepost build by me to coordinate
studnest work and the university

  Open Technologies Research Education and Exchange Services
  https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home

We have even lot of CAN work done for TMS570 before
continuation of my other theses has been blocked
declared as unwanted same as many other promissing
projects in 2016...

Best wishes,

Pavel
-- 
Pavel Pisa
phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
    university: http://control.fel.cvut.cz/
personal:   http://cmp.felk.cvut.cz/~pisa
social: https://social.kernel.org/ppisa
projects:   https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
RISC-V education: https://comparch.edu.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 24/47] bsp/tms570: Remove double pin configuration

[Pavel Pisa]

Hello Sebastian,

On Thursday 21 of December 2023 15:37:57 Sebastian Huber wrote:
> From: Tyler Miller 
>
> ---
>  bsps/arm/tms570/start/pinmux.c | 10 --
>  1 file changed, 10 deletions(-)
>
> diff --git a/bsps/arm/tms570/start/pinmux.c
> b/bsps/arm/tms570/start/pinmux.c index d9c52cd00d..9277a36431 100644
> --- a/bsps/arm/tms570/start/pinmux.c
> +++ b/bsps/arm/tms570/start/pinmux.c
> @@ -182,16 +182,6 @@ tms570_bsp_pinmmr_config(const uint32_t
> *pinmmr_values, int reg_start, int reg_c pval = pinmmr_values;
>cnt = reg_count;
>
> -  do {
> -*pinmmrx = *pinmmrx & *pval;
> -pinmmrx++;
> -pval++;
> -  } while( --cnt );
> -
> -  pinmmrx = (_IOMM.PINMUX.PINMMR0) + reg_start;
> -  pval = pinmmr_values;
> -  cnt = reg_count;
> -
>do {
>  *pinmmrx = *pval;
>  pinmmrx++;

there has been reason for this sequence.

If you use bootloader or if you want to start
RTEMS in SDRAM loaded by another RTEMS or system
in Flash then direct switching from one config
to another can lead to pin configuration collision.

So the logic has been meant such way, that
all configurations which should not be valid
after pin reconfiguration are disabled the first,
(i.e.) pins and internal signals are tristated
and in the second round the final values
are set.

It can have reason even if some peripheral is activated
at runtime according to application config.

May be, that double run is really abundant but I would
suggest to do the analysis again. I need to find some
time to refresh TMS570 knowledge because it is eight
years already when we build base TMS570L3137 support
with Premek...

But I am sure that this was the idea behind update
in two phases.

Best wishes,

Pavel Pisa
phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
personal:   http://cmp.felk.cvut.cz/~pisa
social: https://social.kernel.org/ppisa
projects:   https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
RISC-V education: https://comparch.edu.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/8] Add basic support for TMS570LC4357

[Pavel Pisa]

Hello Sebastian

On Wednesday 06 of December 2023 17:08:39 Sebastian Huber wrote:
> sorry for the delay, but I was busy with all sorts of things.  I checked
> in the first round of patches. I work on cleaning up a patch set with
> support for the TMS570LC4357.
>
> For debugging, we use the Lauterbach PowerDebug System.

thanks for information and pushing the project forward.
I hope I find some day some time to test RTEMS
on TMDX570LC43HFK which I have long time there...
I hope that it would work with OpenOCD, it should
be functional without Flashing.

I am happy that this work continues and I have call with
Premek today to check that he has received your other
e-mail. He is happy too that his thesis work has some use
and promised to reply to your by another e-mail in two, three
days to have his personal reply recorded. Generally we
agree with change of our RTEMS contribution to BSD-2-Clause.
Keeping reference to the university and authors listed
is preferred.

By the way, as I have announced earlies, Michal Lenc's
thesis on RTEMS CAN/CAN FD support progresses

  https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd/-/tree/master/lib/candrv

This week, he has implemented rough initial version of connection
of rtems_filesystem_file_handlers_r (can-bus.c) to FIFOs system
ported from LinCAN. Not tested yet... This work has plan
to target Zynq system but if there is some project in which
we can participate by targetting our CAN work more
to TMS570LC4357, we would consider to rearrange priorities.

I have bought two BeagleV-Fire boards to my company as well

  https://www.beagleboard.org/boards/beaglev-fire

and it could be nice target where we can test RTEMS for hard
realtime in addition to Linux and NuttX. Again if there
is for example some ESA or other project which could
use our work, we can change mode from tinkering and long
term investment into targeting concrete goals and terms.
We plan to test our PXMC motion control HDL and SW on this
platform to have prepared continuation to our previous
LX_RoCoN Cortex-M based systems already used at ESA.

There is some possibility that I will teach computer
architectures in the space oriented course so replacement
of Raspberry Pi by BeagleV-Fire and RTESM could be
great demonstrator on ExoMy or other platform

  https://github.com/esa-prl/ExoMy

Best wishes,

Pavel
-- 
    Pavel Pisa
phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
personal:   http://cmp.felk.cvut.cz/~pisa
social: https://social.kernel.org/ppisa
projects:   https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
RISC-V education: https://comparch.edu.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS CAN/CAN FD project - start and initial progress report

[Pavel Pisa]

Dear RTEMS community,

as I have already pre-announced, we are opening the project
to implement/port CAN/CAN FD framework to RTEMS. Our
wiki to form ideas, locate new and old code, and document
knowledge sources

   https://gitlab.fel.cvut.cz/otrees/rtems/work-and-ideas/-/wikis/can_fd

We do not have external funding for it now/yet. It is driven
by my long-term interest in RTEMS and CAN. Even that
it is more in enthusiast form now; there is some track
record of other viable activities pushed by me and my students,
LinCAN for Linux has been used for about 15 years by industry
(but mostly replaced by SocketCAN now), contribution to Linux
mainline SocketCAN (bit timing, priority filters, some drivers),
QEMU CAN/CAN FD subsystem, CTU CAN FD IP core with drivers
in Linux kernel mainline, used in space scientific payload
already and there are ongoing efforts to integrate it into
mass-produced silicons, etc.

The main developer of the actual project is Michal Lenc
who works on the project in the frame of his diploma thesis
work which is due by May 2024. He has a good track
record of CAN/CAN FD and other related RTOS work
mainly on the NuttX side from 2020

  https://github.com/apache/nuttx/commits?author=michallenc

but even tester RTEMS on Zynq 7000 to implement DC motor
steer-by-wire over UDP with TCP http server already in
a frame of real time systems course.

So I hope that we have a chance to provide something functional
even alone and with review, feedback, and cooperation from
the community and companies there are even better foresight. 

Our actual target hardware for RTEMS development and testing
is the MZ_APO educational kit based on MicroZed Xilinx Zynq 7000.
We plan to target our CTU CAN FD IP core in the first go, but
we have the FPGA design where we can combine XCANs, OpenCores
SJA1000 cores with our modification for CAN FD tolerance
in addition to CTU CAN FD. But work on other drivers probably
does not fit into this thesis's time budget. I try to find
other students or somebody else, even in the GSoC frame,
for example, who can contribute additional drivers.
SJA1000, CTU CAN FD, and Xilinx CAN FD on Versal
and UltraScale have QEMU functional models implemented,
so even that is a viable development environment.
But QEMU CAN supports SJA1000, and CTU CAN FD only
as PCI/PCIe integration for now...
It can be extended to platform mapping, or x86 or some
ARM with PCIe can be used for RTEMS development
as alternative.

The aim is to design the RTEMS CAN/CAN FD subsystem, which
can be/would be integrated into RTEMS mainline cpukit
if it passes RTEMS core developers review. But for now,
it is developed in a separate repository with OMK build
setup against standard RTEMS development kit in /opt/rtems.

The actual project zygote repository is on our GitLab

  https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd

but we can move it to another site or set up access
for others to contribute there. The actual main goal is to
collect sources and form/port infrastructure to use native
RTEMS score APIs. There are located in separate project
subdirectories some our sources to reuse. I.e. the rough port
of fragments of our CTU CAN FD Linux driver sources which
successfully transferred CAN frames between two CTU CAN FD
interfaces when compiled for RTEMS, no interrupts, queues,
etc., for now. Even communication with another USB
and MCU hardware has been tested from RTEMS.

The actual main focus is to adapt LinCAN FIFOs and infrastructure
for chip side and filesystem side nodes to use RTEMS score APIs.
This part is located in the lib/candrv subdirectory of the project.
Actual core files that are under current development

  
https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd/-/blob/master/lib/candrv/dev/can/can-frame.h
  
https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd/-/blob/master/lib/candrv/dev/can/can-queue.h
  
https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd/-/blob/master/lib/candrv/can-queue.c

LinCAN queues are documented in section 1.4. LinCAN Driver
Architecture of the LinCAN manual

  https://cmp.felk.cvut.cz/~pisa/can/doc/lincandoc-0.3.5.pdf

The actual architectural decision (based even on the previous discussion
on the rtems-devel list) is not to port/use RTEMS message queues
but to use original LinCAN FIFOs. That has some advantages.
When the chip message object is required for higher-priority Tx frames,
a pending message can be pushed back on the tail of the FIFO.

rtems_interrupt_lock and score atomic operations are used
for locking and SMP operation, which allows to implement chip
side (ends, low-level driver) even as the state automaton
that pushes messages into FIFOs from interrupt context.
Even that we plan to implement CTU CAN FD support as a regular driver
worker thread, there exist chips with short Rx hardware FIFOs
which could need direct passing of frames from interrupts
to prevent the message drops. If the FIFOs use from interrupts
is not required, then switch of the locking to regular

Re: Status of CAN API?

[Pavel Pisa]

Hello Philip, Gedare and others interested in RTEMS CAN/CAN FD API,

On Tuesday 22 of August 2023 14:11:22 Philip Kirkpatrick wrote:
> Thank you for your input on this.  I'm still digesting LinCAN, but it looks
> like a good way to go.  On our end, we will likely have some resources to
> throw at this in a few weeks.

LinCAN has been designed as full featured, vendor neutral character driver
API based CAN stack for Linux and RTOS RT Linux kernel with ability
to be accessed from Linux user-land and RT Linux modules in the second case.

  https://ortcan.sourceforge.net/lincan/

But SocketCAN is the choice for Linux kernel CAN support today.
It has nicer API but has it problems on real-time side etc...
Even from our experience with NuttX CAN drivers development
I tend to stay with character driver API for RTEMS in the current
iteration...

Potability of LinCAN to RTEMS and even bare metal HW without scheduler
has been taken in mind. There is a branch can-usb1 which used slightly
modified SJA1000 LinCAN chip driver together with LinCAN infrastructure
to provide low level API (only FIFOs, no POSIX read/write call) in system
less mode to implement USB to CAN converter on old NXP LPC21xx and SJA1000
or newer LPC17xx targets

 https://sourceforge.net/p/ortcan/lincan/ci/can-usb1/tree/embedded/app/usbcan/

We have implemented the companion Linux kernel LinCAN and SocketCAN drivers
which allowed to use even USB converter in addition to ISA and PCI
bus connected CAN controllers... 

> On Thu, Aug 17, 2023 at 4:26 PM Gedare Bloom  wrote:
> > Hi Phil,
> >
> > On Wed, Aug 9, 2023 at 6:38 AM Philip Kirkpatrick
> >
> >  wrote:
> > > Hello,
> > >
> > > Some people on our team here at Reflex are preparing to implement some
> >
> > CAN drivers.  Specifically for TMS570 and for ZynqMP-RPU (side note my
> > latest patch for that on Jun 29th is still sitting there unreviewed).  I
> > was wondering what the current status of the CAN API is.
> > Feel free to ping the patch. At the moment, this email based system is
> > all we have, and sometimes patches may not get a lot of attention
> > especially if no one "owns" it -- such as new BSPs.
> >
> > > I saw in August of last year and API was added and then last month was
> >
> > reverted with this patch:
> > > https://lists.rtems.org/pipermail/devel/2023-July/076013.html
> > > The comment on the patch says the API isn't mature enough for release.
> >
> > What deficiencies need to be resolved in the API, is this being actively
> > worked on, and should we design against this API or is there a different
> > API we should target?

We plan keeping CAN/CAN FD structure (discussed and agreed upon with
Oliver Hartkopp) and keep barely the same read/write code as is in already
included CAN solution. I consider deep redesign of the rest as a must.

> > The implementation of that API was deficient. It did not support
> > multiple read/write transactions, it had a custom-built ring buffer
> > that was not fully vetted, and some other problems related to
> > threads+priorities. I expect to have some time to look at how to
> > provide better CAN support inside of RTEMS. This has been an ongoing
> > discussion I've been having with Pavel Pisa and others for many years
> > now (a decade?). The direction that I will prefer to go is to port
> > LinCAN
> > https://cmp.felk.cvut.cz/~pisa/can/doc/lincandoc-0.3.5.pdf
> >
> > Both Pavel and I are interested in seeing this come through. So far,
> > we mostly do it on volunteer time or as side pieces of other work.
> > Pavel's group has good experience with CAN and CAN FD, and with both
> > TMS570 and the Zynq (non-MP) boards, with Linux, RTEMS, and NuttX. We
> > would be open to collaborating, subject to whatever time or resource
> > constraints everyone has :) Michal Lenc has been working on this topic
> > as a thesis, "CAN FD Support for Space Grade Real-Time RTEMS
> > Executive"

Or initial panned target is our own CTU CAN FD IP Core

  https://canbus.pages.fel.cvut.cz/

which we can test on our MZ_APO Zynq 7k based kits
and have emulation for it in QEMU mainline etc...

There has been James Holley working on Zynq 7k XCAN support
during his intern under Noviumdesigns company funding,
if I remember well. But I am not sure if there has been
some final version released to public. It has been based
on actual RTEMS CAN FIFOs stub and they planned to somehow
fix it but if it. If it is offered under RTEMS mainline
compatible license then it can be updated to CAN API
and FIFOS after rewrite and used for RTEMS XCAN support
in the next step. By the way Zynq-MP and Versal have
advantage that Xilinx included corresponding CAN FD
controllers model int

Re: [PATCH] TMS570 console driver, SCI frame error (baudrate calculation error)

[Pavel Pisa]

Hello Zack and Gedare,

On Tuesday 11 of July 2023 19:52:27 Gedare Bloom wrote:
> Thanks for the patch. Someone should probably test it, or identify in
> the documentation why this calculation was off-by-1. Pavel, any clues?
> On Sun, Jul 9, 2023 at 10:09 PM zack  wrote:
> > Fixes #4903
> > diff --git a/bsps/arm/tms570/console/tms570-sci.c
> > b/bsps/arm/tms570/console/tms570-sci.c index 768770a4c8..59a0b7e6f1
> > 100644
> > --- a/bsps/arm/tms570/console/tms570-sci.c
> > +++ b/bsps/arm/tms570/console/tms570-sci.c
> > @@ -311,7 +311,7 @@ bool tms570_sci_set_attributes(
> >/* Apply baudrate to the hardware */
> >baudrate *= 2 * 16;
> >bauddiv = (BSP_PLL_OUT_CLOCK + baudrate / 2) / baudrate;
> > -  ctx->regs->BRS = bauddiv? bauddiv - 1: 0;
> > +  ctx->regs->BRS = bauddiv? bauddiv - 2: 0;

I think that change is not correct. The actual used values
for BSP_PLL_OUT_CLOCK and baudrate should be provided to analyze
the case. The code can result in some rounding error and can
be enhanced if fractional divider is used or even super finegrained
fractional divider. But these options are available only for
for SCI/LIN peripheral case.

According to

TMS570LS31x/21x 16/32-Bit RISC Flash Microcontroller
Technical Reference Manual
Literature Number: SPNU499B

26.2.3 SCI Baud Rate

  SCICLK Frequency = VCLK Frequency / (P + 1 + M / 16)

  Asynchronous baud value = SCICLK Frequency / 16

So the substraction of one corresponds to the manual.

Actual code does not use M part. It would be problem if it is
leftover from some boot/monitor but it is part of BRS 32-bit
register which is overwritten in the whole, so such problem
should not appear either.

So I vote against the proposed change for now and suggest
to do analysis what happens in the computation and what
are input values and output. Change would/could affect
negatively large number of combinations of the baudrate
and clocks.

I would consider to discuss if the rounding formula
could/should be updated, but I think that it is the best
which cane be achieved for rations which do not result
in exact ratio.

  (BSP_PLL_OUT_CLOCK + baudrate / 2) / baudrate;

If there is interrest then code can be enhanced by fraction
dividers for SCI/LIN peripheral case. The field with variant
should be added into tms570_sci_context and in this case
the alternative formula can be used

  long long bauddiv;
  bauddiv = (BSP_PLL_OUT_CLOCK * 16ll + baudrate / 2) / baudrate;
  ctx->regs->BRS = ((bauddiv >> 4) & 0xff) | ((bauddiv & 0xf) << 24);

which should be rewritten after header for SCI/LIN update to

  ctx->regs->BRS = TMS570_LIN_BRS_P(bauddiv >> 4) | TMS570_LIN_BRS_M(bauddiv & 
0xf);

Best wishes,


Pavel
--
Pavel Pisa
phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
personal:   http://cmp.felk.cvut.cz/~pisa
projects:   https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
RISC-V education: https://comparch.edu.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home

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

Re: [PATCH 0/8] Add basic support for TMS570LC4357

[Pavel Pisa]

Hello Sebastian,

I am happy to see that TMS570 RTEMS support is moving
forward. I hope to have some time when semester/exams
ends to play with it at least a little again.

I am curious which development toolas are you using.
I preferred GDB and OpenOCD but there is problem that
TMS570LS3137 has some problems with endianness
access form OpenOCD to external SDRAM. I have some
patches for that but for some branch bused on some
other developers patches which has not propagated into
mainline. 

Another missing part for OpenOCD is Flash programming
support for TMS570 family. Again, I have some hacked
version which was based on side branch of  Andrey Smirnov.
Problem is even inclusion of Cortex-R code linking
TI libraries without sources as data array into OpenOCD.
It would be necessary to use some loader of external
code snippet into TMS570 for license reasons.

Anyway, may old attempts are there

   https://cmp.felk.cvut.cz/~pisa/tms570/openocd-patches/

There is some set of utilities to use it from GDB
in Premysl Houdek's repository

  https://github.com/AoLaD/rtems-tms570-utils

It includes even tools to generate RTEMS style header files
from TI manuals.

As for the BSP documentation, you can look if something from
Premysl Houdek's GSoC documents is reusable.

As for TMS570LC4357 support, I would like to remind the
work done by people from https://www.iri.uni-frankfurt.de

  https://github.com/jalmito/rtems/branches/stale

Best wishes,

Pavel
--
Pavel Pisa
phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
company:https://www.pikron.com/
personal:   http://cmp.felk.cvut.cz/~pisa
projects:   https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
RISC-V education: https://comparch.edu.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [lwip 2/2] Move and rename sys_arch_data_sync_barier()

[Pavel Pisa]

Hello Sebastian,

On Friday 24 of March 2023 11:43:02 Sebastian Huber wrote:
> it seems we have two different MDIO services:

not not nice to have two different APIs...

In general it would be great to have actual MDIO PHY chips drivers
in a separate folder(s) and actual NIC driver should provide
only MDIO access routines through some unified API.

> cpsw/src/include/mdio.h:extern unsigned int MDIOPhyRegRead(unsigned int
> baseAddr, unsigned int phyAddr,
>
> uLan/ports/driver/tms570_emac/ti_drv_mdio.h:MDIOPhyRegRead(volatile
> tms570_mdio_t *baseAddr, uint32_t phyAddr,
>

None of these two definitions is ideal

  uint32_t
  MDIOPhyRegRead(volatile tms570_mdio_t *baseAddr, uint32_t phyAddr,
 uint32_t regNum, volatile unsigned short *dataPtr)

  extern unsigned int MDIOPhyRegRead(unsigned int baseAddr, unsigned int 
phyAddr,
 unsigned int regNum, volatile unsigned 
short *dataPtr);

Same for write etc...

If the generic mdio.h and PHY chip drivers should be used for multiple
NICs, then some prototype like

  uint32_t
  MDIOPhyRegRead(mdiophy_state_t *mdiophyst, uint32_t phyAddr,
 uint32_t regNum, volatile unsigned short *dataPtr)


should be used and and mdiophy_state_t should provide actual
pointers to the routines specific for given NIC as well as base
address. That way multiple instances of even different MDIO
interfaces can be supported.

I would like to see something like Linux struct mdio_if_info

  https://elixir.bootlin.com/linux/latest/source/include/linux/mdio.h#L133

or some BSD equivalent. I see that in BSD based RTEMS TCP/IP stack
is struct rtems_mdio_info defined

  
https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/rtems/rtems_mii_ioctl.h

May it be it could be reused there even that I do not like that
pointer to struct rtems_mdio_info structure is not passed into
rtems_mdio_read_func() and rtems_mdio_write_func() functions.

So generally it would be great if this part can be sorted
and cleaned... I hope to have more time during winter term...

On Wednesday 29 of March 2023 13:43:28 Sebastian Huber wrote:
> > up. I would like to test code on TMS570LS3137 when I find
> > time and on TMS570LC43 one day...
>
> I work currently with these chips.

Nice to know, I have EDKs for both at home...

We have developed really advanced solution to combine
N2HET, DMAs and integrated D-CAN controllers to
achieve time triggered CAN operation with these
with maximal CPU offloading. So if there is interrest
we can try to port that solution to RTEMS...

We have Matlab/Simulink target for that TMS570LS3137
built as well and lot can be ported to RTEMS.

We have even done design of experimental ECU based
on TMS570LS3137 with my colleague from PiKRON company
for Porsche... So we can share knowledge...

TMS570LC4357 is even more interesting, becase it
has more RAM which could allow better TCP/IP
experience even without external RAM.

Best wishes,

Pavel Pisa
phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
    personal:   http://cmp.felk.cvut.cz/~pisa
projects:   https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
RISC-V education: https://comparch.edu.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [lwip 2/2] Move and rename sys_arch_data_sync_barier()

[Pavel Pisa]

Hello Sebastian,

On Friday 24 of March 2023 11:21:57 Sebastian Huber wrote:
> Hello Pavel,
>
> On 18.03.23 01:04, Pavel Pisa wrote:
> > As for
> >
> > +static inline void
> > +tms570_data_sync_barier(void)
> > +{
> > +#ifdef __arm__
> > +  _ARM_Data_synchronization_barrier();
> > +#endif
> > +}
> >
> > it is OK but may it be not ideal, because more drivers could require
> > write buffers and instructions memory access order synchronization.
> > We have added that definition to ports/os/rtems/arch/sys_arch.h
> >
> > #ifndef __rtems__
> > static inline sys_prot_t
> > sys_arch_protect(void)
> > {
> >sys_prot_t pval;
> >
> >rtems_interrupt_disable(pval);
> >return pval;
> > }
> >
> > static inline void
> > sys_arch_unprotect(sys_prot_t pval)
> > {
> >rtems_interrupt_enable(pval);
> > }
> >
> > static inline void
> > sys_arch_data_sync_barier(void){
> >_ARM_Data_synchronization_barrier();
> > }
> > #else
> >
> > as the generic solution when to allow same drivers to be used
> > with different architectures. There can be more drivers requiring
> > such protection.
>
> ok, I will keep the sys_arch_data_sync_barier(). What I don't understand
> is why this stuff is under #ifndef __rtems__ (NOT defined __rtems__).

this is more complex, I need to refresh my memory. We have been using
uLAN OMK fork of LwIP code code in system less, RTEMS and FreeRTOS
setup.

On simple setups, as is FreeRTOS, the sys_arch_protect()
and sys_arch_unprotect() enables and disables interrupts

https://gitlab.com/pikron/sw-base/lwip/-/blob/omk-devel/ports/os/freertos/arch/sys_arch.h#L103

The same change has been made done for RTEMS by bulk change

https://gitlab.com/pikron/sw-base/lwip/-/blob/omk-devel/ports/os/rtems/arch/sys_arch.h#L103

But solution with IRQ disable only could not work on SMP system.

https://git.rtems.org/rtems-lwip/tree/uLan/ports/os/rtems/arch/sys_arch.c#n371

There is patch by Kinsey Moore which correct code to be safe for SMP
and switches rtems_interrupt_disable() to 

pval = _Thread_Dispatch_disable();
+  rtems_recursive_mutex_lock( _arch_lock );

https://git.rtems.org/rtems-lwip/commit/uLan/ports/os/rtems/arch/sys_arch.c?id=c3b8ce71c4897be9984e555d8f1042e273edaa35

and later to

rtems_recursive_mutex_lock( _arch_lock );

which are correct if the interrupt is never called directly into LwIP
driver but only through worker thread wakeup.

So in actual header file, the part which is under  #ifndef __rtems__
should read as use interrupt disable on generic system
but on RTEMS define declare functions prototypes and actual
implementation is in os/rtems/arch/sys_arch.c and for case of
use of the drivers over worker thread is correct.

But if I remember well then actual protect mechanism
should be used minimally if the driver uses thread
model..

So generally, the part in #ifndef __rtems__ in header file
can be moved away, the decalartions without functions body
are enough.

We need to resolve license update in the files and get
rid of uLAN directory and I hope that it can be cleaned
up. I would like to test code on TMS570LS3137 when I find
time and on TMS570LC43 one day...

Best wishes,

Pavel


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

Re: [lwip 2/2] Move and rename sys_arch_data_sync_barier()

[Pavel Pisa]

Hello Kinsey and Sebastian,

On Thursday 09 of March 2023 14:46:28 Kinsey Moore wrote:
> Normally with rtems-lwip I would complain that this doesn't follow the
> convention of using #ifdef __rtems__ to modify files from upstream sources
> (each root directory except rtemslwip has an upstream source), but the uLan
> authors have given permission to fully integrate this code into the
> rtemslwip directory where possible (the TI code will go into its own
> directory). This patch looks good.

driver has no upstream, it has been designed for RTEMS and then
used even on FreeRTOS and it except for headers from Ti mainly
used for MDIO, it has been designed from scratch at CTU.
We have originally started and tried to fix Ti HalCoGen
code to work with Ti provided FreeRTOS and it newer worked
reliably. Then we have thrown away all that stuff and started
from scratch with some inspiration from similar BSD drivers.

I have call with Premek and we both agree on relicense to RTEMS
BSD variant. I can prepare commit when I have some while (I am
loaded by lectures, students support now). Next step is to move
code to 

  rtemslwip/tms570

As for

+static inline void
+tms570_data_sync_barier(void)
+{
+#ifdef __arm__
+  _ARM_Data_synchronization_barrier();
+#endif
+}

it is OK but may it be not ideal, because more drivers could require
write buffers and instructions memory access order synchronization.
We have added that definition to ports/os/rtems/arch/sys_arch.h

#ifndef __rtems__
static inline sys_prot_t
sys_arch_protect(void)
{
  sys_prot_t pval;

  rtems_interrupt_disable(pval);
  return pval;
}

static inline void
sys_arch_unprotect(sys_prot_t pval)
{
  rtems_interrupt_enable(pval);
}

static inline void
sys_arch_data_sync_barier(void){
  _ARM_Data_synchronization_barrier();
}
#else

as the generic solution when to allow same drivers to be used
with different architectures. There can be more drivers requiring
such protection.

In the fact tms570_emac is similar or equivalent to some other
ETHERNET NICs, I do not remember which one at the moment, I would
need to search. But I think that I have seen same/similar registers 
organization on other targets.

If I prepare changes of license, should I sent patches
only to the mailing list or should I try to create branch
and try to push it to rtems-lwip or fork some GitHub
matching repo?

...

It seems that my SSH key for pp...@dispatch.rtems.org has
expired?

Best wishes,

Pavel

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

Re: RTEMS LwIP licensing and organization cleanup proposal - actual Ti code license

[Pavel Pisa]

Hello Joel and Gedare 

On Friday 03 of March 2023 14:32:33 Pavel Pisa wrote:
> The RTEMS core integration layer is held in uLan/ports/os/rtems
> subdirectory
>
>   https://git.rtems.org/rtems-lwip/tree/uLan/ports/os/rtems/arch/sys_arch.c
>
> It should be moved somewhere else, i.e. under
>
>   https://git.rtems.org/rtems-lwip/tree/rtemslwip/common
>
...
> To make integration with RTEMS easier, the source should
> be relicensed to some common actual RTEMS license template,
> for example
>
>   https://git.rtems.org/rtems/tree/bsps/arm/lpc176x/start/bspstart.c
>
> We have referenced Swedish Institute of Computer Science license
> there to allow integration even to some official LwIP port
> but except for function and defines names the code is our own
> so RTEMS copyright with reference to implementation inspired by
> other LwIP OS integration should be OK.
>
> I have contacted Premysl Houdek who worked on project during
> his RTEMS GSoC and followup diploma thesis
>
>  
> https://support.dce.felk.cvut.cz/mediawiki/images/f/f1/Dp_2016_houdek_premy
>sl.pdf
>
> and he is prepared to confirm relicensing to any RTEMS fitting
> open source license.
>
> For actual RTEMS LwIP users and contributors, please propose license change
> or chose some of above offers and then propose new files location including
> git patches or I can take that action if
>

So we have right relicense all uLAN OMK remains except for Ti PHY files
and registers for TMS570 EMAC (actual controller driver is ours).
The original Ti files with license to check are there

  
https://git.rtems.org/rtems-lwip/tree/uLan/ports/driver/tms570_emac/ti_drv_emac.h

Best wishes,

Pavel
-- 
Pavel Pisa
phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
company:https://pikron.com/
personal:   http://cmp.felk.cvut.cz/~pisa
projects:   https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
RISC-V education: https://comparch.edu.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: CAN driver implementation for Xilinx Zynq

[Pavel Pisa]

Dear Carlo and others,

On Friday 03 of March 2023 16:03:52 Gedare Bloom wrote:
> On Wed, Mar 1, 2023 at 3:14 AM  wrote:
> > As part of an internship at the German Aerospace Center, I am currently
> > working on the implementation of a CAN driver for a Xilinx Zynq SoC. For
> > this I used the existing CAN framework /dev/can/can.h. A merge request
> > will follow soon.
> >
> >
> > Here's what I'd like to add to the framework if it hasn't already been
> > done:
> >
> > * RxFIFO. Currently can_bus_read only stores the latest CAN message in
> > can_bus->can_rx_msg. There is a FIXME note on this in can.c, line 188,
> > but I couldn't find an implementation of it.
>
> This will be great. Other issues to address in this code base are the
> lack of integration with existing RTEMS functionality. Especially
> helpful would be to add message queue abstraction layer along with
> making a more proper device driver structure. Message queue has the
> advantage that it can take care of handling multiple priorities and
> synchronization, and reduces the code size and maintenance burden.
>
> You can see an interface/implementation like this in:
> https://git.rtems.org/rtems/tree/bsps/powerpc/gen5200/mscan

or look at

  https://sourceforge.net/p/ortcan/lincan/ci/master/tree/

and related documentation

  https://cmp.felk.cvut.cz/~pisa/can/doc/lincandoc-0.3.5.pdf

The actual RTEMS can-msg.h has updated version which is prepared
for CAN FD for future and has been confirmed by me and Oliver Hartkopp 
(Linux SocketCAN author) as fitting well to RTEMS

  https://git.rtems.org/rtems/tree/cpukit/include/dev/can/can-msg.h

I think that concept of queues in LinCAN is right for char driver
CAN drivers and it worth and could be ported to RTEMS easily.

Important question is, if to use CAN specific FIFOs implementation

  
https://sourceforge.net/p/ortcan/lincan/ci/master/tree/lincan/include/can_queue.h

or change it to some RTEMS or POSIX queue. That is main point to decide.
Then porting of LinCAN code to RTEMS is easy a as main contributor,
architecture and mechanism architects etc. I can change license
to BSD 2 clauses for RTEMS. Even actual LinCAN license is GPL2
with linking exception to be compatible with RTEMS from the project
beginning.

By the way, I we have lot of experience with Zynq Zynq 7000 SoCs,
its XCAN and even own CTU CAN FD on it under GNU/Linux

  https://canbus.pages.fel.cvut.cz/

I have tested RTEMS on it in 2017 and with Michal Lenc, my studnet,
we have tested actual RTEMS on it at end of 2022 year for motion control
with TCP/IP.

I can help with advice or even some contributions but important is
decision what should be right implementation and how much effort
and skills would be invested. I have kept my push at low level
during last summer due to my load by other projects and fear, that
if I will demand to high level, then it would be hard to implement
it and may be full LinCAN like solution with multiple open supported,
filtering etc is too complex. But is we can agree on some level
I can help to get to that. I think that porting of LinCAN queues
to RTEMS is easy task and I can try that in my spare time... 

I would really to see future-proof CAN/CAN FD support in RTEMS.
But on the other hand, I have limited resources, no RTEMS
active product at moment, and I understand that others resources
are limited too. But on Zynq, I have easy way to test. We have designed
and delivered 42 education kits using MicroZed to the university
and I have some more produced for myself

   https://cw.fel.cvut.cz/wiki/courses/b35apo/en/documentation/mz_apo/start

Best wishes,

Pavel
 -- 
Pavel Pisa
phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
company:https://pikron.com/
personal:   http://cmp.felk.cvut.cz/~pisa
projects:   https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
RISC-V education: https://comparch.edu.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS LwIP licensing and organization cleanup proposal

[Pavel Pisa]

Dear Premek and other developers,

I am happy that LwIP is getting into state
of viable alternative of TCP/IP stack for
resource constrained RTEMS targets.

But as I have already reported before, I would
be happy if the code licenses and locations are cleanup.

The RTEMS core integration layer is held in uLan/ports/os/rtems
subdirectory

  https://git.rtems.org/rtems-lwip/tree/uLan/ports/os/rtems/arch/sys_arch.c

It should be moved somewhere else, i.e. under

  https://git.rtems.org/rtems-lwip/tree/rtemslwip/common

but for sure the reference to our uLAN project is nonsense in this
content

  https://ulan.sourceforge.net/

even that initial LwIP integration for RTEMS is based on our
previous work in frame of that project for system-less and later
RTEMS use.

To make integration with RTEMS easier, the source should
be relicensed to some common actual RTEMS license template,
for example

  https://git.rtems.org/rtems/tree/bsps/arm/lpc176x/start/bspstart.c

We have referenced Swedish Institute of Computer Science license
there to allow integration even to some official LwIP port
but except for function and defines names the code is our own
so RTEMS copyright with reference to implementation inspired by
other LwIP OS integration should be OK.

I have contacted Premysl Houdek who worked on project during
his RTEMS GSoC and followup diploma thesis

  
https://support.dce.felk.cvut.cz/mediawiki/images/f/f1/Dp_2016_houdek_premysl.pdf

and he is prepared to confirm relicensing to any RTEMS fitting
open source license.

For actual RTEMS LwIP users and contributors, please propose license change
or chose some of above offers and then propose new files location including
git patches or I can take that action if 

Best wishes,

Pavel
-- 
Pavel Píša
phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
company:https://pikron.com/
personal:   http://cmp.felk.cvut.cz/~pisa
projects:   https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
RISC-V education: https://comparch.edu.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: TMS570 OpenOCD Flash Support

[Pavel Pisa]

Dear Devin Stafford

On Friday 18 of November 2022 19:07:13 Devin Stafford wrote:
> Hope all is well. Thank you for providing the patches and documentation for
> the TMS570 flash support. They have been of great help to me.

that is really pleasing for me, that my old effort in TMS570 area
that partially related to my not so open work under old former group
destroying many of my other investments, has found some user.
But pushing project forward to mainlineable state is big effort.
So I send the CC to RTEMS list where somebody other can have some
experience in this area.

I would personally liked to pour my hands or lead studnet, but until
I finish our ESA project, I am sillent even in more heartily projects
related to RTEMS... Sorry...

  https://gitlab.com/pikron/projects/sumintadc/deliverables

I am keeping only RISC-V and teaching based ones to survive.

> I was able to confirm the functionality of the flash support with your
> patches via XDS100v2 using the TMS570L3137 HDK. I am now trying to use a
> Raspberry Pi to connect to the TMS570L3137 HDK from the RPi's GPIO to the
> TMS570L3137 HDK's external JTAG. I am able to find the JTAG Tap, but I get
> the following error message:
> [image: unsuccessful_old_openocd.png]

Great, the given old GDB version worked well even with FTDI based
adapters as I remember. I can send even technological data for our
JT_USB6 version

  https://pikron.com/pages/products/accessories.html

But XDS1000 standalone adapters from TI are not expensive, so that
can be a better/more accessible choice.

> When I use the same wiring setup and use the latest version of OpenOCD (so
> only debug support for the TMS570 and no flash support), I am able to find
> the TAP, examine the target, and receive no errors.  Here is that output:
> [image: successful_openocd.png]

That is great, that mainline supports TMS570 reliably now. There has been 
problem on big-endian R4 to access memory behind EIM (DRAM) in the
older version if I remember well. I have some hack in my patches, I think

  https://cmp.felk.cvut.cz/~pisa/tms570/openocd-patches/

> I have attached a logic analyzer for both instances, and the signals look
> similar for both.
>
> Therefore, I believe it is a software issue and was wondering if you have
> any advice to resolve this issue? I have attached my openocd.cfg file as
> well.

So to recapitulate, you are trying to use old TMS570 GDB
(working with XDS100v2) with raspberrypi-native JTAG interface
and there is a problem.

The first reported problem (on raspberrypi-native) is
Warn: Invalid ACK 0x6 in JTAG-DP transaction
I would expect, that low level JTAG transport is OK,
a correct part is reported, but the target stays in undefined
state probably. You can try to lower interface frequency
or adjust reset timing. I would expect that there can be
problem with incompatible, other default reset configuration
in old GDB for raspberrypi-native.
Try to look into corersponding
  openocd/scripts/interface/raspberrypi-native.cfg
if that doe snot help, then into interface sources.

Try to check what are mapping and options for reset
related section

# bcm2835gpio_trst_num 7
# reset_config trst_only

# bcm2835gpio_srst_num 24
# reset_config srst_only srst_push_pull

# or if you have both connected,
# reset_config trst_and_srst srst_push_pull

when you compare with

openocd/scripts/interface/ftdi/xds100v2.cfg

#
# Texas Instruments XDS100v2
#
# http://processors.wiki.ti.com/index.php/XDS100#XDS100v2_Features
#

interface ftdi
ftdi_vid_pid 0x0403 0xa6d0 0x0403 0x6010

ftdi_layout_init 0x0038 0x597b
ftdi_layout_signal nTRST -data 0x0010
ftdi_layout_signal nSRST -oe 0x0100
ftdi_layout_signal nEMU_EN -data 0x0020
ftdi_layout_signal nEMU0 -data 0x0040
ftdi_layout_signal nEMU1 -data 0x1000
ftdi_layout_signal PWR_RST -data 0x0800
ftdi_layout_signal LOOPBACK -data 0x4000

echo "\nInfo : to use this adapter you MUST add ``init; ftdi_set_signal 
PWR_RST 1; jtag arp_init'' to the end of your config file!\n"

There are configuration of nTRST, nSRST and PWR_RST signals for FTDI.
Check if equivalent signals are configured correctly for raspberrypi-native.
There can be difference between old and new GDB. Check PWR_RST influence.
Putting some enforced reset into raspberrypi-native could help.

Generally, the right direction is to forget about old GDB version
and make current mainline to support Flash on TMS570. But that
could be really huge project.

There are two main problems. My two patches are based on Andrey Smirnov
series which, as I know, did not reached mainline. There is lot of
work there. May it be, there is already equivalent enhancement included,
but it can be on different basis. needs to analyze understand existing
or add missing functionality.

The other problem are actual Flashing algorithm running on TMS570.
The library is available from TI only in a binary (ELF object archive/lib)
form. Distribution such "firmware

Re: Updated CAN message structure.

[Pavel Pisa]

Hello Prashanth S,

On Tuesday 21 of June 2022 19:00:42 Prashanth S wrote:
> This is to present the updated CAN message structure.
>
> *Updating the CAN message structure:*
>
> struct can_message {
>   uint32_t id; // 32 bits to support extended id (29 bits)
>   uint32_t timestamp;
>   uint16_t flags;// RTR | BRS | EXT ...
>   uint16_t len;
>   uint8_t data[64]; // For supporting data transfer up to 64 bytes.
>   };

from my side optimal, no other suggestions.

Best wishes,

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

Re: GSoC 2022 - CAN API test

[Pavel Pisa]

Hello Prashanth S and others,

I am copying reply to the list for recrd and others consideration

On Sunday 19 of June 2022 17:30:16 Christian Mauderer wrote:
> Would that be a generic test for the CAN API that all BSPs can run? Or
> would it be a hardware specific one?

The CAN base test can be HW independent when system is brought
up and CAN interface is configured. Even bitrate and actual
bring up can be target independed if the driver provides
common IOCTL to setup bitrate, sampling point etc. common
way. Only speed has to be changed for for case when transmitter
cannot handle given rate. And for sure you need to know
if the interface is CAN FD capable.

Even for really thorough performance testing of the driver,
it is enough to to implement function which receives each
received frame, decreases CAN ID by one and sends it back.
The ID decrease is required to increase priority of reply
Tx message which ensures that tester flood does not block
the reply.

This test has been used by Jan Charvat during testing
of NuttX ESP32C3 CAN driver testing
https://dspace.cvut.cz/bitstream/handle/10467/101692/F3-DP-2022-Charvat-Jan-NuttX-RTOS-CAN-Bus-Driver-for-Espressif-ESP32C3.pdf
 
You can use Linux kernel based system on the side of the tester
and if the latency tester side provides HW timestamping
then you can retrieve really precise statistic/characteristic
of the HW. I infrastructure has been used in past even to attest
RTEMS CAN driver on MPC5200.

If you have two interfaces, you can forward messages from one
to another and flood system. We have done such testing
for Oliver Hartkopp to attest Linux kernel CAN gateway.

The code has been updated by Matej Vasilevski during his thesis
https://dspace.cvut.cz/bitstream/handle/10467/101450/F3-DP-2022-Vasilevski-Matej-vasilmat.pdf

The other option is to use our old VCA abstraction which
for CAN provides compatability between LinCAN, SocketCAN
and NuttX CAN API and includes canping utility with
master and slave side for throughput testing.

All is part of OrtCAN project

http://ortcan.sourceforge.net/

CAN ping

https://sourceforge.net/p/ortcan/canping/ci/master/tree/

The interfacing to RTEMS API on libVCA side would be easy.
The file to connect library to SocketCAN, LinCAN or NuttX is
singe file, NuttX example

https://sourceforge.net/p/ortcan/ortcan-vca/ci/master/tree/libvca/vca_inuttx.c

So I think there are many options, simple loop to read aceh message
and send it with ID-1 is simple and usesfull step tos tart.

Best wishes,

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

Fwd: Re: Request for feedback for CAN message structure

[Pavel Pisa]

I am forwarding Oliver Hartkopp's founded reply
to the list for archival and rest of the RTEMS
community

--  Forwarded Message  --

Subject: Re: Request for feedback for CAN message structure
Date: Tuesday 21 of June 2022, 08:55:03
From: Oliver Hartkopp 
To: Pavel Pisa , devel@rtems.org
CC: Prashanth S 

Hello all,

I'm definitely with Pavel's suggestions here!

I added some small remarks regarding the current CAN XL discussion in-line:

On 20.06.22 22:57, Pavel Pisa wrote:
> Hello Prashanth S and others,
> 
> excuse me for lower activity last weeks. We have exams period
> and I have lot of other duties and was even ill. I am at Embedded
> World in Nuremberg now, so may it be there is some chance to meet
> somebody other from RTEMS community.
> 
> As for the e-mail it is better to add one of my personal e-mails
> (p...@cmp.felk.cvut.cz or pp...@pikron.com)
> to notice me for something important, I do not check every
> message comming through my list subscription. I go through
> RTEMS, NuttX, CAN, etc. forums only when I have spare time.
> 
> On Monday 20 of June 2022 18:37:38 Prashanth S wrote:
>> This is a request for suggestions and feedback for the CAN message
>> structure.
>>
>> *CAN message structure that represents the can messages from application to
>> driver:*
>>
>> struct can_message {
>> uint32_t timestamp;
>> uint32_t id; // 32 bits to support extended id (29 bits)
>> uint16_t flags;// RTR | BRS | EXT ...
>> uint8_t dlc; // (0 - 8) | 12 | 16 | 20 | 24 | 32 | 48 | 64
>> uint8_t res; // reserved for alignment.
>> uint8_t data[64]; // For supporting data transfer up to 64 bytes.
>> };
>>
>> This is the CAN messages structure created based on the suggestions in the
>> mail chain and looking through other CAN solutions (Nuttx, GRCAN, LinCAN).
> 
> Yes I like solution with explicit and aligned fields.
> I confirm that I think that length representing real data length is better
> and it has been chosen for CAN FD by SocketCAN.

Yes. Handling the DLC/Length conversion in every user program is a mess. 
That's why we actually changed the dlc to len even for Classical CAN 
frames in the struct can_frame:

struct can_frame {
 canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */
 union {
 /* CAN frame payload length in byte (0 .. CAN_MAX_DLEN)
  * was previously named can_dlc so we need to carry that
  * name for legacy support
  */
 __u8 len;
 __u8 can_dlc; /* deprecated */
 } __attribute__((packed)); /* disable padding added in some ABIs */
 __u8 __pad; /* padding */
 __u8 __res0; /* reserved / padding */
 __u8 len8_dlc; /* optional DLC for 8 byte payload length (9 .. 
15) */
 __u8 data[CAN_MAX_DLEN] __attribute__((aligned(8)));
};

You might also think about a union to carry the Classical CAN length and 
the CAN FD length in one 8 bit value and add the extra Classical CAN raw 
DLC in another 8 bit value - and make a union with a 16 bit length value 
which is needed for CAN XL.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/uapi/linux/can.h?id=ea7800565a128c1adafa1791ce80afd6016fe21c

But in fact the raw DLC value has been introduced only because of some 
people doing security testing. The Classical CAN raw DLC value has no 
value for normal CAN applications and therefore using a simple 16 bit 
length value would be the best choice IMHO (see below).

> I confirm that flags implemented with explicit sized field seem to be more
> safe to me. Bitfields are tricky due to endianing and have problem with
> initialization and copying when new field is added.
> 
> I am not sure if the field name "dlc" (data length code) is right
> when the field represents real length, may be "len" is a better
> match.

Yes, definitely!

> I think that fields order makes sense as well (alignment, purpose etc..).
> Only think to consider is possibility to swap
> 
>uint32_t timestamp;
>uint32_t id;
> 
> because id is the first and the most important and accessed field,
> so when the pointer to structure is give it can be small win
> on some targets that it can be accessed without offset addition.
> But that is probably neglectable and there can be arguments against.

The 'id' really defines the CAN frame so it can be seen as a 'key' - 
like in a data base. It makes sense to put it first.

Btw. adding RTR and EXT to the flags field is something I would do today 
too. Good choice!

> Another think to consider is a size of "dlc" and or "len" code.
> There is ongoing standardization process for CAN XL an

Re: Request for feedback for CAN message structure

[Pavel Pisa]

Hello Prashanth S and others,

excuse me for lower activity last weeks. We have exams period
and I have lot of other duties and was even ill. I am at Embedded
World in Nuremberg now, so may it be there is some chance to meet
somebody other from RTEMS community.

As for the e-mail it is better to add one of my personal e-mails
(p...@cmp.felk.cvut.cz or pp...@pikron.com)
to notice me for something important, I do not check every
message comming through my list subscription. I go through
RTEMS, NuttX, CAN, etc. forums only when I have spare time.

On Monday 20 of June 2022 18:37:38 Prashanth S wrote:
> This is a request for suggestions and feedback for the CAN message
> structure.
>
> *CAN message structure that represents the can messages from application to
> driver:*
>
> struct can_message {
> uint32_t timestamp;
> uint32_t id; // 32 bits to support extended id (29 bits)
> uint16_t flags;// RTR | BRS | EXT ...
> uint8_t dlc; // (0 - 8) | 12 | 16 | 20 | 24 | 32 | 48 | 64
> uint8_t res; // reserved for alignment.
> uint8_t data[64]; // For supporting data transfer up to 64 bytes.
> };
>
> This is the CAN messages structure created based on the suggestions in the
> mail chain and looking through other CAN solutions (Nuttx, GRCAN, LinCAN).

Yes I like solution with explicit and aligned fields.
I confirm that I think that length representing real data length is better
and it has been chosen for CAN FD by SocketCAN.

I confirm that flags implemented with explicit sized field seem to be more
safe to me. Bitfields are tricky due to endianing and have problem with 
initialization and copying when new field is added.

I am not sure if the field name "dlc" (data length code) is right
when the field represents real length, may be "len" is a better
match.

I think that fields order makes sense as well (alignment, purpose etc..).
Only think to consider is possibility to swap

  uint32_t timestamp;
  uint32_t id;

because id is the first and the most important and accessed field,
so when the pointer to structure is give it can be small win
on some targets that it can be accessed without offset addition.
But that is probably neglectable and there can be arguments against.

Another think to consider is a size of "dlc" and or "len" code.
There is ongoing standardization process for CAN XL and it
would allow CAN frames up to 2kB and the length will be with
byte granularity. But CAN XL adds datatype filed and much more
options so it is probably out of the actual RTEMS scope
and would require variable length read and write systemcalls
because 2kB overhead for some 1 or 2 byte message is too high.

So even 8 bit length field is OK for now and may be res field
can solve CAN XL compatibility one day.

So generally I agree with the message structure, I declare
minor weight vote to switch from "dlc" to "len".
I think that switch to common message structure based API
on RTEMS would be big win and that (at least for
now) keeping character device like API with IOCTLs
is simpler and matches better actual RTEMS CAN implementations. 

Best wishes,

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

Re: [PATCH rtems-lwip] lwip: Split sources into origin directories

[Pavel Pisa]

Dear Vijay,

On Thursday 02 of June 2022 05:56:56 Vijay Kumar Banerjee wrote:
> I have pushed this patch and I would like to add a note regarding that.

thanks for the work and time.

> This patch started interesting discussions about the possible ways to
> organize code from multiple sources. Pavel also raised an issue with
> the directory name "uLan". Since the repository is still in a personal
> area and still in the development stage, we can make rapid changes to
> the repository. We will change the directory name from uLan to
> something that's more suitable,

please no uLAN it is RS-485 protocol. Yes it has and reuses our sysless
firware base project and uses OOMK build system which we use
for build of GNU/Linux, sysless, RTEMS, NuttX and even Windows
applications. Because I used our port of LwIP which uses OMK
build to test it in RTEMS I have named it lwip-omk and because
we use the code in our instruments firmware which use OMK build,
sysless and often uLAN protocol it ended in the repo under
uLAN project.

https://sourceforge.net/p/ulan/lwip-omk/ci/omk-devel/tree/

But using this project name in the case where
OMK buid system is unwanted, there is nor RS-485 connection
and no use of other libraries and bare metal support from
that PiKRON project is so misleading, that I have to insist
to not use uLAN label...

I suggest to have only ports directory at the rtems-lwip
toplevel. We should go through the process to relicense
all (where we are authors or where we can contact author)
to RTEMS mainline acceptable licence. If there is some problematic
driver then it stays in 

  ports/driver/driver_name

directory so it will be separated and license precisely defined
in that directory.

I still see in the driers base only our own tms570_emac.
So what is the plan for integrating others?

It would be great to have there at least two working
ports because then it will be seen how to select them
on the build system level.

Thanks for updating project documentation

https://devel.rtems.org/wiki/Packages/LWIP

There is another task to solve. In the OMK build,
there has been made possible to configure the most
of the LwIP options from the project top level
config.omk and config.target. It should be considered,
how buffers size, count and many other featires will
be configured in actual RSB build. Problem is that
LwIP on targets with little memory (it worked on
256 kB TMS570LS3137) and on the other hand configuration
for some bigger systems as is  Gaisler GR740 or somethink
NOEL-V based can be significantly different when
megabytes of RAM can be used.

By the way, I am presenting at

9th International Workshop on Analogue and Mixed-Signal
Integrated Circuits for Space Applications
https://indico.esa.int/event/388/

and I have met there people from TTTech
and they can have interrest to try RTEMS
even on their TTEthernet space ASIC
internal Leon 2 core. But it is memory
constrained environment so for TCP/IP non-real time
traffic they most probably cannot use BSD stack,
so LwIP + RTEMS can be the option there.

But it is necessary to put project into some
reusable shape. Unfortunately I do not have
time to work on it some intensive way now
and I do not know RSB stuff enough.

On the other hand, if they express real interest,
I can try, if I am able attract some students
from our universitywho can work on the project.
I invest a lot to pass knowledge for their serious
work in this area.

By the way, we have switched our Computer Architectures
course to RISC-V in this run

  https://cw.fel.cvut.cz/wiki/courses/b35apo/en/start

including simulator

  https://github.com/cvut/qtrvsim

and public recording (even English, sorry Czenglish)

  https://www.youtube.com/playlist?list=PLQL6z4JeTTQnTrML7HgagbjdpCtvdyu0M

Best wishes,

Pavel Pisa

==
 PiKRON s.r.o.   Phone/Fax: +420 284684676
 Kankovskeho 1235Phone: +420 234697622
 182 00 Praha 8  WWW:   http://www.pikron.com/
 Czech Republic  e-mail:  pik...@pikron.com
==
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Last call for Mentors

[Pavel Pisa]

On Friday 22 of April 2022 23:21:29 Pavel Pisa wrote:
> Hello Gedare,

Excuse me for spamming the list.
I hit send witout checking that
reply to author filled list address
but not to him directly.

Anyway nothing secret in the email.

Nice weekend to all,

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

Re: Last call for Mentors

[Pavel Pisa]

Hello Gedare,

On Wednesday 20 of April 2022 00:29:57 Gedare Bloom wrote:
> If you're interested in potentially mentoring/co-mentoring in GSOC,
> please let me/Joel/Chris know so you can be invited. We're now
> ranking/selecting proposed projects and need to match mentors.

I have offered mentoring to NuttX (which is under Apache foundation
umbrella) this year but it seems that there is no proposal
connected to NuttX at the end.

As for the RTEMS, I would be happy if the there are valuable
contributions. I can offer some help in CAN area and Cortex-R5
for QEMU.

So if you want then invite me as a (co-)mentor
and I help with proposals rating discussion.
I cannot promise to be main mentor because we are
far behind deadline with our ESA project and other
critical stuff. But even if not part of the official
GSoC, I would be happy to provide some opinion
and feedback. But send me notice/CC/FWD when my
reply could be usesfull. I am not capable to read
all RTEMS devel messages.

As for the CAN, driver for CTU CAN FD IP core,
we are hopefully on the way to Linux mainline
as a 5.19 material. So if all goes well it can
be part of mainline around October

  
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/log/?qt=grep=CTU+CAN+FD

But maintainers requests and keeping this and other
projects going would take me a lot of time as well.

In the pysimCoder area https://github.com/robertobucher/pysimCoder ,
we have extended it that blocks parameters can be tuned
through https://github.com/silicon-heaven protocol
at runtime. So even that it is on one side children
toy when compared to Matlab/Simulink, it has nice
features. It targets Linux, NuttX ad some bare metals.
Add RTEMS would be easy as well.

I have updated QtRvSim today so even Windows binaries
are current. We still do not have converted exceptions
model but initial steps to name CSR registers
according to RISC-V notations has been done.
I have studied RISC-V exception model to describe
it to studnets during previous week lecture

  https://cw.fel.cvut.cz/wiki/courses/b35apo/en/lectures/09/start

so I should already know enough to try to write it
to the simulator...

Best wishes,

Pavel

--
    Pavel Pisa
phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
personal:   http://cmp.felk.cvut.cz/~pisa
projects:   https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home

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

Re: Project Ideas - Basic RTEMS BSP for Cortex-R5 on Qemu

[Pavel Pisa]

Hello Kamlesh,

On Tuesday 19 of April 2022 16:30:25 Kamlesh Bharodiya wrote:
> I was afk for the last two days. As the deadline is already here. I have
> submitted the proposal after reviewing your comments from the mail. Thank
> you for taking the time out. Thanks to Noor Aman and Gedare, I have gone
> through the comments and have incorporated your suggestions in the
> proposal. Will continue in discord group.

Thanks for the submitting proposal. It looks reasonable and realistic
from my side.

Best wishes,

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

Re: Project Ideas - Basic RTEMS BSP for Cortex-R5 on Qemu

[Pavel Pisa]

Hello Alan and Kamlesh,

On Sunday 17 of April 2022 18:18:03 Alan Cudmore wrote:
> The R5 basic BSP is needed by the RTEMS community. If you get through that,
> you could look at the Xilinx code for interacting with it.
>  
> Is the Xilinx R5 QEMU support generic enough for a basic BSP? Or could it
> be factored in a way that supports non-xilinx BSPs? I would not mind seeing
> a R5 BSP for the Xilinx MPSoC UltraScale+ since RTEMS has support for the
> A53 now. I thought others on this list might have already created an R5
> BSP. It looks like the Zephyr RTOS supports the Xilinx R5 QEMU model.
> https://docs.zephyrproject.org/latest/boards/arm/qemu_cortex_r5/doc/index.h
>tml The Timer and UART are Xilinx specific.
> https://github.com/zephyrproject-rtos/zephyr/tree/main/boards/arm/qemu_cort
>ex_r5 
> Other than the Xilinx UltraScale+, I see there are TI AM243x processors,
> but are there any other R5 processors available?

As I have already reported that I have TMDX570LC43HDK at home.
There is even Hi-Rel version of the used TMS570LC4357-EP.
Gedare has some smaller boards with these chips as well.
I know and have located again that there are industrial
equivalents RM57L843 and RM48L740. RM are usually little
endian, all TMS570 I have met are big endian.

As I have reported already

On Saturday 16 of April 2022 16:11:02 Pavel Pisa wrote:
> As I know, the Cortex-R5 core is already supported
> by RTEMS and our TMS570LS3137 BSP has been used
> with TMS570LC4357 chips by Frankfurt University
>
>   https://www.rz.uni-frankfurt.de/65100666/dcs
>
> Relevant repository
>
>   https://github.com/jalmito/rtems
>
> It would worth to get mainline TMS570 BSP compatible with
> both chips.

I have not time to work or test that target, nor I have some
project now and I will be quite busy next months so do not
expect major contribution.

But I would be happy if the development moves forward.

But in the fact it would worth to start by QEMU
support the first and it would take whole GSoC
probably.

TI AM243x seems to be interesting from this respect
by possible high simmilarty to BeagleBone AM335x
so probably more peripherals in QEMU could be reused...

Anyway, Kamlesh Bharodiya idea to try R5 on Xilinx MPSoC
which has QEMU support seems to be reasonable start
direction. I have enticed that he has written somewhere
notice that he has some experience with Cortex-R4.
Is my understanding correct? If you have some personal
or company working on some project on this target
than it is even better.

Best wishes,

Pavel
--
Pavel Pisa
phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
    company:https://www.pikron.com/
personal:   http://cmp.felk.cvut.cz/~pisa
projects:   https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home

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

Re: Project Ideas - Basic RTEMS BSP for Cortex-R5 on Qemu

[Pavel Pisa]

Dear Kamlesh,

On Sunday 17 of April 2022 10:19:01 Kamlesh Bharodiya wrote:
> Thanks for your mail. I have not worked on ZCU102. Though, I'm working with
> R4F currently. Shall I go ahead with the GSoC application? Or should I wait
> for any other mentor to reply ?

I do not feel competent to be main mentor for this project
and some feedback from people working on RTEMS core
would be helpfull. But I expect that most are on Easters
now so the time to submission deadline is relatively tight.

I am not sure if somebody else see potential to use RTEMS or Cortex-R5
integrated into ZCU102. I see it in general but do not see any
such project on my horizon university work nor company projects
horizon. I have actually neither project with TMS570LC4357,
but I have at least HW and it could be nice platform to test
RTEMS CAN support if it is updated during this year another GSoC
and interesting platform for LwIP testing... But there is no
QEMU support and I do not suggest to change your project to this
direction. 

As I have checked, it seems that it is possible to use ZCU102 R5
somehow with local UART and timer so it makes project initial
phases as feasible in the GSoC frame. Do you plan project as
the longer or shorter GSoC variant?

I suggest to apply before submission deadline even if the
project is not fully clarified before deadline. It will
be discussed by RTEMS mentors and can be slightly adjusted,
extended before coding phase to match core team vision.
Other option is to select another open topic which is on
the RTEMS project interest list

  https://devel.rtems.org/wiki/Developer/OpenProjects

But if you have already some experience with Cortex-R4
and see some real application use for your work then
the goal has reason.

You wrote in your proposal

  Testing R4 BSP on Qemu - but I think that there is no such
 available target for now

As for the timeline, I suggest to move testing and familiarization
with RTEMS and QEMU ecosystem into bonding period and start real
coding with start of GSoC coding period to have something to
to evaluate and running in the middle

   Testing R4 BSP on Qemu, and few other BSPs on Qemu like STM32 BSP
   to get familiarize myself with machines on Qemu

Because if you finish work only after the second half then there
is not enough time for review, clean up, documentation and adjustment
for mainline submission. Expect two or three round for it and
this should be real goal of GSoC and real evaluation.
So I suggest move more coding to the first half and some reserve
and documention and review process to the second half.

Best wishes,

Pavel

> On Sat, 16 Apr, 2022, 7:41 pm Pavel Pisa,  wrote:
> > Dear Kamlesh,
> >
> > On Friday 15 of April 2022 06:50:44 Kamlesh Bharodiya wrote:
> > > I am looking for mentors for my project. How can I connect to
> > > interested mentors? I have uploaded the draft proposal on GSoC tracking
> > > page.
> >
> > I have long time interrest in RTEMS running on TMS570LC4357
> > which is Arm Cortex-R5F based. I have TMDX570LC43HDK at home
> > and some smaller boards are at Elktroline.cz.
> >
> > As I know, the Cortex-R5 core is already supported
> > by RTEMS and our TMS570LS3137 BSP has been used
> > with TMS570LC4357 chips by Frankfurt University
> >
> >   https://www.rz.uni-frankfurt.de/65100666/dcs
> >
> > Relevant repository
> >
> >   https://github.com/jalmito/rtems
> >
> > It would worth to get mainline TMS570 BSP compatible with
> > both chips.
> >
> > But back to your project, possibility to run RTEMS on Cortex-R5
> > architecture in QEMU would be usesfull for testing. My search through
> > actual QEMU sources confirms Cortex-R support and only in  Cortex-R5
> > and Cortex-R52 variants and only integration on ZCU102.
> > But support of Cortex-R5 comprocessor on "big" Xilinx platforms
> > can be usesfull. I have helped with bought of these boards
> > years ago but for the team which moved away. But I probably
> > can find even somebody with HW who could test the code.
> >
> > The minimal set of the peripherals supported to make port
> > usable and living needs to include GIC (generic interrupt controller),
> > TTC (system timer) and UART (serial port).
> > Other option is some mailbox based exchange with main Cortex-A CPU.
> >
> > Have you some experience with ZCU102?
> > I have no much idea how difficult the project is...
> >
> > I can help as co-mentor, I cannot offer main mentor role
> > because I have too many running projects.
> >
> > I CC to Sebastian Huber, because if I remember well they
> > have provided support for some Cortex-R5 platform already.
> >
> > Best wishes,
> >
> >     Pavel Pisa
> >

Re: [PATCH rtems-lwip] lwip: Split sources into origin directories

[Pavel Pisa]

Hello Joel,

On Saturday 16 of April 2022 17:26:02 Joel Sherrill wrote:
> On Sat, Apr 16, 2022, 9:54 AM Pavel Pisa  wrote:
> > On Thursday 14 of April 2022 22:08:00 Vijay Kumar Banerjee wrote:
> > >  rename {lwip => uLan}/ports/os/lwipopts.h (100%)
> > >
> > > >  rename {lwip => uLan}/ports/os/rtems/arch/cc.h (100%)
> > > >  rename {lwip => uLan}/ports/os/rtems/arch/perf.h (100%)
> > > >  rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.c (100%)
> > > >  rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.h (100%)
>
> Ok. Any suggestions for a directory name? :)

I am not in the full sync and I have lost the tracks where
are all RTEMS LwIP repo copies.

Do we speak about https://git.rtems.org/vijay/rtems-lwip.git ?

If it is that way then LwIP uses practice to put integration
stuff into "ports" directory so I would leave the structure
under LwIP as it is

  ports/os/rtems/arch/sys_arch.c

Or if you want to somehow separate sources into more repos
then possible but would complicate keep the drivers and targets
in a sync in future.  I am losing tracks of the build tools etc...
I hope that when it settles the simple instructions
would be added on the integration page

  https://devel.rtems.org/wiki/Packages/LWIP

If you need to move ports/os/rtems/arch/sys_arch.c under some directory,
then it should be something like

  rtems-support/ports/os/rtems/arch/sys_arch.c

if the code can be used over all RTEMS targets. Which should be
a goal anyway and I have initiated it such way years ago.
But I am not sure why to not let code in the actual
lwip/ports/drivers together as well. I see that
in devel branch is the most of our TMS570 code wiped
out... hmm.. why. There is

 lwip/ports/drivers/bbb

this location seems to me as OK.
In the suggested changes is

{lwip/ports/drivers => uLan/ports/driver/tms570_emac}/phy_dp83848h.c

I agree with move of all TMS570 specific code under

  /ports/driver/tms570_emac

Again if all these shuffles are done only for some license changes
I would prefer to be noticed and I think that I would not be blocked
by any of my former studnets nor the faculty to relicense code.
I would inform the faculty (where I am only left from former group,
where I have lead part of this development, part was at my company)
as well as students.

I would prefer if real developer names who invested time into work
are included at least as Authors in the files but the copyright can
be moved to RTEMS foundation or whatever.

But as I have said I have lost track and hope that stuff will survive
in some form till the time when I have some free time or studnet
to work on the project as his/her theses, GSoC etc...
I have used the code with external OMK make, I agree that this
is not right way forward but I wait for outcome of these who
have more experience with RSB and related tools and propose
integration. 

Best wishes,

Pavel

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

Re: [PATCH rtems-lwip] lwip: Split sources into origin directories

[Pavel Pisa]

Hi Vijay and Kinsey,

I monitor from distance LwIP for RTEMS progress and I am happy
for that and when the code settles and I find a time,
I try to test it with TMS570. But I have notices next moves

On Thursday 14 of April 2022 22:08:00 Vijay Kumar Banerjee wrote:
>  rename {lwip => uLan}/ports/os/lwipopts.h (100%)
>
> >  rename {lwip => uLan}/ports/os/rtems/arch/cc.h (100%)
> >  rename {lwip => uLan}/ports/os/rtems/arch/perf.h (100%)
> >  rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.c (100%)
> >  rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.h (100%)

please do not use uLAN for directory name inside LwIP.
uLAN is our RS-485 communication protocol project
and it includes sysless (bare hardware integration layer)
as well as others for RTEMS, NuttX, GNU/Linux.
And LwIP is used as subproject inside our larger projects.
Yes, project is used as base for more our project even
unrelated to RS-485 but that is historical relict
and should not propagate into RTEMS.

But there is no reason to keep uLAN in the name.
These parts which I have written myself or has been
writtent by Roman Bartosinski under my company
(PiKRON) and colleague Alvat.cz funding acan be
relicensed under any RTEMS compatible preferred license.
Only me and Roman needs to agree on that and I do not
see that as a problem. So do not put there uLAN name.
This RTEMS specific integration should stay in some
RTEMS specific LwIP subdirectory or can be even included
into RTEMS mainline. But please, do not add there uLAN
name nor OMK (our makesystem abbreviation).

Best wishes,

    Pavel
--
Pavel Pisa
phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
company:https://www.pikron.com/
personal:   http://cmp.felk.cvut.cz/~pisa
projects:   https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home

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

Re: GSoC - CAN driver for BBB Was: CAN Options and Licensing, Testing, etc

[Pavel Pisa]

Hello Prashanth,

On Thursday 14 of April 2022 20:20:45 Prashanth S wrote:
> This is to summarize the things suggested from the discussions and clarify
> on CAN generic APIs.
>
> Things on the plate:
>
>- CAN driver for BBB.
OK
>- CAN driver for any one of the QEMU supported SoC (SJA1000 on PCI/e on
>x86, Zynq UltraScale+ MPSo on QEMU).
usesfull for testing
>- Generic CAN APIs
yes
>- ADC driver (not using libbsd) for BBB.

it is my opinion, may it be somebody else should express his/her
from other perspective.

> Please correct me if I missed out anything.

> Query on CAN generic APIs:
> With my understanding on the discussions, Should I use the mentioned stacks
> (LinCAN, CANOpen) as reference
CANopen is higher layer, not relevant for the low level code and should
be possible to build above any of the drivers.
LinCAN not strict, may be only some inspiration
> and define the data structures (CAN message header and CAN message
> structures) or port one of the stacks (In case port one of the stacks is
> the right option:
I would suggest to go through CAN message structures of the existing
projects and use one of them or define one which is easy to use
and port. I would help. I do not suggest unsigned long for ID as it is
in LiNCAN for example. I suggest uint32_t. 
> From the suggestions given in the discussions, I could not conclude which
> stack to choose, Considering the future Scalability (both software stack
> and CAN protocol features) and portability) to RTEMS.
The minimal driver can be directly based on MPC5200 direct use
of rtems_message_queue(s), one for Rx and one for Tx

  https://git.rtems.org/rtems/tree/bsps/powerpc/gen5200/mscan

Its message format there

  https://git.rtems.org/rtems/tree/bsps/powerpc/gen5200/include/bsp/mscan.h

Again problematic uint16_t mess_id; which prevents compatability
with extended message format.

I suggest some single bigger unsigned type used with masks for RTR,
EXT and futire BRS and CAN FD flags, flags.

uint8_t  mess_rtr; is not extensible.

It would be great to find if somebody is actually using MPC5200 RTEMS BSP
still and in such case negotiate changes with them. May it be GrLib
unification could be usesfull as well.

I look at

https://git.rtems.org/rtems/tree/bsps/include/grlib/grcan.h#n133

/* CAN-FD MESSAGE */
typedef struct {
uint8_t extended; /* 1= Extended Frame (29-bit id), 0= STD Frame 
(11-bit id) */
uint8_t rtr;  /* RTR - Remote Transmission Request */
uint8_t fdopts;   /* Bit1: 1=Switch bit rate. bit2: 1=FD frame. */
uint8_t len;  /* 0-8, 12, 16, 20, 24, 32, 48 or 64 bytes */
uint32_t id;
union {
uint64_t dwords[8]; /* up to 64 bytes if FD=1 and len>8 */
uint8_t  bytes[64]; /* up to 64 bytes if FD=1 and len>8 */
} data;
} CANFDMsg;

This messageformat look acceptable. The first uint8_t forms in the fact
aligned unit32_t. I would personally put extended, rtr and fdopts
into single masked integer, but this is acceptable. Missing is space
for 16-bit or better at least 32-bit timestamp.

As for the infrastructure/stack, I would prefer to prepare code
for multiple prioritized queues and LinCAN and SocketCAN
provides. But as I have mentioned simple RTEMS queues can be used
for initial proof and change later to something with more
functions would not be problem if API is designed such way,
that it does not need to be changed. 

I offer co-mentor role or possibly even mentor but I would not have
time over whole summer and I have quite lot to do till semester end,
so I can have week or two delay... not ideal for main mentor.

Best wishes,
Pavel
--
Pavel Pisa
phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
company:    https://www.pikron.com/
personal:   http://cmp.felk.cvut.cz/~pisa
projects:   https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Project Ideas - Basic RTEMS BSP for Cortex-R5 on Qemu

[Pavel Pisa]

Dear Kamlesh,

On Friday 15 of April 2022 06:50:44 Kamlesh Bharodiya wrote:
> I am looking for mentors for my project. How can I connect to interested
> mentors? I have uploaded the draft proposal on GSoC tracking page.

I have long time interrest in RTEMS running on TMS570LC4357
which is Arm Cortex-R5F based. I have TMDX570LC43HDK at home
and some smaller boards are at Elktroline.cz.

As I know, the Cortex-R5 core is already supported
by RTEMS and our TMS570LS3137 BSP has been used
with TMS570LC4357 chips by Frankfurt University

  https://www.rz.uni-frankfurt.de/65100666/dcs

Relevant repository

  https://github.com/jalmito/rtems

It would worth to get mainline TMS570 BSP compatible with
both chips.

But back to your project, possibility to run RTEMS on Cortex-R5
architecture in QEMU would be usesfull for testing. My search through
actual QEMU sources confirms Cortex-R support and only in  Cortex-R5
and Cortex-R52 variants and only integration on ZCU102.
But support of Cortex-R5 comprocessor on "big" Xilinx platforms
can be usesfull. I have helped with bought of these boards
years ago but for the team which moved away. But I probably
can find even somebody with HW who could test the code.

The minimal set of the peripherals supported to make port
usable and living needs to include GIC (generic interrupt controller),
TTC (system timer) and UART (serial port).
Other option is some mailbox based exchange with main Cortex-A CPU.

Have you some experience with ZCU102?
I have no much idea how difficult the project is...

I can help as co-mentor, I cannot offer main mentor role
because I have too many running projects. 

I CC to Sebastian Huber, because if I remember well they
have provided support for some Cortex-R5 platform already.

Best wishes,

    Pavel Pisa
phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
company:https://www.pikron.com/
personal:   http://cmp.felk.cvut.cz/~pisa
projects:   https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: CAN Options and Licensing, Testing, etc

[Pavel Pisa]

Dear Prashanth,

On Wednesday 13 of April 2022 04:32:45 Prashanth S wrote:
> Have you determined how you will test CAN on BBB?
>
> I planned to test the CAN driver with another BBB running linux. And if CAN
> analyzer is economical then I would use that.

I think that testing against Linux kernel is good
option. AM3358 has to CAN controllers so if you can
find pin mux combination to connect CAN transceivers
to both then you can test and load/flood them directly
by the board. So I agree with this as a good environment
for development.

The BBB is probably relatively accessible for others too.

But if you would fit with writing/porting driver
for some other CAN interface which is available
under QEMU it would be great. I.e. SJA1000 on PCI/e
on x86 and may be some other target or  Zynq UltraScale+
MPSo on QEMU it would be nice to have ability to test
driver by everybody and writing at least one other to BBB
would help to define API which would fit more targets better
even in future.

Other option is to add writing BBB CAn controller support
for QEMU, but I think that it would be too much load.

I suggest to focus mainly on CAN anyway and left ADC as
optional task if the time remains...

When RTEMS has reasonable CAN API it would be big GSoC
achievement.

Best wishes,

Pavel

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

Re: CAN Options and Licensing, Testing, etc

[Pavel Pisa]

nfrastructure which has been tested
on Linux LinCAN then SocketCAN API and I have running it even
on NuttX above its character driver API.

http://ortcan.sourceforge.net/vca/

https://cmp.felk.cvut.cz/~pisa/can/doc/ocera-canopen-ug.pdf

But the code would need to be extended with CANopen FD support.
I have been in invited academic guest position at the CANopen
FD standard SIG group meetings and even proposed some minor
tweaks. So I have some background knowledge to help there.
Our university is CiA member so we have access to all
info and I have preliminary standard copies which can be
probably shared with people cooperating with us.
But it is large amount of work which would worth more
people and better funding.

Best wishes,

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

Re: CAN driver message structure

[Pavel Pisa]

Hello Prashanth, Karel and Gedare,

On Tuesday 12 of April 2022 08:50:04 Karel Gardas wrote:
> not sure about others but Pavel Pisa is CAN expert here. CCing him
> directly as I've not seen him active recently.

Thanks for poke. I am subscribed on RTEMS devel (and many more lists)
but I am not capable to read all the messages so they are automatically
routed to the related folder.

As for the actual project proposal, I have already got notice
from Gedare and I have read it.

I have been driving force behind attempt to provide common
CAN drivers API for the Linux kernel

  http://ortcan.sourceforge.net/lincan/

but then thanks to cooperation of Volswagen and Pengutronix
SocketCAN API has been developed and only small remnants
of LinCAN has been reused.

As for the APIs, SocketCAN API is much more rich and user
friendly than characted driver LinCAN and others APIs.

On the other hand SocketCAN API is based on SKB infrastructure
and complete networking stack of Linux the kernel and this
stack is still not real-time/low latency capable even on
fully-preemptive Linux kernel variant.

We have done more analyses in cooperation with Oliver Hartkopp
from Volswagen

  https://static.lwn.net/images/conf/rtlws11/papers/proc/p30.pdf
  https://static.lwn.net/images/conf/rtlws-2011/proc/Sojka.pdf

The Linux kernel situation is better now but still not optimal
for demanding real-time CAN bus use.

In the case of RTEMS, using socket interface would even bind
driver to actually used external TCP/IP stack and BSD one
is problematic for smaller MCUs where CAN is really appropriate
choice.

I have proposed to port LinCAN to RTEMS many years ago.
But because no common testing environment has been found,
it has been decided that such tool has to be provided the first
and RTEMS donated GSoC slot to QEMU

  https://devel.rtems.org/wiki/Developer/Simulators/QEMU/CANEmulation
  https://www.qemu.org/docs/master/system/devices/can.html

After years of my further investments, the GSoC result has been
accepted into QEMU mainline and one of my bachelor studnets
implemented even CAN FD extension and support for our open source
CTU CAN FD IP core

  https://canbus.pages.fel.cvut.cz/

Xilinx used this base to include emulation of their CAN FD controllers
into QEMU.

We have invested into CAN bus support in NuttX in the last years.
NuttX provided character device API. See struct can_hdr_s
and struct can_msg_s

  https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/can/can.h

It has options for finegrained tuning of its size according to the required
capabilities. It has sense for memory really constrained MCUs,
but RTEMS targets little bigger ones and variability is a problem
on the user and driver codes which as to put too many lines
under different ifdefs. So I would chose single head format
for all variants. Differentiate CAN_MAXDATALEN worth because
24 unused bytes overhead for each CAN message is large for
really small MCUs with CAN only support of application.

There was attempt to provide even SocketCAN API on NuttX
which would be attractive to build portable applications
for both GNU/Linux and NuttX. The initial attempt has been
done for S32 by Peter van der Perk from NXP. When we
looked for MCU for Elektroline.cz applications we have choosen
imxRT the first and my student Michal Lenc has ported and extended
SocketCAN NuttX driver to imxRT 

https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/imxrt/imxrt_flexcan.c

May problems has been corrected and it is running for year on
non safety NuttX based monitoring part of the resonant track circuit
electronic unit prototype. But I do not have good feeling about
mapping of this driver into NuttX TCP/IP stack infrastructure
and it makes driver quite complex... Later we proposed Elektroline.cz
to move focus on SAMV7/SAME70 MCUs due to total incapability of NXP
representants to provide their suggested S32 chip in shorter than years
frame. In this case we have used  Gregory Nut's already provided
MCAN CAN driver and enhanced it for CAN FD and new core revision.
The most CAN drivers n NuttX are based on this character driver
API and at least in the NuttX case and actual development status
I have much better feeling about robustness and RT capabilities
of this solution.

> If you are going to write CAN driver, then you first need to interface
> with the physical hardware which may expect data push to it and pulled
> from it in a certain format. That is probably the reason why you see
> different CAN message formats spread over RTEMS tree.

Yes and it is bad from application point of view. Unfortunately,
there exists more integrated CAN drivers for RTEMS with many different
origins. Probably GRlib is the one really used and tested.

But situation is really suboptimal. I have proposed for RTEMS
to try use and unify support on many years ago (may it be even
before SocketCAN existence), but have never RTEMS project
which could pay at least some my stu

Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition

[Pavel Pisa]

Hello Joel,

On Thursday 22 of July 2021 22:19:21 Joel Sherrill wrote:
> On Thu, Jul 22, 2021 at 12:25 PM Robin Müller  > 
> The current version of the rtems-lwip support after I added STM32H7 can
> > still be found here:
> > https://github.com/rmspacefish/rtems-lwip/tree/mueller/master and
> > includes the TMS570 code as well.
> >
> > There is also a LPC port here:
> > https://github.com/sacha23/lwip-rtems-support/tree/master/src/ports/drive
> >r/lpc_emac But that one still appears to use Makefiles, and needs to be
> > updated to waf if it is integrated.
>
> Very nice. Updating to waf should be a lot easier than writing the driver.
> :)
>
> Vijay.. it's your call but if adding drivers with status of "compile
> only" is OK with you, that at least lays the groundwork for someone
> else to test later. I'm just thinking that compiles and untested makes
> it easy for someone to push it across the goal line.

That is surprise, I forgot that port of our sysless LPC driver to RTEMS
exists. The code in sysless mode is used by Alvat company http://alvat.cz/
(founded by our alumni Pavel Nemecek ) to provide Pick to Light system
gateway and embedded web on LPC. Our robotic control systems LX_RoCoN
use it in daily operation in selfbuild interferometer of Czech Academy
of Sciences aspherical lens production etc. So the core of the driver
should be functional. I have newer used it on RTEMS but I have
there LX_RoCoN running on table before me exactly now. Not
with RTEMS, but I have tested RTEMS on it, so I can give it
a try if I learn again WAF stuff.

I am adding Roman Bartosnsky to CC, he is main author
of LPC driver and LwIP OMK port done under my company
funding and then on some Alvat budget. He woks on more
ESA projects at his company https://www.daiteq.com/ ,
an actual one is NOEL-V related. He worked with me for years
on our RTEMS based medical infusion systems, so he knew
RTEMS and CPU architectures well.

So there are people who have strong insight into the code.
So if it has been located again it would worth to collect
in on one place. We have some enhancements of the LPC
driver in our OMK repo, so we can merge updates.
I expect that they do not collide with changes for
RTEMS build.

Best wishes, 

Pavel Pisa

==
 PiKRON s.r.o.   Phone/Fax: +420 284684676
 Kankovskeho 1235Phone: +420 234697622
 182 00 Praha 8  WWW:   http://www.pikron.com/
 Czech Republic  e-mail:  pik...@pikron.com
==
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition

[Pavel Pisa]

Hello Vijay,

thanks of the status.

On Wednesday 21 of July 2021 07:16:51 Vijay Kumar Banerjee wrote:
> Hi Pavel,
>
> On Tue, Jul 20, 2021 at 1:13 PM Pavel Pisa  wrote:
> > Is it devel branch of  Vijay Kumar Banerjee's
> > repo
> >
> >   https://git.rtems.org/vijay/rtems-lwip.git/
>
> Right now yes. Once this is mature, it will probably be pushed to the
> top directory.
>
> > If so, it would worth to put that on the top
> > of LwIP RTEMS info page to guide people interested
> > to live work and not lose time in another
> > abandonned attempts
> >
> >   https://devel.rtems.org/wiki/Packages/LWIP
>
> Thanks, I'll add a note there.
>
> > Addition of pointers to STM WIP to some
> > central place would worth too with
> > pointer to the instructions or instructions
> > included...
>
> I haven't tested it myself. Robin is working on this one and might be
> able to add the instructions. But this is supposed to be merged into
> the repo you mentioned above.

Great that there is the common merge place.


> > Generally I am curious what works and where
> > are problems. I do not expect to have time or
> > find students this summer but I try to offer
> > project as theses and next summer and there
> > chance (small) that I find some studnet
> > to participate.
>
> I am currently actively working on the lwip port to get it working
> with at least a few boards, along with a streamlined build system. I
> could only get the BBB running with a telnetd application that I added
> in the test/ directory in the rtems-lwip repository. I used the
> drivers from TI for BBB.

OK, I have some access to BBB so when my or some studnet
time allows we can test it on this target.
I am more personally interested to TMS570.
I think that I can find some time for testing on TMS570LS3137
if the instructions and code is declared to worth to test.
I hope that I have all tools for this setup.

=
Side note to TMS570 FEE CTU code (if there is interest,
I it would worth to move to separate thread)

By the way, the way my former colleagues who left faculty
stopped blocking (after many years) TMS570 Rapid Prototyping
Platform code
  http://rtime.felk.cvut.cz/rpp-tms570/
and changed master branch license to MIT (The work has been
exploited to gain money from their industrial partners and has
little value for them now). Code was and is licensed under our
faculty name and I can legally show it to third parties now
and  try to find arrangement to share my and my students effort
with community.

There is XCP https://en.wikipedia.org/wiki/XCP_(protocol)
loader implemented on FreeRTOS base which allows to update
firmware over ETHERNET so it can be used as boot block for
RTEMS. It can make RTEMS support testing and even continuous
integration much easier. When RTEMS is run from SDRAM it
would prevent Flash wear-out, important for TMS570,
because guaranteed erase cycles are limited.

Then there is support for lot of the TMS570 peripherals
in the state twisted with HalCoGen, not directly usable,
but valuable as reference. Lot of Matlab/Simulink glue
which can be reused with minimal changes and  N2HET and
DMA based "HW" implementation of time triggered CAN
transfers with clock scaling and synchronization.

So if there is interest, I can provide more information
and collect it in RTEMS Wiki or on 

  Open Technologies Research Education and Exchange Services
  https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home

pages, which are intended primarily for cooperation with
our students.

As for original RTIME wiki and documentation (even documenting
RTEMS and GNU/Linux work shared from my company, done with studnets,
myself at home), I do not expect to contribute to it any more.
Even that substantial part is result of my 25 years of investent
to that group but its leaders took it with them to another
place with end expressed strong will/command to not contact
"their" people anymore. Most of them have left them anyway
so no problem to ask them for advises and help directly.
=
Back to LwIP

Extending loader and OpenOCD support for TMS570LC4357
is another target long term on my list.

Back to LwIP, I see some your effort to implement
select  sowwakeup(so); and sorwakeup() based
on some code copied from BSD stack

  https://git.rtems.org/vijay/rtems-lwip.git/tree/netinet?h=devel

I think that there would be problem to integrate
select cleanly when LwIP SOCK API is used.
If we limit select only on sockets, then the option
is to translate FD sets to LwIP struct *socket and
then use LwIP select implementation. But I do not like
this approach. I would prefer if the select mechanism
is part of RTEMS core, allows character devices (UART...)
support an

Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition

[Pavel Pisa]

Hello everybody,

I have no technical stuff to share for now,
but I am happy that work on LwIP alternative
stack for RTEMS continues on.

I have question which repo is considered as
mainline (integration point) for this work.
Is it devel branch of  Vijay Kumar Banerjee's
repo

  https://git.rtems.org/vijay/rtems-lwip.git/

If so, it would worth to put that on the top
of LwIP RTEMS info page to guide people interested
to live work and not lose time in another
abandonned attempts 

  https://devel.rtems.org/wiki/Packages/LWIP

Addition of pointers to STM WIP to some
central place would worth too with
pointer to the instructions or instructions
included...

In the longer term horizon, it would worth
to get rid of twisted translation layer I have
introduced initially

  
https://git.rtems.org/vijay/rtems-lwip.git/tree/lwip/src/api/rtems_lwip_sysdefs.c?h=devel

The best option would be if mainline LwIP provides
configurable option to use external types, enums,
structures (struct sockaddr) prototypes from libc
(i.e. NewLib) which would remove this translation.
I still think that move to LWIP_NETCONN only
and disable of LWIP_SOCKET could be the way
forward, but would require to implement own
layer to switch right NetCon base according
to socket AF domain, and type. So it would not be
easy task and solution based on actual FD to LwIP FD
translation could be used until then.

Generally I am curious what works and where
are problems. I do not expect to have time or
find students this summer but I try to offer
project as theses and next summer and there
chance (small) that I find some studnet
to participate.

This summer is my main interrest with studnets
work focused on pysimCoder to boost usability.

  https://github.com/robertobucher/pysimCoder

It is usable with preemptive GNU/Linux
on more targets, NuttX and adding support
for RTEMS would be easy as well.
Some demo with NuttX

  https://youtu.be/6HlGk3ecPNQ

Same targets are supported by our support
for Matlab/Simulink, RTEMS is on my list
for this projet for many years as well,
so if somebody have interrest, I would help
by advice or some prototype (which I have
for RTEMS in some hacked state in the past)

  https://github.com/aa4cc/ert_linux/

Best wishes,

Pavel

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

Re: [PATCH] Fixes for TMS570 BSP

[Pavel Pisa]

; >> @@ -50,7 +50,7 @@
> >>  #define TMS570_IRQ_ADC1_EVENT 14
> >>  #define TMS570_IRQ_ADC1_GROUP_1 15
> >>  #define TMS570_IRQ_CAN1_HIGH 16
> >> -#define TMS570_IRQ_RESERVED 17
> >> +#define TMS570_IRQ_RESERVED_1 17
> >>  #define TMS570_IRQ_FLEXRAY_HIGH 18
> >>  #define TMS570_IRQ_CRC_1 19
> >>  #define TMS570_IRQ_ESM_LOW 20
> >> @@ -63,7 +63,7 @@
> >>  #define TMS570_IRQ_SCI_LEVEL_1 27
> >>  #define TMS570_IRQ_ADC1_GROUP_2 28
> >>  #define TMS570_IRQ_CAN1_LOW 29
> >> -#define TMS570_IRQ_RESERVED
> >> +#define TMS570_IRQ_RESERVED_2 30
> >>  #define TMS570_IRQ_ADC1_MAG 31
> >>  #define TMS570_IRQ_FLEXRAY_LOW 32
> >>  #define TMS570_IRQ_DMA_FTCA 33
> >> diff --git a/spec/build/bsps/arm/tms570/obj.yml
> >> b/spec/build/bsps/arm/tms570/obj.yml index 7932299c1d..36f99a700e 100644
> >> --- a/spec/build/bsps/arm/tms570/obj.yml
> >> +++ b/spec/build/bsps/arm/tms570/obj.yml
> >> @@ -29,7 +29,7 @@ install:
> >>- bsps/arm/tms570/include/bsp/tms570_selftest_parity.h
> >>- bsps/arm/tms570/include/bsp/tms570lc4357-pins.h
> >>- bsps/arm/tms570/include/bsp/tms570ls3137zwt-pins.h
> >> -- destination: ${BSP_INCLUDEDIR}/bsp/ti/herc
> >> +- destination: ${BSP_INCLUDEDIR}/bsp/ti_herc
> >>source:
> >>- bsps/arm/tms570/include/bsp/ti_herc/reg_adc.h
> >>- bsps/arm/tms570/include/bsp/ti_herc/reg_ccmsr.h
> >> --
> >> 2.29.2.windows.2

So if the code builds for you and ideally if you can report that it runs
well, then I ACK the change.

I have there small local change as well. In the past, baudrate for UART has not
been defined for some test. I have added wokaround to select 115200
when baudrate is not selected anywhere. But this is hack which is probably
solved on the other level already 

--- a/bsps/arm/tms570/console/tms570-sci.c
+++ b/bsps/arm/tms570/console/tms570-sci.c
@@ -261,6 +261,8 @@ bool tms570_sci_set_attributes(

   /* Baud rate */
   baudrate = rtems_termios_baud_to_number(cfgetospeed(t));
+  if ( baudrate == 0 )
+baudrate = 115200;

   rtems_termios_device_lock_acquire(base, _context);

Best wishes,

Pavel

PS: I pose both TMS570LS3137 and TMS570LC4357 HDK and I have even access
to newer TMS570LC4357 kits at Elektroline company, so I can run some tests.
As for development tools, I have modified OpenOCD for TMS570LS3137 but
changes are based on other series, which never has got into mainline
  https://cmp.felk.cvut.cz/~pisa/tms570/
Binary only Flash API is another problem, but it can be solved by runtime 
ELF load.
I would be happy if somebody has newer OpenOCD working with TMS570LS3137
and even better if somebody has already invested time to TMS570LC4357 
support.
We have nice ETHERNET based XCP loader, but former head believes that he 
has control
about that proprietary code...
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: How to use lvgl on pc386 BSP.

[Pavel Pisa]

he latest one is enabled by default and that's what I'm trying to use.
>
> > Maybe
> > an alternative to using the BSP framebuffer driver could be to just port
> > the FreeBSD framebuffer driver for PC and use that one? That might could
> > be less work than fixing the PC BSPs driver.
>
> Hmm. Just a brief check reveals that FB also supports several FB drivers:
>
> - for EFI frame buffer
> - for KMS enabled graphics card with vt_fb backend

If there is safe EFI service which can be called from RTEMS protected
mode safely or before full RTEMS core is started it could be interesting
option. But generally I do consider to call anything outside of RTEMS
code as extremely unsafe for any RT application. There is no guarantee
how badly proprietary code is written.

The other option which would be great even for x86_64 BSP is to sandbox
VESA BIOS code execution (real one, because protected seem to be broken
on the most cards anyway). It requires small interpreter of x86 ISA subset.
Because it is interpretted it cannot lad to the lost of the CPU control,
tasks switching etc. And it allows to allows access only to the address
ranges which are belonging and reserved for video BIOS and HW use
and protect rest of the RT executive from this buggy code.
It can corrupt memory anyway because it can setup DMA or command
GPU processing cores which has full access to the main memory,
but it is much better separated.

Generally, I would like to participate on such work, but my time
is really limited. We experienced  adventure of distance only teaching
in the last semester and next one has been switched to the distat
one on the last Friday as well.

Best wishes,

Pavel Pisa
company:https://www.pikron.com/
e-mail: pp...@pikron.com

Czech Technical University in Prague
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://dce.fel.cvut.cz/
personal:   http://cmp.felk.cvut.cz/~pisa
projects:   https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/



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

Re: RTEMS CAN support Was: Hello World on BeagleBone

[Pavel Pisa]

Hello Gedare and John,

I have long term interrest in (not only) RTEMS CAN
support. So I would help as time and energy allows
me. I want and must spent some holiday time out
of computers and school load. I would apply for
(co-)menthor. Send me invitation, please.

As for RTEMS CAN support, as I know there is no
single CAN driver model available over all BSPs
with CAN support implemented as I know. I need
to go through sources again to analyze actual state.
There is

  bsps/shared/grlib/can
  bsps/powerpc/gen5200/mscan
  bsps/arm/lpc176x/can
  bsps/arm/atsam/contrib/libraries/libchip/source/mcan.c

On RTEMS, I have experience only with gen5200 mscan
many years ago. The API was minimal but provided
required functionality.

I have offered cooperation on our LinCAN API porting
to RTEMS. The driver for Linux
  http://ortcan.sourceforge.net/lincan/
See 1.4. LinCAN Driver Architecture section from the manual
  http://cmp.felk.cvut.cz/~pisa/can/doc/lincandoc-0.3.5.pdf
The complete concept of our CAN/CANopen components support there
  http://cmp.felk.cvut.cz/~pisa/can/doc/ocera-canopen-ug.pdf
But the head of former Real-Time Systems group at our department
has no interrest to continue on work to make it really
usesfull when the EU funded project has finished.
So I have tried to keep it at least at the level usable
as demonstrator of technology and tool for our other
CAN related projects. On Linux side, Oliver Hartkopp and Pengutronix
SocketCAN is the mainline choice. It has more advanced
and easy to use API, CAN FD support etc. So I have helped
to reuse some LinCAN code for this project. As for RT side,
I have still some doubts if the choice is optimal ...
But we use SocketCAN on Linux as main target now for
almost all CAN related faculty activities
  http://canbus.pages.fel.cvut.cz/
and our CAopen support can use SocketCAN as the driver API
as well
  
https://sourceforge.net/p/ortcan/ortcan-vca/ci/master/tree/libvca/vca_isocketcan.c
I have demonstrated that the project has some value still in 2017,
when I have setup DS-402 motion control CANopen profile device
from Zynq based MZ_APO board and other PiKRON designed hardware
and PiKRON provided PXMC motion control library
  https://www.linuxdays.cz/2017/video/Pavel_Pisa-CAN_canopen.pdf
The connection and use of RTEMS sponsored QEMU CAN support
was part of the presentation.
  http://cmp.felk.cvut.cz/~pisa/can/doc/rtlws-17-pisa-qemu-can.pdf
  https://github.com/qemu/qemu/blob/master/docs/can.txt
I have bachelor student working on our open source CTU CAN FD IP
core QEMU model now.
I have demonstrated, that I am alive still on LinuxDays 2019
when I have ported most of OrtCAN compnents to work on NuttX
  https://sourceforge.net/p/ortcan/ortcan-vca/ci/master/tree/libvca/vca_inuttx.c

So back to RTEMS, It would be great if there is some consensus
what is the CAN driver API preferred choice.
The grlib defines basic CANMsg type but even it is non consistent
because it defines it twice. It uses char for each flag instead
of bit and when CAN FD support is added then it would require
to make structure incompatible. SocketCAN API is BSD sockets
based and I think to complex. NuttX CAN API is functional
but too much configurable to squeeze it to less bytes for small
devices
  https://bitbucket.org/nuttx/nuttx/src/master/include/nuttx/can/can.h
But it is reasonable character device CAN API. NuttX is Apache
licensed now so even direct use for RTEMS could be OK including drivers.
LinCAN API can be extended to support CAN FD and provide even
internal FIFOs etc. LinCAN is GPL2 licensed with linking exception,
I have though about its RTEMS use from beginning. I have chance
to relicence it, it is partially based on older Linux CAN projects
to keep API partial compatibility but all is rewitted by me at least
onece. I expect no problem to negotiate change with our department
head now to cover even reference to it. But I am not sure if it is
the best option.

As for BeagleBone, it uses D_CAN based on BOSCH C_CAN.
Linux driver
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/can/c_can/c_can.c
NuttX driver
  https://bitbucket.org/nuttx/nuttx/src/master/arch/arm/src/am335x/am335x_can.c
We have worked on CCAN support for OKI ML9620 chip support
under BOSCH funding long time ago, so initial version of working
LinCAN support for CCAN (DCAN) exists there
  https://sourceforge.net/p/ortcan/lincan/ci/master/tree/lincan/src/c_can.c
I have lot of experience with DCAN on TMS570 on the rapid prototyping
platform done on EATON contract at former DCE RT group.
I have lead, guide and invested in diploma theses student to implemented
nice time triggered CAN support but due doctor Michal Sojka and professor
Zdenek Hanzalek order, only disfigured version could be published
as part of final theses text same as the whole work on Matlab/Simulink
target done mainly in a frame of diploma theses of foreign and local students
(often with my personal investment into guiding

LwIP integration - mapping RTEMS FDs to LwIP ones

[Pavel Pisa]

Hello Antonio,

I have noticed that you have tried to map
RTEMS network applications to LwIP.
You have tried to use LwIP headers instead
of NewLib provided ones. To integrate read, write,
close etc. correctly it is necessary to use
RTEMS FDs and map them to LwIP ones.

See my description in RTEMS Wiki

  https://devel.rtems.org/wiki/Packages/LWIP

I have tried to implement this mapping based on original
RETMS network stack cpukit/libnetworking/rtems/rtems_syscall.c file.
There is the result

  
https://github.com/ppisa/rtems-devel/blob/master/rtems-omk-template/applwiptest/rtems_lwip_io.c

I have been able to run RTEMS provided telnetd over this
IP stack replacement on TMS570LS3137.

See telned startup fragment at starting lines 58 and 155 of example application

  
https://github.com/ppisa/rtems-devel/blob/master/rtems-omk-template/applwiptest/init.c#L58

Because LwIP sockaddr type can in general differ and AF_XXX and PF_XXX differ 
between NewLib
and LwIP there is implemented layer to translate NewLib application types and 
defines to
from/to LwIP ones

  
​https://github.com/ppisa/rtems-devel/blob/master/rtems-omk-template/applwiptest/rtems_lwip_int.h

  
​https://github.com/ppisa/rtems-devel/blob/master/rtems-omk-template/applwiptest/rtems_lwip_sysdefs.c

I have revised actual sockaddr types and it seems that they should
compile to same fields types and offset. So that part of the
file is probably not required. I have removed RTEMS provided archives

  ar d librtemscpu.a in_proto.o ip_fw.o ip_icmp.o ip_input.o \
 main_netstats.o main_ping.o rtems_syscall.o \
 tcp_debug.o tcp_input.o tcp_output.o tcp_subr.o \
 tcp_timer.o tcp_usrreq.o udp_usrreq.o

and replaced them by

   ar r librtemscpu.a rtems_lwip_sysdefs.o rtems_lwip_io.o

I have used already described mapping to LwIP

  https://sourceforge.net/p/ulan/lwip-omk/ci/master/tree/ports/os/rtems/arch/

LwIP stack is our code with OMK build system, probably some simpler
RTEMS only build tree can be prepared

  https://sourceforge.net/p/ulan/lwip-omk/ci/master/tree/

Test application together with links to LwIP has been build
from OMK templete

  https://github.com/ppisa/rtems-devel/tree/master/rtems-omk-template

config.target:

RTEMS_MAKEFILE_PATH=/opt/rtems5.0/arm-rtems5.0/tms570ls3137_hdk_sdram


config.omk:

CONFIG_OC_APP_APPLWIPTEST=y
CONFIG_OC_APP_APPLWIPTEST_RTEMS_IO=y
CONFIG_OC_APP_APPLWIPTEST_TELNETD=y

CONFIG_LWIP_LIB=y

CONFIG_LWIP_LWIP_IPV4=y
#CONFIG_LWIP_LWIP_SNMP=y
CONFIG_LWIP_LWIP_ARP=y

CONFIG_LWIP_OS_PORT = rtems
CONFIG_LWIP_DEVICE_DRIVERS = tms570_emac

#lwipots
CONFIG_LWIP_STATIC_IP_ADDRESS=0

CONFIG_LWIP_HOST_TMR_INTERVAL=0
#CONFIG_LWIP_DYNAMIC_HTTP_HEADERS=y vypnul jsem ja

CONFIG_LWIP_SYS_LIGHTWEIGHT_PROT=1
CONFIG_LWIP_LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT=1

#CONFIG_LWIP_MEMP_OVERFLOW_CHECK=2
#CONFIG_LWIP_MEMP_SANITY_CHECK=y
CONFIG_LWIP_MEMP_SEPARATE_POOLS=y
CONFIG_LWIP_NO_SYS=0

CONFIG_LWIP_TCPIP_THREAD_PRIO=5
CONFIG_LWIP_TCPIP_THREAD_STACKSIZE=8192

CONFIG_LWIP_MEM_LIBC_MALLOC=0
#CONFIG_LWIP_MBOX_SIZE=4
CONFIG_LWIP_MEM_ALIGNMENT=4
CONFIG_LWIP_MEM_SIZE=(64*1024)
CONFIG_LWIP_MEMP_NUM_PBUF=48
CONFIG_LWIP_MEMP_NUM_TCP_PCB=32
CONFIG_LWIP_PBUF_POOL_SIZE=256
CONFIG_LWIP_MEMP_NUM_TCPIP_MSG_INPKT=50
CONFIG_LWIP_MEMP_NUM_TCPIP_MSG_API=30 

CONFIG_LWIP_IP_REASSEMBLY=0
CONFIG_LWIP_IP_FRAG=0

CONFIG_LWIP_LWIP_DHCP=1
CONFIG_LWIP_DHCP_DOES_ARP_CHECK=0

CONFIG_LWIP_LWIP_AUTOIP=0

CONFIG_LWIP_TCP_MSS=512
CONFIG_LWIP_TCP_WND=(512*4)
CONFIG_LWIP_TCP_SND_BUF=(512*4)

CONFIG_LWIP_PBUF_LINK_HLEN=14
CONFIG_LWIP_PBUF_POOL_BUFSIZE=256

CONFIG_LWIP_ETH_PAD_SIZE=0
CONFIG_LWIP_MEMP_NUM_NETCONN=10

CONFIG_LWIP_LWIP_NETCONN=1
CONFIG_LWIP_LWIP_SOCKET=1
CONFIG_LWIP_LWIP_SO_RCVTIMEO=1

CONFIG_LWIP_TCPIP_MBOX_SIZE=100
CONFIG_LWIP_DEFAULT_RAW_RECVMBOX_SIZE=100
CONFIG_LWIP_DEFAULT_UDP_RECVMBOX_SIZE=100
CONFIG_LWIP_DEFAULT_TCP_RECVMBOX_SIZE=100
CONFIG_LWIP_DEFAULT_ACCEPTMBOX_SIZE=100

CONFIG_LWIP_LWIP_STATS_DISPLAY=y
CONFIG_LWIP_LWIP_STATS=1
CONFIG_LWIP_MEMP_STATS=y
CONFIG_LWIP_MEM_STATS=y
#CONFIG_LWIP_ALL_DBG_ON=1
CONFIG_LWIP_LWIP_NETIF_API=1


Best wishes,

Pavel Pisa

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

Re: [PATCH 2/2] score: Introduce new monotonic clock

[Pavel Pisa]

Hello Sebastian,

On Friday 22 of December 2017 13:30:53 Sebastian Huber wrote:
> Rename PER_CPU_WATCHDOG_MONOTONIC to PER_CPU_WATCHDOG_TICKS.  Add new
> PER_CPU_WATCHDOG_MONOTONIC which is based on the system uptime (measured
> by timecounter).

This is great change.

Best wishes to you and all others,

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

Re: TMS570LC43x - what should be done before coding

[Pavel Pisa]

 conditionalized to easily
   find incompatibility if BSP is build for older chips. Silent write to
   unimplemented bits and use of unimplemented features is a problem.

 * if you find differences in c/src/lib/libbsp/arm/tms570/include/ti_herc
   files and need to adapt them, try to that systematic way. We have generated
   all these files by scripts and tools "make all.bat", "make_header.py" etc.
   found in "headers/python"  directories

  https://github.com/AoLaD/rtems-tms570-utils

   clone the tools repository and try to adapt files in the JSON form if you 
need
   to add one or two fields

 
https://github.com/AoLaD/rtems-tms570-utils/tree/master/headers/prepared_files
  
   if there is more differences then the mechanism to run comparison 
automatically
   is required. Our registers descriptions files has been obtained hard way
   by parsing PDFs due to unclear licences status at that days. Files generated
   by HalCoGen are correctly licensed now. On the other hand I think that files
   generated from our tools are following better form used by RTEMS (reference
   is mainly other modern RTEMS ports started or updated by Sebastian Huber).
   HalCoGen headers quite often lacks definition of masks for peripherals
   fields etc. The has been worse than what we have for sure in the past and 
they
   often differ in registers names and fields names for same peripheral
   between different family members. At least that has been situation one
   or two years ago. May it be that it has been improved since then.

   Anyway, I consider as optimal solution to use HalCoGen or CCS debugger XML
   definitions of registers and their fields as the source to generate
   Hercules family wide well matching header files for RTEMS.
   
   I plan to contact/speak with Ti representatives I have communicated
   in the past and check if they support and confirm that we can use this
   approach.

 * you should to check startup code stub at 

  https://github.com/hornmich/tms570ls3137-hdk-sdram

   try to use CCS to populate simple application which setups as much
   as possible peripherals on your board then prints something to serial
   port and waits in the infinite loop. Try to use GCC option for the
   code generation. But even application compiled by Ti compiler
   counts when runs well on your target. It has to be without operating
   system and interrupts enabled. Prepare repo with this application.
   It should be easy copy required files to the RTEMS and use it in
   that HalCoGen assisted mode to run simple shell demo.

Use your GSoC project Wiki page to maintain some TODO list and sumarise
your achievements and problems

  https://devel.rtems.org/wiki/GSoC/2017/TMS570_BSP_improvements

It may be possible Trac issue tracking system to organize
and prioritize work. But how and under which categories should
such points fall should be discussed with Gedare and others.

Best wishes,

Pavel Pisa

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

Re: Help Request - Fix Out of Bounds Subscript Warning in Raspberry Pi

[Pavel Pisa]

Hello Joel,

On Wednesday 26 of April 2017 01:03:30 Joel Sherrill wrote:
> Pavel,
>
> Feel free to commit the patch.

the patch should be tested and (unfortunately) I do not get
to that in next weeks. I have not even check that it compiles.
If you apply it and it compiles for you and you are happy with
it, push it please.

As for the GCC analysis, it does not warn for preceding
sequence

  *bank_number = bank;

  ACQUIRE_LOCK(gpio_bank_state[bank].lock);

but the first iteration has to go through this branch of the if.
So the range check has to be valid for values stored 
into *bank_number for all following iterations.

I think that GCC is puzzled because it does not
find that there is no other way into else branch then
after if branch.

At least it is my expectation.

Best wishes,

Pavel


> Why do you think the warning is a false positive?
>
> --joel
>
> On Tue, Apr 25, 2017 at 4:53 AM, Pavel Pisa <ppisa4li...@pikron.com> wrote:
> > From 3a2957faeb744af08196f1fd3baac71f15d76c85 Mon Sep 17 00:00:00 2001
> > Message-Id: <3a2957faeb744af08196f1fd3baac71f15d76c85.1493113587.git.
> > pp...@pikron.com>
> > From: Pavel Pisa <pp...@pikron.com>
> > Date: Tue, 25 Apr 2017 11:45:57 +0200
> > Subject: [PATCH] bsp/raspberrypi: GPIO silence warning and ensure that
> > lock is
> >  always released.
> > To: rtems-de...@rtems.org
> >
> > Signed-off-by: Pavel Pisa <pp...@pikron.com>
> > ---
> >  c/src/lib/libbsp/shared/gpio.c | 18 --
> >  1 file changed, 12 insertions(+), 6 deletions(-)
> >
> > Not tested or even compiled quick fix of warning and more serious real
> > problem.
> > The waning seems to be GCC false positive. The first iteration
> > (i == 0) sets *bank_number for sure. But return with RTEMS_INVALID_ID can
> > happen without lock release.
> >
> > diff --git a/c/src/lib/libbsp/shared/gpio.c b/c/src/lib/libbsp/shared/
> > gpio.c
> > index 9ceeb407..bf0e415 100644
> > --- a/c/src/lib/libbsp/shared/gpio.c
> > +++ b/c/src/lib/libbsp/shared/gpio.c
> > @@ -303,6 +303,7 @@ static rtems_status_code get_pin_bitmask(
> >uint32_t pin_number;
> >uint32_t bank;
> >uint8_t i;
> > +  int locked_bank = -1;
> >
> >if ( pin_count < 1 ) {
> >  return RTEMS_UNSATISFIED;
> > @@ -314,18 +315,23 @@ static rtems_status_code get_pin_bitmask(
> >  pin_number = pins[i];
> >
> >  if ( pin_number < 0 || pin_number >= BSP_GPIO_PIN_COUNT ) {
> > +  if (locked_bank >= 0)
> > +RELEASE_LOCK(gpio_bank_state[locked_bank].lock);
> > +
> >return RTEMS_INVALID_ID;
> >  }
> >
> >  bank = BANK_NUMBER(pin_number);
> >
> > -if ( i == 0 ) {
> > +if ( locked_bank < 0 ) {
> >*bank_number = bank;
> > +  locked_bank = bank;
> >
> > -  ACQUIRE_LOCK(gpio_bank_state[bank].lock);
> > +  ACQUIRE_LOCK(gpio_bank_state[locked_bank].lock);
> >  }
> > -else if ( bank != *bank_number ) {
> > -  RELEASE_LOCK(gpio_bank_state[*bank_number].lock);
> > +else if ( bank != locked_bank ) {
> > +  if (locked_bank >= 0)
> > +RELEASE_LOCK(gpio_bank_state[locked_bank].lock);
> >
> >return RTEMS_UNSATISFIED;
> >  }
> > @@ -334,7 +340,7 @@ static rtems_status_code get_pin_bitmask(
> >  gpio_pin_state[pin_number].pin_function != function ||
> >  gpio_pin_state[pin_number].on_group
> >  ) {
> > -  RELEASE_LOCK(gpio_bank_state[bank].lock);
> > +  RELEASE_LOCK(gpio_bank_state[locked_bank].lock);
> >
> >return RTEMS_NOT_CONFIGURED;
> >  }
> > @@ -342,7 +348,7 @@ static rtems_status_code get_pin_bitmask(
> >  *bitmask |= (1 << PIN_NUMBER(pin_number));
> >}
> >
> > -  RELEASE_LOCK(gpio_bank_state[bank].lock);
> > +  RELEASE_LOCK(gpio_bank_state[locked_bank].lock);
> >
> >return RTEMS_SUCCESSFUL;
> >  }
> > --
> > 1.9.1

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

Re: Help Request - Fix Out of Bounds Subscript Warning in Raspberry Pi

[Pavel Pisa]

>From 3a2957faeb744af08196f1fd3baac71f15d76c85 Mon Sep 17 00:00:00 2001
Message-Id: 
<3a2957faeb744af08196f1fd3baac71f15d76c85.1493113587.git.pp...@pikron.com>
From: Pavel Pisa <pp...@pikron.com>
Date: Tue, 25 Apr 2017 11:45:57 +0200
Subject: [PATCH] bsp/raspberrypi: GPIO silence warning and ensure that lock is
 always released.
To: rtems-de...@rtems.org

Signed-off-by: Pavel Pisa <pp...@pikron.com>
---
 c/src/lib/libbsp/shared/gpio.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

Not tested or even compiled quick fix of warning and more serious real problem.
The waning seems to be GCC false positive. The first iteration
(i == 0) sets *bank_number for sure. But return with RTEMS_INVALID_ID can
happen without lock release.

diff --git a/c/src/lib/libbsp/shared/gpio.c b/c/src/lib/libbsp/shared/gpio.c
index 9ceeb407..bf0e415 100644
--- a/c/src/lib/libbsp/shared/gpio.c
+++ b/c/src/lib/libbsp/shared/gpio.c
@@ -303,6 +303,7 @@ static rtems_status_code get_pin_bitmask(
   uint32_t pin_number;
   uint32_t bank;
   uint8_t i;
+  int locked_bank = -1;
 
   if ( pin_count < 1 ) {
 return RTEMS_UNSATISFIED;
@@ -314,18 +315,23 @@ static rtems_status_code get_pin_bitmask(
 pin_number = pins[i];
 
 if ( pin_number < 0 || pin_number >= BSP_GPIO_PIN_COUNT ) {
+  if (locked_bank >= 0)
+RELEASE_LOCK(gpio_bank_state[locked_bank].lock);
+
   return RTEMS_INVALID_ID;
 }
 
 bank = BANK_NUMBER(pin_number);
 
-if ( i == 0 ) {
+if ( locked_bank < 0 ) {
   *bank_number = bank;
+  locked_bank = bank;
 
-  ACQUIRE_LOCK(gpio_bank_state[bank].lock);
+  ACQUIRE_LOCK(gpio_bank_state[locked_bank].lock);
 }
-else if ( bank != *bank_number ) {
-  RELEASE_LOCK(gpio_bank_state[*bank_number].lock);
+else if ( bank != locked_bank ) {
+  if (locked_bank >= 0)
+RELEASE_LOCK(gpio_bank_state[locked_bank].lock);
 
   return RTEMS_UNSATISFIED;
 }
@@ -334,7 +340,7 @@ static rtems_status_code get_pin_bitmask(
 gpio_pin_state[pin_number].pin_function != function ||
 gpio_pin_state[pin_number].on_group
 ) {
-  RELEASE_LOCK(gpio_bank_state[bank].lock);
+  RELEASE_LOCK(gpio_bank_state[locked_bank].lock);
 
   return RTEMS_NOT_CONFIGURED;
 }
@@ -342,7 +348,7 @@ static rtems_status_code get_pin_bitmask(
 *bitmask |= (1 << PIN_NUMBER(pin_number));
   }
 
-  RELEASE_LOCK(gpio_bank_state[bank].lock);
+  RELEASE_LOCK(gpio_bank_state[locked_bank].lock);
 
   return RTEMS_SUCCESSFUL;
 }
-- 
1.9.1

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

Re: [PATCH 0/2] Zynq7000 series device configuration driver

[Pavel Pisa]

Hello Chris, Patrick and others,

I am sending pointers to some of our Zynq work which can be used
for test designs.

On Friday 21 of April 2017 00:37:16 Chris Johns wrote:
> On 21/04/2017 07:55, Patrick Gauvin wrote:
> > Gedare,
> >
> >
> > if the test programs are specific to the Zynq BSP, then we don't
> > currently have a very good mechanism for maintaining them. Probably
> > submitting them as "example programs" in the
> > git.rtems.org/examples-v2.git <http://git.rtems.org/examples-v2.git>
> > is the best place to look at integrating
> > application/bsp-level tests. This is an area in need of longer-term
> > solutions.
> >
> >
> > OK, I will plan on putting them there.
>
> What happens with bitfiles? For example I have a MicroZed with a 7Z010
> and I am not sure what a Zedboard has?
>
> Do you have a simple bitfile we can load?
>
> A bitfile that is not secured can compress well. Once this driver is in
> RTEMS it would be nice to add another layer to load compressed files.

There is some set of peripherals available and tested on Xilinx MicroZed
which is used from our group at Czech Technical University projects

  http://rtime.felk.cvut.cz/gitweb/fpga/zynq/canbench-sw.git

The master branch add two SJA1000 CAN controllers and routes integrated
ones to the interfaces on CAN benchmaring setup with MicroZed.

The "microzed_apo" branch adds some LEDs, knobs etc connected over
SPI, more PWM modulators for RC servos, simple audio etc

  
http://rtime.felk.cvut.cz/gitweb/fpga/zynq/canbench-sw.git/tree/refs/heads/microzed_apo

The project is interesting that it uses PetaLinux base and we have
carefully selected set of files which have to be distributed
and versioned in GIT and which can be regenerated by build.
Project is not perfect but much better than when everything
is stored in the GIT.

Some IPs for peripherals which we use

  
http://rtime.felk.cvut.cz/gitweb/fpga/zynq/canbench-sw.git/tree/refs/heads/microzed_apo:/system/ip

educational ones have been writted in a hurry to finish before start
of the semester so they are not perfect. But woking.
I have examples to add additional UARTs etc as well.

There are constrain files for MicroZed with CAN bench board
and educational kit

  
http://rtime.felk.cvut.cz/gitweb/fpga/zynq/canbench-sw.git/tree/refs/heads/microzed_apo:/system/src/constrs

The schematic diagrams and photos of our design can be found
in the directory

  http://cmp.felk.cvut.cz/~pisa/apo/mz_apo/

I have archived/published some U-boot patches and
my local build configuration for U-Boot, Linux
and RTEMS can be found there

  https://github.com/ppisa/zynq-rt-utils-and-builds

But RTEMS config is dated, I have tested RTEMS on Zynq
during last summer.

The presentation of real-time PMSM/BLDC for both Raspberry Pi and MicroZed
targets can be found there

  http://cmp.felk.cvut.cz/~pisa/installfest/linux_and_fpga_in_rt_control.pdf

I have interrest to prepare RTEMS one one day as well. I have some
RTEMS RPi DC motor one with video in English already but the sound
and language quality is bad so I am not decided if I should publish
it or wait for some rare moment when I find time to dub it better
myself or find somebody who is better English language gifted.

Best wishes,

Pavel


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

Re: Lots of BSPs Fail to Build Tests on Master

[Pavel Pisa]

Hello Joel,

On Saturday 14 of January 2017 00:01:09 Joel Sherrill wrote:
> Hi
>
> The following BSPs do not successfully complete a build with all
> tests enabled. A spot check of a few shows that some tests do
> not fit in memory. There may be other issues. This is a major
> regression.
>
> arm-lm3s3749 arm-lm3s6965 arm-lm4f120 arm-lpc1768_mbed_ahb_ram_eth
> arm-lpc1768_mbed_ahb_ram arm-lpc1768_mbed arm-lpc17xx_ea_rom_int
> arm-lpc17xx_plx800_rom_int arm-lpc2362 arm-lpc23xx_tli800
> arm-lpc24xx_ncs_rom_int arm-lpc24xx_plx800_rom_int
> arm-lpc32xx_mzx_stage_1 arm-lpc40xx_ea_rom_int arm-rtl22xx
> arm-rtl22xx_t arm-stm32f105rc arm-stm32f4
> arm-tms570ls3137_hdk_intram

It is definitely size issue when it builds for other TMS570
variants. Only linker script is different for this one
and the memory size is really small for "intram" variant -
256 kB for data and code together.

> epiphany-epiphany_sim m32c-m32csim 
> m68k-mcf5206elite m68k-mcf52235 m68k-mcf5225x m68k-mrm332
> mips-hurricane mips-rbtx4925 mips-rbtx4938 moxie-moxiesim
> nios2-nios2_iss or1k-generic_or1k powerpc-gwlcfm
> powerpc-mpc5566evb powerpc-mpc5566evb_spe powerpc-mpc5643l_dpu
> powerpc-mpc5643l_evb powerpc-mpc5674f_ecu508_boot
> powerpc-mpc5674f_rsm6 powerpc-phycore_mpc5554 sh-gensh1 sh-gensh2
> sh-simsh1 sh-simsh2e sh-simsh2 sh-simsh4

Best wishes,

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

Re: Update virtio network driver

[Pavel Pisa]

Hello Jin-Hyun,

On Tuesday 15 of November 2016 11:29:05 Pavel Pisa wrote:
> Hello Jin-Hyun,
>
> thanks for update.
>
> I have returned from my USA holydays now and catching up
> with e-mails and work backlogs.
>
> On Thursday 10 of November 2016 10:42:34 Jinhyun wrote:
> > Hi, all!
> >
> > We removed our RTEMS-virtio driver's dependencies on architecture. We
> > used built-in function of gcc, __sync_synchronize(). This function
> > generates proper memory barrier for target architecture on compile time.
> > In addition, we replaced pcib_conf_read/write functions to
> > pci_read/write_config functions. We added several lines of codes for
> > exception handling suggested by Pavel Pisa. Thank you, Pavel Pisa. As we
> > removed dependencies on CPU architectures, we moved the virtio source
> > directory located at
> > c/src/lib/libbsp/i386/pc386/ to c/src/lib/libbsp/shared.
>
> I have done some updates and testing of your work some time ago.
> I think I reported that but I am not 100% sure. Please,
> look if some changes in my WIP branch are of some use for you

OK, I see that it is integrated.

Great.

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

Re: Update virtio network driver

[Pavel Pisa]

Hello Jin-Hyun,

thanks for update.

I have returned from my USA holydays now and catching up
with e-mails and work backlogs.

On Thursday 10 of November 2016 10:42:34 Jinhyun wrote:
> Hi, all!
>
> We removed our RTEMS-virtio driver's dependencies on architecture. We used
> built-in function of gcc, __sync_synchronize(). This function generates
> proper memory barrier for target architecture on compile time. In addition,
> we replaced pcib_conf_read/write functions to pci_read/write_config
> functions. We added several lines of codes for exception handling suggested
> by Pavel Pisa. Thank you, Pavel Pisa. As we removed dependencies on CPU
> architectures, we moved the virtio source directory located at
> c/src/lib/libbsp/i386/pc386/ to c/src/lib/libbsp/shared.

I have done some updates and testing of your work some time ago.
I think I reported that but I am not 100% sure. Please,
look if some changes in my WIP branch are of some use for you

https://github.com/ppisa/rtems/commits/devel-virtio

As for RTEMS_COMPILER_MEMORY_BARRIER() suggested by Gedare,
I am not sure if it is enough in some places.
VirtIO is PCI like device and compiler barrier would
work if the hypervisor places data into shared
buffer from the same CPU. If it runs on different
one in parallel with RTEMS driver (in network polled API
like mode) then real SMP barrier is more appropriate.

Best wishes,

Pavel

> We plan to enhance the virtio driver for RTEMS, and we have several
> additional patches for it. To easily manage this project from our side, we
> created Github repository. You can see the latest version of our virtio
> driver in our Github: https://github.com/sslab-konkuk/RTEMS-virtio
>
> Recently, we succeeded to test the virtio with Motorola_powerpc BSP. For
> this, we made additional modifications. Motorola_powerpc BSP doesn't
> support functions such as rtems_insterrupt_handler_install, so we used
> functions such as BSP_install_rtems_irq_handler instead of those. Moreover,
> in order to make our virtio work on PowerPC, we added initialization codes
> to virtio_pci.c because qemu_fakerom, which is the PowerPC bios of
> Motorola_powerpc BSP, doesn't initialize the virtio back-end driver. But
> some runtime error is occurred on RTEMS master branch, so we will submit
> about it again soon.
>
> Best regards,
> Jin-Hyun.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: i386 SMP buils - Was: libchip/network/if_fxp.c: do not use rtems_interrupt_disable.

[Pavel Pisa]

Hello Chris,

On Monday 17 of October 2016 03:00:56 Chris Johns wrote:
> I have built and tested these patches with no issues and 0 spurious
> interrupts.
>
> The changes look fine to me.

Thanks much for testing. I have pushed changes to the master.

I have spent considerable time over weekend by debugging
i386 SMP build but without success.

I have found and fixed some problems, I get to the state when
two CPUs runs under QEMU and even IPI is exchanged but then
execution finish by different kinds of fatal exceptions.

On the other hand, SMP build when only one CPU is enabled
runs stable under QEMU.

Some found issues and corrections tested with

  CONFIGURE_SMP_MAXIMUM_PROCESSORS  2

According to the more sources, INIT and SIPI duplication
is not required on modern CPUs. INIT is ignored so no problem,
but if the second SIPI is delayed too much then the first
one causes complete start of the second core reaching RTEMS
secondary_cpu_initialize() and then next SIPI resets the core
and it starts again so you count CPU twice. The specification
is strict about 200usec between two SIPI. But according to
some discussion that second SIPI is not required on modern systems.
Next modification tries bring up the second core by single SIPI
and if the core does not reach RTEMS code in really long time
it expect old system and restries the second SIPI.
Probably LAPIC version can be used there to switch this workaround
for newer cores at all. 

diff --combined c/src/lib/libbsp/i386/shared/smp/smp-imps.c
--- a/c/src/lib/libbsp/i386/shared/smp/smp-imps.c
+++ b/c/src/lib/libbsp/i386/shared/smp/smp-imps.c
@@@ -301,12 -301,12 +334,21 @@@
 */
  
if (proc->apic_ver >= APIC_VER_NEW) {
--int i;
--for (i = 1; i <= 2; i++) {
++int retry = 2;
++while (retry) {
++  int wait_for_ap = 100;
++
++  printk("boot_cpu sending SIPI\n");
++
send_ipi(apicid, LAPIC_ICR_DM_SIPI | ((bootaddr >> 12) & 0xFF));
--  UDELAY(1000);
++  do {
++UDELAY(10);
++if (acked_ap_cpus != _Atomic_Load_uint(_ap_cpus_acked, 
ATOMIC_ORDER_SEQ_CST))
++  retry = 0;
++  } while(wait_for_ap--);
  }
}
++  printk("boot_cpu secondary acked\n");
  
/*
 *  Generic CPU startup sequence ends here, the rest is cleanup.

Another strange thing for SMP is, that secondary CPUs continues
to run with temporary GDT set by CPU SIPI trampoline code at 0x7.
So I have added function to setup the secondary CPU the same GDT
as is used on the primary

diff --combined c/src/lib/libbsp/i386/shared/smp/smp-imps.c
--- a/c/src/lib/libbsp/i386/shared/smp/smp-imps.c
+++ b/c/src/lib/libbsp/i386/shared/smp/smp-imps.c
@@@ -785,7 -785,7 +829,7 @@@ static void secondary_cpu_initialize(vo
  {
int apicid;
  
--  asm volatile( "lidt IDT_Descriptor" );
++  _load_segments_secondary();
  
apicid = IMPS_LAPIC_READ(LAPIC_SPIV);
IMPS_LAPIC_WRITE(LAPIC_SPIV, apicid|LAPIC_SPIV_ENABLE_APIC);
@@@ -794,6 -794,6 +838,8 @@@
enable_sse();
  #endif
  
++  _Atomic_Fetch_add_uint(_ap_cpus_acked, 1, ATOMIC_ORDER_SEQ_CST);
++
_SMP_Start_multitasking_on_secondary_processor();
  }

+++ b/c/src/lib/libbsp/i386/pc386/startup/ldsegs.S
++
++  .p2align 4
++
++PUBLIC ( _load_segments_secondary)
++SYM (_load_segments_secondary):
++
++  lgdt SYM(gdtdesc)
++  lidt SYM(IDT_Descriptor)
++
++  /* Load CS, flush prefetched queue */
++  ljmp $0x8, $next_step_secondary
++
++next_step_secondary:
++/* Load segment registers */
++  movw $0x10, ax
++  movw ax, ss
++  movw ax, ds
++  movw ax, es
++  movw ax, fs
++  movw ax, gs
++  ret

As for GDT, I am not sure if one GDT for all CPUs can work.
Problem is TSS. RTEMS runs in ring 0 only, so TSS is not required
to switch between ring 3 and ring 0 but I am not sure if there
is not some situation when TSS is accessed anyway. The additional
TSS is required for sure if we want to catch double fault exception.

To be on safe side, it would worth to move user descriptors
to LDT, left global GDT to point to LDT and area for primary
CPU TSS and allocate new GDT and TSS for each CPU during bringup.

Generally, I am not expert for x86 and do not like this area much
so if some student or somebody else wants to exercise in this
remains of dark age, I would be happy and help with some hints.

On the other hand, RTEMS should provide reasonable x6 SMP
support for testing and may it be Jailhouse or other interresting
hypervisor base divisions to RT and generic OS domains.
Other option is to left i386 SMP support unsolved and add
x86_64 support which skips many of these oddities like TSS and GDT.
(OK GDT is required but only that simple short lived in the trampoline
is enough).

Best wishes,

Pavel

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

Re: Time spent in ticks...

[Pavel Pisa]

Hello Joel,

On Friday 14 of October 2016 00:56:21 Joel Sherrill wrote:
> On Thu, Oct 13, 2016 at 1:37 PM, Joel Sherrill  wrote:
> > On Thu, Oct 13, 2016 at 11:21 AM, Jakob Viketoft <
> >
> > jakob.viket...@aacmicrotec.com> wrote:
> >> *From:* Joel Sherrill [j...@rtems.org]
> >> *Sent:* Thursday, October 13, 2016 17:38
> >> *To:* Jakob Viketoft
> >> *Cc:* devel@rtems.org
> >> *Subject:* Re: Time spent in ticks...
> >>
> >> >I don't have an or1k handy so ran on a sparc/erc32 simulator/
> >> >It is is a SPARC v7 at 15 Mhz.
> >> >
> >> >These times are in microseconds and based on the tmtests.
> >> >Specifically tm08and tm27.
> >> >
> >> >(1) rtems_clock_tick: only case - 52
> >> >(2) rtems interrupt: entry overhead returns to interrupted task - 12
> >> >(3) rtems interrupt: exit overhead returns to interrupted task - 4
> >> >(4) rtems interrupt: entry overhead returns to nested interrupt - 11
> >> >(5) rtems interrupt: exit overhead returns to nested interrupt - 3
> >
> > The above was from the master with SMP enabled. I repeated it with
> > SMP disabled and it had no impact.
> >
> > Since the timing change is post 4.11, I decided to try 4.11 with SMP
> > disabled:
> >
> > rtems_clock_tick: only case - 42
> > rtems interrupt: entry overhead returns to interrupted task - 11
> > rtems interrupt: exit overhead returns to interrupted task - 4
> > rtems interrupt: entry overhead returns to nested interrupt - 11
> > rtems interrupt: exit overhead returns to nested interrupt - 3
> >
> > So 42 + 12 + 4 = 58 microseconds, 58 * 15 = 870 cycles
> >
> > So the overhead has gone up some but as Pavel says it is quite likely
> > some mathematical operation on 64 bit types is slow on your CPU.
> >
> > HINT: If you can write a benchmark for 64-bit operations,
> > it would be a good comparison between CPUs and might
> > highlight where the software implementation needs improvement.
>
> I decided that another good point of reference was the powerpc/psim BSP. It
> reports the benchmarks in instructions:
>
> (1) rtems_clock_tick: only case - 229
> (2) rtems interrupt: entry overhead returns to interrupted task - 102
> (3) rtems interrupt: exit overhead returns to interrupted task - 95
> (4) rtems interrupt: entry overhead returns to nested interrupt - 105
> (5) rtems interrupt: exit overhead returns to nested interrupt - 85
>
> 229 + 102 + 96 = 427 instructions.
>
> That seems roughly inline with the erc32 which is 1 cycle for all
> instructions
> except loads which are 3 and stores which are 2. And the sparc has
> register windows so entering and exiting an ISR can potentially save
> and restore a lot of registers.
>
> So I am still leaning to Pavel's explanation that some primitive operation
> is really inefficient.

These numbers looks good.

I would expect that in the case of or1k there can be real penalty
if it is synthesized without multiply or barrel shifter.
Or CPU has these and compiler is set to not use them.
If that cannot be corrected (for example hardware multiplier
or shifter would cause design to not fit in FPGA) then there
is real problem and mitchmatch between RTEMS and CPU target
area. This can be solved by configurable time measurement
data type. For example use only ticks in 32-bit number
and change even timers queues to this type. It cannot be unconditional,
because today users of RTEMS expect that the time resolution
is better and that time does not overflow in longer range, ideally 2100
or more supported.

As for actual code, if I remember, I have not liked conversions
of monotonic to ticks in nanosleep and there has been some division.
The division is not in tick code (at least I thinks so). So this should
be OK. The packet sec and fractions format of timespec for one
of queues has some interresting properties but on the other hand
its repcaking has some overhead even in the tick processing.

If we take that for some CPU time spent in tick is for example 50 usec
then it is not problem if there are no deadlines in the similar range.
For example, tollerated latencies of 500 or 1000 usec and critical tasks
execution time is 300 usec then it is OK. If the tick rate is selected
1 kHz then 5% of CPU time consumption by time keeping looks like quite
a lot. If the timing of applications can tolerated tick time 0.1 sec (10 Hz)
then load contribution by tick processing is neglectable.

So all these numbers are relative to needs of planned target application.

Best wishes,

Pavel


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

Re: Time spent in ticks...

[Pavel Pisa]

Hello Jakob,

On Thursday 13 of October 2016 18:21:05 Jakob Viketoft wrote:
> I re-tested my case using an -O3 optimization (we have been using -O0
> during development for debugging purposes) and I got a good performance
> boost, but I'm still nowhere near your numbers. I can vouch for that the
> interrupt (exception really) isn't stuck, but that the code unfortunately
> takes a long time to compute. I have a subsecond counter (1/16 of a second)
> which I'm sampling at various places in the code, storing its numbers to a
> buffer in memory so as to interfere with the program as little as possible.
>
> With -O3, a tick handling still takes ~320 us to perform, but the weight
> has now shifted. tc_windup takes ~214 us and the rest is obviously
> _Watchdog_Tick(). When fragmenting the tc_windup function to find the worst
> speed bumps the biggest contribution (~122 us) seem to be coming from scale
> factor recalculation. Since it's 64 bits, it's turned into a software
> function which can be quite time-consuming apparently.
>
> Even though _Watchdog_Tick() "only" takes ~100 us now, it still sound much
> higher than your total tick with a slower system (we're running at 50 MHz).
>
> Is there anything we can do to improve these numbers? Is Clock_isr intended
> to be run uninterrupted as it is now? Can't see that much of the BSP patch
> code has anything to do with the speed of what I'm looking at right now...

the time is measured and timers queue use 64-bit types for time
representation. When higher time measurement resolution than tick
is requested then it is reasonable (optimal) choice but it can be problem
for 16-bit CPUs and some 32-bit one as well.

How you have configured or1k CPU? Have you available hardware multiplier
and barrel shifter or only shift by one and multiplier in SW?
Do the CFLAGS match available instructions?

I am not sure, if there is not 64 division in the time computation
either. This is would be a killer for your CPU. The high resolution
time sources and even tickless timers support can be implemented
with full scaling and adjustment with only shifts, addition and 
multiplications in hot paths.

I have tried to understand to actual RTEMS time-keeping code
some time ago when nanosleep has been introduced and
I have tried to analyze, propose some changes and compared
it to Linux. See the thread following next messages

  https://lists.rtems.org/pipermail/devel/2016-August/015720.html

  https://lists.rtems.org/pipermail/devel/2016-August/015721.html

Some discussed changes to nanosleep has been been implemented
already.

Generally, try to measure how many times multiplication
and division is called in ISR.
I think that I am capable to design implementation which
restricted to mul, add and shr and minimizes number
of transformations but if it sis found that RTEMS implementation
needs to be optimized/changed then it can be task counted
in man months.

Generally, if tick interrupt last more than 10 (may be 20) usec then
there is problem. One its source can be SW implementation ineffectiveness
other that OS selected and possibly application required features
are above selected CPU capabilities.

Best wishes,


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

Re: [PATCH 3/3] libchip/network/if_fxp.c: do not use rtems_interrupt_disable.

[Pavel Pisa]

Some typo corrections of e-mail written when I have returned
late in night from meeting with friends.

And some more clarification as well.

On Thursday 13 of October 2016 01:55:30 Pavel Pisa wrote:
> Hello Chris,
>
> On Wednesday 12 of October 2016 23:05:30 Chris Johns wrote:
> > On 13/10/2016 03:22, Pavel Pisa wrote:
> > > But RTEMS i8269 support has been broken to disable
> > > vector for level triggered interrupts in generic
> > > IRQ processing code.
> >
> > I am not sure where the blame should be placed. We need to disable at
> > the PIC when using libbsd with shared PCI interrupts because an
> > interrupt server is used that is common to a few architectures. Some
> > legacy drivers like this one assume processing inside the interrupt
> > context. It is not clear to me shared interrupts were ever supported
> > with these drivers. I would assume it means some type of per driver
> > interrupt chaining.
> >
> > > So I have introduced reenable
> > > bsp_interrupt_vector_enable to ensure that driver
> > > can work even with that setup.
> >
> > I am not sure we can mix both models without some changes.
>
> I hope that interrupt server should work after the committed change.
> At least, I have feeling that it has been outcome of previous debate.
>
> The IRQ server bsp_interrupt_server_trigger() disables given IRQ
> vector on PIC level in hardware IRQ context by
> bsp_interrupt_vector_disable()
>
> See
>
>  
> https://git.rtems.org/rtems/tree/c/src/lib/libbsp/shared/src/irq-server.c#n
>64
>
> I would not push the changes if it has not be a case.
>
> > > classic networking: adapt FXP driver to work with actual PCI and IRQ
> > > code.
> > >
> > > The hack is not required after
> >
> > Which hack?
>
> The reenabling of PIC level ISR in driver code. Generally I consider
> the functions bsp_interrupt_vector_disable() and
> bsp_interrupt_vector_enable() should be used as paired and use should allow
> to use them even
> if implemented as counting disable clock> . 

spellchecker ...

s/clock/lock/

The counting of disable calls is required if vector is shared
because if multiple hard IRQ handlers needs to disable
source at controller level (generally bad practice, better is handling
on device level if possible) then if source is enabled on controller level
when the first worker theread finishes processing and cause of the shared
level triggered IRQ is other device for which threaded handler
dis not finish yet then there is complete system dead/livelock.

Linux provides next functions to maintain controller side
interrupt disable and enable

https://www.kernel.org/doc/htmldocs/kernel-api/hardware.html#idp11592384

 disable_irq - this function guarantees that after it finishes
   corresponding IRQ source handlers are not invoked
   and not running in parallel (wait for their finish)
   This function cannot be called in the handler itself
   (deadlock).

 disable_irq_nosync - disables vector at controller level, does not guarantee
   that the last actually running instances of each of shared
   handlers is finished before call return. This can be called
   for source from its own hard context handler.

 enable_irq - undoes effect of the corresponding disable_irq, it is necessary
   to call it as many times as disable_irq has been called before.
   Only when all calls are balanced then controller enables
   source.

I this that when all possible HW and SW constellations are possible then
this is only usable API.

And yes, there are strange thing in the world.

I have debugged over e-mail my CAN driver at another university when I have 
found that PCI card has level triggered IRQ output but multiple CAN 
controllers connected to local bus behind card PCI bridge has shared
interrupts and bridge has asserted interrupt only at shared signal
raising edge. So if PCI interrupt processing finished without beeing
sure that all chips behind bridge has their output inactive then
the device and CAN control/monitoring inside some intelligent van
on the street has been lost. Fortunately not without driver at that time.

> That is implementation where bsp_interrupt_vector_enable() enables vector
> only after same number of calls as was the number of calls
> bsp_interrupt_vector_enable()
>
> > > bsps/i386: Separate variable for i8259 IRQs disable due to in progress
> > > state.
> > >
> > > so I have removed unneeded reenable from daemon hot path.
> > > I have left it in the setup to be sure that it is enabled
> > > after some driver stop start cycles.
> > >
> > > In theory, this occurren

Re: [PATCH 3/3] libchip/network/if_fxp.c: do not use rtems_interrupt_disable.

[Pavel Pisa]

Hello Chris,

On Wednesday 12 of October 2016 23:05:30 Chris Johns wrote:
> On 13/10/2016 03:22, Pavel Pisa wrote:
> > But RTEMS i8269 support has been broken to disable
> > vector for level triggered interrupts in generic
> > IRQ processing code.
>
> I am not sure where the blame should be placed. We need to disable at
> the PIC when using libbsd with shared PCI interrupts because an
> interrupt server is used that is common to a few architectures. Some
> legacy drivers like this one assume processing inside the interrupt
> context. It is not clear to me shared interrupts were ever supported
> with these drivers. I would assume it means some type of per driver
> interrupt chaining.
>
> > So I have introduced reenable
> > bsp_interrupt_vector_enable to ensure that driver
> > can work even with that setup.
>
> I am not sure we can mix both models without some changes.

I hope that interrupt server should work after the committed change.
At least, I have feeling that it has been outcome of previous debate.

The IRQ server bsp_interrupt_server_trigger() disables given IRQ
vector on PIC level in hardware IRQ context by bsp_interrupt_vector_disable()

See

  https://git.rtems.org/rtems/tree/c/src/lib/libbsp/shared/src/irq-server.c#n64

I would not push the changes if it has not be a case.

> > classic networking: adapt FXP driver to work with actual PCI and IRQ
> > code.
> >
> > The hack is not required after
>
> Which hack?

The reenabling of PIC level ISR in driver code. Generally I consider
the functions bsp_interrupt_vector_disable() and bsp_interrupt_vector_enable()
should be used as paired and use should allow to use them even
if implemented as counting disable clock.
That is implementation where bsp_interrupt_vector_enable() enables vector
only after same number of calls as was the number of calls
bsp_interrupt_vector_enable()

> > bsps/i386: Separate variable for i8259 IRQs disable due to in progress
> > state.
> >
> > so I have removed unneeded reenable from daemon hot path.
> > I have left it in the setup to be sure that it is enabled
> > after some driver stop start cycles.
> >
> > In theory, this occurrence should be deleted as well.
> >
> > Generally, I am not sure if/how much I have broken/I am
> > breaking i386 support by all these changes.
>
> I have not testing the i386 with libbsd with your recent changes. I will
> see what I can do. I did not notice the enables/disables had been changed.
>
> > I believe only, hat it is the right direction.
>
> I am sorry it is not clear to me what direction this is.

I have on mind changes required for i386 BSP SMP build and generally
that all RTEMS code (not only x86) should eliminate constructs based
on UP assumptions or directly incompatible with SMP. That is
rtems_interrupt_lock_acquire should be used to protect low level operations
which has to be serialized (short system level/hardware critical sections).

i386 support needs to move forward. basic SMP support and LAPIC seems
to be included. So it needs to enable its testing. The proposed changes
allows the build. I have tested UP and SMP i386 builds only under QEMU.
My test of networking, RTL and some others seems to work for both
builds. UP and SMP build single core applications seems to run
on real HW.

SMP build with 1 CPU output on real HW

-
novaboot: Serial line interaction (press Ctrl-C to interrupt)...
Scanning from 0x9D400 for 1024 bytes
Scanning from 0xF for 65536 bytes
Found MP Floating Structure Pointer at FDA40
Intel MultiProcessor Spec 1.4 BIOS support detected
APIC config: "Virtual Wire mode"Local APIC address: 0xFEE0
  OEM id: CBX3 Product id: DELL
  Bus id 0 is PCI
  Bus id 1 is PCI
  Bus id 2 is PCI
  Bus id 3 is PCI
  Bus id 4 is ISA
  I/O APIC id 2 ver 32, address: 0xFEC0
WARNING!! Found more CPUs (4) than configured for (1)!!


RTEMS v 4.11.99
Starting application appfoo v 0.1.0
*** Starting up Task_1 ***
Task_1 woken

RTEMS Shell on /dev/console. Use 'help' to list commands.
[/] # Task_1 woken
Task_1 woken
-

When I try to enable two CPUs and try to run SMP build on QEMU
and real HW then it breaks. REAL HW output

-
i386: isr=0 irr=1
Scanning from 0x9D400 for 1024 bytes
Scanning from 0xF for 65536 bytes
Found MP Floating Structure Pointer at FDA40
Intel MultiProcessor Spec 1.4 BIOS support detected
APIC config: "Virtual Wire mode"Local APIC address: 0xFEE0
  OEM id: CBX3 Product id: DELL
  Processor [APIC id 0 ver 21]: #0  BootStrap Processor (BSP)
  Processor [APIC id 2 ver 21]:

i386: isr=0 irr=1
Scanning from 0x9D400 for 1024 bytes
Sc

Re: [PATCH 3/3] libchip/network/if_fxp.c: do not use rtems_interrupt_disable.

[Pavel Pisa]

Hello Gedare,

On Wednesday 12 of October 2016 18:10:19 Gedare Bloom wrote:
> On Wed, Oct 12, 2016 at 4:26 AM,  <p...@cmp.felk.cvut.cz> wrote:
> > From: Pavel Pisa <p...@cmp.felk.cvut.cz>
> >
> > The single write to memory or ioport output are mostly
> > atomic operations already. The proper memory synchronization barrier
> > should be used around them to guarantee ordering (sync or eieio
> > on PowerPC for example) but because I have not found settable
> > portable primitive only compiler barrier is used.
> > It should be enough on x86 because the externally visible order
> > should be/is guaranteed to be preserved on x86 architecture.
> > ---
> >  c/src/libchip/network/if_fxp.c | 11 ---
> >  1 file changed, 4 insertions(+), 7 deletions(-)
> >
> > diff --git a/c/src/libchip/network/if_fxp.c
> > b/c/src/libchip/network/if_fxp.c index 4d9d983..c2ca419 100644
> > --- a/c/src/libchip/network/if_fxp.c
> > +++ b/c/src/libchip/network/if_fxp.c
> > @@ -1130,7 +1130,6 @@ fxp_start(struct ifnet *ifp)
> >  {
> > struct fxp_softc *sc = ifp->if_softc;
> > struct fxp_cb_tx *txp;
> > -   rtems_interrupt_level level;
> >
> > DBGLVL_PRINTK(3,"fxp_start called\n");
> >
> > @@ -1279,10 +1278,10 @@ tbdinit:
> > /*
> >  * reenable interrupts
> >  */
> > -   rtems_interrupt_disable (level);
> > +   RTEMS_COMPILER_MEMORY_BARRIER();
> > CSR_WRITE_1(sc, FXP_CSR_SCB_INTRCNTL,0);
> > bsp_interrupt_vector_enable(sc->irq_num);
>
> Here you don't delete bsp_interrupt_vector_enable ...

Good catch. The reason is that there should not be
bsp_interrupt_vector_enable() in neither.
The interrupt is enabled after attach and should stay that
way for whole driver life. The disable at ISR level
and enable in daemon is controlled on the board registers
level  for FXP which is how correct PCI driver with
possibly shared interrupts should work.

But RTEMS i8269 support has been broken to disable
vector for level triggered interrupts in generic
IRQ processing code. So I have introduced reenable
bsp_interrupt_vector_enable to ensure that driver
can work even with that setup.

classic networking: adapt FXP driver to work with actual PCI and IRQ code.

The hack is not required after

bsps/i386: Separate variable for i8259 IRQs disable due to in progress state.

so I have removed unneeded reenable from daemon hot path.
I have left it in the setup to be sure that it is enabled
after some driver stop start cycles.

In theory, this occurrence should be deleted as well.

Generally, I am not sure if/how much I have broken/I am
breaking i386 support by all these changes.

I believe only, hat it is the right direction.
I would be happy to discus them with others.

Thanks for review,

 Pavel


> > -   rtems_interrupt_enable (level);
> > +   RTEMS_COMPILER_MEMORY_BARRIER();
> >  }
> >
> >  /*
> > @@ -1311,7 +1310,6 @@ static void fxp_daemon(void *xsc)
> > struct ifnet *ifp = >sc_if;
> > u_int8_t statack;
> > rtems_event_set events;
> > -   rtems_interrupt_level level;
> >
> >  #ifdef NOTUSED
> > if (sc->suspended) {
> > @@ -1458,10 +1456,9 @@ rcvloop:
> >   /*
> >* reenable interrupts
> >*/
> > - rtems_interrupt_disable (level);
> > + RTEMS_COMPILER_MEMORY_BARRIER();
> >   CSR_WRITE_1(sc, FXP_CSR_SCB_INTRCNTL,0);
> > - bsp_interrupt_vector_enable(sc->irq_num);
>
> ... here you do. Why are the cases different?
>
> > - rtems_interrupt_enable (level);
> > + RTEMS_COMPILER_MEMORY_BARRIER();
> > }
> >  }
> >
> > --
> > 1.9.1
> >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/3] bsps/i386: use Pentimum instructions for pc586 and pc686 builds.

[Pavel Pisa]

Hello Sebastian,

On Wednesday 12 of October 2016 10:35:55 Sebastian Huber wrote:
> On 12/10/16 10:26, p...@cmp.felk.cvut.cz wrote:
> > SMP build is broken with i386 set because libatomic and GCC
> > generate infinite loop for __atomic_fetch_add_4 used
> > in rtems_interrupt_lock_acquire
> >
> > __atomic_fetch_add_4:
> >  push   %ebp
> >  mov%esp,%ebp
> >  movl   $0x5,0x10(%ebp)
> >  pop%ebp
> >  jmp__atomic_fetch_add_4
>
> Do you have a test case for this compiler/RTEMS bug?  The use of
> libatomic is inefficient, but it should work.

may be it is problem of my i386 toolchain build, I have not
updated it from April.

The next is a simple test


#include 

atomic_uint atvar1;

volatile unsigned int res1;
volatile unsigned int  res2;

int main(void)
{

  res1 = atomic_fetch_or(, 0x55);

  res2 = atomic_fetch_add(, 0xaa);

  return 0;
}


The next build commands are used

i386-rtems4.12-gcc --pipe -B/opt/rtems4.12/i386-rtems4.12/pc686/lib/ -specs 
bsp_specs -qrtems-I /opt/rtems4.12/i386-rtems4.12/pc686/lib/include 
-march=i386 -Wall  -O2 -g -ffunction-sections -fdata-sections -o 
libatomic-add-test.o -c libatomic-add-test.c

i386-rtems4.12-gcc --pipe -B/opt/rtems4.12/i386-rtems4.12/pc686/lib/ -specs 
bsp_specs -qrtems -mtune=pentiumpro -march=pentium -Wall -O2 -g 
-ffunction-sections -fdata-sections   -Wl,--gc-sections -Wl,-Ttext,0x0010  
libatomic-add-test.o -o libatomic-test-add

problem appears with and without -march=i386, when -march is something
newer (pentium) then all is OK.


Disassembly looks like



00120a76 <__atomic_fetch_add_4>:
  120a76:   55  push   %ebp
  120a77:   89 e5   mov%esp,%ebp
  120a79:   c7 45 10 05 00 00 00movl   $0x5,0x10(%ebp)
  120a80:   5d  pop%ebp
  120a81:   eb f3   jmp120a76 <__atomic_fetch_add_4>

00120a83 <__atomic_add_fetch_4>:
  120a83:   55  push   %ebp
  120a84:   89 e5   mov%esp,%ebp
  120a86:   c7 45 10 05 00 00 00movl   $0x5,0x10(%ebp)
  120a8d:   5d  pop%ebp
  120a8e:   eb e6   jmp120a76 <__atomic_fetch_add_4>

00120a90 <__atomic_fetch_or_4>:
  120a90:   55  push   %ebp
  120a91:   89 e5   mov%esp,%ebp
  120a93:   56  push   %esi
  120a94:   53  push   %ebx
  120a95:   83 ec 0csub$0xc,%esp
  120a98:   8b 5d 08mov0x8(%ebp),%ebx
  120a9b:   53  push   %ebx
  120a9c:   e8 df 66 00 00  call   127180 <_Libatomic_Protect_start>
  120aa1:   8b 33   mov(%ebx),%esi
  120aa3:   8b 55 0cmov0xc(%ebp),%edx
  120aa6:   09 f2   or %esi,%edx
  120aa8:   89 13   mov%edx,(%ebx)
  120aaa:   5a  pop%edx
  120aab:   59  pop%ecx
  120aac:   50  push   %eax
  120aad:   53  push   %ebx
  120aae:   e8 ed 66 00 00  call   1271a0 <_Libatomic_Protect_end>
  120ab3:   8d 65 f8lea-0x8(%ebp),%esp
  120ab6:   89 f0   mov%esi,%eax
  120ab8:   5b  pop%ebx
  120ab9:   5e  pop%esi
  120aba:   5d  pop%ebp
  120abb:   c3  ret




_Libatomic_Protect_start is provided by RTEMS.


00127180 <_Libatomic_Protect_start>:
__uint32_t _Libatomic_Protect_start( void *ptr )
{
  ISR_Level isr_level;

  (void) ptr;
  _ISR_Local_disable( isr_level );
  127180:   9c  pushf
  127181:   fa  cli
  127182:   58  pop%eax
static inline bool _CPU_atomic_Flag_test_and_set( CPU_atomic_Flag *obj, 
CPU_atomic_Order order )
{
#if defined(_RTEMS_SCORE_CPUSTDATOMIC_USE_ATOMIC)
  return obj->test_and_set( order );
#elif defined(_RTEMS_SCORE_CPUSTDATOMIC_USE_STDATOMIC)
  return atomic_flag_test_and_set_explicit( obj, order );
  127183:   b1 01   mov$0x1,%cl
  127185:   8d 74 26 00 lea0x0(%esi,%eiz,1),%esi
  127189:   8d bc 27 00 00 00 00lea0x0(%edi,%eiz,1),%edi
  127190:   88 ca   mov%cl,%dl
  127192:   86 15 8c 85 13 00   xchg   %dl,0x13858c

#if defined(RTEMS_SMP)
  while (
  127198:   84 d2   test   %dl,%dl
  12719a:   75 f4   jne127190 
<_Libatomic_Protect_start+0x10>

[PATCH 3/3] libchip/network/if_fxp.c: do not use rtems_interrupt_disable.

[pisa]

From: Pavel Pisa <p...@cmp.felk.cvut.cz>

The single write to memory or ioport output are mostly
atomic operations already. The proper memory synchronization barrier
should be used around them to guarantee ordering (sync or eieio
on PowerPC for example) but because I have not found settable
portable primitive only compiler barrier is used.
It should be enough on x86 because the externally visible order
should be/is guaranteed to be preserved on x86 architecture.
---
 c/src/libchip/network/if_fxp.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/c/src/libchip/network/if_fxp.c b/c/src/libchip/network/if_fxp.c
index 4d9d983..c2ca419 100644
--- a/c/src/libchip/network/if_fxp.c
+++ b/c/src/libchip/network/if_fxp.c
@@ -1130,7 +1130,6 @@ fxp_start(struct ifnet *ifp)
 {
struct fxp_softc *sc = ifp->if_softc;
struct fxp_cb_tx *txp;
-   rtems_interrupt_level level;
 
DBGLVL_PRINTK(3,"fxp_start called\n");
 
@@ -1279,10 +1278,10 @@ tbdinit:
/*
 * reenable interrupts
 */
-   rtems_interrupt_disable (level);
+   RTEMS_COMPILER_MEMORY_BARRIER();
CSR_WRITE_1(sc, FXP_CSR_SCB_INTRCNTL,0);
bsp_interrupt_vector_enable(sc->irq_num);
-   rtems_interrupt_enable (level);
+   RTEMS_COMPILER_MEMORY_BARRIER();
 }
 
 /*
@@ -1311,7 +1310,6 @@ static void fxp_daemon(void *xsc)
struct ifnet *ifp = >sc_if;
u_int8_t statack;
rtems_event_set events;
-   rtems_interrupt_level level;
 
 #ifdef NOTUSED
if (sc->suspended) {
@@ -1458,10 +1456,9 @@ rcvloop:
  /*
   * reenable interrupts
   */
- rtems_interrupt_disable (level);
+ RTEMS_COMPILER_MEMORY_BARRIER();
  CSR_WRITE_1(sc, FXP_CSR_SCB_INTRCNTL,0);
- bsp_interrupt_vector_enable(sc->irq_num);
- rtems_interrupt_enable (level);
+ RTEMS_COMPILER_MEMORY_BARRIER();
}
 }
 
-- 
1.9.1

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

[PATCH 1/3] bsps/i386: replace global interrupt disable by SMP build supporting locking.

[pisa]

From: Pavel Pisa <p...@cmp.felk.cvut.cz>

---
 c/src/lib/libbsp/i386/pc386/clock/ckinit.c | 19 ++---
 c/src/lib/libbsp/i386/pc386/console/inch.c | 10 +++--
 c/src/lib/libbsp/i386/pc386/console/keyboard.c | 55 --
 c/src/lib/libbsp/i386/pc386/console/vt.c   | 13 +++---
 c/src/lib/libbsp/i386/pc386/include/bsp.h  |  5 +++
 c/src/lib/libbsp/i386/pc386/timer/timer.c  | 45 ++---
 c/src/lib/libbsp/i386/shared/irq/idt.c | 34 ++--
 c/src/lib/libbsp/i386/shared/irq/irq.c | 32 ++-
 c/src/lib/libbsp/i386/shared/irq/irq_init.c|  7 +++-
 9 files changed, 148 insertions(+), 72 deletions(-)

diff --git a/c/src/lib/libbsp/i386/pc386/clock/ckinit.c 
b/c/src/lib/libbsp/i386/pc386/clock/ckinit.c
index 67f4bf7..e7fe50a 100644
--- a/c/src/lib/libbsp/i386/pc386/clock/ckinit.c
+++ b/c/src/lib/libbsp/i386/pc386/clock/ckinit.c
@@ -84,15 +84,18 @@ static uint32_t pc386_get_timecount_i8254(struct 
timecounter *tc)
 {
   uint32_t irqs;
   uint8_t  lsb, msb;
-  rtems_interrupt_levellevel;
+  rtems_interrupt_lock_context lock_context;
 
   /*
* Fetch all the data in an interrupt critical section.
*/
-  rtems_interrupt_disable(level);
+
+  rtems_interrupt_lock_acquire(_i386_i8254_access_lock, _context);
+
 READ_8254(lsb, msb);
 irqs = Clock_driver_ticks;
-  rtems_interrupt_enable(level);
+
+  rtems_interrupt_lock_release(_i386_i8254_access_lock, _context);
 
   return (irqs + 1) * pc386_microseconds_per_isr - ((msb << 8) | lsb);
 }
@@ -141,6 +144,7 @@ static void calibrate_tsc(void)
 
 static void clockOn(void)
 {
+  rtems_interrupt_lock_context lock_context;
   pc386_isrs_per_tick= 1;
   pc386_microseconds_per_isr = rtems_configuration_get_microseconds_per_tick();
 
@@ -150,8 +154,6 @@ static void clockOn(void)
   }
   pc386_clock_click_count = US_TO_TICK(pc386_microseconds_per_isr);
 
-  bsp_interrupt_vector_enable( BSP_PERIODIC_TIMER - BSP_IRQ_VECTOR_BASE );
-
   #if 0
 printk( "configured usecs per tick=%d \n",
   rtems_configuration_get_microseconds_per_tick() );
@@ -160,9 +162,13 @@ static void clockOn(void)
 printk( "final timer counts=%d\n", pc386_clock_click_count );
   #endif
 
+  rtems_interrupt_lock_acquire(_i386_i8254_access_lock, _context);
   outport_byte(TIMER_MODE, TIMER_SEL0|TIMER_16BIT|TIMER_RATEGEN);
   outport_byte(TIMER_CNTR0, pc386_clock_click_count >> 0 & 0xff);
   outport_byte(TIMER_CNTR0, pc386_clock_click_count >> 8 & 0xff);
+  rtems_interrupt_lock_release(_i386_i8254_access_lock, _context);
+
+  bsp_interrupt_vector_enable( BSP_PERIODIC_TIMER - BSP_IRQ_VECTOR_BASE );
 
   /*
* Now calibrate cycles per tick. Do this every time we
@@ -174,10 +180,13 @@ static void clockOn(void)
 
 static void clockOff(void)
 {
+  rtems_interrupt_lock_context lock_context;
+  rtems_interrupt_lock_acquire(_i386_i8254_access_lock, _context);
   /* reset timer mode to standard (BIOS) value */
   outport_byte(TIMER_MODE, TIMER_SEL0 | TIMER_16BIT | TIMER_RATEGEN);
   outport_byte(TIMER_CNTR0, 0);
   outport_byte(TIMER_CNTR0, 0);
+  rtems_interrupt_lock_release(_i386_i8254_access_lock, _context);
 } /* Clock_exit */
 
 bool Clock_isr_enabled = false;
diff --git a/c/src/lib/libbsp/i386/pc386/console/inch.c 
b/c/src/lib/libbsp/i386/pc386/console/inch.c
index 047269e..f5d5079 100644
--- a/c/src/lib/libbsp/i386/pc386/console/inch.c
+++ b/c/src/lib/libbsp/i386/pc386/console/inch.c
@@ -260,13 +260,17 @@ int BSP_wait_polled_input(void)
 int rtems_kbpoll( void )
 {
   intrc;
-  rtems_interrupt_level level;
 
-  rtems_interrupt_disable(level);
+  /*
+   * The locking or disable of interrupts does not help
+   * there because if interrupts are enabled after leave of this
+   * function the state can change without notice anyway.
+   */
+  RTEMS_COMPILER_MEMORY_BARRIER();
 
   rc = ( kbd_first != kbd_last ) ? TRUE : FALSE;
 
-  rtems_interrupt_enable(level);
+  RTEMS_COMPILER_MEMORY_BARRIER();
 
   return rc;
 }
diff --git a/c/src/lib/libbsp/i386/pc386/console/keyboard.c 
b/c/src/lib/libbsp/i386/pc386/console/keyboard.c
index 3a33c54..0c8991b 100644
--- a/c/src/lib/libbsp/i386/pc386/console/keyboard.c
+++ b/c/src/lib/libbsp/i386/pc386/console/keyboard.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define SIZE(x) (sizeof(x)/sizeof((x)[0]))
 
@@ -28,59 +29,53 @@
 #define KBD_DEFLOCK 0
 #endif
 
-static int set_bit(int nr, unsigned long * addr)
+static int kbd_test_and_set_bit(int nr, atomic_uint_least32_t * addr)
 {
-  int   mask;
+  uint_least32_tmask;
   int   retval;
-  rtems_interrupt_level level;
 
   addr += nr >> 5;
-  mask = 1 << (nr & 0x1f);
-  rtems_interrupt_disable(level);
-retval = (mask & *addr) != 0;
-*addr |= mask;
-  rtems_interrupt_enable(level);
+  mask = 1UL << (nr & 0x1f);
+
+  re

[PATCH 0/3] bsps/i386: updates to allow SMP build of x86 BSP

[pisa]

From: Pavel Pisa <p...@cmp.felk.cvut.cz>

The elimination of global interrupt lock is necessity condition
but far from being sufficient for RTEMS x86 SMP support.

Provided changes allows to build i386 BSP with configure
option --enable-smp. The build BSP runs in UP and SMP
configurations on QEMU when only one/boot CPU is used.
Testing with more CPUs has not been done and I expect
that fundamental parts of code are missing.

IRQ processing of i8259 interrupts could be sufficient
for SMP configuration now when legacy interrupts
are routed to single core only.

But there is missing mechanism to wait for finishing
interrupt service routine running on one CPU when
interrupt disable is called on another CPU.

Local, IO APIC and MSI interrupts seems to be missing.

Pavel Pisa (3):
  bsps/i386: replace global interrupt disable by SMP build supporting
locking.
  bsps/i386: use Pentimum instructions for pc586 and pc686 builds.
  libchip/network/if_fxp.c: do not use rtems_interrupt_disable.

 c/src/lib/libbsp/i386/pc386/clock/ckinit.c| 19 +---
 c/src/lib/libbsp/i386/pc386/console/inch.c| 10 +++--
 c/src/lib/libbsp/i386/pc386/console/keyboard.c| 55 +++
 c/src/lib/libbsp/i386/pc386/console/vt.c  | 13 +++---
 c/src/lib/libbsp/i386/pc386/include/bsp.h |  5 +++
 c/src/lib/libbsp/i386/pc386/make/custom/pc586.cfg |  2 +-
 c/src/lib/libbsp/i386/pc386/make/custom/pc686.cfg |  2 +-
 c/src/lib/libbsp/i386/pc386/timer/timer.c | 45 ---
 c/src/lib/libbsp/i386/shared/irq/idt.c| 34 +-
 c/src/lib/libbsp/i386/shared/irq/irq.c| 32 +
 c/src/lib/libbsp/i386/shared/irq/irq_init.c   |  7 ++-
 c/src/libchip/network/if_fxp.c| 11 ++---
 12 files changed, 154 insertions(+), 81 deletions(-)

-- 
1.9.1

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

[PATCH 2/3] bsps/i386: use Pentimum instructions for pc586 and pc686 builds.

[pisa]

From: Pavel Pisa <p...@cmp.felk.cvut.cz>

When GCC option -march is not specifies i386-rtems toolchain
defaults to i386 architecture instruction set. It does not
provide atomic instructions which results in really inefficient
atomic_fetch_or even on UP build.

SMP build is broken with i386 set because libatomic and GCC
generate infinite loop for __atomic_fetch_add_4 used
in rtems_interrupt_lock_acquire

__atomic_fetch_add_4:
push   %ebp
mov%esp,%ebp
movl   $0x5,0x10(%ebp)
pop%ebp
jmp__atomic_fetch_add_4
---
 c/src/lib/libbsp/i386/pc386/make/custom/pc586.cfg | 2 +-
 c/src/lib/libbsp/i386/pc386/make/custom/pc686.cfg | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/c/src/lib/libbsp/i386/pc386/make/custom/pc586.cfg 
b/c/src/lib/libbsp/i386/pc386/make/custom/pc586.cfg
index 73e42cd..6f9cfcb 100644
--- a/c/src/lib/libbsp/i386/pc386/make/custom/pc586.cfg
+++ b/c/src/lib/libbsp/i386/pc386/make/custom/pc586.cfg
@@ -6,7 +6,7 @@ RTEMS_CPU_MODEL=pentium
 
 #  This contains the compiler options necessary to select the CPU model
 #  and (hopefully) optimize for it.
-CPU_CFLAGS = -mtune=pentium
+CPU_CFLAGS = -mtune=pentium -march=pentium
 
 include $(RTEMS_ROOT)/make/custom/pc386.cfg
 
diff --git a/c/src/lib/libbsp/i386/pc386/make/custom/pc686.cfg 
b/c/src/lib/libbsp/i386/pc386/make/custom/pc686.cfg
index 04f001f..b27e8ae 100644
--- a/c/src/lib/libbsp/i386/pc386/make/custom/pc686.cfg
+++ b/c/src/lib/libbsp/i386/pc386/make/custom/pc686.cfg
@@ -6,7 +6,7 @@ RTEMS_CPU_MODEL=pentiumpro
 
 #  This contains the compiler options necessary to select the CPU model
 #  and (hopefully) optimize for it.
-CPU_CFLAGS = -mtune=pentiumpro
+CPU_CFLAGS = -mtune=pentiumpro -march=pentium
 
 include $(RTEMS_ROOT)/make/custom/pc386.cfg
 
-- 
1.9.1

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

Re: [PATCH] bsps/i386: Separate variable for i8259 IRQs disable due to in progress state.

[Pavel Pisa]

On Sunday 25 of September 2016 02:48:03 Pavel Pisa wrote:
> From: Pavel Pisa <p...@cmp.felk.cvut.cz>
>
> The global state of enabled and disabled interrupts has to hold
> interrupts really disabled by drivers and system. If the state is
> combined with interrupts temporarily disabled because they are
> processed at given time then it is impossible to maintain state
> by interrupt handlers in drivers.

I have added compiler barrier to make code fully correct
for UP

@@ -346,6 +362,7 @@ void BSP_dispatch_isr(int vector)
  */
 irq_count[vector]++;
 
+RTEMS_COMPILER_MEMORY_BARRIER();
 /*
  * Allow nesting.
  */
@@ -358,6 +375,8 @@ void BSP_dispatch_isr(int vector)
  */
 __asm__ __volatile__("cli");
 
+RTEMS_COMPILER_MEMORY_BARRIER();
+

and I have tested in on real HW, without networking
because I do have there classic PCI E100 card.
But ticker and my projects including VESA graphics
seems to run correctly.

Have somebody else found time to test the code?
Some testing with serial ports (ideally multiple)
would help there. Even that there is risk of some
problems I think that step in this direction
is necessary.

Branch including even VirtIO can be found on my GitHub
sandbox

  https://github.com/ppisa/rtems/tree/devel-virtio

I think that i8259 IRQs is needed for mainline and it
would worth to push change.

I can prepare and push or send for review trivial
followup patch to replace

rtems_interrupt_disable(level);

by

RTEMS_INTERRUPT_LOCK_DEFINE

rtems_interrupt_lock_acquire

I think that if i8259 interrupts are routed/delivered
to single core only then such setup can be used even
on i386 SMP system when IPI is made working.


Best wishes,

   Pavel


> ---
>  c/src/lib/libbsp/i386/shared/irq/irq.c | 51
> +- 1 file changed, 32 insertions(+), 19
> deletions(-)
>
> diff --git a/c/src/lib/libbsp/i386/shared/irq/irq.c
> b/c/src/lib/libbsp/i386/shared/irq/irq.c index 0511257..8316fe6 100644
> --- a/c/src/lib/libbsp/i386/shared/irq/irq.c
> +++ b/c/src/lib/libbsp/i386/shared/irq/irq.c
> @@ -51,7 +51,22 @@ static enum intr_trigger
> irq_trigger[BSP_IRQ_LINES_NUMBER]; * while upper bits are interrupt on the
> slave PIC.
>   * This cache is initialized in ldseg.s
>   */
> -static rtems_i8259_masks i8259a_cache = 0xFFFB;
> +static rtems_i8259_masks i8259a_imr_cache = 0xFFFB;
> +static rtems_i8259_masks i8259a_in_progress = 0;
> +
> +static inline
> +void BSP_i8259a_irq_update_master_imr( void )
> +{
> +  rtems_i8259_masks mask = i8259a_in_progress | i8259a_imr_cache;
> +  outport_byte( PIC_MASTER_IMR_IO_PORT, mask & 0xff );
> +}
> +
> +static inline
> +void BSP_i8259a_irq_update_slave_imr( void )
> +{
> +  rtems_i8259_masks mask = i8259a_in_progress | i8259a_imr_cache;
> +  outport_byte( PIC_SLAVE_IMR_IO_PORT, ( mask >> 8 ) & 0xff );
> +}
>
>  /*
>   * Print the stats.
> @@ -107,7 +122,7 @@ static inline uint8_t
> BSP_i8259a_irq_in_service_reg(uint32_t ioport)
> /*-
>+
>
>  | Function:  BSP_irq_disable_at_i8259a
>  |  Description: Mask IRQ line in appropriate PIC chip.
>
> -| Global Variables: i8259a_cache
> +| Global Variables: i8259a_imr_cache, i8259a_in_progress
>
>  |Arguments: vector_offset - number of IRQ line to mask.
>  |  Returns: 0 is OK.
>
> 
> +--
>*/ @@ -119,15 +134,15 @@ static int BSP_irq_disable_at_i8259a(const
> rtems_irq_number irqLine) rtems_interrupt_disable(level);
>
>mask = 1 << irqLine;
> -  i8259a_cache |= mask;
> +  i8259a_imr_cache |= mask;
>
>if (irqLine < 8)
>{
> -outport_byte(PIC_MASTER_IMR_IO_PORT, i8259a_cache & 0xff);
> +BSP_i8259a_irq_update_master_imr();
>}
>else
>{
> -outport_byte(PIC_SLAVE_IMR_IO_PORT, (i8259a_cache >> 8) & 0xff);
> +BSP_i8259a_irq_update_slave_imr();
>}
>
>rtems_interrupt_enable(level);
> @@ -138,7 +153,7 @@ static int BSP_irq_disable_at_i8259a(const
> rtems_irq_number irqLine)
> /*-
>+
>
>  | Function:  BSP_irq_enable_at_i8259a
>  |  Description: Unmask IRQ line in appropriate PIC chip.
>
> -| Global Variables: i8259a_cache
> +| Global Variables: i8259a_imr_cache, i8259a_in_progress
>
>  |Arguments: irqLine - number of IRQ line to mask.
>  |  Returns: Nothing.
>
> 
> +--
>*/ @@ -152,19 +167,19 @@ static int BSP_irq_enable_at_i8259a(const
> rtems_irq_number irqLine) rte

Re: Backport of ARM cache, RTL and TMS570 to RTEMS 4.11 Was: Simple question about RTL

[Pavel Pisa]

Hello Chris,

On Tuesday 04 of October 2016 23:10:20 Chris Johns wrote:
> On 04/10/2016 09:51, Pavel Pisa wrote:
> > Hello Chris and Joel,
> >
> > I would like to correct my mistake which breaks RTEMS 4.11 build for
> > non-ARM architectures, as fast as possible. Proposed solution on devel
> > list.
> >
> > [PATCH] libdl/rtl-obj.c: synchronize cache should not depend on
> > CPU_CACHE_LINE_BYTES.
> >
> > [PATCH] bsps/arm: do not introduce CPU_CACHE_LINE_BYTES in 4.11 and
> > correct CPU_STRUCTURE_ALIGNMENT.
> >
> > I have checked 4.11 build with patches for Raspberry Pi 2 and TMS570.
> > including RTL functionality on targets. I have tested 4.11 that it
> > works on TMS570 with lwIP in build without initialization when
> > loaded to SDRAM with external init and standalone RTEMS Flash version
> > which includes complete RTEMS driven initialization.
> >
> > I have tested that i386 builds and checked to run ticker,
> > my dlopen and PCI i82557b/fxp1 betworking tests in QEMU.
> > i386 build has been done mainly to check that I have not
> > introduced problem to non-ARM architectures this time.
>
> Great.
>
> > Do you agree with fixes?
>
> Yes.
>
> > What is your opinion for CPU_CACHE_LINE_BYTES in 4.11.
> > Do you agree/prefer that it should not be introduced back
> > (which I have done by mistake) and kept as 4.12 specific?
>
> I agree it should not be introduced back into 4.11.

OK, I have pushed changes to 4.11 and I have changed master
to use the same rtems_cache_get_maximal_line_size() in RTL
as is used 4.11 now to have support consistent between branches
and have chance to catch eventual problem even on master.

Best wishes,

  Pavel

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

Re: Update Atsam BSP Support

[Pavel Pisa]

Hello Gedare and Alexander,

one possible solution to keep that in sync.

Change of README in BSP directory
to MarkDown or Rest-Text syntax and put on the web
generated pages synced directly from master and last stable.

On the other hand, wiki allows to include more information
and relation links.

Best wishes,

Pavel

On Tuesday 04 of October 2016 15:21:46 Gedare Bloom wrote:
> Thanks. does this BSP have a wiki page? If not, it would be good to
> make one for it. Generally we need to do a better job of keeping a
> web-visible "feature set" up to date.
>
> On Tue, Oct 4, 2016 at 7:39 AM, Alexander Krutwig
>
>  wrote:
> > Hello,
> >
> > over the last months, lots of work and effort has been put into the
> > development
> > of the BSP support for ATSAMV7 microcontrollers by Atmel.
> > Thus, I updated the README of the BSP with the work already done in the
> > process and
> > attached it to this email in order to keep you updated about the
> > progress.
> >
> > In addition to the work described in the document, we currently work on
> > USB and SD-card
> > support. Support for NOR flashes is already finished, however, not yet
> > committed.
> >
> > Best regards,
> > Alexander Krutwig
> >
> > --
> > 
> > embedded brains GmbH
> > Alexander Krutwig
> > Dornierstr. 4
> > D-82178 Puchheim
> > Germany
> > email: alexander.krut...@embedded-brains.de
> > Phone: +49-89-18 94 741 - 17
> > Fax:   +49-89-18 94 741 - 09
> > 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
>
> ___
> 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: Backport of ARM cache, RTL and TMS570 to RTEMS 4.11 Was: Simple question about RTL

[Pavel Pisa]

Hello Chris and Joel,

I would like to correct my mistake which breaks RTEMS 4.11 build for non-ARM
architectures, as fast as possible. Proposed solution on devel list.

[PATCH] libdl/rtl-obj.c: synchronize cache should not depend on 
CPU_CACHE_LINE_BYTES.

[PATCH] bsps/arm: do not introduce CPU_CACHE_LINE_BYTES in 4.11 and correct 
CPU_STRUCTURE_ALIGNMENT.

I have checked 4.11 build with patches for Raspberry Pi 2 and TMS570.
including RTL functionality on targets. I have tested 4.11 that it
works on TMS570 with lwIP in build without initialization when
loaded to SDRAM with external init and standalone RTEMS Flash version
which includes complete RTEMS driven initialization.

I have tested that i386 builds and checked to run ticker,
my dlopen and PCI i82557b/fxp1 betworking tests in QEMU.
i386 build has been done mainly to check that I have not
introduced problem to non-ARM architectures this time.

Do you agree with fixes?
What is your opinion for CPU_CACHE_LINE_BYTES in 4.11.
Do you agree/prefer that it should not be introduced back
(which I have done by mistake) and kept as 4.12 specific?

Best wishes,

   Pavel

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

[PATCH] bsps/arm: do not introduce CPU_CACHE_LINE_BYTES in 4.11 and correct CPU_STRUCTURE_ALIGNMENT.

[Pavel Pisa]

---
 cpukit/score/cpu/arm/rtems/score/cpu.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/cpukit/score/cpu/arm/rtems/score/cpu.h 
b/cpukit/score/cpu/arm/rtems/score/cpu.h
index 25d4ee2..69838c5 100644
--- a/cpukit/score/cpu/arm/rtems/score/cpu.h
+++ b/cpukit/score/cpu/arm/rtems/score/cpu.h
@@ -146,13 +146,11 @@
 #define CPU_STACK_GROWS_UP FALSE
 
 #if defined(ARM_MULTILIB_CACHE_LINE_MAX_64)
-  #define CPU_CACHE_LINE_BYTES 32
+  #define CPU_STRUCTURE_ALIGNMENT __attribute__ ((aligned ( 64 )))
 #else
-  #define CPU_CACHE_LINE_BYTES 64
+  #define CPU_STRUCTURE_ALIGNMENT __attribute__ ((aligned ( 32 )))
 #endif
 
-#define CPU_STRUCTURE_ALIGNMENT __attribute__ ((aligned (CPU_CACHE_LINE_BYTES 
)))
-
 #define CPU_TIMESTAMP_USE_STRUCT_TIMESPEC TRUE
 
 /*
-- 
1.9.1

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

[PATCH] libdl/rtl-obj.c: synchronize cache should not depend on CPU_CACHE_LINE_BYTES.

[Pavel Pisa]

The CPU_CACHE_LINE_BYTES has been introduced after 4.11 branch
fork and is not available for all architectures on RTEMS 4.11.

Use of rtems_cache_get_maximal_line_size() is more descriptive
choice. The min/max data/instruction cache line size is not critical
there, value is used for optimization only to use single operation
for decently following sections.
---
 cpukit/libdl/rtl-obj.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/cpukit/libdl/rtl-obj.c b/cpukit/libdl/rtl-obj.c
index f61d4e5..bdcebce 100644
--- a/cpukit/libdl/rtl-obj.c
+++ b/cpukit/libdl/rtl-obj.c
@@ -566,6 +566,7 @@ typedef struct
   uint32_t mask;
   void *start_va;
   void *end_va;
+  size_t   cache_line_size;
 } rtems_rtl_obj_sect_sync_ctx_t;
 
 static bool
@@ -582,10 +583,10 @@ rtems_rtl_obj_sect_sync_handler (rtems_chain_node* node, 
void* data)
   if (sync_ctx->end_va == sync_ctx->start_va) {
 sync_ctx->start_va = sect->base;
   } else {
-old_end = (uintptr_t)sync_ctx->end_va & ~(CPU_CACHE_LINE_BYTES - 1);
-new_start = (uintptr_t)sect->base & ~(CPU_CACHE_LINE_BYTES - 1);
+old_end = (uintptr_t)sync_ctx->end_va & ~(sync_ctx->cache_line_size - 1);
+new_start = (uintptr_t)sect->base & ~(sync_ctx->cache_line_size - 1);
 if ( (sect->base <  sync_ctx->start_va) ||
- (new_start - old_end > CPU_CACHE_LINE_BYTES) ) {
+ (new_start - old_end > sync_ctx->cache_line_size) ) {
   rtems_cache_instruction_sync_after_code_change(sync_ctx->start_va,
  sync_ctx->end_va - sync_ctx->start_va + 1);
   sync_ctx->start_va = sect->base;
@@ -605,6 +606,8 @@ rtems_rtl_obj_synchronize_cache (rtems_rtl_obj_t*obj)
   if (rtems_cache_get_instruction_line_size() == 0)
 return;
 
+  sync_ctx.cache_line_size = rtems_cache_get_maximal_line_size();
+
   sync_ctx.mask = RTEMS_RTL_OBJ_SECT_TEXT | RTEMS_RTL_OBJ_SECT_CONST |
   RTEMS_RTL_OBJ_SECT_DATA | RTEMS_RTL_OBJ_SECT_BSS |
   RTEMS_RTL_OBJ_SECT_EXEC;
-- 
1.9.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Bacport of ARM cache, RTL and TMS570 to RTEMS 4.11 Was: Simple question about RTL

[Pavel Pisa]

Hello Alan,

thanks much for test.

On Monday 03 of October 2016 03:40:46 Alan Cudmore wrote:
> Hi Pavel,
> I have built the Raspberry Pi 1 and 2 BSPs with the latest 4.11 branch. I
> plan on testing them soon.
>
> I also tried to build the 4.11 sparc/sis BSP, but it failed to compile:
> ../../../../../../../rtems-src/rtems-4.11/c/src/../../cpukit/libdl/rtl-obj.
>c:585:47: error: 'CPU_CACHE_LINE_BYTES' undeclared (first use in this
> function) old_end = (uintptr_t)sync_ctx->end_va & ~(CPU_CACHE_LINE_BYTES -
> 1);
>
> It looks like rtl-obj.c uses CPU_CACHE_LINE_BYTES, but a grep only shows
> that is defined for ARM.

This bug falls on my head. I have not noticed that it is not defined
on 4.11 same as on the master.

I have introduced that for ARM to change hardcodded aligned
to 4.12 style. The right think id probably to return this to hardcoded
value

#if defined(ARM_MULTILIB_CACHE_LINE_MAX_64)
  #define CPU_CACHE_LINE_BYTES 32
#else
  #define CPU_CACHE_LINE_BYTES 64
#endif

#define CPU_STRUCTURE_ALIGNMENT __attribute__ ((aligned (CPU_CACHE_LINE_BYTES 
)))


> Do we need to back port these defines for the other CPU architectures as
> well?

As for RTL, the line size is used only for optimization, merging
directly following sections to the single region so it is not critical
if value is instruction/data cache line max/min

old_end = (uintptr_t)sync_ctx->end_va & ~(CPU_CACHE_LINE_BYTES - 1);
new_start = (uintptr_t)sect->base & ~(CPU_CACHE_LINE_BYTES - 1);
if ( (sect->base <  sync_ctx->start_va) ||

So any value returned from the cache manager can be used there

  rtems_cache_get_maximal_line_size()

  rtems_cache_get_instruction_line_size()

  rtems_cache_get_data_line_size()

I would would prefer rtems_cache_get_maximal_line_size()
and to use this for both master and 4.11 to keep consistency.

What is preferred change for CPU_CACHE_LINE_BYTES removal from 4.11 ARM?
I am inclined it to remove it to ensure same behavior over all architectures.
Introduction would help with compatibility but it I think that other 
architectures
should not be touched by this ARM bring up.

Best wishes,

Pavel


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

Bacport of ARM cache, RTL and TMS570 to RTEMS 4.11 Was: Simple question about RTL

[Pavel Pisa]

Hello all,

I have pushed massive update to RTEMS-4.11 ARM BSPs
support. The cache manager and RTL update has been
prepared in response to RTL failures reported by Tim Tian
on Zynq BSP more than month ago. I have proposed
4.11 update series at September 9.

  https://github.com/ppisa/rtems/tree/4.11-arm-update

Code has been tested by Alan Cudmore and more RPi
versions and correction of Zynq problem has been reported
as well. Because there has not been reported any
problem on master nor on my 4.11-arm-update branch
I have pushed changes to official 4.11 tree.

Please, check on more BSPs and applications
if all works correctly.

I have pushed TMS570 backport from master to 4.11 as well,
there has been critical problem corrected on master


#2794 ARM TMS570 BSP: Serial port hangs when baudrate change
  initiates before all characters are sent

and the rest of updates is required to boot RTEMS
on TMS570LS3137 without separate loader or mixing
code with other sources.

I expect to do some more testing of 4.11 on TMS570 HW
next week.

>From my side, I think that RTEMS 4.11 branch is in the
state where release can report Raspberry Pi 1, 2
and TMS570 as supported now.

Best wishes,

 Pavel

On Tuesday 06 of September 2016 09:28:42 Pavel Pisa wrote:
> Hello Chris,
>
> On Tuesday 06 of September 2016 07:12:53 Chris Johns wrote:
> > Hi Tim and Pavel,
> >
> > Thank you for the patches and testing. I will have a chat to Joel
> > tomorrow about the patches and what we will do. If Joel agrees I may
> > test and push the patches.
> >
> > FYI I am currently looking at #2767 which is reported against 4.11 and a
> > zynq so there is real interest on these patches ending up on 4.11.
> >
> > Chris
>
> I have made 4.11 to boot on Raspberry Pi.
>
> The final patch
>
>   arm/raspberrypi: minimized mainline patch move MMU in front of
> application image and correct RPi2 boot on 4.11 branch.
> https://github.com/ppisa/rtems/commit/984047e8295bb82b12700edb3aac911bd8427
>8af
>
> of branch
>
>   https://github.com/ppisa/rtems/tree/4.11-arm-update
>
> series.
>
> Tickets
>
>   https://devel.rtems.org/ticket/2783
>
>   https://devel.rtems.org/ticket/2782
>
> At least one of these tickets can be assigned to all patches
> in this backports branch.
>
> I have to move to other tasks today to have students exams prepared
> and to have resources to pay our company bills.
>
> I understand that modifications are huge for 4.11 
>
> If there is interrest I can resend series to mainlinglist
> when I return from our potential customers meeting.
>
> Best wishes,
>
>   Pavel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Unify CORE mutex seize/surrender

[Pavel Pisa]

Hello Sebastian,

On Wednesday 28 of September 2016 11:06:19 Sebastian Huber wrote:
> On 28/09/16 10:47, Sebastian Huber wrote:
> > On 28/09/16 10:38, Pavel Pisa wrote:
> >> Hello Sebastian and Gedare,
> >>
> >> I cannot hold myself to not express my opinion there.
> >>
> >> On Wednesday 28 of September 2016 07:52:51 Sebastian Huber wrote:
> >>> On 27/09/16 16:59, Gedare Bloom wrote:
> >>>> A mostly unrelated question: why do we have two different
> >>>> _Semaphore_Get functions, one static in score/src/semaphore.c and the
> >>>> other inlined from semimpl.h?
> >>>
> >>> Yes, this is a bit confusing. One is part of the Classic API, the other
> >>> is for the self-contained semaphores.
> >>
> >> what is the reason to name these self-contained semaphores.
> >
> > the name "self-contained" is used for objects which work with a user
> > supplied storage.  For example:
> >
> > https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib
> >/libc/sys/rtems/include/sys/lock.h;h=c261adf681e542af945969149f6533248eb06
> >fd6;hb=HEAD
> >
> >
> > In contrast to the Classic and POSIX objects which work with a kernel
> > supplied storage which is accessed via the object identifier.
> >
> > In the context of the Newlib  a "semaphore" is a counting
> > semaphore.
>
> In case the name "self-contained" is confusing for this purpose, then I
> am happy to replace it with a better alternative.

No, I like self-contained, I have no problem with that. It describes
how it works. I have problem with SEMPAHORE part because
it associates for me with IPC/inter thread even delivery, producer
consumer pattern. Not mutual exclusion of enter to given code.

Excuse for confussing specification of the naming note.

Best wishes,

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

Re: [PATCH] score: Unify CORE mutex seize/surrender

[Pavel Pisa]

Hello Sebastian and Gedare,

I cannot hold myself to not express my opinion there.

On Wednesday 28 of September 2016 07:52:51 Sebastian Huber wrote:
> On 27/09/16 16:59, Gedare Bloom wrote:
> > A mostly unrelated question: why do we have two different
> > _Semaphore_Get functions, one static in score/src/semaphore.c and the
> > other inlined from semimpl.h?
>
> Yes, this is a bit confusing. One is part of the Classic API, the other
> is for the self-contained semaphores.

what is the reason to name these self-contained semaphores.
If they cannot be used as signaling mechanism between threads,
then they should be called mutexes to clearly state,
that the only valid use is initialize it as full,
gain and release it from the same thread.

For me, even use of simple, full binary etc.. semaphores
in the classic RTEMS API is a problem. There is semaphore
and mutex and each has different semantic and rules.

I understand, that historically semaphore has more meaning
as the way to pass only one task or limited number of tasks
to given part of the road, but today meaning is settled.

So if the self-contained x cannot be used to signal event
between threads then it is mutex. If there is plan to
use self-contained x even like futex/conditional variable
etc., then situation is more complex and it has reason
to have some naming layer working with semaphore or futex
stem but programmer should get clear mutex named primitives
at the end. Which is what POSIX does. Linux kernel internal
APIs cured this confusion some time ago as well.

And even rtems_* API should include mutex operations.
It is clear and it is not necessary to complicate
documentation then what is allowed and what is not
with each semaphore flags combination.

Best wishes,

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

Re: [PATCH] bsps/i386: Separate variable for i8259 IRQs disable due to in progress state.

[Pavel Pisa]

Hello Chris,

On Sunday 25 of September 2016 03:24:06 Chris Johns wrote:
> Hi Pavel,
>
> Thank you for this. What testing has the patch had?

Only QEMU, serial and E100 and VirtIO NIC.
So I agree that testing on the real HW is a must.
We have some test PCs with remote booting and monitoring
at university. But I am not sure if when I get to that.
But I am not sure which IRQ sources could be used there
to flood RTEMS. NIC are special Intel IEEE-1588 equipped
ones so probably unsupported by RTEMS.

So if you have hardware which has been used in past
to debug IRQs then it would be of more value.

> >*/
> > -static rtems_i8259_masks i8259a_cache = 0xFFFB;
> > +static rtems_i8259_masks i8259a_imr_cache = 0xFFFB;
> > +static rtems_i8259_masks i8259a_in_progress = 0;
>
> Should these be volatile to be sure?

The i8259a_cache has not been and because these and i8259
registers accesses from enable/disable are protected
by rtems_interrupt_disable() then they should be full
barrier even in SMP respect.

In the IRQ processing, there is only plain

  __asm__ __volatile__("sti");

which brings me to conclusion now that this is problematic
not only in the respect of these two variables but
all other state. So there should be added at least
compiler barrier even for UP build before sti
and after cli.

It could be more interesting to change variables
to atomic but i8259 registers accesses has to be
serialized and generally any interaction with i8259
is catastrophic from the performance point of view.
Using it in SMP case is allmost impossible so this
whole part should have better, local APIC based
alternative ideally combined with MSI interrupts
for modern systems.

So cli and sti is minimal performance problem there
and volatile alone is unusable.

> > +
> > @@ -365,11 +380,9 @@ void BSP_dispatch_isr(int vector)
> >  * again.
> >  */
> > if (vector <= BSP_IRQ_MAX_ON_i8259A) {
> > -if (irq_trigger[vector] == INTR_TRIGGER_LEVEL)
> > -  old_imr |= 1 << vector;
>
> Looking at the interrupt server I see a disable in the trigger call
> which means it should be ok to remove this code. I am wondering if this
> piece of code is an artefact of the comparison of the code in FreeBSD I
> did which always uses an interrupt server and may assume the interrupt
> is masked.

Yes, I have checked that before patch sending too and server
looks to be implemented portable and correctly.

Best wishes,

  Pavel

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

Re: VirtIO based network driver works well after i8259 masks maintenance correction

[Pavel Pisa]

Hello Jin-Hyun Kim, Hyun-Wook Jin  and others,

I have returned back to VirtIO based network driver
after I have make PCI based E100 card work by woraround
which re-enables IRQ in driver worker daemon.

In meanwhile, I have included alternative networking setup
with E100 to RTEMS QEMU Wiki page

https://devel.rtems.org/wiki/Developer/Simulators/QEMU#Inteli82557be100PCICardEmulation

I have cleaned a VirtIO driver a little but including
IRQ workaround would be really complicated in this case.
Interrupt source signalling is cleaned by inport_byte
from corresponding VIRTIO_PCI_ISR. But if interrupt
is disabled on controller level by i8259 then reenable
would to be moved to rtems_bsdnet worker thread.
But that would violate all ideas about separation
of layers and encapsulation. Not by one, but over three
levels. So I have corrected (at least according my feeling)
i8259 IRQ processing.

The VirtIO networking seems to work great with this fix.
There is updated VirtIO support on branch "devel-virtio"
of my GitHub repository

  https://github.com/ppisa/rtems/tree/devel-virtio

I would like express big thanks to authors that they
have contributed port.

The last time there has not been reached final decision
if the code should be included in RTEMS or if there is
plug on old networking stack.

I think that it works well and can be used before
there is other alternative location for the code.

As for the code, I would be happy if it can be moved
out of i386 BSP directory or at least that part which
is independent if there is some i386 specific code.
But it uses generic IRQ now, generic PCI so it
should be usable with all other architectures.

There is even another reason why to included virtio
support. It can be used (if extended) even for providing
disk device to the virtualized environment and this
part probably stays in core RTEMS codebase even if
libbsd is used for networking.

Best wishes,

   Pavel

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

[PATCH] bsps/i386: Separate variable for i8259 IRQs disable due to in progress state.

[Pavel Pisa]

From: Pavel Pisa <p...@cmp.felk.cvut.cz>

The global state of enabled and disabled interrupts has to hold
interrupts really disabled by drivers and system. If the state is
combined with interrupts temporarily disabled because they are
processed at given time then it is impossible to maintain state
by interrupt handlers in drivers.
---
 c/src/lib/libbsp/i386/shared/irq/irq.c | 51 +-
 1 file changed, 32 insertions(+), 19 deletions(-)

diff --git a/c/src/lib/libbsp/i386/shared/irq/irq.c 
b/c/src/lib/libbsp/i386/shared/irq/irq.c
index 0511257..8316fe6 100644
--- a/c/src/lib/libbsp/i386/shared/irq/irq.c
+++ b/c/src/lib/libbsp/i386/shared/irq/irq.c
@@ -51,7 +51,22 @@ static enum intr_trigger irq_trigger[BSP_IRQ_LINES_NUMBER];
  * while upper bits are interrupt on the slave PIC.
  * This cache is initialized in ldseg.s
  */
-static rtems_i8259_masks i8259a_cache = 0xFFFB;
+static rtems_i8259_masks i8259a_imr_cache = 0xFFFB;
+static rtems_i8259_masks i8259a_in_progress = 0;
+
+static inline
+void BSP_i8259a_irq_update_master_imr( void )
+{
+  rtems_i8259_masks mask = i8259a_in_progress | i8259a_imr_cache;
+  outport_byte( PIC_MASTER_IMR_IO_PORT, mask & 0xff );
+}
+
+static inline
+void BSP_i8259a_irq_update_slave_imr( void )
+{
+  rtems_i8259_masks mask = i8259a_in_progress | i8259a_imr_cache;
+  outport_byte( PIC_SLAVE_IMR_IO_PORT, ( mask >> 8 ) & 0xff );
+}
 
 /*
  * Print the stats.
@@ -107,7 +122,7 @@ static inline uint8_t 
BSP_i8259a_irq_in_service_reg(uint32_t ioport)
 /*-+
 | Function:  BSP_irq_disable_at_i8259a
 |  Description: Mask IRQ line in appropriate PIC chip.
-| Global Variables: i8259a_cache
+| Global Variables: i8259a_imr_cache, i8259a_in_progress
 |Arguments: vector_offset - number of IRQ line to mask.
 |  Returns: 0 is OK.
 +--*/
@@ -119,15 +134,15 @@ static int BSP_irq_disable_at_i8259a(const 
rtems_irq_number irqLine)
   rtems_interrupt_disable(level);
 
   mask = 1 << irqLine;
-  i8259a_cache |= mask;
+  i8259a_imr_cache |= mask;
 
   if (irqLine < 8)
   {
-outport_byte(PIC_MASTER_IMR_IO_PORT, i8259a_cache & 0xff);
+BSP_i8259a_irq_update_master_imr();
   }
   else
   {
-outport_byte(PIC_SLAVE_IMR_IO_PORT, (i8259a_cache >> 8) & 0xff);
+BSP_i8259a_irq_update_slave_imr();
   }
 
   rtems_interrupt_enable(level);
@@ -138,7 +153,7 @@ static int BSP_irq_disable_at_i8259a(const rtems_irq_number 
irqLine)
 /*-+
 | Function:  BSP_irq_enable_at_i8259a
 |  Description: Unmask IRQ line in appropriate PIC chip.
-| Global Variables: i8259a_cache
+| Global Variables: i8259a_imr_cache, i8259a_in_progress
 |Arguments: irqLine - number of IRQ line to mask.
 |  Returns: Nothing.
 +--*/
@@ -152,19 +167,19 @@ static int BSP_irq_enable_at_i8259a(const 
rtems_irq_number irqLine)
   rtems_interrupt_disable(level);
 
   mask = 1 << irqLine;
-  i8259a_cache &= ~mask;
+  i8259a_imr_cache &= ~mask;
 
   if (irqLine < 8)
   {
 isr = BSP_i8259a_irq_in_service_reg(PIC_MASTER_COMMAND_IO_PORT);
 irr = BSP_i8259a_irq_int_request_reg(PIC_MASTER_COMMAND_IO_PORT);
-outport_byte(PIC_MASTER_IMR_IO_PORT, i8259a_cache & 0xff);
+BSP_i8259a_irq_update_master_imr();
   }
   else
   {
 isr = BSP_i8259a_irq_in_service_reg(PIC_SLAVE_COMMAND_IO_PORT);
 irr = BSP_i8259a_irq_int_request_reg(PIC_SLAVE_COMMAND_IO_PORT);
-outport_byte(PIC_SLAVE_IMR_IO_PORT, (i8259a_cache >> 8) & 0xff);
+BSP_i8259a_irq_update_slave_imr();
   }
 
   if (((isr ^ irr) & mask) != 0)
@@ -298,7 +313,7 @@ void BSP_dispatch_isr(int vector);
 
 void BSP_dispatch_isr(int vector)
 {
-  uint16_t old_imr = 0;
+  rtems_i8259_masks in_progress_save = 0;
 
   if (vector < BSP_IRQ_VECTOR_NUMBER) {
 /*
@@ -329,10 +344,10 @@ void BSP_dispatch_isr(int vector)
* vector clear.
*/
   if (vector <= BSP_IRQ_MAX_ON_i8259A) {
-old_imr = i8259a_cache;
-i8259a_cache |= irq_mask_or_tbl[vector];
-outport_byte(PIC_MASTER_IMR_IO_PORT, i8259a_cache & 0xff);
-outport_byte(PIC_SLAVE_IMR_IO_PORT, (i8259a_cache >> 8) & 0xff);
+in_progress_save = i8259a_in_progress;
+i8259a_in_progress |= irq_mask_or_tbl[vector];
+BSP_i8259a_irq_update_master_imr();
+BSP_i8259a_irq_update_slave_imr();
   }
 
   /*
@@ -365,11 +380,9 @@ void BSP_dispatch_isr(int vector)
* again.
*/
   if (vector <= BSP_IRQ_MAX_ON_i8259A) {
-if (irq_trigger[vector] == INTR_TRIGGER_LEVEL)
-  old_imr |= 1 << vector;
-i8259a_cache = old_imr;
-outport_byte(PIC_MASTER

Re: [PATCH 0/5] arm/tms570: include hardware initialization and selftests to run RTEMS directly from Flash without loader on TMS570LS3137 HDK.

[Pavel Pisa]

Hello Gedare,

On Thursday 22 of September 2016 03:26:32 Gedare Bloom wrote:
> I only added a couple of very minor inline comments. Looks good, I
> think you can push directly no one else needs to re-read this
> BSP-specific stuff.

thanks much for reading that huge pieces.

I have corrected some typos and renamed tms570_test_parity*
files to tms570_selftest_parity* to match function names
you proposed.

I have pushed agreed upon patches.
The result builds without single warning form me.
I need testing on HW. But generally there has been
no real code change after last tests. Only style, comments
etc.

MPU patch is left out, it needs to transform from generated
code (bunch of hexa values) to some readable and verifiable
form.

I have not pushed update of SDRAM init as well.

>  c/src/lib/libbsp/arm/tms570/hwinit/init_emif_sdram.c
> @@ -1,5 +1,6 @@
>  #include 
>  #include 
> +#include 
>  #include "tms570_hwinit.h"
>
>  void tms570_emif_sdram_init( void )
> @@ -45,12 +46,21 @@ void tms570_emif_sdram_init( void )
>/* Page Size. This field defines the internal page size of connected
> SDRAM devices. */ sdcr = TMS570_EMIF_SDCR_PAGESIZE_SET( sdcr, 0 ); /*
> elements_256 */
>
> +  _ARM_Data_synchronization_barrier();
> +  _ARM_Instruction_synchronization_barrier();
> +
> @gedare
> gedare 7 hours ago
>
> I think it usually worthwhile to comment why barrier/fence are necessary.

The EMIF/SDRAM address range can be/is on another bus than peripheral
which registers control EMIF timing and setup. So my idea has been that
test/setup propagation read from SDRAM space can reach interface before
it is configured. The barriers should prevent that.

But the code/HW has some glitches even with barriers included.
The sequence is (should be) exactly same as HalCoGen generated code
but it is compiled with Ti tools and they optimize much less
in used basic setup than GCC. But I expect that problem is somewhere
else anyway. May it be initialization too early after power on,
some clock domain or power enable not controlled right way.

Genrally, the SDRAM configuration fails for the first start after
POR, the configuration is correct after second and more system resets.
I can put there code to retry it. But it needs more debugging
and I would like to find real cause.

Best wishes,

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

Re: RTEMS classic networking: fixed FXP driver works under QEMU on Linux

[Pavel Pisa]

Hello all,

the driver works after hours of problem seeking
in incorrect directions.

I have debugged, examined and patched both, RTEMS and QEMU.
The main problem is quite simple. Update of RTEMS interrupts
processing disable level type interrupts when they arrive
and the driver/daemon has to re-enable interrupt source
on the interrupt controller level.

Generally, idea to disable interrupt source at hard interrupt
time and do all processing outside of interrupt is the
the best solution for RT system. But I consider actual
behavior seriously broken. It is for longer description.
But if you consider shared interrupts (all PCI ones on PC
for example) then the correct behavior is to use hard IRQ
to disable/gate interrupt on given device level
(not all sharing devices at controller level) and release
worker thread for each device from corresponding
hard IRQ and left the scheduler to select between these
according to the priority. When more important/critical
device finishes its IRQ processing, it enables IRQ
on given device level and processing of its interrupts
in time is possible.

Actual state pushes device drivers to attempt re-enable
IRQ on controller level. But if IRQ is re-enabled by hight
priority device worker thread in case that there exists
lower priority device sharing the IRQ which is still signalling
IRQ, then without gating on device level this has to lead
to livelock. Cotroller fires IRQ dispatch, that releases
high priority device driver, that finds nothing to do and reenables
IRQ on the controller level.

There is option to make things work even with shared IRQs
if gating on device level is not available. And it is
to have counted disable on the controller level which ensures
that IRQ is re-enabled only after all devices worker
threads finish processing. But priority rules are broken in that
case as well.

I know that there is interrupt server option but base
interrupts should be working and not broken.

Shared edge trigerred interrupts processing is complex
problem either. I think that I have provided analysis
years ago for RTEMS.



found it

https://lists.rtems.org/pipermail/users/2008-May/018775.html

If I could find month somewhere, I would try provide
changes which could go under critique and testing .

Anyway, back to solve Saeed Ehteshamifar problem with
lack of network supporting environment for his dynamic
loading task. I have tested it on Linux, Debian.
I have done setup without helper scripts and toolsfrom
QEMU or other system. I decided to use separate
"network segment" for testing. The wire for L2/ethernet
layer is created by
 
  ip tuntap add tap1 mode tap user pi
  ip link set tap1 up

You need root access.
I have connected this stub to Linux TCP/IP networking
subsystem by

  ip addr add 192.168.3.1/24 dev tap1
  ip link set tap1 up

You need to select address from private address range.
Check that whole range, in above case 192.168.3.0
to 192.168.3.255 does not overlap with networks
visible from your computer. It should be really
isolated island. The kernel does default setup
of routing to the range

  ip route show

  192.168.3.0/24 dev tap1  proto kernel  scope link  src 192.168.3.1

To keep range separate you should not have enabled forwarding

  cat /proc/sys/net/ipv4/ip_forward

should show 0 or you need to setup iptables or check and set
routing rules to keep island network.

I start RTEMS application by command

qemu-system-x86_64 -enable-kvm -kernel $APP_BINARY \
  -vga cirrus \
  -append "--console=/dev/com1" \
  -serial stdio \
  -net nic,vlan=1,macaddr=be:be:be:10:00:01,model=i82557b \
  -net tap,ifname=tap1,vlan=1,script=no,downscript=no  \

You can add "-s -S" for debugging by GDB "target remote localhost:1234"
Be carefull, if you want to set breakpoints then setting them when
in real mode at address 0x0 is not good idea. You need
to be in virtual space of RTEMS application after its load
to set software breakpoints. But there are two or three HW
breakpoints emulated. Decide for some function and use

  hbreak rtems_fxp_attach
  c

When the function is reached you can insert regular SW
breakpoints.

When application runs, you can access it from Linux system.
The configured address has to be withing island network range.
I.e.

  ping 192.168.3.66

The netwok card should be found by ARP broadcast coming
to QEMU where RTEMS responds that it is its address.
You can use 

  arping -i tap1 192.168.3.66

or 

 arping -i tap1 be:be:be:10:00:01

to check lowest level connection.

The OMK template includes application "appnet" which uses
RTEMS integrated telnet to access RTEMS shell remotely.

  telnet 192.168.3.66

See

  
http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/HEAD:/rtems-omk-template/appnet

The config

static struct rtems_bsdnet_ifconfig netdriver_config = {
.name = "fxp1" /*RTEMS_BSP_NETWORK_DRIVER_NAME*/,
.attach = rtems_fxp_attach /*RTEMS_BSP_NETWORK_DRIVER_ATTACH*/,
.next = NULL,

[PATCH] classic networking: adapt FXP driver to work with actual PCI

[Pavel Pisa]

From: Pavel Pisa <p...@cmp.felk.cvut.cz>

Tested to work with QEMU provided Intel i82557b network controller emulation.

qemu-system-x86_64 -enable-kvm -kernel $APP_BINARY \
  -vga cirrus \
  -append "--console=/dev/com1" \
  -serial stdio \
  -net nic,vlan=1,macaddr=be:be:be:10:00:01,model=i82557b \
  -net tap,ifname=tap1,vlan=1,script=no,downscript=no
---
 c/src/libchip/network/if_fxp.c| 186 ++
 c/src/libchip/network/if_fxpvar.h |  18 ++--
 2 files changed, 98 insertions(+), 106 deletions(-)

diff --git a/c/src/libchip/network/if_fxp.c b/c/src/libchip/network/if_fxp.c
index 35d7c07..4d9d983 100644
--- a/c/src/libchip/network/if_fxp.c
+++ b/c/src/libchip/network/if_fxp.c
@@ -76,6 +76,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #ifdef NS
@@ -221,7 +222,7 @@ int fxp_output (struct ifnet *,
   struct mbuf *, struct sockaddr *, struct rtentry *);
 
 
-static rtems_isrfxp_intr(rtems_vector_number v);
+static voidfxp_intr(void *arg);
 static voidfxp_init(void *xsc);
 static voidfxp_tick(void *xsc);
 static voidfxp_start(struct ifnet *ifp);
@@ -285,7 +286,7 @@ static __inline u_int8_t fxp_csr_read_1(struct fxp_softc 
*sc,int  reg) {
 inport_byte(sc->pci_regs_base + reg,val);
   }
   else {
-val = *(u_int8_t*)(sc->pci_regs_base+reg);
+val = *(volatile u_int8_t*)(sc->pci_regs_base+reg);
   }
   return val;
 }
@@ -295,7 +296,7 @@ static __inline u_int32_t fxp_csr_read_2(struct fxp_softc 
*sc,int  reg) {
 inport_word(sc->pci_regs_base + reg,val);
   }
   else {
-val = *(u_int16_t*)(sc->pci_regs_base+reg);
+val = *(volatile u_int16_t*)(sc->pci_regs_base+reg);
   }
   return val;
 }
@@ -305,7 +306,7 @@ static __inline u_int32_t fxp_csr_read_4(struct fxp_softc 
*sc,int  reg) {
 inport_long(sc->pci_regs_base + reg,val);
   }
   else {
-val = *(u_int32_t*)(sc->pci_regs_base+reg);
+val = *(volatile u_int32_t*)(sc->pci_regs_base+reg);
   }
   return val;
 }
@@ -322,7 +323,8 @@ fxp_scb_wait(struct fxp_softc *sc)
while (CSR_READ_1(sc, FXP_CSR_SCB_COMMAND) && --i)
DELAY(2);
if (i == 0)
-   device_printf(sc->dev, "SCB timeout: 0x%x 0x%x 0x%x 0x%x\n",
+   device_printf(sc->dev, "SCB timeout: 0x%d 0x%d"
+"0x%d" PRIx32 "0x%" PRIx32 "\n",
CSR_READ_1(sc, FXP_CSR_SCB_COMMAND),
CSR_READ_1(sc, FXP_CSR_SCB_STATACK),
CSR_READ_1(sc, FXP_CSR_SCB_RUSCUS),
@@ -351,86 +353,61 @@ fxp_dma_wait(volatile u_int16_t *status, struct fxp_softc 
*sc)
device_printf(sc->dev, "DMA timeout\n");
 }
 
-/*
- * These macros and instantiations define PCI Configuration Space accessors
- * which use the legacy API based on the PCI BIOS only used by pc386.
- * This was the only device driver using these.
- *
- * TBD: It may be worth it to fix this driver to use the current PCI API rather
- *  than this legacy PC386 API.
- */
-#define PCIB_DEVSIG_BUS(x) (((x)>>8) &0xff)
-#define PCIB_DEVSIG_DEV(x) (((x)>>3) & 0x1f)
-#define PCIB_DEVSIG_FUNC(x) ((x) & 0x7)
-#define PCIB_DEVSIG_MAKE(b,d,f) ((b<<8)|(d<<3)|(f))
 
-#define PCI_CONF_ACCESSOR(_confop, _baseop, _type) \
-  /* prototype before body */ \
-  static inline int _confop ( \
-int signature, \
-int offset, \
-_type data ); \
+#define FXP_PCI_CONF_ACCESSOR(_confop, _baseop, _type) \
   \
   static inline int _confop ( \
-int signature, \
+struct fxp_softc *sc, \
 int offset, \
 _type data ) \
   { \
 _baseop( \
-PCIB_DEVSIG_BUS(signature), \
-PCIB_DEVSIG_DEV(signature), \
-PCIB_DEVSIG_FUNC(signature), \
+sc->pci_bus, \
+sc->pci_dev, \
+sc->pci_fun, \
 offset, \
 data \
 ); \
return PCIB_ERR_SUCCESS; \
   }
 
-PCI_CONF_ACCESSOR( pcib_conf_read8,   pci_read_config_byte,   uint8_t * );
-PCI_CONF_ACCESSOR( pcib_conf_read16,  pci_read_config_word,   uint16_t * );
-PCI_CONF_ACCESSOR( pcib_conf_read32,  pci_read_config_dword,  uint32_t * );
-PCI_CONF_ACCESSOR( pcib_conf_write8,  pci_write_config_byte,  uint8_t );
-PCI_CONF_ACCESSOR( pcib_conf_write16, pci_write_config_word,  uint16_t );
-PCI_CONF_ACCESSOR( pcib_conf_write32, pci_write_config_dword, uint32_t );
+FXP_PCI_CONF_ACCESSOR( fxp_pci_conf_read8,   pci_read_config_byte,   uint8_t * 
);
+FXP_PCI_CONF_ACCESSOR( fxp_pci_conf_read16,  pci_read_config_word,   uint16_t 
* );
+FXP_PCI_CONF_ACCESSOR( fxp_pci_conf_read32,  pci_read_config_dword,  uint32_t 
* );
+FXP_PCI_CONF_ACCESSOR( fxp_pci_conf_write8,  pci_write_config_byte,  uint8_t );
+FXP_PCI_CONF_ACCESSOR( fxp_pci_conf_write16, pci_write_config_word,  uint16_t 
);
+FXP_PCI_CONF_ACCESSOR( fxp_pci_conf_

Re: [PATCH 0/5] arm/tms570: include hardware initialization and selftests to run RTEMS directly from Flash without loader on TMS570LS3137 HDK.

[Pavel Pisa]

Hello Gedare,

On Wednesday 14 of September 2016 02:13:47 Gedare Bloom wrote:
> On Tue, Sep 13, 2016 at 5:11 PM, Pavel Pisa <p...@cmp.felk.cvut.cz> wrote:
> > Hello Gedare,
> >
> > thanks for the review. It is huge piece and not in a state
> > as nice as I would like it.
> >
> > On Tuesday 13 of September 2016 21:42:48 Gedare Bloom wrote:
> >> I'm slowly reading through these. Is there a doc or is it worth it to
> >> generate one that maps the HalcoGen functions to their RTEMS renamed
> >> versions? I'm not sure if it is of much value.
> >
> > I am not sure at the end. I have tried to change names
> > to RTEMS, Linux, POSIX style. The rest of BSP (which
> > is written mostly from scratch) already follows that.
> > Other option is to use Ti CammelCase and add tms570_ prefix.
> > Genrally I am not sure. I have not renamed functions
> > in the ARM core support tms570_sys_core.S .
> > But if we agree that all should follow single naming
> > convention I take a while for that.
> > But there could be value in preserving Ti names either.
>
> I wouldn't mind simple tms570_preserveCamelCase() as an easy rule to
> follow and to track back clearly to what came from halcogen versus own
> code that should use bsp style (tms570_xxx_yyy_zzz).

The most HalCoGen generated code is editted considerably anyway.

We have tested other proof of concept/option initially.
This is RTEMS with unmodified HalCoGen files solution
and it is archived on "tms570-bsp-with-hwinit" branch.

https://github.com/AoLaD/rtems/tree/tms570-bsp-with-hwinit

The code sits in c/src/lib/libbsp/arm/tms570/halcogen directory
of the branch

https://github.com/AoLaD/rtems/tree/tms570-bsp-with-hwinit/c/src/lib/libbsp/arm/tms570/halcogen

So you can look at that as the reference.

I think that for this case it does not worth directly include
generated code in RTEMS repo. When regenerated for other board
or chip variant or by other HalCoGen version it would differ.

But for quick start on other chip it could be faster solution.

May it be, we can use tms570_xxx_yyy_zzz and put original
name after that in Doxygen first line after new name.

Best wishes,

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

[PATCH 5/5] arm/tms570: update bootstrap generated preinstall.am

[pisa]

From: Pavel Pisa <p...@cmp.felk.cvut.cz>

---
 c/src/lib/libbsp/arm/tms570/preinstall.am | 13 +
 1 file changed, 13 insertions(+)

diff --git a/c/src/lib/libbsp/arm/tms570/preinstall.am 
b/c/src/lib/libbsp/arm/tms570/preinstall.am
index be8e42e..7d79184 100644
--- a/c/src/lib/libbsp/arm/tms570/preinstall.am
+++ b/c/src/lib/libbsp/arm/tms570/preinstall.am
@@ -282,3 +282,16 @@ $(PROJECT_LIB)/linkcmds: startup/linkcmds 
$(PROJECT_LIB)/$(dirstamp)
$(INSTALL_DATA) $< $(PROJECT_LIB)/linkcmds
 TMPINSTALL_FILES += $(PROJECT_LIB)/linkcmds
 
+if TMS570_USE_HWINIT_STARTUP
+$(PROJECT_INCLUDE)/bsp/tms570_parity_tests.h: hwinit/tms570_parity_tests.h 
$(PROJECT_INCLUDE)/bsp/$(dirstamp)
+   $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/bsp/tms570_parity_tests.h
+PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/tms570_parity_tests.h
+
+$(PROJECT_INCLUDE)/bsp/tms570_hwinit.h: hwinit/tms570_hwinit.h 
$(PROJECT_INCLUDE)/bsp/$(dirstamp)
+   $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/bsp/tms570_hwinit.h
+PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/tms570_hwinit.h
+
+$(PROJECT_INCLUDE)/bsp/tms570_selftest.h: hwinit/tms570_selftest.h 
$(PROJECT_INCLUDE)/bsp/$(dirstamp)
+   $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/bsp/tms570_selftest.h
+PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/tms570_selftest.h
+endif
-- 
1.9.1

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

[PATCH 4/5] arm/tms570: document BSP setup with included hardware initialization.

[pisa]

From: Pavel Pisa <p...@cmp.felk.cvut.cz>

---
 c/src/lib/libbsp/arm/tms570/README | 104 +
 1 file changed, 82 insertions(+), 22 deletions(-)

diff --git a/c/src/lib/libbsp/arm/tms570/README 
b/c/src/lib/libbsp/arm/tms570/README
index f48744f..840ce68 100644
--- a/c/src/lib/libbsp/arm/tms570/README
+++ b/c/src/lib/libbsp/arm/tms570/README
@@ -2,11 +2,14 @@ Development Board: TMS570LS31x Hercules Development Kit from 
TI
 
 http://www.ti.com/tool/tmds570ls31hdk
 
+Overview
+
+
 Drivers:
 
-   o Console
-   o Clock
-  o Ethernet - work in progress
+  o Console
+  o Clock
+  o Ethernet - external lwIP fork repository
 
 BSP variants:
   tms570ls3137_hdk_intram - place code and data into internal SRAM
@@ -14,14 +17,20 @@ BSP variants:
   tms570ls3137_hdk_with_loader - reserve 256kB at Flash start for loader
  and place RTEMS application from address
  0x0004
-  tms570ls3137_hdk - variant prepared for stand-alone RTEMS application
-  stored and running directly from flash. Not working yet.
+  tms570ls3137_hdk - variant for stand-alone RTEMS application stored
+ and running directly from flash. This variant
+ requires initialization of hardware to be integrated
+ into RTEMS. RTEMS has to be configured with
+   TMS570_USE_HWINIT_STARTUP=1
+ and initialization code has to be included in the sources.
+
+Tool-chain used for development
+---
 
-Tool-chain
-  GCC 4.9.0 + Newlib 2.1.0 + Binutils 2.24 configuration:
+  arm-rtems4.12-gcc (GCC) 6.1.1 20160526 + Newlib 2.4.0.20160527 + Binutils 
2.26.20160125
 
   CFLAGS="-O2 -pipe" LDFLAGS=-s \
-  ../../../src/gcc-4.9/configure --target=arm-rtems4.11 --prefix=/usr \
+  ../../../src/gcc-6.1/configure --target=arm-rtems4.12 --prefix=/usr \
--enable-languages=c,c++ \
--disable-libstdcxx-pch \
--with-gnu-ld \
@@ -38,33 +47,84 @@ Tool-chain
--enable-version-specific-runtime-libs \
--enable-newlib-iconv \
--disable-lto \
+   --disable-lto \
+   --enable-libgomp \
+   --enable-newlib-iconv \
+   --enable-newlib-iconv-encodings="iso_8859_1,utf_8" \
+
+All patches required for Cortex-R and big-endian ARM support are already
+integrated in GCC the mainline.
 
-Patches required for Cortex-R and big-endian ARM support are already
-accepted by the mainline.
+RTEMS build configuration used for testing of self contained
+applications to run directly from Flash
+
+  ../../../src/rtems/configure  --target=arm-rtems4.12 --prefix=/opt/rtems4.12 
\
+--enable-rtems-inlines --disable-multiprocessing --enable-cxx \
+--enable-rdbg --enable-maintainer-mode --enable-tests=samples \
+--disable-networking --enable-posix --enable-itron --disable-ada \
+--disable-expada --disable-multilib --disable-docs \
+--enable-rtemsbsp="tms570ls3137_hdk" \
+--enable-rtems-debug \
+TMS570_USE_HWINIT_STARTUP=1
 
 Execution
+-
+
+Application build by above process can be directly programmed
+into Flash and run.
 
-Currently, a bootloader is not used. For test and debug purposes, TI's
-HalCoGen generated application is used to set up the board and then
-the RTEMS application image is loaded using OpenOCD to internal
-EEC SRAM or external DRAM. The following features are
-not implemented in the BSP:
+For test and debug purposes, TI's HalCoGen generated application
+is used to set up the board and then the RTEMS application
+image is loaded using OpenOCD to internal EEC SRAM or external SDRAM.
+This prevents wear of Flash which has limited guaranteed
+erase cycles count.
 
- + Initial complex CPU and peripheral initialization
+The following features are implemented in the BSP only partially:
+
+ + Initial CPU and peripheral initialization
  + Cores Self-test
 
 Setup application code is available there:
   https://github.com/hornmich/tms570ls3137-hdk-sdram
 
-Howto setup TMDS570LS31HDK?
+TMDS570LS31HDK setup to use SDRAM to load and debug RTEMS applications
+---
 
-   o Unpack board. 
-   o Verify that demo application runs.
-  o Upload bootloader specified above
+  o Program SDRAM_SCI_configuration-program or another boot loader
+(for example ETHERNET XCP is developed)
   o write BSP application either to sdram or intram and jump to RTEMS start 
code
 
-Additional information about the board can be found at
-  http://www.rtems.org/wiki/index.php/Tms570
+ETHERNET
+
+
+For ETHERNET, the lwIP port for TMS570LS3137 has been developed
+at Industrial Informatics Group of Czech Technical University
+in Prague and development versions are available on S

[PATCH 3/5] arm/tms570: include TMS570_USE_HWINIT_STARTUP option to select bare metal startup and selftest.

[pisa]

From: Pavel Pisa <p...@cmp.felk.cvut.cz>

---
 c/src/lib/libbsp/arm/tms570/Makefile.am  | 21 +
 c/src/lib/libbsp/arm/tms570/configure.ac |  4 
 2 files changed, 25 insertions(+)

diff --git a/c/src/lib/libbsp/arm/tms570/Makefile.am 
b/c/src/lib/libbsp/arm/tms570/Makefile.am
index c4d39bc..012ce23 100644
--- a/c/src/lib/libbsp/arm/tms570/Makefile.am
+++ b/c/src/lib/libbsp/arm/tms570/Makefile.am
@@ -168,8 +168,29 @@ libbsp_a_SOURCES += 
../../../libcpu/shared/src/cache_manager.c
 libbsp_a_SOURCES += ../../../libcpu/arm/shared/include/cache_.h
 libbsp_a_CPPFLAGS += -I$(srcdir)/../../../libcpu/arm/shared/include
 
+if TMS570_USE_HWINIT_STARTUP
+libbsp_a_SOURCES += hwinit/tms570_sys_core.S
+libbsp_a_SOURCES += hwinit/fail_notification.c
+libbsp_a_SOURCES += hwinit/init_pinmux.c
+libbsp_a_SOURCES += hwinit/init_system.c
+libbsp_a_SOURCES += hwinit/init_emif_sdram.c
+libbsp_a_SOURCES += hwinit/init_esm.c
+libbsp_a_SOURCES += hwinit/tms570_selftest.c
+libbsp_a_SOURCES += hwinit/tms570_parity_tests.c
+libbsp_a_SOURCES += hwinit/tms570_parity_std.c
+libbsp_a_SOURCES += hwinit/tms570_parity_can.c
+libbsp_a_SOURCES += hwinit/tms570_parity_mibspi.c
+
+include_bsp_HEADERS += hwinit/tms570_parity_tests.h
+include_bsp_HEADERS += hwinit/tms570_hwinit.h
+include_bsp_HEADERS += hwinit/tms570_selftest.h
+
+# Start hooks
+libbsp_a_SOURCES += hwinit/bspstarthooks-hwinit.c
+else
 # Start hooks
 libbsp_a_SOURCES += startup/bspstarthooks.c
+endif
 
 # 
 # --  Special Rules
diff --git a/c/src/lib/libbsp/arm/tms570/configure.ac 
b/c/src/lib/libbsp/arm/tms570/configure.ac
index e06d4e4..7662064 100644
--- a/c/src/lib/libbsp/arm/tms570/configure.ac
+++ b/c/src/lib/libbsp/arm/tms570/configure.ac
@@ -50,6 +50,10 @@ RTEMS_BSPOPTS_HELP([TMS570_OSCILLATOR_RTC],[RTC oscillator 
frequency in Hz])
 RTEMS_BSPOPTS_SET([TMS570_CCLK],[*],[9600U])
 RTEMS_BSPOPTS_HELP([TMS570_CCLK],[CPU clock in Hz])
 
+RTEMS_BSPOPTS_SET([TMS570_USE_HWINIT_STARTUP],[*],[0])
+RTEMS_BSPOPTS_HELP([TMS570_USE_HWINIT_STARTUP],[use minimalized startup code 
for TMS570LS3137])
+AM_CONDITIONAL(TMS570_USE_HWINIT_STARTUP,test "$TMS570_USE_HWINIT_STARTUP" = 
"1")
+
 RTEMS_BSP_CLEANUP_OPTIONS(0, 1)
 RTEMS_BSP_LINKCMDS
 
-- 
1.9.1

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

[PATCH 2/5] arm/tms570: include hardware initialization and selftest based on Ti HalCoGen generated files.

[pisa]

From: Pavel Pisa <p...@cmp.felk.cvut.cz>

The configuration is specific for TMS570LS3137 based HDK.
But pins configuration can be easily changed in

  rtems/c/src/lib/libbsp/arm/tms570/hwinit/init_pinmux.c

file.
---
 .../arm/tms570/hwinit/bspstarthooks-hwinit.c   | 393 ++
 .../libbsp/arm/tms570/hwinit/fail_notification.c   |  17 +
 .../lib/libbsp/arm/tms570/hwinit/init_emif_sdram.c |  59 +++
 c/src/lib/libbsp/arm/tms570/hwinit/init_esm.c  |  50 ++
 c/src/lib/libbsp/arm/tms570/hwinit/init_pinmux.c   | 195 +++
 c/src/lib/libbsp/arm/tms570/hwinit/init_system.c   | 380 +
 c/src/lib/libbsp/arm/tms570/hwinit/tms570_hwinit.h |  23 +
 .../libbsp/arm/tms570/hwinit/tms570_parity_can.c   |  60 +++
 .../arm/tms570/hwinit/tms570_parity_mibspi.c   |  72 +++
 .../libbsp/arm/tms570/hwinit/tms570_parity_std.c   |  55 ++
 .../libbsp/arm/tms570/hwinit/tms570_parity_tests.c | 273 ++
 .../libbsp/arm/tms570/hwinit/tms570_parity_tests.h |  75 +++
 .../lib/libbsp/arm/tms570/hwinit/tms570_selftest.c | 589 +
 .../lib/libbsp/arm/tms570/hwinit/tms570_selftest.h | 156 ++
 .../lib/libbsp/arm/tms570/hwinit/tms570_sys_core.S | 575 
 15 files changed, 2972 insertions(+)
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/bspstarthooks-hwinit.c
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/fail_notification.c
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/init_emif_sdram.c
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/init_esm.c
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/init_pinmux.c
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/init_system.c
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/tms570_hwinit.h
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/tms570_parity_can.c
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/tms570_parity_mibspi.c
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/tms570_parity_std.c
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/tms570_parity_tests.c
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/tms570_parity_tests.h
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/tms570_selftest.c
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/tms570_selftest.h
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/tms570_sys_core.S

diff --git a/c/src/lib/libbsp/arm/tms570/hwinit/bspstarthooks-hwinit.c 
b/c/src/lib/libbsp/arm/tms570/hwinit/bspstarthooks-hwinit.c
new file mode 100644
index 000..a33d4b2
--- /dev/null
+++ b/c/src/lib/libbsp/arm/tms570/hwinit/bspstarthooks-hwinit.c
@@ -0,0 +1,393 @@
+#include 
+#include 
+#include 
+#include 
+
+#include "tms570_selftest.h"
+#include "tms570_parity_tests.h"
+#include "tms570_hwinit.h"
+
+void bsp_start_hook_0_done( void );
+
+BSP_START_TEXT_SECTION void bsp_start_hook_0( void )
+{
+  /*
+   * Work Around for Errata DEVICE#140: ( Only on Rev A silicon)
+   *
+   * Errata Description:
+   *The Core Compare Module(CCM-R4) may cause nERROR to be 
asserted after a cold power-on
+   * Workaround:
+   *Clear ESM Group2 Channel 2 error in ESMSR2 and Compare error 
in CCMSR register
+   */
+  if ( TMS570_SYS1.DEVID == 0x802AAD05U ) {
+_esmCcmErrorsClear_();
+  }
+
+  /* Enable CPU Event Export */
+  /* This allows the CPU to signal any single-bit or double-bit errors detected
+   * by its ECC logic for accesses to program flash or data RAM.
+   */
+  _coreEnableEventBusExport_();
+
+  /* Workaround for Errata CORTEXR4 66 */
+  _errata_CORTEXR4_66_();
+
+  /* Workaround for Errata CORTEXR4 57 */
+  _errata_CORTEXR4_57_();
+
+  /* check for power-on reset condition */
+  /*SAFETYMCUSW 139 S MR:13.7  "Hardware status bit read check" */
+  if ( ( TMS570_SYS1.SYSESR & TMS570_SYS1_SYSESR_PORST ) != 0U ) {
+/* clear all reset status flags */
+TMS570_SYS1.SYSESR = 0xU;
+
+/* continue with normal start-up sequence */
+  }
+  /*SAFETYMCUSW 139 S MR:13.7  "Hardware status bit read check" */
+  else if ( ( TMS570_SYS1.SYSESR & TMS570_SYS1_SYSESR_OSCRST ) != 0U ) {
+/* Reset caused due to oscillator failure.
+   Add user code here to handle oscillator failure */
+  }
+  /*SAFETYMCUSW 139 S MR:13.7  "Hardware status bit read check" */
+  else if ( ( TMS570_SYS1.SYSESR & TMS570_SYS1_SYSESR_WDRST ) != 0U ) {
+/* Reset caused due
+ *  1) windowed watchdog violation - Add user code here to handle watchdog 
violation.
+ *  2) ICEPICK Reset - After loading code via CCS / System Reset through 
CCS
+ */
+/* Check the WatchDog Status register */
+if ( TMS570_RTI.WDSTATUS != 0U ) {
+  /* Add user code here to handle watchdog violation. */
+  /* Clear the Watchdog reset flag in Exception Status register */
+  TMS570_SYS1.SYSESR = TMS570_SYS1_SYSESR_WDRST;
+} else {
+  /* Clear the ICEPICK reset flag in Exception Status register */
+  T

[PATCH 1/5] arm/tms570: define base addresses of all TMS570LS3137 SPI interfaces.

[pisa]

From: Pavel Pisa <p...@cmp.felk.cvut.cz>

Generated header file ti_herc/reg_spi.h contains complete registers
and fields set for Ti MibSPI peripheral.
Care has to be taken that only TMS570_SPI1, TMS570_SPI3 and TMS570_SPI5
are of this complete multibuffer type. TMS570_SPI2 and TMS570_SPI4
have substantial part of registers removed but else they are compatible.
---
 c/src/lib/libbsp/arm/tms570/include/tms570.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/c/src/lib/libbsp/arm/tms570/include/tms570.h 
b/c/src/lib/libbsp/arm/tms570/include/tms570.h
index f3daac1..f278a93 100644
--- a/c/src/lib/libbsp/arm/tms570/include/tms570.h
+++ b/c/src/lib/libbsp/arm/tms570/include/tms570.h
@@ -125,7 +125,11 @@
 #define TMS570_TCRAM2 (*(volatile tms570_tcram_t*)0xF900)
 #define TMS570_VIM (*(volatile tms570_vim_t*)0XFDEC)
 #define TMS570_POM (*(volatile tms570_pom_t*)0XFFA04000)
-#define TMS570_SPI (*(volatile tms570_spi_t*)0xFFF7F400)
+#define TMS570_SPI1 (*(volatile tms570_spi_t*)0xFFF7F400)
+#define TMS570_SPI2 (*(volatile tms570_spi_t*)0xFFF7F600)
+#define TMS570_SPI3 (*(volatile tms570_spi_t*)0xFFF7F800)
+#define TMS570_SPI4 (*(volatile tms570_spi_t*)0xFFF7FA00)
+#define TMS570_SPI5 (*(volatile tms570_spi_t*)0xFFF7FC00)
 #define TMS570_STC (*(volatile tms570_stc_t*)0xE600)
 #define TMS570_SYS1 (*(volatile tms570_sys1_t*)0xFF00)
 #define TMS570_SYS2 (*(volatile tms570_sys2_t*)0xE100)
-- 
1.9.1

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

[PATCH 0/5] arm/tms570: include hardware initialization and selftests to run RTEMS directly from Flash without loader on TMS570LS3137 HDK.

[pisa]

From: Pavel Pisa <p...@cmp.felk.cvut.cz>

The code introduces initialization algorithms bases on Ti HalCoGen
generated files. The most of the code has been rewritten to use
RTEMS much more complete header files. This allowed to replace most
of the hardcoded hexadecimal values by appropriate fields macros documenting
how values are build.

The parity self-tests have been rewritten completely to minimize
code duplication. The solution is much better prepared to cover
variations of integrated peripherals between different Hercules
family chips.

The pin multiplexer code is written from scratch and complete
pin alternative functions "database" is included for easy
preparation of configurations for different chips and even
runtime pin functions changes.

Original Ti HalCoGen generated files include a BSD-like license.
It has been preserved where the file is mostly based Ti code.
Some other smaller (mostly rewritten) fragments are without
copyright header for now.

The code is reformatted to conform RTEMS coding style mostly.
There are left some original functions names and comments
using C++ delimiters "//". I expect to remove them in long
term perspective. But I would like to use them for matching
code and algorithms with other chip family members code
generated by HalCoGen. When two or three variants are fully
supported then we learn how to write support portable
and configurable way in the C code and these remarks would
not be required anymore.

The code taking care about internal SRAM parity self-test
is disabled for now because it clashes with code testing
for internal RAM linking variant. The MPU initialization
is missing as well. It would be required to use external
SDRAM for code.

Generally, there is much work required still to make BSP
full industry grade one. But I think that actual state
is the great step forward and work worth to be included
in RTEMS mainline in the actual state to simplify testing
and be base for new projects.

The second patch is quite huge so if it does not pass
through list then it can be accessed on GitHub

The branch: https://github.com/AoLaD/rtems/commits/tms570-bsp
Patch 2/5:  
https://github.com/AoLaD/rtems/commit/9d06f3be64f9b5e9e1988163762b613daba0963c

Pavel Pisa (5):
  arm/tms570: define base addresses of all TMS570LS3137 SPI interfaces.
  arm/tms570: include hardware initialization and selftest based on Ti
HalCoGen generated files.
  arm/tms570: include TMS570_USE_HWINIT_STARTUP option to select bare
metal startup and selftest.
  arm/tms570: document BSP setup with included hardware initialization.
  arm/tms570: update bootstrap generated preinstall.am

 c/src/lib/libbsp/arm/tms570/Makefile.am|  21 +
 c/src/lib/libbsp/arm/tms570/README | 104 +++-
 c/src/lib/libbsp/arm/tms570/configure.ac   |   4 +
 .../arm/tms570/hwinit/bspstarthooks-hwinit.c   | 393 ++
 .../libbsp/arm/tms570/hwinit/fail_notification.c   |  17 +
 .../lib/libbsp/arm/tms570/hwinit/init_emif_sdram.c |  59 +++
 c/src/lib/libbsp/arm/tms570/hwinit/init_esm.c  |  50 ++
 c/src/lib/libbsp/arm/tms570/hwinit/init_pinmux.c   | 195 +++
 c/src/lib/libbsp/arm/tms570/hwinit/init_system.c   | 380 +
 c/src/lib/libbsp/arm/tms570/hwinit/tms570_hwinit.h |  23 +
 .../libbsp/arm/tms570/hwinit/tms570_parity_can.c   |  60 +++
 .../arm/tms570/hwinit/tms570_parity_mibspi.c   |  72 +++
 .../libbsp/arm/tms570/hwinit/tms570_parity_std.c   |  55 ++
 .../libbsp/arm/tms570/hwinit/tms570_parity_tests.c | 273 ++
 .../libbsp/arm/tms570/hwinit/tms570_parity_tests.h |  75 +++
 .../lib/libbsp/arm/tms570/hwinit/tms570_selftest.c | 589 +
 .../lib/libbsp/arm/tms570/hwinit/tms570_selftest.h | 156 ++
 .../lib/libbsp/arm/tms570/hwinit/tms570_sys_core.S | 575 
 c/src/lib/libbsp/arm/tms570/include/tms570.h   |   6 +-
 c/src/lib/libbsp/arm/tms570/preinstall.am  |  13 +
 20 files changed, 3097 insertions(+), 23 deletions(-)
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/bspstarthooks-hwinit.c
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/fail_notification.c
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/init_emif_sdram.c
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/init_esm.c
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/init_pinmux.c
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/init_system.c
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/tms570_hwinit.h
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/tms570_parity_can.c
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/tms570_parity_mibspi.c
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/tms570_parity_std.c
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/tms570_parity_tests.c
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/tms570_parity_tests.h
 create mode 100644 c/src/lib/libbsp/arm/tms570/hwinit/tms570_selftest.c
 create mode 1

Re: [PATCH 00/10] Raspberry Pi 2 (BCM2836) SMP support

[Pavel Pisa]

Hello Chris and others,

On Sunday 11 of September 2016 08:53:09 Chris Johns wrote:
> On 09/09/2016 17:47, Sebastian Huber wrote:
> > On 09/09/16 09:43, Pavel Pisa wrote:
> >> Hello Chris and others,
> >>
> >> On Friday 09 of September 2016 02:06:19 Chris Johns wrote:
> >>> >On 09/09/2016 07:46, Pavel Pisa wrote:
> >>>> > >I have provided simple bsp_reset() for Raspberry Pi and pushed it
> >>>>
> >>>> into
> >>>>
> >>>> > >master.
> >>> >
> >>> >Thank you. Is the reset on exit on by default? I rebuilt without a BSP
> >>> >opt and the Rpi2 did not reset. I see a reference to
> >>> >BSP_RESET_BOARD_AT_EXIT but I do not know what the default is.
> >>> >
> >>> >I think*all*  RTEMS BSPs should reset on exit and shut-down by
> >>> > default. It is the normal production setting for most systems.
> >>
> >> Mainly for others, the BSP default cleanup operations
> >> selection mechanism is defined in
> >>
> >>rtems/c/src/aclocal/bsp-bspcleanup-options.m4
> >>
> >> RTEMS_BSP_CLEANUP_OPTIONS
> >> dnl USAGE:
> >> dnlRTEMS_BSP_CLEANUP_OPTIONS([0|1], [0|1], [0|1])
> >> dnl WHERE:
> >> dnlargument 1 indicates the default value for
> >> BSP_PRESS_KEY_FOR_RESET dnlargument 2 indicates the default value
> >> for BSP_RESET_BOARD_AT_EXIT dnlargument 3 indicates the default
> >> value for
> >> BSP_PRINT_EXCEPTION_CONTEXT
> >
> > Maybe it makes sense to remove the ability to change the default, so
> > what all BSPs have the same defaults. You can change the behaviour via
> > the configure command line if needed.
>
> Yes I think this is the way we should head. Any BSP which does not reset
> and start again by default needs to be changed making the default state
> for a BSP production ready. This statement covers this configure option
> plus it covers things like pressing a key which the PC BSP has on by
> default and should be defaulted to off.

May it be that RTEMS_BSP_CLEANUP_OPTIONS should not define
default but provide information which options are supported
for given BSP.

Best wishes,

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

Re: [PATCH 00/10] Raspberry Pi 2 (BCM2836) SMP support

[Pavel Pisa]

Hello Chris,

On Thursday 08 of September 2016 09:14:00 Chris Johns wrote:
> On 05/09/2016 00:38, Alan Cudmore wrote:
> > I applied your patches, and verified that my apps still work on the
> > Raspberry Pi 1 ( Pi Zero ). Now I am moving to the Pi 2 for some tests.
>
> I have verified a few tests running on RPi2 no-smp using HEAD on master.
> Well done to all who have made this happen, the support is looking
> really nice.
>
> My only issue is the BSP does not reset when it exits. I think all RPi
> variants should reset once finished because it will be a big help to
> automating test runs with the rtems-test command.

I have provided simple bsp_reset() for Raspberry Pi and pushed it into master.
I have not defined BSP specific bspclean.c. May it be that there could be
some problem with SMP shutdown without

#ifdef RTEMS_SMP
  if (src == RTEMS_FATAL_SOURCE_SMP && code == SMP_FATAL_SHUTDOWN_RESPONSE) {
while (true) {
  _ARM_Wait_for_event();
}
  }
#endif

But for simple testing it seems to work.

Best wishes,

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

Re: Raspberry Pi 2 SMP pushed to the master - Was: [PATCH 11 minor addeum] ...

[Pavel Pisa]

Hello Sebastian, Alan and others,

On Wednesday 07 of September 2016 09:27:21 Sebastian Huber wrote:
> > should they go to the same compilation unit as _CPU_SMP_Start_processor
> > or bspsmp-init.c separate one.
> >
> > Or I should not care about smpfatal08 or add required symbol to it.
>
> It would be nice to get the smpfatal08 to work with this BSP. There is
> already a special case for the the qoriq BSPs in this test, so maybe we
> need something similar for the RPI.


I have cleanly divided file startup/bspsmp.c into two parts

  startup/bspsmp_api.c which holds SuperCore requred/defined functions
   which are replaced by smpfatal08

  startup/bspsmp_init.c which holds IPI and secondary CPU initialization

This way there is no need to polute smpfatal08 by BSP specific code.

Because there is no functional/code change from already published
series, I have pushed patch series into master.

Thanks for review and Alan Cudmore for number of testing rounds.

Best wishes,

Pavel

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

Re: [PATCH 11 minor addeum] arm/raspberrypi: GPIO - using RTEMS interrupt lock during BSP

[Pavel Pisa]

Hello Sebastian,

On Wednesday 07 of September 2016 07:33:36 Sebastian Huber wrote:
> Hello Pavel,
>
> On 06/09/16 21:48, Pavel Pisa wrote:
> > Hello Sebastian,
> >
> > On Tuesday 06 of September 2016 20:33:08 Sebastian Huber wrote:
> >> The interrupt locks are simple interrupt disable/enable or spin locks.
> >> So, they always work.
> >
> > Allmost, on UP they are simple local IRQ disable.
> > But on SMP they are spinlock combined with IRQ disable.
> > But spinlock requires that corresponding memory location is initialized.
> > It is initialized to 0,0 as ticked lock or combination with some
> > debug/non-zero information depending on RTEMS_DEBUG, RTEMS_PROFILING etc.
> > The locks ends in BSS for zero case and I expect that it is source of
> > my problems.
>
> if you want to use something before the BSS initialization, then you can
> move it to the BSP_START_DATA_SECTION section or explicitly initialize
> it, e.g. in your case via rtems_interrupt_lock_initialize().

I skip this patch. I have found one other corner case for it usefullens
and it is changing value of output pins to safe state during BSP fatal
handling. If other CPU hard-faults when holding spinlock then fatal
handler can block. But again artificially constructed case.

> The rest of the patch series looks good.

Thanks

> The smpfatal08 test is quite a hack since it re-defines some global SMP
> support functions locally. In order to support this, the ARM BSPs must
> place the _CPU_SMP_Start_processor() function as the only global
> function into the bspsmp.c file.

I expected that

CFLAGS_OPTIMIZE_V += -ffunction-sections -fdata-sections

in BSP and linker -Wl,--gc-section could/sould resolve that.

So should I divide bspsmp.c into two files?

For example, bspsmp-startcpu.c, bspsmp-init.c.

What about 

uint32_t _CPU_SMP_Initialize(void)
{
  uint32_t cpu_count = (uint32_t)bsp_processor_count;

  if ( cpu_count > 4 )
cpu_count = 4;

  return cpu_count;
}

void _CPU_SMP_Finalize_initialization( uint32_t cpu_count )
{
  /* Do nothing */
}

void _CPU_SMP_Prepare_start_multitasking( void )
{
  /* Do nothing */
}

void _CPU_SMP_Send_interrupt( uint32_t target_cpu_index )
{
  /* Generates IPI */
  BCM2835_REG(BCM2836_MAILBOX_3_WRITE_SET_BASE +
  0x10 * target_cpu_index) = 0x1;
}

should they go to the same compilation unit as _CPU_SMP_Start_processor
or bspsmp-init.c separate one.

Or I should not care about smpfatal08 or add required symbol to it.

Best wishes,

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

Re: [PATCH 11 minor addeum] arm/raspberrypi: GPIO - using RTEMS interrupt lock during BSP

[Pavel Pisa]

Hello Sebastian,

On Tuesday 06 of September 2016 20:33:08 Sebastian Huber wrote:
> The interrupt locks are simple interrupt disable/enable or spin locks. So,
> they always work.

Allmost, on UP they are simple local IRQ disable.
But on SMP they are spinlock combined with IRQ disable.
But spinlock requires that corresponding memory location is initialized.
It is initialized to 0,0 as ticked lock or combination with some
debug/non-zero information depending on RTEMS_DEBUG, RTEMS_PROFILING etc.
The locks ends in BSS for zero case and I expect that it is source of
my problems.

I have experienced hard lock of RPi BSP on rpi_select_pin_function()
in SMP build when I use it in bsp_start_hook_0(), this is before
bsp_start_copy_sections(). I use that for hacking to enable JTAG
early in boot for BSP debugging

https://github.com/ppisa/rtems/blob/rtems-rpi-devel-160621/c/src/lib/libbsp/arm/raspberrypi/startup/bspstarthooks.c#L85

I am sure that deadlock has been in rpi_select_pin_function().
Removing JTAG setup helped. I am sure that skipping locks
would help. But you are right that I have not analyzed
where _System_state_Is_up( _System_state_Get() ) global variable
is placed. If it is in BSS then it is only matter of luck
that it does not match system up state when BSS is not
initialized yet.

So value of patch for real BSP use case is questionable.
My use case is corner or even more obscure and can be solved
by setup in u-boot or definition of the function variant without
locking. 

Anyway, thanks for review. I expect that you are quite overloaded
after return from vacations but I would be really happy if you
can say your comments/ACK/NACK to the rest or RPi SMP series
in next days.

There is that problem with generic RTL, caches on ARM and
RPi BSP mostly unusable with actual firmaware on 4.11 branch.
I understand, that my proposal of backport of most of related
fixes from master to 4.11 is sensitive question. Again your
income/voting to debate (ideally with Joel, Chris and Gedare)
could help in steering 4.11 branch.

Best wishes,

  Pavel

PS: Congratulation to "Rework thread priority management".
This is big/fundamental step forward for RTEMS.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 11 minor addeum] arm/raspberrypi: GPIO - using RTEMS interrupt lock during BSP

[Pavel Pisa]

Locking can be used only when RTEMS reaches multitasking state
  _System_state_Is_up( _System_state_Get() )
---
 c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c 
b/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c
index 6c01d62..f7c8c36 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -57,16 +58,21 @@ static rtems_status_code rpi_select_pin_function(
   /* Calculate the pin function select register address. */
   volatile uint32_t *pin_addr = (uint32_t *) BCM2835_GPIO_REGS_BASE +
  (pin / 10);
-  uint32_t reg_old;
   uint32_t reg_new;
+  int use_locks;
   rtems_interrupt_lock_context lock_context;
 
-  rtems_interrupt_lock_acquire(_gpio_bsp_lock, _context);
-  reg_new = reg_old = *pin_addr;
+  use_locks = _System_state_Is_up( _System_state_Get() );
+  if ( use_locks )
+rtems_interrupt_lock_acquire(_gpio_bsp_lock, _context);
+
+  reg_new = *pin_addr;
   reg_new &= ~SELECT_PIN_FUNCTION(RPI_ALT_FUNC_MASK, pin);
   reg_new |= SELECT_PIN_FUNCTION(type, pin);
   *pin_addr = reg_new;
-  rtems_interrupt_lock_release(_gpio_bsp_lock, _context);
+
+  if ( use_locks )
+rtems_interrupt_lock_release(_gpio_bsp_lock, _context);
 
   return RTEMS_SUCCESSFUL;
 }
-- 
1.9.1

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

Re: [PATCH 00/10] Raspberry Pi 2 (BCM2836) SMP support

[Pavel Pisa]

Hello Alan,

On Sunday 04 of September 2016 16:38:36 Alan Cudmore wrote:
> Hi Pavel,
> I applied your patches, and verified that my apps still work on the
> Raspberry Pi 1 ( Pi Zero ). Now I am moving to the Pi 2 for some tests.
>
> When building for the Pi 2, I need to use the —enable-smp configure switch,
> correct?

Yes. There is even added configure option RASPBERRYPI_CPUS which controls
number of CPUs reported trough linker script to the application.
The default is all four (4) when --enable-smp is set. If it is not set
then it is set to 1. I have not solved misconfiguration which can
be caused by selection --enable-smp for RPi1. It fails horribly
because some peripherals referenced by SMP code are not available.

> When I build the raspberrypi2 BSP with —enable-smp and —enable-tests, the
> smpfatal08 test does not compile. It has multiple definition errors like
> the following:
> ../../../../../raspberrypi2/lib/librtemsbsp.a(libbsp_a-bspsmp.o): In
> function `_CPU_SMP_Get_current_processor':
> /Users/alan/rtems/build/build-pavel-tmp/arm-rtems4.12/c/raspberrypi2/lib/li
>bbsp/arm/raspberrypi/../../../../../.././raspberrypi2/lib/include/rtems/scor
>e/cpu.h:522: multiple definition of `_CPU_SMP_Start_processor'
> init.o:/Users/alan/rtems/build/build-pavel-tmp/arm-rtems4.12/c/raspberrypi2
>/testsuites/smptests/smpfatal08/../../../../../../../../rtems-src/rtems-pave
>l/c/src/../../testsuites/smptests/smpfatal08/init.c:60: first defined here

I have tried complete tests build and this one fails for me as well.
I have removed references to smpfatal08 from lists in the file

  arm-rtems4.12/c/raspberrypi2/testsuites/smptests/Makefile

The test seems to check cpukit core by replacing BSP provided
CPU management functions by some dummy/test ones and for given
setup the original ones are pull in together with some another
symbol and result is clash.

Then all other tests build OK. I have tried many of them. I have
noticed only one failure (testsuites/smptests/smpmutex01)

*** BEGIN OF TEST SMPMUTEX 1 ***
../../../../../../../../../git/rtems/c/src/../../testsuites/smptests/smpmutex01/init.c:
 184 expected == actual

Has that problem been spotted on Zynq or Altera too?

> But I tried several of the SMP tests that did compile before this one and
> they are working on my Raspberry Pi 2!
>
> When I build with just the samples, rather than the full test suite, the
> build completes, and I can link and run my application just like the Pi.

If you build own application then you need to to include something
like

  #define CONFIGURE_SMP_MAXIMUM_PROCESSORS  2
  #define CONFIGURE_SCHEDULER_PRIORITY_AFFINITY_SMP

before

  #include 

to configure application to actually use more CPUs. Example is to use
only two. If you select limit above 4 then it is corrected by BSP.

I have prepared simple OMK example which runs two tasks on two CPUs

  
https://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/refs/heads/master:/rtems-omk-template/appsmptest

I used it during SMP mailboxes and timer debugging.

By the way, have you Raspberry Pi 3?
I have not tested that but there is some chance that RPi2
build could run on RPi3 unmodified for 32-bit mode.
According to scattered information it seems that
there are no differences in base addresses of critical
peripherals. But may it be that there would be some problem
in core code support or elsewhere.

Best wishes,

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

[PATCH 08/10] bsps/arm: basic BCM2836 SMP implementation.

[pisa]

From: Pavel Pisa <p...@cmp.felk.cvut.cz>

---
 c/src/lib/libbsp/arm/raspberrypi/Makefile.am   |   3 +
 c/src/lib/libbsp/arm/raspberrypi/include/bsp.h |   3 +
 c/src/lib/libbsp/arm/raspberrypi/irq/irq.c |  18 +++
 c/src/lib/libbsp/arm/raspberrypi/startup/bspsmp.c  | 122 +
 .../libbsp/arm/raspberrypi/startup/bspstarthooks.c |  35 +-
 .../lib/libbsp/arm/raspberrypi/startup/linkcmds.in |   2 +-
 .../arm/raspberrypi/startup/mm_config_table.c  |   8 ++
 7 files changed, 187 insertions(+), 4 deletions(-)
 create mode 100644 c/src/lib/libbsp/arm/raspberrypi/startup/bspsmp.c

diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am 
b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
index 01f4ad2..1a2f0aa 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
+++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
@@ -100,6 +100,9 @@ libbsp_a_SOURCES += ../../shared/bspreset_loop.c
 libbsp_a_SOURCES += startup/bspstart.c
 libbsp_a_SOURCES += startup/cmdline.c
 libbsp_a_SOURCES += startup/bspgetworkarea.c
+if HAS_SMP
+libbsp_a_SOURCES += startup/bspsmp.c
+endif
 
 # IRQ
 libbsp_a_SOURCES += ../shared/arm-cp15-set-exception-handler.c
diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h 
b/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h
index 5241979..ecd5b6a 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h
+++ b/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h
@@ -50,6 +50,9 @@ void  rpi_video_init(void);
 void  rpi_fb_outch  (char);
 int rpi_video_is_initialized(void);
 
+void rpi_ipi_initialize(void);
+void rpi_start_rtems_on_secondary_processor(void);
+
 #ifdef __cplusplus
 }
 #endif /* __cplusplus */
diff --git a/c/src/lib/libbsp/arm/raspberrypi/irq/irq.c 
b/c/src/lib/libbsp/arm/raspberrypi/irq/irq.c
index e654d07..48f7810 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/irq/irq.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/irq/irq.c
@@ -32,6 +32,11 @@
 #include 
 #include 
 
+#ifdef RTEMS_SMP
+#include 
+#include 
+#endif
+
 typedef struct {
   unsigned long enable_reg_addr;
   unsigned long disable_reg_addr;
@@ -97,6 +102,19 @@ void bsp_interrupt_dispatch(void)
 
   rtems_vector_number vector = 255;
 
+#ifdef RTEMS_SMP
+  uint32_t cpu_index_self = _SMP_Get_current_processor();
+  uint32_t local_source = BCM2835_REG(BCM2836_IRQ_SOURCE_REG(cpu_index_self));
+
+  if ( local_source & BCM2836_IRQ_SOURCE_MBOX3 ) {
+/* reset mailbox 3 contents to zero */
+BCM2835_REG(BCM2836_MAILBOX_3_READ_CLEAR_BASE + 0x10 * cpu_index_self) = 
0x;
+_SMP_Inter_processor_interrupt_handler();
+  }
+  if ( cpu_index_self != 0 )
+return;
+#endif /* RTEMS_SMP */
+
   pend = BCM2835_REG(BCM2835_IRQ_BASIC);
   if ( pend & BCM2835_IRQ_BASIC_SPEEDUP_USED_BITS ) {
 pend_bit = ffs(pend) - 1;
diff --git a/c/src/lib/libbsp/arm/raspberrypi/startup/bspsmp.c 
b/c/src/lib/libbsp/arm/raspberrypi/startup/bspsmp.c
new file mode 100644
index 000..3f9fd6a
--- /dev/null
+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/bspsmp.c
@@ -0,0 +1,122 @@
+/*
+ * Copyright (c) 2016 Pavel Pisa <p...@cmp.felk.cvut.cz>
+ *
+ * Czech Technical University in Prague
+ * Zikova 1903/4
+ * 166 36 Praha 6
+ * Czech Republic
+ *
+ * Reuses some ideas from Rohini Kulkarni <krohini1...@gmail.com>
+ * GSoC 2015 project and Altera Cyclone-V SMP code
+ * by embedded brains GmbH
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+bool _CPU_SMP_Start_processor( uint32_t cpu_index )
+{
+  bool started;
+  uint32_t cpu_index_self = _SMP_Get_current_processor();
+
+  if (cpu_index != cpu_index_self) {
+
+BCM2835_REG(BCM2836_MAILBOX_3_WRITE_SET_BASE + 0x10 * cpu_index) = 
(uint32_t)_start;
+
+/*
+ * Wait for secondary processor to complete its basic initialization so
+ * that we can enable the unified L2 cache.
+ */
+started = _Per_CPU_State_wait_for_non_initial_state(cpu_index, 0);
+  } else {
+started = false;
+  }
+
+  return started;
+}
+
+
+void rpi_ipi_initialize(void)
+{
+  uint32_t cpu_index_self = _SMP_Get_current_processor();
+
+  /*
+   * Includes support only for mailbox 3 interrupt.
+   * Further interrupt support has to be added. This will have to be integrated
+   * with existing interrupt support for Raspberry Pi
+   */
+
+  /* reset mailbox 3 contents to zero */
+  BCM2835_REG(BCM2836_MAILBOX_3_READ_CLEAR_BASE + 0x10 * cpu_index_self) = 
0x;
+
+  BCM2835_REG(BCM2836_MAILBOX_IRQ_CTRL(cpu_index_self)) =
+BCM2836_MAILBOX_IRQ_CTRL_MBOX3_IRQ;
+}
+
+void rpi_start_rtems_on_secondary_processor(void)
+{
+  uint32_t ctrl;
+
+  ctrl = arm_cp15_start_setup_mmu_and_cache(
+0,
+ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z
+  );
+
+  rpi_ipi_initialize();
+
+  arm_cp15_set_domain_access_control(
+ARM_CP15_DAC_DOMAIN(ARM

[PATCH 05/10] arm/raspberrypi: more definitions of BCM2836 core local peripherals.

[pisa]

From: Pavel Pisa <p...@cmp.felk.cvut.cz>

---
 .../libbsp/arm/raspberrypi/include/raspberrypi.h   | 142 -
 1 file changed, 140 insertions(+), 2 deletions(-)

diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h 
b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
index 4cedc4c..2f42731 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
+++ b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
@@ -347,6 +347,17 @@
 /** @} */
 
 /**
+ * @name Raspberry Pi 2 CPU Cores Local Peripherals
+ *
+ * @{
+ */
+
+#define BCM2836_CORE_LOCAL_PERIPH_BASE0x4000
+#define BCM2836_CORE_LOCAL_PERIPH_SIZE0x0004
+
+/** @} */
+
+/**
  * @name Raspberry Pi 2 Mailbox Register Defines
  *
  * @{
@@ -364,13 +375,140 @@
 /** @} */
 
 /**
+ * @name Raspberry Pi 2 Core Timer
+ *
+ * @{
+ */
+
+#define BCM2836_CORE_TIMER_CTRL   0x4000
+
+#define BCM2836_CORE_TIMER_CTRL_APB_CLK   0x0100
+#define BCM2836_CORE_TIMER_CTRL_INC_2 0x0200
+
+#define BCM2836_CORE_TIMER_PRESCALER  0x4008
+
+#define BCM2836_CORE_TIMER_LS32   0x401C
+#define BCM2836_CORE_TIMER_MS32   0x4020
+
+/** @} */
+
+/**
+ * @name Raspberry Pi 2 Local Timer
+ *
+ * @{
+ */
+
+#define BCM2836_LOCAL_TIMER_CTRL  0x4034
+
+#define BCM2836_LOCAL_TIMER_CTRL_IRQ_FLAG 0x8000
+#define BCM2836_LOCAL_TIMER_CTRL_IRQ_EN   0x2000
+#define BCM2836_LOCAL_TIMER_CTRL_TIMER_EN 0x1000
+#define BCM2836_LOCAL_TIMER_RELOAD0x0FFF
+
+#define BCM2836_LOCAL_TIMER_IRQ_RELOAD0x4038
+
+#define BCM2836_LOCAL_TIMER_IRQ_CLEAR 0x8000
+#define BCM2836_LOCAL_TIMER_RELOAD_NOW0x4000
+
+#define BCM2836_LOCAL_TIMER_IRQ_ROUTING   0x4024
+#define BCM2836_LOCAL_TIMER_ROU_CORE0_IRQ   0x00
+#define BCM2836_LOCAL_TIMER_ROU_CORE1_IRQ   0x01
+#define BCM2836_LOCAL_TIMER_ROU_CORE2_IRQ   0x02
+#define BCM2836_LOCAL_TIMER_ROU_CORE3_IRQ   0x03
+#define BCM2836_LOCAL_TIMER_ROU_CORE0_FIQ   0x04
+#define BCM2836_LOCAL_TIMER_ROU_CORE1_FIQ   0x05
+#define BCM2836_LOCAL_TIMER_ROU_CORE2_FIQ   0x06
+#define BCM2836_LOCAL_TIMER_ROU_CORE3_FIQ   0x07
+
+/** @} */
+
+/**
+ * @name Raspberry Pi 2 IRQ Routing
+ *
+ * @{
+ */
+
+#define BCM2836_GPU_IRQ_ROUTING   0x400C
+
+#define BCM2836_GPU_IRQ_ROU_GPU_IRQ_CORE0 0x
+#define BCM2836_GPU_IRQ_ROU_GPU_IRQ_CORE1 0x0001
+#define BCM2836_GPU_IRQ_ROU_GPU_IRQ_CORE2 0x0002
+#define BCM2836_GPU_IRQ_ROU_GPU_IRQ_CORE4 0x0003
+
+#define BCM2836_GPU_IRQ_ROU_GPU_FIQ_CORE0 0x
+#define BCM2836_GPU_IRQ_ROU_GPU_FIQ_CORE1 0x0004
+#define BCM2836_GPU_IRQ_ROU_GPU_FIQ_CORE2 0x0008
+#define BCM2836_GPU_IRQ_ROU_GPU_FIQ_CORE4 0x000C
+
+#define BCM2836_GPU_IRQ_ROU_GPU_FIQ_CORE4 0x000C
+
+
+/** @} */
+
+/**
  * @name Raspberry Pi 2 Interrupt Register Defines
  *
  * @{
  */
 
-#define BCM2836_MAILBOX_IRQ_CTRL_BASE 0x4050
-#define BCM2836_IRQ_SOURCE_REG_BASE 0x4060
+/* Timers interrupt control registers */
+#define BCM2836_CORE0_TIMER_IRQ_CTRL_BASE 0x4040
+#define BCM2836_CORE1_TIMER_IRQ_CTRL_BASE 0x4044
+#define BCM2836_CORE2_TIMER_IRQ_CTRL_BASE 0x4048
+#define BCM2836_CORE3_TIMER_IRQ_CTRL_BASE 0x404C
+
+#define BCM2836_CORE_TIMER_IRQ_CTRL(cpuidx) \
+  (BCM2836_CORE0_TIMER_IRQ_CTRL_BASE + 0x4 * (cpuidx))
+
+/*
+ * Where to route timer interrupt to, IRQ/FIQ
+ * Setting both the IRQ and FIQ bit gives an FIQ
+ */
+#define BCM2836_CORE_TIMER_IRQ_CTRL_TIMER0_IRQ  0x01
+#define BCM2836_CORE_TIMER_IRQ_CTRL_TIMER1_IRQ  0x02
+#define BCM2836_CORE_TIMER_IRQ_CTRL_TIMER2_IRQ  0x04
+#define BCM2836_CORE_TIMER_IRQ_CTRL_TIMER3_IRQ  0x08
+#define BCM2836_CORE_TIMER_IRQ_CTRL_TIMER0_FIQ  0x10
+#define BCM2836_CORE_TIMER_IRQ_CTRL_TIMER1_FIQ  0x20
+#define BCM2836_CORE_TIMER_IRQ_CTRL_TIMER2_FIQ  0x40
+#define BCM2836_CORE_TIMER_IRQ_CTRL_TIMER3_FIQ  0x80
+
+/* CPU mailbox registers */
+#define BCM2836_MAILBOX_IRQ_CTRL_BASE 0x4050
+#define BCM2836_MAILBOX_IRQ_CTRL(cpuidx) \
+  (BCM2836_MAILBOX_IRQ_CTRL_BASE + 0x4 * (cpuidx))
+/*
+ * Where to route mailbox interrupt to, IRQ/FIQ
+ * Setting both the IRQ and FIQ bit gives an FIQ
+ */
+#define BCM2836_MAILBOX_IRQ_CTRL_MBOX0_IRQ  0x01
+#define BCM2836_MAILBOX_IRQ_CTRL_MBOX1_IRQ  0x02
+#define BCM2836_MAILBOX_IRQ_CTRL_MBOX2_IRQ  0x04
+#define BCM2836_MAILBOX_IRQ_CTRL_MBOX3_IRQ  0x08
+#define BCM2836_MAILBOX_IRQ_CTRL_MBOX0_FIQ  0x10
+#define BCM2836_MAILBOX_IRQ_CTRL_MBOX1_FIQ  0x20
+#define BCM2836_MAILBOX_IRQ_CTRL_MBOX2_FIQ  0x40
+#define BCM2836_MAILBOX_IRQ_CTRL_MBOX3_FIQ  0x80
+
+#define BCM2836_IRQ_SOURCE_REG_BASE   0x4060
+#define BCM2836_IRQ_SOURCE_REG(cpuidx) \
+  (BCM2836_IRQ_SOURCE_REG_BASE + 0x4 * (cpuidx))
+
+#define BCM2836_FIQ_SOURCE_REG_BASE   0x4070
+#define BCM2836_FIQ_SOURCE_REG(cpuidx) \
+  (BCM2836_FIQ_SOURCE_REG_BASE + 0x4 * (cpuidx))
+
+#define BCM2836_IRQ_SOURCE_TIMER0 0x0001
+#

[PATCH 03/10] bsps/arm: reorganize CP15 code to allow clean and invalidate ARMv7 cache by level.

[pisa]

From: Pavel Pisa <p...@cmp.felk.cvut.cz>

New function arm_cp15_cache_invalidate_level and arm_cp15_cache_clean_level
can be used to maintain single cache level (instruction or data).
---
 c/src/lib/libcpu/arm/shared/include/arm-cp15.h | 108 ++---
 1 file changed, 60 insertions(+), 48 deletions(-)

diff --git a/c/src/lib/libcpu/arm/shared/include/arm-cp15.h 
b/c/src/lib/libcpu/arm/shared/include/arm-cp15.h
index 4e4cac4..7b27c1b 100644
--- a/c/src/lib/libcpu/arm/shared/include/arm-cp15.h
+++ b/c/src/lib/libcpu/arm/shared/include/arm-cp15.h
@@ -1083,6 +1083,35 @@ 
arm_cp15_data_cache_invalidate_line_by_set_and_way(uint32_t set_and_way)
 }
 
 ARM_CP15_TEXT_SECTION static inline void
+arm_cp15_cache_invalidate_level(uint32_t level, uint32_t inst_data_fl)
+{
+  uint32_t ccsidr;
+  uint32_t line_power;
+  uint32_t associativity;
+  uint32_t way;
+  uint32_t way_shift;
+
+  ccsidr = arm_cp15_get_cache_size_id_for_level((level << 1) | inst_data_fl);
+
+  line_power = arm_ccsidr_get_line_power(ccsidr);
+  associativity = arm_ccsidr_get_associativity(ccsidr);
+  way_shift = __builtin_clz(associativity - 1);
+
+  for (way = 0; way < associativity; ++way) {
+uint32_t num_sets = arm_ccsidr_get_num_sets(ccsidr);
+uint32_t set;
+
+for (set = 0; set < num_sets; ++set) {
+  uint32_t set_way = (way << way_shift)
+| (set << line_power)
+| (level << 1);
+
+  arm_cp15_data_cache_invalidate_line_by_set_and_way(set_way);
+}
+  }
+}
+
+ARM_CP15_TEXT_SECTION static inline void
 arm_cp15_data_cache_invalidate_all_levels(void)
 {
   uint32_t clidr = arm_cp15_get_cache_level_id();
@@ -1094,30 +1123,7 @@ arm_cp15_data_cache_invalidate_all_levels(void)
 
 /* Check if this level has a data cache or unified cache */
 if (((ctype & (0x6)) == 2) || (ctype == 4)) {
-  uint32_t ccsidr;
-  uint32_t line_power;
-  uint32_t associativity;
-  uint32_t way;
-  uint32_t way_shift;
-
-  ccsidr = arm_cp15_get_cache_size_id_for_level(level << 1);
-
-  line_power = arm_ccsidr_get_line_power(ccsidr);
-  associativity = arm_ccsidr_get_associativity(ccsidr);
-  way_shift = __builtin_clz(associativity - 1);
-
-  for (way = 0; way < associativity; ++way) {
-uint32_t num_sets = arm_ccsidr_get_num_sets(ccsidr);
-uint32_t set;
-
-for (set = 0; set < num_sets; ++set) {
-  uint32_t set_way = (way << way_shift)
-| (set << line_power)
-| (level << 1);
-
-  arm_cp15_data_cache_invalidate_line_by_set_and_way(set_way);
-}
-  }
+  arm_cp15_cache_invalidate_level(level, 0);
 }
   }
 }
@@ -1155,6 +1161,35 @@ arm_cp15_data_cache_clean_line_by_set_and_way(uint32_t 
set_and_way)
 }
 
 ARM_CP15_TEXT_SECTION static inline void
+arm_cp15_data_cache_clean_level(uint32_t level)
+{
+  uint32_t ccsidr;
+  uint32_t line_power;
+  uint32_t associativity;
+  uint32_t way;
+  uint32_t way_shift;
+
+  ccsidr = arm_cp15_get_cache_size_id_for_level(level << 1);
+
+  line_power = arm_ccsidr_get_line_power(ccsidr);
+  associativity = arm_ccsidr_get_associativity(ccsidr);
+  way_shift = __builtin_clz(associativity - 1);
+
+  for (way = 0; way < associativity; ++way) {
+uint32_t num_sets = arm_ccsidr_get_num_sets(ccsidr);
+uint32_t set;
+
+for (set = 0; set < num_sets; ++set) {
+  uint32_t set_way = (way << way_shift)
+| (set << line_power)
+| (level << 1);
+
+  arm_cp15_data_cache_clean_line_by_set_and_way(set_way);
+}
+  }
+}
+
+ARM_CP15_TEXT_SECTION static inline void
 arm_cp15_data_cache_clean_all_levels(void)
 {
   uint32_t clidr = arm_cp15_get_cache_level_id();
@@ -1166,30 +1201,7 @@ arm_cp15_data_cache_clean_all_levels(void)
 
 /* Check if this level has a data cache or unified cache */
 if (((ctype & (0x6)) == 2) || (ctype == 4)) {
-  uint32_t ccsidr;
-  uint32_t line_power;
-  uint32_t associativity;
-  uint32_t way;
-  uint32_t way_shift;
-
-  ccsidr = arm_cp15_get_cache_size_id_for_level(level << 1);
-
-  line_power = arm_ccsidr_get_line_power(ccsidr);
-  associativity = arm_ccsidr_get_associativity(ccsidr);
-  way_shift = __builtin_clz(associativity - 1);
-
-  for (way = 0; way < associativity; ++way) {
-uint32_t num_sets = arm_ccsidr_get_num_sets(ccsidr);
-uint32_t set;
-
-for (set = 0; set < num_sets; ++set) {
-  uint32_t set_way = (way << way_shift)
-| (set << line_power)
-| (level << 1);
-
-  arm_cp15_data_cache_clean_line_by_set_and_way(set_way);
-}
-  }
+  arm_cp15_data_cache_clean_level(level);
 }
   }
 }
-- 
1.9.1

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

[PATCH 10/10] arm/raspberrypi: use GPU/system timer as clock source.

[pisa]

From: Pavel Pisa <p...@cmp.felk.cvut.cz>

It has advantage that it is designed as free-running counter
with compare registers and can easily serve for for both
timecounter and tick interrupt.
---
 c/src/lib/libbsp/arm/raspberrypi/clock/clockdrv.c | 98 ++-
 1 file changed, 62 insertions(+), 36 deletions(-)

diff --git a/c/src/lib/libbsp/arm/raspberrypi/clock/clockdrv.c 
b/c/src/lib/libbsp/arm/raspberrypi/clock/clockdrv.c
index 4ce795f..72c85b1 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/clock/clockdrv.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/clock/clockdrv.c
@@ -10,6 +10,7 @@
  * BCM2835 Clock driver
  *
  * Copyright (c) 2013 Alan Cudmore
+ * Copyright (c) 2016 Pavel Pisa
  *
  *  The license and distribution terms for this file may be
  *  found in the file LICENSE in this distribution or at
@@ -21,71 +22,96 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 /* This is defined in ../../../shared/clockdrv_shell.h */
 void Clock_isr(rtems_irq_hdl_param arg);
 
+static struct timecounter raspberrypi_tc;
+
+static uint32_t raspberrypi_clock_get_timecount(struct timecounter *tc)
+{
+  return BCM2835_REG(BCM2835_GPU_TIMER_CLO);
+}
+
 static void raspberrypi_clock_at_tick(void)
 {
-   BCM2835_REG(BCM2835_TIMER_CLI) = 0;
+  uint32_t act_val;
+  uint32_t next_cmp = BCM2835_REG(BCM2835_GPU_TIMER_C3);
+  next_cmp += rtems_configuration_get_microseconds_per_tick();
+  BCM2835_REG(BCM2835_GPU_TIMER_C3) = next_cmp;
+  act_val = BCM2835_REG(BCM2835_GPU_TIMER_CLO);
+
+  /*
+   * Clear interrupt only if there is time left to the next tick.
+   * If time of the next tick has already passed then interrupt
+   * request stays active and fires immediately after current tick
+   * processing is finished.
+   */
+  if ((int32_t)(next_cmp - act_val) > 0)
+BCM2835_REG(BCM2835_GPU_TIMER_CS) = BCM2835_GPU_TIMER_CS_M3;
 }
 
-static void raspberrypi_clock_handler_install(void)
+static void raspberrypi_clock_handler_install_isr(
+  rtems_isr_entry clock_isr
+)
 {
   rtems_status_code sc = RTEMS_SUCCESSFUL;
 
-  sc = rtems_interrupt_handler_install(
-BCM2835_IRQ_ID_TIMER_0,
-"Clock",
-RTEMS_INTERRUPT_UNIQUE,
-(rtems_interrupt_handler) Clock_isr,
-NULL
-  );
-  if (sc != RTEMS_SUCCESSFUL) {
+  if (clock_isr != NULL) {
+sc = rtems_interrupt_handler_install(
+  BCM2835_IRQ_ID_GPU_TIMER_M3,
+  "Clock",
+  RTEMS_INTERRUPT_UNIQUE,
+  (rtems_interrupt_handler) clock_isr,
+  NULL
+);
+  } else {
+/* Remove interrupt handler */
+sc = rtems_interrupt_handler_remove(
+  BCM2835_IRQ_ID_GPU_TIMER_M3,
+  (rtems_interrupt_handler) Clock_isr,
+  NULL
+);
+  }
+  if ( sc != RTEMS_SUCCESSFUL ) {
 rtems_fatal_error_occurred(0xdeadbeef);
   }
 }
 
-static void raspberrypi_clock_initialize(void)
+static void raspberrypi_clock_initialize_hardware(void)
 {
-   BCM2835_REG(BCM2835_TIMER_CTL) = 0x003E;
-   BCM2835_REG(BCM2835_TIMER_LOD) =
-rtems_configuration_get_microseconds_per_tick() - 1;
-   BCM2835_REG(BCM2835_TIMER_RLD) =
-rtems_configuration_get_microseconds_per_tick() - 1;
-   BCM2835_REG(BCM2835_TIMER_DIV) = BCM2835_TIMER_PRESCALE;
-   BCM2835_REG(BCM2835_TIMER_CLI) = 0;
-   BCM2835_REG(BCM2835_TIMER_CTL) = 0x003E00A2;
+  uint32_t next_cmp = BCM2835_REG(BCM2835_GPU_TIMER_CLO);
+  next_cmp += rtems_configuration_get_microseconds_per_tick();
+  BCM2835_REG(BCM2835_GPU_TIMER_C3) = next_cmp;
+  BCM2835_REG(BCM2835_GPU_TIMER_CS) = BCM2835_GPU_TIMER_CS_M3;
+
+  raspberrypi_tc.tc_get_timecount = raspberrypi_clock_get_timecount;
+  raspberrypi_tc.tc_counter_mask = 0x;
+  raspberrypi_tc.tc_frequency = 100; /* 1 MHz */
+  raspberrypi_tc.tc_quality = RTEMS_TIMECOUNTER_QUALITY_CLOCK_DRIVER;
+  rtems_timecounter_install(_tc);
 }
 
 static void raspberrypi_clock_cleanup(void)
 {
-  rtems_status_code sc = RTEMS_SUCCESSFUL;
-
-  /* Remove interrupt handler */
-  sc = rtems_interrupt_handler_remove(
-BCM2835_IRQ_ID_TIMER_0,
-(rtems_interrupt_handler) Clock_isr,
-NULL
-  );
-  if (sc != RTEMS_SUCCESSFUL) {
-rtems_fatal_error_occurred(0xdeadbeef);
-  }
+  bsp_interrupt_vector_disable(BCM2835_IRQ_ID_GPU_TIMER_M3);
 }
 
 #define Clock_driver_support_at_tick() raspberrypi_clock_at_tick()
 
-#define Clock_driver_support_initialize_hardware() 
raspberrypi_clock_initialize()
+#define Clock_driver_support_initialize_hardware() 
raspberrypi_clock_initialize_hardware()
 
-#define Clock_driver_support_install_isr(isr, old_isr) \
+#define Clock_driver_support_shutdown_hardware() raspberrypi_clock_cleanup()
+
+#define Clock_driver_support_install_isr(clock_isr, old_isr) \
   do { \
-raspberrypi_clock_handler_install();   \
+raspberrypi_clock_handler_install_isr(clock_isr);  \
 old_isr = NULL;\
   } while (0)
 
-#define Clock_driver_support_shutdown_hardwar

[PATCH 07/10] arm/raspberrypi: propagate number of configured CPUs into linker script.

[pisa]

From: Pavel Pisa <p...@cmp.felk.cvut.cz>

---
 c/src/lib/libbsp/arm/raspberrypi/configure.ac| 14 ++
 c/src/lib/libbsp/arm/raspberrypi/startup/linkcmds.in |  2 ++
 2 files changed, 16 insertions(+)

diff --git a/c/src/lib/libbsp/arm/raspberrypi/configure.ac 
b/c/src/lib/libbsp/arm/raspberrypi/configure.ac
index 48bd62c..b772d6e 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/configure.ac
+++ b/c/src/lib/libbsp/arm/raspberrypi/configure.ac
@@ -40,6 +40,20 @@ RTEMS_BSPOPTS_SET([BSP_IS_RPI2],[*],[0])
 RTEMS_BSPOPTS_HELP([BSP_IS_RPI2],[Set if the BSP variant is Raspberry Pi 2.])
 AM_CONDITIONAL(RTEMS_RPI2,[test "$BSP_IS_RPI2" = "1"])
 
+# Hom many CPUs are used?
+RASPBERRYPI_CPUS="1"
+RTEMS_CHECK_SMP
+AM_CONDITIONAL(HAS_SMP,[test "$rtems_cv_HAS_SMP" = "yes"])
+AS_IF([test "$rtems_cv_HAS_SMP" = "yes"],
+  [RASPBERRYPI_CPUS="4"])
+
+AC_DEFUN([RASPBERRYPI_LINKCMD],[
+AC_ARG_VAR([$1],[$2; default $3])dnl
+[$1]=[$]{[$1]:-[$3]}
+])
+
+RASPBERRYPI_LINKCMD([RASPBERRYPI_CPUS],[Number of active 
cores],[${RASPBERRYPI_CPUS}])
+
 RTEMS_BSP_CLEANUP_OPTIONS(0, 0)
 
 AC_CONFIG_FILES([
diff --git a/c/src/lib/libbsp/arm/raspberrypi/startup/linkcmds.in 
b/c/src/lib/libbsp/arm/raspberrypi/startup/linkcmds.in
index fc72b5c..d88c6d7 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/startup/linkcmds.in
+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/linkcmds.in
@@ -41,6 +41,8 @@ MEMORY {
 RAM(AIW) : ORIGIN = 0x8000, LENGTH = 128M - 32k
 }
 
+bsp_processor_count = DEFINED (bsp_processor_count) ? bsp_processor_count : 
@RASPBERRYPI_CPUS@;
+
 REGION_ALIAS ("REGION_START", RAM);
 REGION_ALIAS ("REGION_VECTOR", VECTOR_RAM);
 REGION_ALIAS ("REGION_TEXT", RAM);
-- 
1.9.1

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

[PATCH 02/10] bsps/arm: remove lock in arm_cp15_set_translation_table_entries().

[pisa]

From: Pavel Pisa <p...@cmp.felk.cvut.cz>

Protection by rtems_interrupt_disable() is incompatible with SMP build.
Actual page table entries manipulation function does not need locking
and disabling cache and can be run concurrently even on multiple
CPUs as long as changes do not modify same region. If the function
is called from more threads/CPUs to modify same region with different
mapping options concurrently then there is problem at another level
of virtual address space management  and has to be solved by mutex
or other locking at that level.
---
 c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c 
b/c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c
index f650009..c2be0f5 100644
--- a/c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c
+++ b/c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c
@@ -85,13 +85,5 @@ uint32_t arm_cp15_set_translation_table_entries(
   uint32_t section_flags
 )
 {
-  rtems_interrupt_level level;
-  uint32_t section_flags_of_first_entry;
-
-  rtems_interrupt_disable(level);
-  section_flags_of_first_entry =
-set_translation_table_entries(begin, end, section_flags);
-  rtems_interrupt_enable(level);
-
-  return section_flags_of_first_entry;
+  return set_translation_table_entries(begin, end, section_flags);
 }
-- 
1.9.1

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