Re: [PATCH v1 1/3] cpukit: Add signal mapping support

[Sebastian Huber]

On 20/04/2021 07:30, Chris Johns wrote:


We need a way for libdebugger or any other piece of software to capture and
cascade the call. If this can be done on aarch64 then I am happy.


The fatal error extensions execute in a user controllable order. You can 
for example register a libdebugger handler which deals with break point 
exceptions before the signal mapping handler is called.


Synchronous exceptions should end up in an RTEMS_FATAL_SOURCE_EXCEPTION 
fatal error. The fatal code is a pointer to rtems_exception_frame 
(CPU_Exception_frame). In this data structure should be the complete 
state of the interrupted context (which could be also an interrupt 
handler). If you want to resume execution of the interrupted context, 
then we need an API for this (setters/getters and some sort of a longjmp()).


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

Re: [PATCH] bsps/arm: Set MSP in ARMv7-M start code

[Sebastian Huber]

On 20/04/2021 07:30, Chris Johns wrote:


On 20/4/21 3:28 pm, Sebastian Huber wrote:

This helps if applications are started by a boot loader.

How does it help?

    /*
     * Set the Main Stack Pointer (MSP) to the ISR stack area end just in
     * case we run using the Process Stack Pointer (PSP).
     */

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

Re: [PATCH] bsps/arm: Set MSP in ARMv7-M start code

[Chris Johns]

On 20/4/21 3:28 pm, Sebastian Huber wrote:
> This helps if applications are started by a boot loader.

How does it help?

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

Re: [PATCH v1 1/3] cpukit: Add signal mapping support

[Chris Johns]

On 20/4/21 5:02 am, Kinsey Moore wrote:
> On 4/18/2021 20:18, Chris Johns wrote:
>> On 19/4/21 9:23 am, Joel Sherrill wrote:
>>>
>>> On Sun, Apr 18, 2021, 5:13 PM Chris Johns >> > wrote:
>>>
>>>  On 17/4/21 10:00 am, Kinsey Moore wrote:
>>>  > On 4/16/2021 08:48, Gedare Bloom wrote:
>>>  >> On Fri, Apr 16, 2021 at 1:19 AM Sebastian Huber
>>>  >> >>  > wrote:
>>>  >>> Hello Kinsey,
>>>  >>>
>>>  >>> why don't you use a fatal error extension for this? You can save 
>>> all
>>> the
>>>  >>> processor state to a structure and use it to jump to previous or 
>>> next
>>>  >>> instruction it if needed in a custom fatal error handler which 
>>> deals
>>>  >>> with RTEMS_FATAL_EXCEPTION. I think libdebugger uses this approach.
>>>  >>>
>>>  >> +1
>>>  >>
>>>  >> This is otherwise a major overhaul/addition to the CPU port
>>>  >> requirements. I'd lean in favor of adding any CPU_* API that is
>>>  >> necessary to support vectoring from an exception to a signal. I 
>>> don't
>>>  >> think we can make this kind of intrusive modification to basic
>>>  >> interrupt handling capabilities across all ports easily. Some of 
>>> that
>>>  >> code is old and very stable.
>>>  >
>>>  > I avoided going that direction to maintain the interrupt stack since 
>>> an
>>>  > exception return from within those handlers would necessarily leave
>>> the CPU
>>>  > state as well as intervening functions on the stack along with a 
>>> minor
>>>  amount of
>>>  > data on the thread stack. In addition, thread dispatch needs to occur
>>> and all
>>>  > exception handling for AArch64 (as modeled after ARM) is currently
>>> considered
>>>  > final with no way to reasonably return to execution.
>>>  >
>>>  > Not every platform will need this kind of intrusive change. Any
>>> platform that
>>>  > handles exceptions in a manner similar to IRQs can deal with this
>>> exception
>>>  > mapping far more trivially. ARM and AArch64 don't have that luxury,
>>> but SPARC
>>>  > does and I assume others do as well.
>>>
>>>  How would a user in an application debug a data abort error if all they
>>> get is a
>>>  signal?
>>>
>>>
>>> This is optional and just the way certain Ada exceptions work.
>> Optional means what? What about other optional pieces?
>>
>> Does the change have a wider use case than Ada? I think it may which is good.
>> As a result I feel we need to consider other users of exceptions and how they
>> may interact with this change.
> I think Joel meant optional the same way libdebugger is optional. This change
> operates the same way on AArch64 that libdebugger operates on ARMv7.
>>
>>> If the user
>>> wanted more detail, they would like have to poke directly before it becomes 
>>> a
>>> signal.
>> I would connect a debugger and then expect to have the pc left at the 
>> faulting
>> instruction. At a technical level this means the faulting exception frame 
>> needs
>> to be handled and not compacted down to a single signal. On a 32 bit ARM it 
>> is a
>> very difficult piece of code and I would be pleasantly surprised if you did 
>> not
>> need this on an aarch64.
> It's likely to be just as painful as ARMv7. I spent part of the morning
> reviewing the relevant libdebugger code and both hook directly into the vector
> table. As things stand, libdebugger and this code can not coexist on ARMv7 or
> AArch64.

I suppose the debugger needs to be able to capture the exceptions over this
code. I think that works?

>>
>>>  How would this type of signal support be implemented on the 32bit ARM
>>> arch and
>>>  maintain libdebugger support?
>>>
>>> Is there a technical limitation I don't know about? On the SPARC, it 
>>> recognizes
>>> that only certain faults can be mapped.
>> Not specifically, I am just wondering how each part of our code integrates. 
>> Does
>> adding aarch64 to libdebugger need to work with these changes so the signal
>> exception confdef option is still works? And then the other way around does
>> adding exception signal support to the 32 bit ARM have to deal with 
>> libdebugger
>> as it exists? Who is paying the tax and what does it look like?
> 
> The current implementation of both libdebugger on ARMv7 and this exception to
> signal translator on AArch64 are very similar in how they operate. libdebugger
> on ARMv7 hooks every exception type at the vector table while this translator
> hooks the common/unified exception vector for AArch64. There isn't currently a
> way they could even partially share the exceptions as there isn't a mechanism
> available to register hooks to them individually.
> 
> Some form of sharing could be possible on SPARC since both exceptions and IRQs
> are just different ranges of traps (all of which have handler hooks), but with
> possibly reduced functionality on the libdebugger side since 

[PATCH] bsps/arm: Set MSP in ARMv7-M start code

[Sebastian Huber]

This helps if applications are started by a boot loader.
---
 bsps/arm/shared/start/start.S | 8 
 1 file changed, 8 insertions(+)

diff --git a/bsps/arm/shared/start/start.S b/bsps/arm/shared/start/start.S
index 50bf1d4841..bd623178ed 100644
--- a/bsps/arm/shared/start/start.S
+++ b/bsps/arm/shared/start/start.S
@@ -553,6 +553,14 @@ _start:
 #endif
 
ldr sp, =_ISR_Stack_area_end
+
+   /*
+* Set the Main Stack Pointer (MSP) to the ISR stack area end just in
+* case we run using the Process Stack Pointer (PSP).
+*/
+   mov r0, sp
+   msr msp, r0
+
ldr lr, =bsp_start_hook_0_done + 1
b   bsp_start_hook_0
 
-- 
2.26.2

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

Re: OS Neutrality in Python Development Guidelines?

[Chris Johns]

On 20/4/21 4:12 am, Sebastian Huber wrote:
> On 19/04/2021 18:48, Gedare Bloom wrote:
> 
 A random pick of a file and a brief scan ...

 https://git.rtems.org/rtems-central/tree/rtemsspec/interface.py#n313
>>> There is no issue in this line.

I disagree. At a technical level there is an issue. Python provides os.linesep
to handle this specific case. Any place you force the ending the has to be
considered code brittle. Maybe the code will not show any issue but what it
creates may.

>> I believe some can configure their git to inject \n\r on clone/pull
>> and fixes it up on commit. I have to do this for example to use
>> Windows source files in some projects where the IDE is only available
>> there.
> 
> This code generates C source files for RTEMS. These files should have Unix 
> line
> endings.

A more specific and maybe better version of this sentence is ...

  "This code generates C source files for RTEMS on the host the
   generator is run on. The files have host's end of line
   encoding."

> There are probably Git users on Windows which enable the LF to CRLF 
> conversion.
> There are probably also Git users on Windows which don't enable this feature.

This should be covered by the format we hold for the files in the repo and what
the user has or uses is for them to manage. If a tool such as a git defaults to
the host standard and our tools also use that same default then things should 
work.

My experience over the last decade of the RSB has taught me if it is wrong it
will show up. A guide needs to cover these issues and we need to review so our
code meets those guide lines.

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

Re: [PATCH] score: Remove unused _Thread_queue_Dequeue()

[Sebastian Huber]

On 19/04/2021 21:12, Gedare Bloom wrote:


OK. Interesting, was this previously used and something changed?
This was previously used (some years ago). Changes for the SMP support 
made it unused at some point. I reviewed this code recently and there 
are more things left to clean up.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

Re: OS Neutrality in Python Development Guidelines?

[Chris Johns]

On 20/4/21 2:52 am, Gedare Bloom wrote:
> The biggest issues are paths and CaseSensitive filesystems. I'm sure
> there are other hidden brambles though.

Path length in Windows ...

https://git.rtems.org/rtems-tools/tree/rtemstoolkit/path.py#n63

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

Re: [PATCH] score: Remove unused _Thread_queue_Dequeue()

[Gedare Bloom]

OK. Interesting, was this previously used and something changed?

On Mon, Apr 19, 2021 at 12:08 PM Sebastian Huber
 wrote:
>
> ---
>  cpukit/include/rtems/score/threadqimpl.h | 51 
>  cpukit/score/src/threadqenqueue.c| 32 ---
>  2 files changed, 83 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/threadqimpl.h 
> b/cpukit/include/rtems/score/threadqimpl.h
> index 88aba49a68..ca59de9e31 100644
> --- a/cpukit/include/rtems/score/threadqimpl.h
> +++ b/cpukit/include/rtems/score/threadqimpl.h
> @@ -793,57 +793,6 @@ RTEMS_INLINE_ROUTINE void _Thread_queue_Release(
>  }
>  #endif
>
> -/**
> - * @brief Dequeues the first thread waiting on the thread queue and returns 
> it.
> - *
> - * @param the_thread_queue The thread queue for the operation.
> - * @param operations The thread queue operations.
> - *
> - * @return The first locked thread.
> - */
> -Thread_Control *_Thread_queue_Do_dequeue(
> -  Thread_queue_Control  *the_thread_queue,
> -  const Thread_queue_Operations *operations
> -#if defined(RTEMS_MULTIPROCESSING)
> -  ,
> -  Thread_queue_MP_calloutmp_callout
> -#endif
> -);
> -
> -/**
> - *  @brief Gets a pointer to a thread waiting on the_thread_queue.
> - *
> - *  This function returns a pointer to a thread waiting on
> - *  the_thread_queue.  The selection of this thread is based on
> - *  the discipline of the_thread_queue.  If no threads are waiting
> - *  on the_thread_queue, then NULL is returned.
> - *
> - *  - INTERRUPT LATENCY:
> - *+ single case
> - */
> -#if defined(RTEMS_MULTIPROCESSING)
> -  #define _Thread_queue_Dequeue( \
> -the_thread_queue, \
> -operations, \
> -mp_callout \
> -  ) \
> -_Thread_queue_Do_dequeue( \
> -  the_thread_queue, \
> -  operations, \
> -  mp_callout \
> -)
> -#else
> -  #define _Thread_queue_Dequeue( \
> -the_thread_queue, \
> -operations, \
> -mp_callout \
> -  ) \
> -_Thread_queue_Do_dequeue( \
> -  the_thread_queue, \
> -  operations \
> -)
> -#endif
> -
>  /**
>   * @brief Blocks the thread and places it on the thread queue.
>   *
> diff --git a/cpukit/score/src/threadqenqueue.c 
> b/cpukit/score/src/threadqenqueue.c
> index ba31b13dd1..5e228b7190 100644
> --- a/cpukit/score/src/threadqenqueue.c
> +++ b/cpukit/score/src/threadqenqueue.c
> @@ -746,38 +746,6 @@ void _Thread_queue_Surrender_sticky(
>  }
>  #endif
>
> -Thread_Control *_Thread_queue_Do_dequeue(
> -  Thread_queue_Control  *the_thread_queue,
> -  const Thread_queue_Operations *operations
> -#if defined(RTEMS_MULTIPROCESSING)
> -  ,
> -  Thread_queue_MP_calloutmp_callout
> -#endif
> -)
> -{
> -  Thread_queue_Context  queue_context;
> -  Thread_Control   *the_thread;
> -
> -  _Thread_queue_Context_initialize( _context );
> -  _Thread_queue_Context_set_MP_callout( _context, mp_callout );
> -  _Thread_queue_Acquire( the_thread_queue, _context );
> -
> -  the_thread = _Thread_queue_First_locked( the_thread_queue, operations );
> -
> -  if ( the_thread != NULL ) {
> -_Thread_queue_Extract_critical(
> -  _thread_queue->Queue,
> -  operations,
> -  the_thread,
> -  _context
> -);
> -  } else {
> -_Thread_queue_Release( the_thread_queue, _context );
> -  }
> -
> -  return the_thread;
> -}
> -
>  #if defined(RTEMS_MULTIPROCESSING)
>  void _Thread_queue_Unblock_proxy(
>Thread_queue_Queue *queue,
> --
> 2.26.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1 1/3] cpukit: Add signal mapping support

[Kinsey Moore]

On 4/18/2021 20:18, Chris Johns wrote:

On 19/4/21 9:23 am, Joel Sherrill wrote:


On Sun, Apr 18, 2021, 5:13 PM Chris Johns mailto:chr...@rtems.org>> wrote:

 On 17/4/21 10:00 am, Kinsey Moore wrote:
 > On 4/16/2021 08:48, Gedare Bloom wrote:
 >> On Fri, Apr 16, 2021 at 1:19 AM Sebastian Huber
 >> mailto:sebastian.hu...@embedded-brains.de>> wrote:
 >>> Hello Kinsey,
 >>>
 >>> why don't you use a fatal error extension for this? You can save all 
the
 >>> processor state to a structure and use it to jump to previous or next
 >>> instruction it if needed in a custom fatal error handler which deals
 >>> with RTEMS_FATAL_EXCEPTION. I think libdebugger uses this approach.
 >>>
 >> +1
 >>
 >> This is otherwise a major overhaul/addition to the CPU port
 >> requirements. I'd lean in favor of adding any CPU_* API that is
 >> necessary to support vectoring from an exception to a signal. I don't
 >> think we can make this kind of intrusive modification to basic
 >> interrupt handling capabilities across all ports easily. Some of that
 >> code is old and very stable.
 >
 > I avoided going that direction to maintain the interrupt stack since an
 > exception return from within those handlers would necessarily leave the 
CPU
 > state as well as intervening functions on the stack along with a minor
 amount of
 > data on the thread stack. In addition, thread dispatch needs to occur 
and all
 > exception handling for AArch64 (as modeled after ARM) is currently 
considered
 > final with no way to reasonably return to execution.
 >
 > Not every platform will need this kind of intrusive change. Any platform 
that
 > handles exceptions in a manner similar to IRQs can deal with this 
exception
 > mapping far more trivially. ARM and AArch64 don't have that luxury, but 
SPARC
 > does and I assume others do as well.

 How would a user in an application debug a data abort error if all they 
get is a
 signal?


This is optional and just the way certain Ada exceptions work.

Optional means what? What about other optional pieces?

Does the change have a wider use case than Ada? I think it may which is good.
As a result I feel we need to consider other users of exceptions and how they
may interact with this change.
I think Joel meant optional the same way libdebugger is optional. This 
change operates the same way on AArch64 that libdebugger operates on ARMv7.



If the user
wanted more detail, they would like have to poke directly before it becomes a
signal.

I would connect a debugger and then expect to have the pc left at the faulting
instruction. At a technical level this means the faulting exception frame needs
to be handled and not compacted down to a single signal. On a 32 bit ARM it is a
very difficult piece of code and I would be pleasantly surprised if you did not
need this on an aarch64.
It's likely to be just as painful as ARMv7. I spent part of the morning 
reviewing the relevant libdebugger code and both hook directly into the 
vector table. As things stand, libdebugger and this code can not coexist 
on ARMv7 or AArch64.



 How would this type of signal support be implemented on the 32bit ARM arch 
and
 maintain libdebugger support?

Is there a technical limitation I don't know about? On the SPARC, it recognizes
that only certain faults can be mapped.

Not specifically, I am just wondering how each part of our code integrates. Does
adding aarch64 to libdebugger need to work with these changes so the signal
exception confdef option is still works? And then the other way around does
adding exception signal support to the 32 bit ARM have to deal with libdebugger
as it exists? Who is paying the tax and what does it look like?


The current implementation of both libdebugger on ARMv7 and this 
exception to signal translator on AArch64 are very similar in how they 
operate. libdebugger on ARMv7 hooks every exception type at the vector 
table while this translator hooks the common/unified exception vector 
for AArch64. There isn't currently a way they could even partially share 
the exceptions as there isn't a mechanism available to register hooks to 
them individually.


Some form of sharing could be possible on SPARC since both exceptions 
and IRQs are just different ranges of traps (all of which have handler 
hooks), but with possibly reduced functionality on the libdebugger side 
since some of the exceptions libdebugger typically catches would instead 
get translated and pushed into whichever runtime was operating, be it 
Ada, C++, Fortran, etc..





 How would libdebugger be integrated on the aarch64 with this change?

Again what's the limitation? You appear to there's something about the
architecture that would cause a clash.

Are the exceptions a shared resource or exclusive? If shared, how? If exclusive
does this mean an aarch64 libdebugger back end does not need to deal 

Re: [PATCH] Fixes for TMS570 BSP

[Pavel Pisa]

Hello Robin and Gedare,

(sent again to pass into the list)

On Monday 19 of April 2021 19:13:29 Gedare Bloom wrote:
> Hi Robin, Pavel:
>
> On Mon, Apr 19, 2021 at 2:57 AM Robin Müller  
> wrote:
> > If this was intentional, I can also adapt the lwIP port sources to use
> > ti/herc. I was not sure about that.
>
> I think Pavel should comment. I believe at the time care was taken to
> avoid importing TI HalCoGen code generation, and maybe this missing
> ti_herc is an artifact from that. I think over time TI has moved
> toward providing a slightly better license (2-clause BSD with hardware
> restriction) on their HAL/SOC libs. We won't merge code with the
> hardware restriction clause. So it can be a little problematic to get
> things working nicely, it has to be well documented the steps to
> reproduce setups based on restrictive vendor-provided code.
>
> That's what I remember anyway. Pavel may explain better.

Yes, the main problem has been incompatible license, other problem
is that HalCoGen header files was and probably is still different
for different family members. It seems to make header files to be generated
partly by hand and by different people, some code fills hexadecimal numbers
into registers without using predefined bit fields etc., basically
basically the code quality which should never go into any safety related
application.

Premysl Houdek has workend o project as part of thesis work and GSoC.
He converted complete fields description from the manual to the JSON
files and then generated all header files according to format,
which has been declared as the best one by Embedded Brains for other
BSPs. Se the project with headers generation

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

But we have added option to compile RTEMS BSP with HalCoGen
generated files the first. Then we have written UART
and other parts from scratch, because there was not full documentation
for test subsystem init, there has been some parts taken
from Ti example files and where possible tidied up to use
symbols for bitfields. When BSP is compiled with

  TMS570_USE_HWINIT_STARTUP=1

it can start without external initialization or loader.

Long term plan has been to add support for TMS570LC4357
as well but cooperation with other universities, open-source
and RTEMS has been of no interrest of my former head...

The work on this BSP is on my very long todo list, but
with very low priority

Anyway, we achieved to port LwIP to RTEMS BSP, TMS570 part
is generally rewrite from scratch, we have failde many times
at that time with Ti provided code even with their FreeRTOS
code. Our port is in omk-devel branch of the next repo

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

Code worked with FreeRTOS and HalCoGen BSP as well as with RTEMS

  
https://sourceforge.net/p/ulan/lwip-omk/ci/omk-devel/tree/ports/driver/tms570_emac/
  https://sourceforge.net/p/ulan/lwip-omk/ci/omk-devel/tree/ports/os/rtems/

But on RTEMS there is some way to go still to integrate LwIP
with RTEMS+NEWLIB to be usable same way as old included BSD
and new external BSD stack. I hope that things move forward
during this year GSoC.

As for changes, I have not worked with TMS570 RTEMS for long time.
Again, I would like to check that BSP runs correctly before next
release, but time is a problem, so no promise there.

If there is problem with defines collision, I ACK to change
names. In the fact, it seems to be incorrect even in past.

I have worked with BSP before switch to YAML based build,
so I cannot say what is right for now. But ti_herc seems
to be consistet with headers location in the BSP sources,
so I think that the change is correct as well.


> > On Mon, 19 Apr 2021 at 10:55, Robin Mueller  
> > wrote:
> >> When compiling the lwIP port for the TMS570, there
> >> were issues with the BSP. Headers are expected in a folder
> >> named ti_herc which did not exist. This fixes the issue.
> >>
> >> Furthermore, there were multiple warnings about define redefinitions.
> >> This was fixed as well.
> >> ---
> >>  bsps/arm/tms570/include/bsp/irq.h  | 6 +++---
> >>  spec/build/bsps/arm/tms570/obj.yml | 2 +-
> >>  2 files changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/bsps/arm/tms570/include/bsp/irq.h
> >> b/bsps/arm/tms570/include/bsp/irq.h index c37ebadbc4..0b6ea1e6fd 100644
> >> --- a/bsps/arm/tms570/include/bsp/irq.h
> >> +++ b/bsps/arm/tms570/include/bsp/irq.h
> >> @@ -34,7 +34,7 @@
> >>
> >>  #define BSP_INTERRUPT_VECTOR_MIN 0U
> >>  #define TMS570_IRQ_ESM_HIGH 0
> >> -#define TMS570_IRQ_RESERVED 1
> >> +#define TMS570_IRQ_RESERVED_0 1
> >>  #define TMS570_IRQ_TIMER_0 2
> >>  #define TMS570_IRQ_TIMER_1 3
> >>  #define TMS570_IRQ_TIMER_2 4
> >> @@ -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 

Re: OS Neutrality in Python Development Guidelines?

[Sebastian Huber]

On 19/04/2021 18:48, Gedare Bloom wrote:


A random pick of a file and a brief scan ...

https://git.rtems.org/rtems-central/tree/rtemsspec/interface.py#n313

There is no issue in this line.


I believe some can configure their git to inject \n\r on clone/pull
and fixes it up on commit. I have to do this for example to use
Windows source files in some projects where the IDE is only available
there.


This code generates C source files for RTEMS. These files should have 
Unix line endings.


There are probably Git users on Windows which enable the LF to CRLF 
conversion. There are probably also Git users on Windows which don't 
enable this feature.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

[PATCH rtems-docs] legacy-networking: Add note with build instructions for rtems-net-legacy

[Vijay Kumar Banerjee]

---
 legacy-networking/index.rst   |  1 +
 legacy-networking/quick_start.rst | 29 +
 2 files changed, 30 insertions(+)
 create mode 100644 legacy-networking/quick_start.rst

diff --git a/legacy-networking/index.rst b/legacy-networking/index.rst
index b85119d..acbfd35 100644
--- a/legacy-networking/index.rst
+++ b/legacy-networking/index.rst
@@ -22,6 +22,7 @@ RTEMS Legacy Network User Manual (|version|).
:numbered:
 
preface
+   quick_start
network_task_structure
networking_driver
using_networking_rtems_app
diff --git a/legacy-networking/quick_start.rst 
b/legacy-networking/quick_start.rst
new file mode 100644
index 000..97ea71c
--- /dev/null
+++ b/legacy-networking/quick_start.rst
@@ -0,0 +1,29 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+Quick Start
+###
+
+This legacy networking is now a standalone repository and needs to be built
+separately.
+
+The repository can be found here: https://git.rtems.org/rtems-net-legacy/
+
+The RSB build recipe for legacy networking is:
+
+  .. code-block:: shell
+
+../source-builder/sb-set-builder \
+--prefix=/path/to/rtems/prefix \
+6/rtems-net-legacy \
+--host=powerpc-rtems6 \
+--with-rtems-bsp=beatnik
+
+Manually building the rtems-net-legacy repo:
+
+  .. code-block:: shell
+
+git submodule init
+git submodule update
+./waf configure --prefix=/path/to/rtems/prefix
+./waf
+./waf install
-- 
2.26.2

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

[PATCH] score: Remove unused _Thread_queue_Dequeue()

[Sebastian Huber]

---
 cpukit/include/rtems/score/threadqimpl.h | 51 
 cpukit/score/src/threadqenqueue.c| 32 ---
 2 files changed, 83 deletions(-)

diff --git a/cpukit/include/rtems/score/threadqimpl.h 
b/cpukit/include/rtems/score/threadqimpl.h
index 88aba49a68..ca59de9e31 100644
--- a/cpukit/include/rtems/score/threadqimpl.h
+++ b/cpukit/include/rtems/score/threadqimpl.h
@@ -793,57 +793,6 @@ RTEMS_INLINE_ROUTINE void _Thread_queue_Release(
 }
 #endif
 
-/**
- * @brief Dequeues the first thread waiting on the thread queue and returns it.
- *
- * @param the_thread_queue The thread queue for the operation.
- * @param operations The thread queue operations.
- *
- * @return The first locked thread.
- */
-Thread_Control *_Thread_queue_Do_dequeue(
-  Thread_queue_Control  *the_thread_queue,
-  const Thread_queue_Operations *operations
-#if defined(RTEMS_MULTIPROCESSING)
-  ,
-  Thread_queue_MP_calloutmp_callout
-#endif
-);
-
-/**
- *  @brief Gets a pointer to a thread waiting on the_thread_queue.
- *
- *  This function returns a pointer to a thread waiting on
- *  the_thread_queue.  The selection of this thread is based on
- *  the discipline of the_thread_queue.  If no threads are waiting
- *  on the_thread_queue, then NULL is returned.
- *
- *  - INTERRUPT LATENCY:
- *+ single case
- */
-#if defined(RTEMS_MULTIPROCESSING)
-  #define _Thread_queue_Dequeue( \
-the_thread_queue, \
-operations, \
-mp_callout \
-  ) \
-_Thread_queue_Do_dequeue( \
-  the_thread_queue, \
-  operations, \
-  mp_callout \
-)
-#else
-  #define _Thread_queue_Dequeue( \
-the_thread_queue, \
-operations, \
-mp_callout \
-  ) \
-_Thread_queue_Do_dequeue( \
-  the_thread_queue, \
-  operations \
-)
-#endif
-
 /**
  * @brief Blocks the thread and places it on the thread queue.
  *
diff --git a/cpukit/score/src/threadqenqueue.c 
b/cpukit/score/src/threadqenqueue.c
index ba31b13dd1..5e228b7190 100644
--- a/cpukit/score/src/threadqenqueue.c
+++ b/cpukit/score/src/threadqenqueue.c
@@ -746,38 +746,6 @@ void _Thread_queue_Surrender_sticky(
 }
 #endif
 
-Thread_Control *_Thread_queue_Do_dequeue(
-  Thread_queue_Control  *the_thread_queue,
-  const Thread_queue_Operations *operations
-#if defined(RTEMS_MULTIPROCESSING)
-  ,
-  Thread_queue_MP_calloutmp_callout
-#endif
-)
-{
-  Thread_queue_Context  queue_context;
-  Thread_Control   *the_thread;
-
-  _Thread_queue_Context_initialize( _context );
-  _Thread_queue_Context_set_MP_callout( _context, mp_callout );
-  _Thread_queue_Acquire( the_thread_queue, _context );
-
-  the_thread = _Thread_queue_First_locked( the_thread_queue, operations );
-
-  if ( the_thread != NULL ) {
-_Thread_queue_Extract_critical(
-  _thread_queue->Queue,
-  operations,
-  the_thread,
-  _context
-);
-  } else {
-_Thread_queue_Release( the_thread_queue, _context );
-  }
-
-  return the_thread;
-}
-
 #if defined(RTEMS_MULTIPROCESSING)
 void _Thread_queue_Unblock_proxy(
   Thread_queue_Queue *queue,
-- 
2.26.2

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

Re: [PATCH libBSD] iicbus/rtems-i2c.c: Add rtems, path as an additional bus path

[Niteesh G. S.]

Hello Christian,

On Mon, Apr 19, 2021 at 10:18 PM Christian Mauderer 
wrote:

> Hello Niteesh,
>
> On 19/04/2021 18:45, Niteesh G. S. wrote:
> >
> >
> > On Mon, Apr 19, 2021 at 9:55 PM Gedare Bloom  > > wrote:
> >
> > On Sun, Apr 18, 2021 at 9:12 AM G S Niteesh Babu
> > mailto:niteesh...@gmail.com>> wrote:
> >  >
> >  > Adds "rtems,path" as an additional bus path for the i2c driver.
> >  > Previously the bus path was provided in "rtems,i2c-path" property
> >  > only.
> >  > ---
> >  >  rtemsbsd/sys/dev/iicbus/rtems-i2c.c | 9 ++---
> >  >  1 file changed, 6 insertions(+), 3 deletions(-)
> >  >
> >  > diff --git a/rtemsbsd/sys/dev/iicbus/rtems-i2c.c
> > b/rtemsbsd/sys/dev/iicbus/rtems-i2c.c
> >  > index b965f248..7ac7a7c4 100644
> >  > --- a/rtemsbsd/sys/dev/iicbus/rtems-i2c.c
> >  > +++ b/rtemsbsd/sys/dev/iicbus/rtems-i2c.c
> >  > @@ -87,9 +87,12 @@ rtems_i2c_attach(device_t dev)
> >  >
> >  > len = OF_getprop_alloc(node, "rtems,i2c-path", >path);
> >  > if (len == -1){
> >  > -   device_printf(sc->dev, "Path not found in Device
> > Tree");
> >  > -   OF_prop_free(sc->path);
> >  > -   return (ENXIO);
> >  > +   len = OF_getprop_alloc(node, "rtems,path",
> > >path);
> >  > +   if (len == -1) {
> >  > +   device_printf(sc->dev, "Path not found in
> > Device Tree");
> >  > +   OF_prop_free(sc->path);
> > If OF_get_prop_alloc failed, is sc->path valid here? Or do you
> > free(NULL) maybe.
> >
> > OF_getprop_alloc doesn't allocate a buffer on missing properties and 0
> > length
> > properties. In other cases, if it internally fails(in OF_getprop) it
> > frees the buffer and
> > then returns.
> > In this case, if no path property exists we just free a null buffer.
> >
>
> So if I understand you correctly, we either get a valid pointer with len
> != -1 or we get NULL? Sounds like the OF_prop_free(...) wasn't necessary
> before your change and isn't necessary now. So you might remove it.
>
I have removed it and have sent a v2.

The updated list of patches pending.
1) https://lists.rtems.org/pipermail/devel/2021-April/066458.html
2) https://lists.rtems.org/pipermail/devel/2021-April/066460.html
3) https://lists.rtems.org/pipermail/devel/2021-April/00.html


Thanks,
Niteesh.

> Best regards
>
> Christian
>
> >
> >  > +   return (ENXIO);
> >  > +   }
> >  > }
> >  >
> >  > if ((sc->sc_iicbus = device_add_child(sc->dev, "iicbus",
> > -1)) == NULL) {
> >  > --
> >  > 2.17.1
> >  >
> >  > ___
> >  > devel mailing list
> >  > devel@rtems.org 
> >  > http://lists.rtems.org/mailman/listinfo/devel
> > 
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH libBSD v2] iicbus/rtems-i2c.c: Add rtems, path as an additional bus path

[G S Niteesh Babu]

Adds "rtems,path" as an additional bus path for the i2c driver.
Previously the bus path was provided in "rtems,i2c-path" property
only.
---
 rtemsbsd/sys/dev/iicbus/rtems-i2c.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/rtemsbsd/sys/dev/iicbus/rtems-i2c.c 
b/rtemsbsd/sys/dev/iicbus/rtems-i2c.c
index b965f248..0fb14d1a 100644
--- a/rtemsbsd/sys/dev/iicbus/rtems-i2c.c
+++ b/rtemsbsd/sys/dev/iicbus/rtems-i2c.c
@@ -87,9 +87,11 @@ rtems_i2c_attach(device_t dev)
 
len = OF_getprop_alloc(node, "rtems,i2c-path", >path);
if (len == -1){
-   device_printf(sc->dev, "Path not found in Device Tree");
-   OF_prop_free(sc->path);
-   return (ENXIO);
+   len = OF_getprop_alloc(node, "rtems,path", >path);
+   if (len == -1) {
+   device_printf(sc->dev, "Path not found in Device Tree");
+   return (ENXIO);
+   }
}
 
if ((sc->sc_iicbus = device_add_child(sc->dev, "iicbus", -1)) == NULL) {
-- 
2.17.1

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

Re: [PATCH] updated HAL_GetTick function

[Sebastian Huber]

On 19/04/2021 18:42, Gedare Bloom wrote:


On Mon, Apr 19, 2021 at 10:41 AM Gedare Bloom  wrote:

On Mon, Apr 19, 2021 at 2:51 AM Robin Müller  wrote:

 From 88ac5780f5597a8bb3bf68c6b37fe6694956faaf Mon Sep 17 00:00:00 2001
From: Robin Mueller
Date: Mon, 19 Apr 2021 10:39:55 +0200
Subject: [PATCH] updated HAL_GetTick function

Patch text went missing, here is the full version of the patch.
Provides implementation for HAL_GetTick but uses RTEMS.
Accounts for the tick base not being 1ms now
---
  bsps/arm/stm32h7/start/bspstart.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bsps/arm/stm32h7/start/bspstart.c 
b/bsps/arm/stm32h7/start/bspstart.c
index 2fc8133cca..e6e995a50c 100644
--- a/bsps/arm/stm32h7/start/bspstart.c
+++ b/bsps/arm/stm32h7/start/bspstart.c
@@ -32,9 +32,10 @@

  #include 

+/* Get number of milliseconds elapsed since startup */
  uint32_t HAL_GetTick(void)
  {
-  return 0;
+  return (rtems_clock_get_ticks_since_boot() * 1000) / 
rtems_clock_get_ticks_per_second();

This is reasonable, but note that:
1. usually it is better to divide before multiplying, to reduce the
chance of arithmetic overflows.
2. the ticks_since_boot is 32-bits, with 1000 Hz ticking it overflows
in ~2 months

I suggest you consider
   return rtems_clock_get_uptime_seconds()*1000;

Or you can use rtems_clock_get_uptime_nanoseconds() / (1000) if ms
precision is needed.


I just saw that the HAL function also returns a u32, so it will
overflow anyway and it doesn't really matter what you do.

The HAL_GetTick() should still be correct, otherwise you have an 
infrequent bug which may or may not trouble you seriously. Maybe just do 
the computation with 64-bit floating point numbers or just 
rtems_clock_get_uptime_nanoseconds() / 1000.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

Re: [PATCH rtems-net-legacy v2] bsp_drivers: Use os.path for compatibility with non Unix host

[Vijay Kumar Banerjee]

On Mon, Apr 19, 2021 at 11:30 AM Vijay Kumar Banerjee  wrote:
>
> ---
>  bsp_drivers.py | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/bsp_drivers.py b/bsp_drivers.py
> index 3ca10c6..ec25c23 100644
> --- a/bsp_drivers.py
> +++ b/bsp_drivers.py
> @@ -36,18 +36,18 @@ def bsp_files(bld):
>  include_dirs = {}
>  include_files = []
>
> -special_case_dirs = {'atsamv': './bsps/arm/atsam',
> - 'lm32_evr': './bsps/lm32',
> - 'lpc24xx_ea': './bsps/arm/shared/'}
> +special_case_dirs = {'atsamv': os.path.expanduser('bsps/arm/atsam'),
> + 'lm32_evr': os.path.expanduser('bsps/lm32'),
> + 'lpc24xx_ea': 
> os.path.expanduser('bsps/arm/shared/')}
>  special_case_sources = {'leon2':
> -
> ['./bsps/shared/grlib/net/network_interface_add.c',
> - './bsps/shared/grlib/net/greth.c'],
> +
> [os.path.expanduser('bsps/shared/grlib/net/network_interface_add.c'),

I would like to add that these lines are over 80 characters limit.

> + 
> os.path.expanduser('bsps/shared/grlib/net/greth.c')],
>  'leon3':
> -
> ['./bsps/shared/grlib/net/network_interface_add.c',
> - './bsps/shared/grlib/net/greth.c'],
> +
> [os.path.expanduser('bsps/shared/grlib/net/network_interface_add.c'),
> + 
> os.path.expanduser('bsps/shared/grlib/net/greth.c')],
>  'griscv':
> -
> ['./bsps/shared/grlib/net/network_interface_add.c',
> - './bsps/shared/grlib/net/greth.c']}
> +
> [os.path.expanduser('bsps/shared/grlib/net/network_interface_add.c'),
> + 
> os.path.expanduser('bsps/shared/grlib/net/greth.c')]}
>
>  bsp_list = bld.env.RTEMS_ARCH_BSP_LIST
>
> @@ -57,7 +57,7 @@ def bsp_files(bld):
>  include_dirs[bsp] = []
>  source_files[bsp] = []
>  if bsp not in special_case_dirs:
> -source_dir = os.walk(os.path.join('./bsps', arch, bsp))
> +source_dir = os.walk(os.path.join('bsps', arch, bsp))
>  else:
>  source_dir = os.walk(special_case_dirs[bsp])
>  for root, dirs, files in source_dir:
> @@ -70,5 +70,5 @@ def bsp_files(bld):
>  include_dirs[bsp].append(root)
>  if bsp in special_case_sources:
>  source_files[bsp].extend(special_case_sources[bsp])
> -include_dirs[bsp].append(os.path.join('./bsps', arch, bsp, 'net'))
> +include_dirs[bsp].append(os.path.join('bsps', arch, bsp, 'net'))
>  return (include_dirs, source_files)
> --
> 2.26.2
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-net-legacy v2] bsp_drivers: Use os.path for compatibility with non Unix host

[Vijay Kumar Banerjee]

---
 bsp_drivers.py | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/bsp_drivers.py b/bsp_drivers.py
index 3ca10c6..ec25c23 100644
--- a/bsp_drivers.py
+++ b/bsp_drivers.py
@@ -36,18 +36,18 @@ def bsp_files(bld):
 include_dirs = {}
 include_files = []
 
-special_case_dirs = {'atsamv': './bsps/arm/atsam',
- 'lm32_evr': './bsps/lm32',
- 'lpc24xx_ea': './bsps/arm/shared/'}
+special_case_dirs = {'atsamv': os.path.expanduser('bsps/arm/atsam'),
+ 'lm32_evr': os.path.expanduser('bsps/lm32'),
+ 'lpc24xx_ea': os.path.expanduser('bsps/arm/shared/')}
 special_case_sources = {'leon2':
-['./bsps/shared/grlib/net/network_interface_add.c',
- './bsps/shared/grlib/net/greth.c'],
+
[os.path.expanduser('bsps/shared/grlib/net/network_interface_add.c'),
+ 
os.path.expanduser('bsps/shared/grlib/net/greth.c')],
 'leon3':
-['./bsps/shared/grlib/net/network_interface_add.c',
- './bsps/shared/grlib/net/greth.c'],
+
[os.path.expanduser('bsps/shared/grlib/net/network_interface_add.c'),
+ 
os.path.expanduser('bsps/shared/grlib/net/greth.c')],
 'griscv':
-['./bsps/shared/grlib/net/network_interface_add.c',
- './bsps/shared/grlib/net/greth.c']}
+
[os.path.expanduser('bsps/shared/grlib/net/network_interface_add.c'),
+ 
os.path.expanduser('bsps/shared/grlib/net/greth.c')]}
 
 bsp_list = bld.env.RTEMS_ARCH_BSP_LIST
 
@@ -57,7 +57,7 @@ def bsp_files(bld):
 include_dirs[bsp] = []
 source_files[bsp] = []
 if bsp not in special_case_dirs:
-source_dir = os.walk(os.path.join('./bsps', arch, bsp))
+source_dir = os.walk(os.path.join('bsps', arch, bsp))
 else:
 source_dir = os.walk(special_case_dirs[bsp])
 for root, dirs, files in source_dir:
@@ -70,5 +70,5 @@ def bsp_files(bld):
 include_dirs[bsp].append(root)
 if bsp in special_case_sources:
 source_files[bsp].extend(special_case_sources[bsp])
-include_dirs[bsp].append(os.path.join('./bsps', arch, bsp, 'net'))
+include_dirs[bsp].append(os.path.join('bsps', arch, bsp, 'net'))
 return (include_dirs, source_files)
-- 
2.26.2

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

Re: [PATCH] Fixes for TMS570 BSP

[Gedare Bloom]

Hi Robin, Pavel:

On Mon, Apr 19, 2021 at 2:57 AM Robin Müller  wrote:
>
> If this was intentional, I can also adapt the lwIP port sources to use 
> ti/herc. I was not sure about that.
>
I think Pavel should comment. I believe at the time care was taken to
avoid importing TI HalCoGen code generation, and maybe this missing
ti_herc is an artifact from that. I think over time TI has moved
toward providing a slightly better license (2-clause BSD with hardware
restriction) on their HAL/SOC libs. We won't merge code with the
hardware restriction clause. So it can be a little problematic to get
things working nicely, it has to be well documented the steps to
reproduce setups based on restrictive vendor-provided code.

That's what I remember anyway. Pavel may explain better.
Gedare

> Kind Regards
> Robin
>
> On Mon, 19 Apr 2021 at 10:55, Robin Mueller  wrote:
>>
>> When compiling the lwIP port for the TMS570, there
>> were issues with the BSP. Headers are expected in a folder
>> named ti_herc which did not exist. This fixes the issue.
>>
>> Furthermore, there were multiple warnings about define redefinitions.
>> This was fixed as well.
>> ---
>>  bsps/arm/tms570/include/bsp/irq.h  | 6 +++---
>>  spec/build/bsps/arm/tms570/obj.yml | 2 +-
>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/bsps/arm/tms570/include/bsp/irq.h 
>> b/bsps/arm/tms570/include/bsp/irq.h
>> index c37ebadbc4..0b6ea1e6fd 100644
>> --- a/bsps/arm/tms570/include/bsp/irq.h
>> +++ b/bsps/arm/tms570/include/bsp/irq.h
>> @@ -34,7 +34,7 @@
>>
>>  #define BSP_INTERRUPT_VECTOR_MIN 0U
>>  #define TMS570_IRQ_ESM_HIGH 0
>> -#define TMS570_IRQ_RESERVED 1
>> +#define TMS570_IRQ_RESERVED_0 1
>>  #define TMS570_IRQ_TIMER_0 2
>>  #define TMS570_IRQ_TIMER_1 3
>>  #define TMS570_IRQ_TIMER_2 4
>> @@ -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
>>
> ___
> 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: OS Neutrality in Python Development Guidelines?

[Gedare Bloom]

On Sun, Apr 18, 2021 at 5:20 PM Joel Sherrill  wrote:
>
>
>
> On Sun, Apr 18, 2021, 5:29 PM Chris Johns  wrote:
>>
>> On 16/4/21 3:28 pm, Sebastian Huber wrote:
>> > On 15/04/2021 22:58, Gedare Bloom wrote:
>> >> I guess we should define something to add here? Is anything written
>> >> somewhere we can adopt?
>> > the spirit of the Python guide is to have rules which are enforced by 
>> > tools.
>>
>> I see a guide as a means to provide robust and portable code in a common 
>> style
>> where we document and learn from our experiences. Any forced line like 
>> needing a
>> tool would create an artificial barrier where needed rules are not added 
>> because
>> we do not have a tool. I doubt any of us would want that to happen.
>>
>> > If
>> > a certain component should run on platform X, then I think some CI system 
>> > should
>> > be in place which runs the test suite on platform X.
>>
>> This is hard to do, costs money and is only as good as a tests. It is 
>> important
>> but we should also use reviews as a way to catch issues.
>
>
> Does the PEP cover this? If so, then some tool should exist to help. 
> Otherwise, we need some heuristics to at least flag an inspection.
>
> I had a shell script years ago to check BSPs for some basic rules and fixed a 
> lot.  It was about the time we tried to be more standardized on file names in 
> BSPs and some methods would always be in a file of a particular name. Not the 
> brightest and hardest rules but the script could flag what needs to be 
> inspected.
>>
>>
>> >> Was this considered at all under the pre-qual effort (which stimulated
>> >> these guidelines in the first place)? Do we have a Windows blind spot
>> >> in our Python code bases?
>> > The Python modules in rtems-central should run on Windows, however, I never
>> > tested this.
>>
>> A random pick of a file and a brief scan ...
>>
>> https://git.rtems.org/rtems-central/tree/rtemsspec/interface.py#n313
>>
>> For generating code it is important to make sure you use the platform's line
>> separator or git will get upset.
>
>
> Ok. And a grep would find these. Is this part of PEP?
>
> Are there files which should never have \n? All? Some?
>
> Is there other things that can be enforced now or we build some script which 
> has a number of rules which we grow.
>

A quick look did not show any advice on writing code that works cross-platform.

The biggest issues are paths and CaseSensitive filesystems. I'm sure
there are other hidden brambles though.

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

Re: [PATCH libBSD] iicbus/rtems-i2c.c: Add rtems, path as an additional bus path

[Christian Mauderer]

Hello Niteesh,

On 19/04/2021 18:45, Niteesh G. S. wrote:



On Mon, Apr 19, 2021 at 9:55 PM Gedare Bloom > wrote:


On Sun, Apr 18, 2021 at 9:12 AM G S Niteesh Babu
mailto:niteesh...@gmail.com>> wrote:
 >
 > Adds "rtems,path" as an additional bus path for the i2c driver.
 > Previously the bus path was provided in "rtems,i2c-path" property
 > only.
 > ---
 >  rtemsbsd/sys/dev/iicbus/rtems-i2c.c | 9 ++---
 >  1 file changed, 6 insertions(+), 3 deletions(-)
 >
 > diff --git a/rtemsbsd/sys/dev/iicbus/rtems-i2c.c
b/rtemsbsd/sys/dev/iicbus/rtems-i2c.c
 > index b965f248..7ac7a7c4 100644
 > --- a/rtemsbsd/sys/dev/iicbus/rtems-i2c.c
 > +++ b/rtemsbsd/sys/dev/iicbus/rtems-i2c.c
 > @@ -87,9 +87,12 @@ rtems_i2c_attach(device_t dev)
 >
 >         len = OF_getprop_alloc(node, "rtems,i2c-path", >path);
 >         if (len == -1){
 > -               device_printf(sc->dev, "Path not found in Device
Tree");
 > -               OF_prop_free(sc->path);
 > -               return (ENXIO);
 > +               len = OF_getprop_alloc(node, "rtems,path",
>path);
 > +               if (len == -1) {
 > +                       device_printf(sc->dev, "Path not found in
Device Tree");
 > +                       OF_prop_free(sc->path);
If OF_get_prop_alloc failed, is sc->path valid here? Or do you
free(NULL) maybe.

OF_getprop_alloc doesn't allocate a buffer on missing properties and 0 
length
properties. In other cases, if it internally fails(in OF_getprop) it 
frees the buffer and

then returns.
In this case, if no path property exists we just free a null buffer.



So if I understand you correctly, we either get a valid pointer with len 
!= -1 or we get NULL? Sounds like the OF_prop_free(...) wasn't necessary 
before your change and isn't necessary now. So you might remove it.


Best regards

Christian



 > +                       return (ENXIO);
 > +               }
 >         }
 >
 >         if ((sc->sc_iicbus = device_add_child(sc->dev, "iicbus",
-1)) == NULL) {
 > --
 > 2.17.1
 >
 > ___
 > devel mailing list
 > devel@rtems.org 
 > http://lists.rtems.org/mailman/listinfo/devel



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


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

Re: OS Neutrality in Python Development Guidelines?

[Gedare Bloom]

On Mon, Apr 19, 2021 at 9:36 AM Sebastian Huber
 wrote:
>
> On 19/04/2021 00:29, Chris Johns wrote:
>
> > On 16/4/21 3:28 pm, Sebastian Huber wrote:
> >> On 15/04/2021 22:58, Gedare Bloom wrote:
> >>> I guess we should define something to add here? Is anything written
> >>> somewhere we can adopt?
> >> the spirit of the Python guide is to have rules which are enforced by 
> >> tools.
> > I see a guide as a means to provide robust and portable code in a common 
> > style
> > where we document and learn from our experiences.
> I am not against a couple of best practice rules.
> > Any forced line like needing a
> > tool would create an artificial barrier where needed rules are not added 
> > because
> > we do not have a tool. I doubt any of us would want that to happen.
> >
> >> If
> >> a certain component should run on platform X, then I think some CI system 
> >> should
> >> be in place which runs the test suite on platform X.
> > This is hard to do, costs money and is only as good as a tests. It is 
> > important
> > but we should also use reviews as a way to catch issues.
> In github for example, you have test runners available for Linux,
> Windows and macOS. Testing is never perfect, but no tests at all is
> really not that great.
> >
> >>> Was this considered at all under the pre-qual effort (which stimulated
> >>> these guidelines in the first place)? Do we have a Windows blind spot
> >>> in our Python code bases?
> >> The Python modules in rtems-central should run on Windows, however, I never
> >> tested this.
> > A random pick of a file and a brief scan ...
> >
> > https://git.rtems.org/rtems-central/tree/rtemsspec/interface.py#n313
>
> There is no issue in this line.
>

I believe some can configure their git to inject \n\r on clone/pull
and fixes it up on commit. I have to do this for example to use
Windows source files in some projects where the IDE is only available
there.

> We probably have to use newline="\n" for the open() calls which write
> files. However, getting this to work on Window is currently not on my
> high priority list.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH libBSD] iicbus/rtems-i2c.c: Add rtems, path as an additional bus path

[Niteesh G. S.]

On Mon, Apr 19, 2021 at 9:55 PM Gedare Bloom  wrote:

> On Sun, Apr 18, 2021 at 9:12 AM G S Niteesh Babu 
> wrote:
> >
> > Adds "rtems,path" as an additional bus path for the i2c driver.
> > Previously the bus path was provided in "rtems,i2c-path" property
> > only.
> > ---
> >  rtemsbsd/sys/dev/iicbus/rtems-i2c.c | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/rtemsbsd/sys/dev/iicbus/rtems-i2c.c
> b/rtemsbsd/sys/dev/iicbus/rtems-i2c.c
> > index b965f248..7ac7a7c4 100644
> > --- a/rtemsbsd/sys/dev/iicbus/rtems-i2c.c
> > +++ b/rtemsbsd/sys/dev/iicbus/rtems-i2c.c
> > @@ -87,9 +87,12 @@ rtems_i2c_attach(device_t dev)
> >
> > len = OF_getprop_alloc(node, "rtems,i2c-path", >path);
> > if (len == -1){
> > -   device_printf(sc->dev, "Path not found in Device Tree");
> > -   OF_prop_free(sc->path);
> > -   return (ENXIO);
> > +   len = OF_getprop_alloc(node, "rtems,path", >path);
> > +   if (len == -1) {
> > +   device_printf(sc->dev, "Path not found in Device
> Tree");
> > +   OF_prop_free(sc->path);
> If OF_get_prop_alloc failed, is sc->path valid here? Or do you free(NULL)
> maybe.
>
OF_getprop_alloc doesn't allocate a buffer on missing properties and 0
length
properties. In other cases, if it internally fails(in OF_getprop) it frees
the buffer and
then returns.
In this case, if no path property exists we just free a null buffer.

>
> > +   return (ENXIO);
> > +   }
> > }
> >
> > if ((sc->sc_iicbus = device_add_child(sc->dev, "iicbus", -1)) ==
> NULL) {
> > --
> > 2.17.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] clock:_TOD_To_seconds(): Fix year 2514 overflow

[Gedare Bloom]

It is reasonable. Let's capture the analysis. I thought there was a
place we had notes related to different time source overflows, but I
can't find it quickly

On Mon, Apr 19, 2021 at 9:44 AM Sebastian Huber
 wrote:
>
> On 13/04/2021 18:03, Sebastian Huber wrote:
>
> > Hello,
> >
> > On 08/04/2021 15:41, Frank Kuehndel wrote:
> >> +/**
> >> + *  @brief Latest year to which a time of day can be initialized.
> >> + *
> >> + *  The following constant defines the latest year to which an
> >> + *  RTEMS time of day can be set using rtems_clock_set().
> >> + *
> >> + *  32 bits can accept as latest point in time 2106-Feb-7 6:28:15
> >> + *  but to simplify the implementation, is was decided to only
> >> + *  check that the year is not greater than the year of this constant.
> >> + *
> >> + *  The internal realtime clock can run centuries longer but in
> >> + *  contrast to the POSIX API, the RTEMS Classic API does not
> >> + *  support this for efficiency reasons.
> >> + */
> >> +#define TOD_LATEST_YEAR 2105
> >
> > any objections to use this approach? If we want to support years after
> > 2105 in the Classic API, then we would need 64-bit values and
> > calculations in several places. I think an RTEMS system which operates
> > after 2105 is currently a bit unrealistic.
> >
> > If we limit the time frame to the year 2100 we could simplify
> > _TOD_Validate() a bit more since all years % 4 == 0 are leap years in
> > the range 1988 to 2100 (exclusive).
> If there are no objections, then I will check this in on Wednesday and
> send a documentation update.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] updated HAL_GetTick function

[Gedare Bloom]

On Mon, Apr 19, 2021 at 10:41 AM Gedare Bloom  wrote:
>
> On Mon, Apr 19, 2021 at 2:51 AM Robin Müller  
> wrote:
> >
> > From 88ac5780f5597a8bb3bf68c6b37fe6694956faaf Mon Sep 17 00:00:00 2001
> > From: Robin Mueller 
> > Date: Mon, 19 Apr 2021 10:39:55 +0200
> > Subject: [PATCH] updated HAL_GetTick function
> >
> > Patch text went missing, here is the full version of the patch.
> > Provides implementation for HAL_GetTick but uses RTEMS.
> > Accounts for the tick base not being 1ms now
> > ---
> >  bsps/arm/stm32h7/start/bspstart.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/bsps/arm/stm32h7/start/bspstart.c 
> > b/bsps/arm/stm32h7/start/bspstart.c
> > index 2fc8133cca..e6e995a50c 100644
> > --- a/bsps/arm/stm32h7/start/bspstart.c
> > +++ b/bsps/arm/stm32h7/start/bspstart.c
> > @@ -32,9 +32,10 @@
> >
> >  #include 
> >
> > +/* Get number of milliseconds elapsed since startup */
> >  uint32_t HAL_GetTick(void)
> >  {
> > -  return 0;
> > +  return (rtems_clock_get_ticks_since_boot() * 1000) / 
> > rtems_clock_get_ticks_per_second();
>
> This is reasonable, but note that:
> 1. usually it is better to divide before multiplying, to reduce the
> chance of arithmetic overflows.
> 2. the ticks_since_boot is 32-bits, with 1000 Hz ticking it overflows
> in ~2 months
>
> I suggest you consider
>   return rtems_clock_get_uptime_seconds()*1000;
>
> Or you can use rtems_clock_get_uptime_nanoseconds() / (1000) if ms
> precision is needed.
>

I just saw that the HAL function also returns a u32, so it will
overflow anyway and it doesn't really matter what you do.

> >  }
> >
> >  uint32_t stm32h7_systick_frequency(void)
> > --
> > 2.29.2.windows.2
> >
> > On Mon, 19 Apr 2021 at 10:48, Robin Mueller  
> > wrote:
> >>
> >> diff --git a/bsps/arm/stm32h7/start/bspstart.c 
> >> b/bsps/arm/stm32h7/start/bspstart.c
> >> index 2fc8133cca..e6e995a50c 100644
> >> --- a/bsps/arm/stm32h7/start/bspstart.c
> >> +++ b/bsps/arm/stm32h7/start/bspstart.c
> >> @@ -32,9 +32,10 @@
> >>
> >>  #include 
> >>
> >> +/* Get number of milliseconds elapsed since startup */
> >>  uint32_t HAL_GetTick(void)
> >>  {
> >> -  return 0;
> >> +  return (rtems_clock_get_ticks_since_boot() * 1000) / 
> >> rtems_clock_get_ticks_per_second();
> >>  }
> >>
> >>  uint32_t stm32h7_systick_frequency(void)
> >> --
> >> 2.29.2.windows.2
> >>
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] updated HAL_GetTick function

[Gedare Bloom]

On Mon, Apr 19, 2021 at 2:51 AM Robin Müller  wrote:
>
> From 88ac5780f5597a8bb3bf68c6b37fe6694956faaf Mon Sep 17 00:00:00 2001
> From: Robin Mueller 
> Date: Mon, 19 Apr 2021 10:39:55 +0200
> Subject: [PATCH] updated HAL_GetTick function
>
> Patch text went missing, here is the full version of the patch.
> Provides implementation for HAL_GetTick but uses RTEMS.
> Accounts for the tick base not being 1ms now
> ---
>  bsps/arm/stm32h7/start/bspstart.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/bsps/arm/stm32h7/start/bspstart.c 
> b/bsps/arm/stm32h7/start/bspstart.c
> index 2fc8133cca..e6e995a50c 100644
> --- a/bsps/arm/stm32h7/start/bspstart.c
> +++ b/bsps/arm/stm32h7/start/bspstart.c
> @@ -32,9 +32,10 @@
>
>  #include 
>
> +/* Get number of milliseconds elapsed since startup */
>  uint32_t HAL_GetTick(void)
>  {
> -  return 0;
> +  return (rtems_clock_get_ticks_since_boot() * 1000) / 
> rtems_clock_get_ticks_per_second();

This is reasonable, but note that:
1. usually it is better to divide before multiplying, to reduce the
chance of arithmetic overflows.
2. the ticks_since_boot is 32-bits, with 1000 Hz ticking it overflows
in ~2 months

I suggest you consider
  return rtems_clock_get_uptime_seconds()*1000;

Or you can use rtems_clock_get_uptime_nanoseconds() / (1000) if ms
precision is needed.

>  }
>
>  uint32_t stm32h7_systick_frequency(void)
> --
> 2.29.2.windows.2
>
> On Mon, 19 Apr 2021 at 10:48, Robin Mueller  wrote:
>>
>> diff --git a/bsps/arm/stm32h7/start/bspstart.c 
>> b/bsps/arm/stm32h7/start/bspstart.c
>> index 2fc8133cca..e6e995a50c 100644
>> --- a/bsps/arm/stm32h7/start/bspstart.c
>> +++ b/bsps/arm/stm32h7/start/bspstart.c
>> @@ -32,9 +32,10 @@
>>
>>  #include 
>>
>> +/* Get number of milliseconds elapsed since startup */
>>  uint32_t HAL_GetTick(void)
>>  {
>> -  return 0;
>> +  return (rtems_clock_get_ticks_since_boot() * 1000) / 
>> rtems_clock_get_ticks_per_second();
>>  }
>>
>>  uint32_t stm32h7_systick_frequency(void)
>> --
>> 2.29.2.windows.2
>>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH libBSD] iicbus/rtems-i2c.c: Add rtems, path as an additional bus path

[Gedare Bloom]

On Sun, Apr 18, 2021 at 9:12 AM G S Niteesh Babu  wrote:
>
> Adds "rtems,path" as an additional bus path for the i2c driver.
> Previously the bus path was provided in "rtems,i2c-path" property
> only.
> ---
>  rtemsbsd/sys/dev/iicbus/rtems-i2c.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/rtemsbsd/sys/dev/iicbus/rtems-i2c.c 
> b/rtemsbsd/sys/dev/iicbus/rtems-i2c.c
> index b965f248..7ac7a7c4 100644
> --- a/rtemsbsd/sys/dev/iicbus/rtems-i2c.c
> +++ b/rtemsbsd/sys/dev/iicbus/rtems-i2c.c
> @@ -87,9 +87,12 @@ rtems_i2c_attach(device_t dev)
>
> len = OF_getprop_alloc(node, "rtems,i2c-path", >path);
> if (len == -1){
> -   device_printf(sc->dev, "Path not found in Device Tree");
> -   OF_prop_free(sc->path);
> -   return (ENXIO);
> +   len = OF_getprop_alloc(node, "rtems,path", >path);
> +   if (len == -1) {
> +   device_printf(sc->dev, "Path not found in Device 
> Tree");
> +   OF_prop_free(sc->path);
If OF_get_prop_alloc failed, is sc->path valid here? Or do you free(NULL) maybe.

> +   return (ENXIO);
> +   }
> }
>
> if ((sc->sc_iicbus = device_add_child(sc->dev, "iicbus", -1)) == 
> NULL) {
> --
> 2.17.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] clock:_TOD_To_seconds(): Fix year 2514 overflow

[Sebastian Huber]

On 13/04/2021 18:03, Sebastian Huber wrote:


Hello,

On 08/04/2021 15:41, Frank Kuehndel wrote:

+/**
+ *  @brief Latest year to which a time of day can be initialized.
+ *
+ *  The following constant defines the latest year to which an
+ *  RTEMS time of day can be set using rtems_clock_set().
+ *
+ *  32 bits can accept as latest point in time 2106-Feb-7 6:28:15
+ *  but to simplify the implementation, is was decided to only
+ *  check that the year is not greater than the year of this constant.
+ *
+ *  The internal realtime clock can run centuries longer but in
+ *  contrast to the POSIX API, the RTEMS Classic API does not
+ *  support this for efficiency reasons.
+ */
+#define TOD_LATEST_YEAR 2105


any objections to use this approach? If we want to support years after 
2105 in the Classic API, then we would need 64-bit values and 
calculations in several places. I think an RTEMS system which operates 
after 2105 is currently a bit unrealistic.


If we limit the time frame to the year 2100 we could simplify 
_TOD_Validate() a bit more since all years % 4 == 0 are leap years in 
the range 1988 to 2100 (exclusive). 
If there are no objections, then I will check this in on Wednesday and 
send a documentation update.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

Re: OS Neutrality in Python Development Guidelines?

[Sebastian Huber]

On 19/04/2021 00:29, Chris Johns wrote:


On 16/4/21 3:28 pm, Sebastian Huber wrote:

On 15/04/2021 22:58, Gedare Bloom wrote:

I guess we should define something to add here? Is anything written
somewhere we can adopt?

the spirit of the Python guide is to have rules which are enforced by tools.

I see a guide as a means to provide robust and portable code in a common style
where we document and learn from our experiences.

I am not against a couple of best practice rules.

Any forced line like needing a
tool would create an artificial barrier where needed rules are not added because
we do not have a tool. I doubt any of us would want that to happen.


If
a certain component should run on platform X, then I think some CI system should
be in place which runs the test suite on platform X.

This is hard to do, costs money and is only as good as a tests. It is important
but we should also use reviews as a way to catch issues.
In github for example, you have test runners available for Linux, 
Windows and macOS. Testing is never perfect, but no tests at all is 
really not that great.



Was this considered at all under the pre-qual effort (which stimulated
these guidelines in the first place)? Do we have a Windows blind spot
in our Python code bases?

The Python modules in rtems-central should run on Windows, however, I never
tested this.

A random pick of a file and a brief scan ...

https://git.rtems.org/rtems-central/tree/rtemsspec/interface.py#n313


There is no issue in this line.

We probably have to use newline="\n" for the open() calls which write 
files. However, getting this to work on Window is currently not on my 
high priority list.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

Re: Booting a rtems exe on Zynq UltraScale+ MPSoC ZCU106 board

[Kinsey Moore]

I'll start by saying that AArch64 RTEMS on QEMU (for which there is a 
ZynqMP hardware model) works great and is what the current BSP targets.


The current status of AArch64 RTEMS on real hardware is not as simple as 
I'd like, but it's possible and I've run the uniprocessor testsuite 
tests on an an Avnet dev board (ZU3EG). The complications are caused by 
lack of support for the MMU on AArch64 leading to all memory requiring 
strict alignment for accesses. Due to this, the toolchain needs to be 
recompiled with additional flags:


 --targetcflags="-DPREFER_SIZE_OVER_SPEED -mstrict-align" 
--targetcxxflags="-mstrict-align"


To deal with an EL2 start, optstarthyp.yml needs to be added to the BSP 
definition and -mstrict-align needs to be added to abi.yml.


Unfortunately, these changes are unfit for inclusion in RTEMS and my 
next step is to work on the MMU driver to avoid these alignment problems.



Kinsey

On 4/19/2021 00:19, Richi Dubey wrote:

Thanks!

Can I get rtems to build images as an AArch64 code, so that I don't 
have to change anything for uboot?


On Thu, Apr 15, 2021 at 12:01 AM Kinsey Moore 
mailto:kinsey.mo...@oarcorp.com>> wrote:


That exception dump doesn't say a lot other than the ELR pointing
at the very first instruction in your image, so I suspect that
u-boot is trying to start your image as AArch64 code instead of
AArch32/ARMv7 code. The ESR just specifies that it was a 32-bit
instruction that blew up (both AArch32 and AArch64 use 32-bit
instructions) instead of a 16-bit instruction.

The u-boot images that come with the PetaLinux distributions
default to starting code as AArch64 at EL2, so you either need to
figure out how to make u-boot default to AArch32/ARMv7 at EL1 or
build a new u-boot that can do what you need and then package it
into BOOT.bin using bootgen (the code is available on github).
From what I remember, the ARMv7 BSP for ZynqMP mentions booting
over JTAG.


Kinsey

On 4/14/2021 13:18, Richi Dubey wrote:

Hi Jan, Kinsey,

Thanks for your quick responses.

I rebuilt the .img file with  -O rtems option, and I think it is
the standard uboot available from PetaLinux. It still fails, but
I think it is related to RTEMS now:

Welcome to minicom 2.7.1

OPTIONS: I18n
Compiled on May  6 2018, 08:02:47.Welcome to minicom 2.7.1

OPTIONS: I18n
Compiled on May  6 2018, 08:02:47.
Port /dev/ttyUSB32, 18:14:14

Press CTRL-K Z for help on special keys

Xilinx Zynq MP First Stage Boot Loader
Release 2020.1   Jan  1 2021  -  07:33:16
NOTICE:  ATF running on XCZU7EV/silicon v4/RTL5.1 at 0xfffea000
NOTICE:  BL31: Secure code at 0x6000
NOTICE:  BL31: Non secure code at 0x1008
NOTICE:  BL31: v2.0(release):xilinx-v2019.1-12-g713dace9
NOTICE:  BL31: Built : 08:36:10, Sep  1 2020
PMUFW:  v1.1


U-Boot 2019.01 (Sep 01 2020 - 08:36:54 +)

Model: ZynqMP ZCU106 RevA
Board: Xilinx ZynqMP
DRAM:  4 GiB
EL Level:       EL2
Chip ID:        zu7ev
MMC:   mmc@ff17: 0
Loading Environment from SPI Flash... SF: Detected n25q512a with
page size 512 B
ytes, erase size 128 KiB, total 128 MiB
OK
In:    serial@ff00
Out:   serial@ff00
Err:   serial@ff00
Model: ZynqMP ZCU106 RevA
Board: Xilinx ZynqMP
Net:   ZYNQ GEM: ff0e, phyaddr c, interface rgmii-id

Warning: ethernet@ff0e MAC addresses don't match:
Address in ROM is          00:0a:35:05:2f:ec
Address in environment is  00:0a:35:00:22:19
eth0: ethernet@ff0e
Hit any key to stop autoboot:  0
ZynqMP> tftpboot 0x300 rdubey/sp01new.img
Using ethernet@ff0e device
TFTP from server 172.19.0.3; our IP address is 172.19.2.40
Filename 'rdubey/sp01new.img'.
Load address: 0x300
Loading: 
         1.7 MiB/s
done
Bytes transferred = 50978 (c722 hex)
ZynqMP> bootm  0x300  ; reset
## Booting kernel from Legacy Image at 0300 ...
   Image Name:   RTEMS
   Image Type:   ARM RTEMS Kernel Image (gzip compressed)
   Data Size:    50914 Bytes = 49.7 KiB
   Load Address: 0030
   Entry Point:  0030
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Transferring control to RTEMS (at address 0030) ...
"Synchronous Abort" handler, esr 0x0200
elr: 90593000 lr : 10097a90 (reloc)
elr: 0030 lr : 7fe04a90
x0 : 7ddacf58 x1 : 
x2 : 6802 x3 : 0020
x4 :  x5 : 0030
x6 : 7fe7e9cd x7 : 000f
x8 : 0038 x9 : 0008
x10: 7ddbd530 x11: ffd0
x12:  x13: 0200
x14: 0001 x15: 0008
x16: 

Re: [PATCH] Fixes for TMS570 BSP

[Robin Müller]

If this was intentional, I can also adapt the lwIP port sources to use
ti/herc. I was not sure about that.

Kind Regards
Robin

On Mon, 19 Apr 2021 at 10:55, Robin Mueller 
wrote:

> When compiling the lwIP port for the TMS570, there
> were issues with the BSP. Headers are expected in a folder
> named ti_herc which did not exist. This fixes the issue.
>
> Furthermore, there were multiple warnings about define redefinitions.
> This was fixed as well.
> ---
>  bsps/arm/tms570/include/bsp/irq.h  | 6 +++---
>  spec/build/bsps/arm/tms570/obj.yml | 2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/bsps/arm/tms570/include/bsp/irq.h
> b/bsps/arm/tms570/include/bsp/irq.h
> index c37ebadbc4..0b6ea1e6fd 100644
> --- a/bsps/arm/tms570/include/bsp/irq.h
> +++ b/bsps/arm/tms570/include/bsp/irq.h
> @@ -34,7 +34,7 @@
>
>  #define BSP_INTERRUPT_VECTOR_MIN 0U
>  #define TMS570_IRQ_ESM_HIGH 0
> -#define TMS570_IRQ_RESERVED 1
> +#define TMS570_IRQ_RESERVED_0 1
>  #define TMS570_IRQ_TIMER_0 2
>  #define TMS570_IRQ_TIMER_1 3
>  #define TMS570_IRQ_TIMER_2 4
> @@ -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
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Fixes for TMS570 BSP

[Robin Mueller]

When compiling the lwIP port for the TMS570, there
were issues with the BSP. Headers are expected in a folder
named ti_herc which did not exist. This fixes the issue.

Furthermore, there were multiple warnings about define redefinitions.
This was fixed as well.
---
 bsps/arm/tms570/include/bsp/irq.h  | 6 +++---
 spec/build/bsps/arm/tms570/obj.yml | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/bsps/arm/tms570/include/bsp/irq.h 
b/bsps/arm/tms570/include/bsp/irq.h
index c37ebadbc4..0b6ea1e6fd 100644
--- a/bsps/arm/tms570/include/bsp/irq.h
+++ b/bsps/arm/tms570/include/bsp/irq.h
@@ -34,7 +34,7 @@
 
 #define BSP_INTERRUPT_VECTOR_MIN 0U
 #define TMS570_IRQ_ESM_HIGH 0
-#define TMS570_IRQ_RESERVED 1
+#define TMS570_IRQ_RESERVED_0 1
 #define TMS570_IRQ_TIMER_0 2
 #define TMS570_IRQ_TIMER_1 3
 #define TMS570_IRQ_TIMER_2 4
@@ -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

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

Re: [PATCH] updated HAL_GetTick function

[Robin Müller]

>From 88ac5780f5597a8bb3bf68c6b37fe6694956faaf Mon Sep 17 00:00:00 2001
From: Robin Mueller 
Date: Mon, 19 Apr 2021 10:39:55 +0200
Subject: [PATCH] updated HAL_GetTick function

Patch text went missing, here is the full version of the patch.
Provides implementation for HAL_GetTick but uses RTEMS.
Accounts for the tick base not being 1ms now
---
 bsps/arm/stm32h7/start/bspstart.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bsps/arm/stm32h7/start/bspstart.c
b/bsps/arm/stm32h7/start/bspstart.c
index 2fc8133cca..e6e995a50c 100644
--- a/bsps/arm/stm32h7/start/bspstart.c
+++ b/bsps/arm/stm32h7/start/bspstart.c
@@ -32,9 +32,10 @@

 #include 

+/* Get number of milliseconds elapsed since startup */
 uint32_t HAL_GetTick(void)
 {
-  return 0;
+  return (rtems_clock_get_ticks_since_boot() * 1000) /
rtems_clock_get_ticks_per_second();
 }

 uint32_t stm32h7_systick_frequency(void)
-- 
2.29.2.windows.2

On Mon, 19 Apr 2021 at 10:48, Robin Mueller 
wrote:

> diff --git a/bsps/arm/stm32h7/start/bspstart.c
> b/bsps/arm/stm32h7/start/bspstart.c
> index 2fc8133cca..e6e995a50c 100644
> --- a/bsps/arm/stm32h7/start/bspstart.c
> +++ b/bsps/arm/stm32h7/start/bspstart.c
> @@ -32,9 +32,10 @@
>
>  #include 
>
> +/* Get number of milliseconds elapsed since startup */
>  uint32_t HAL_GetTick(void)
>  {
> -  return 0;
> +  return (rtems_clock_get_ticks_since_boot() * 1000) /
> rtems_clock_get_ticks_per_second();
>  }
>
>  uint32_t stm32h7_systick_frequency(void)
> --
> 2.29.2.windows.2
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] updated HAL_GetTick function

[Robin Mueller]

diff --git a/bsps/arm/stm32h7/start/bspstart.c 
b/bsps/arm/stm32h7/start/bspstart.c
index 2fc8133cca..e6e995a50c 100644
--- a/bsps/arm/stm32h7/start/bspstart.c
+++ b/bsps/arm/stm32h7/start/bspstart.c
@@ -32,9 +32,10 @@
 
 #include 
 
+/* Get number of milliseconds elapsed since startup */
 uint32_t HAL_GetTick(void)
 {
-  return 0;
+  return (rtems_clock_get_ticks_since_boot() * 1000) / 
rtems_clock_get_ticks_per_second();
 }
 
 uint32_t stm32h7_systick_frequency(void)
-- 
2.29.2.windows.2

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

Re: [PATCH 1/4] Implementation for HAL_GetTick

[Robin Müller]

This implementation is problematic because HAL_GetTick is supposed to
return elapsed milliseconds since boot and the current implementation
assumes there are 1000 ticks per second.
I'll send an updated patch.

Kind Regards
Robin

On Mon, 12 Apr 2021 at 11:55, Robin.Mueller 
wrote:

> This commit adds an implementation for the HAL_GetTick function.
> It simply forwards the call to the respective RTEMS function.
> ---
>  bsps/arm/stm32h7/start/bspstart.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/bsps/arm/stm32h7/start/bspstart.c
> b/bsps/arm/stm32h7/start/bspstart.c
> index 2fc8133cca..d942fbdcb3 100644
> --- a/bsps/arm/stm32h7/start/bspstart.c
> +++ b/bsps/arm/stm32h7/start/bspstart.c
> @@ -34,7 +34,7 @@
>
>  uint32_t HAL_GetTick(void)
>  {
> -  return 0;
> +  return rtems_clock_get_ticks_since_boot();
>  }
>
>  uint32_t stm32h7_systick_frequency(void)
> --
> 2.25.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel