date:20191113

Re: RFC: Building RTEMS/RISC-V with LLVM/Clang

2019-11-13 Thread Sebastian Huber


Hello Hesham,

On 13/11/2019 16:32, Hesham Almatary wrote:

On Wed, 13 Nov 2019 at 14:48, Sebastian Huber
 wrote:


Hello Hesham,

On 23/10/2019 15:50, Hesham Almatary wrote:

Hi,

I submitted a RFC patch series to be able to build RTEMS/RISC-V with
LLVM/Clang. I'd appreciate your feedback on that.

A sample configure line to build RTEMS with LLVM/Clang is:

../rtems/configure --target=riscv-rtems6
--enable-rtemsbsp=rv64imafdc_clang  CC_FOR_TARGET="clang"
CXX_FOR_TARGET="clang++" AR_FOR_TARGET="llvm-ar"


Could you provide me a 64-bit Linux binary installation of your clang
toolchain so that I can test it locally?


https://drive.google.com/file/d/1I0WHOMT2CCkxn_9mz7_WxEXXgCp6yNab/view?usp=sharing


thanks, you can delete the file if you want.



You can you also to build it yourself from source here
https://github.com/CTSRD-CHERI/llvm-project



NEWLIB_SYSROOT env variable needs to point to where newlib is
installed while configuring/building RTEMS.


To which directory NEWLIB_SYSROOT in the /opt/rtems/5 installation tree
must this point?


riscv-rtems5. Or the corresponding multilib directory for your RISC-V BSP.


So, if I use --sysroot=/opt/rtems/5/riscv-rtems5, then clang will pick 
up /opt/rtems/5/riscv-rtems5/include for the headers and 
/opt/rtems/5/riscv-rtems5/lib for the libraries. I guess this works only 
for the default multilib. What do I have to do to use another multilib? 
Add a -L/build/rtems/5/riscv-rtems5/lib/rv32im/ilp32 before the 
--sysroot? Why don't you use -I and -L instead of the --sysroot? This 
--sysroot seems to me quite unsafe in combination with multilibs.


I tried to to this, unfortunately it doesn't work with assembler files:

[  65/3840] Compiling cpukit/score/cpu/riscv/riscv-counter.S
08:12:49 runner ['/build/rtems-clang-riscv/sdk/bin/clang', '-DASM', 
'-target', 'riscv32-unknown-rtems6', '-Icpukit/include', 
'-I../../../cpukit/include', '-Icpukit/score/cpu/riscv/include', 
'-I../../../cpukit/score/cpu/riscv/include', 
'../../../cpukit/score/cpu/riscv/riscv-counter.S', 
'cpukit/score/cpu/riscv/riscv-counter.S.20.o']
clang-10: error: invalid argument 'missing --sysroot= option' not 
allowed with 'rtems driver'


For C files, it is not an issue:

[  63/3840] Compiling bsps/riscv/riscv/clock/clockdrv.c
08:23:20 runner ['/build/rtems-clang-riscv/sdk/bin/clang', '-MMD', 
'-Wmissing-prototypes', '-Wimplicit-function-declaration', 
'-Wstrict-prototypes', '-Wnested-externs', '-Wall', '-O2', '-g', 
'-fdata-sections', '-ffunction-sections', '-target', 
'riscv32-unknown-rtems6', '-I/build/rtems/5/riscv-rtems5/include', 
'-Icpukit/include', '-I../../../cpukit/include', 
'-Icpukit/score/cpu/riscv/include', 
'-I../../../cpukit/score/cpu/riscv/include', '-Ibsps/include', 
'-I../../../bsps/include', '-Ibsps/riscv/include', 
'-I../../../bsps/riscv/include', '-Ibsps/riscv/riscv/include', 
'-I../../../bsps/riscv/riscv/include', 
'../../../bsps/riscv/riscv/clock/clockdrv.c', '-c', 
'-o/home/EB/sebastian_h/git-rtems-5/build/riscv/rv32imac/bsps/riscv/riscv/clock/clockdrv.c.5.o', 
'-DHAVE_CONFIG_H=1']


This looks like a bug in the RTEMS clang driver. Are you able to fix it?

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: *.tcfg specification?

2019-11-13 Thread Sebastian Huber


On 14/11/2019 01:09, Chris Johns wrote:

On 13/11/19 5:22 pm, Sebastian Huber wrote:

On 13/11/2019 01:39, Chris Johns wrote:

  > Ok, it seems a test program has exactly one state for a given BSP.

  Yes, this is driven by the ABI, hardware profile and similar constraints.


This is generally the case but we have a few BSPs where the same executable
runs on real hardware and multiple simulators. The SPARC BSPs are at the
top of this list. The pc386 is another example.

We currently have no way to specify that a test could pass on real hardware,
fail on simulator 1 and pass on simulator 2. For the SPARC BSPs, we now
have real HW, sis, qemu and tsim.

The .tcfg files don't begin to address this and I really don't have any good
ideas myself. It is just a very real life case that it would be nice to address
so we have 100% expected passes on all execution platforms.

I think it is a difficult problem to try and solve in RTEMS with test states. I
think this is best handled in the eco-system with rtems-test and anything that
processes the results it generates. In the eco-system we have more flexibility
to define a hardware profile and assign a BSP to it.

A hardware test result is of higher importance that a simulator result and a
simulator test result is of higher importance than no test results. The
expected-fail state is feedback driven and we cannot set this state without a
suitable set of results. The tier a BSP resides in defines how you view the test
state for a specific BSP.

Here are some observations ...

1. By definition an accurate simulator will always match the hardware test
results


This depends on the goals of the simulator. In Qemu for example there is by
design no preservation of the timing properties of the simulated hardware. We
see this in the spintrcritical* tests for example.


No doubt however the assertion is still true. Having tests that pass on
simulator and fail on hardware then flagging them as valid does not make sense.


2. We need to provide a workable way to capture the test results and feedback
this back into the tiers

3. The tiers need to be current and visible to be meaningful to our users

4. We have no expected-fail states in any tests and we should ...

    $ grep 'expected-fail' `find . -name \*.tcfg`` | wc -l
     0


One approach to capture the actual expectations on a particular target system
(e.g. real hardware H, simulator A, simulator B) would be to split the state
definitions. The build system would just build the test or not.


I am not following why you would want this.


See some lines above from Joel:

"We currently have no way to specify that a test could pass on real 
hardware, fail on simulator 1 and pass on simulator 2. For the SPARC 
BSPs, we now have real HW, sis, qemu and tsim."


If we want to specify the test state at this level (I don't know if we 
want to do this, but Joel asked.), then the information should move from 
the BSPs to the test runner. Otherwise we have to pick up one target 
platform for the BSP and use the results on this platform to specify the 
states.





A particular
test runner which knows if the test runs on H, A, or B could use a test runner
specific data set to get the runtime states (pass, expected-fail, user-input,
indeterminate, benchmark).


We should always build and run a test that can be executed. 


Yes.


We need to know if a
test flagged as expected-fail is now passing.


Yes.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add TOD Hooks to allow BSP to take action when TOD is set

2019-11-13 Thread Joel Sherrill

Sorry about the indenting. I don't know that we have an RTEMS style
recommendation on that.
It's a personal thing. I suspect there is RTEMS code with it. It makes
lock/unlock regions obvious
but it isn't conducive to unlocking inside if paths.

I will remove the indentation unless we think there is value to it and then
we need a separate
thread to define some rules.

I also fixed the one case of unnecessarily locking the TOD.

On Wed, Nov 13, 2019 at 6:16 PM Chris Johns  wrote:

> On 14/11/19 12:46 am, Joel Sherrill wrote:
> > Two use cases were envisioned for this.
> >
> > 1) a BSP or application which desires to update a real-time clock
> >when the RTEMS TOD is set.
> >
> > 2) a paravirtualized BSP can use this to propagate setting the time
> >in an RTEMS application to the hosting environment. This enables
> >the entire set of applications in the virtualized environments
> >to have a single consistent TOD.
> > ---
> >  cpukit/Makefile.am |   4 +
> >  cpukit/include/rtems/score/todimpl.h   |  97 +-
> >  cpukit/posix/src/clocksettime.c|  16 +-
> >  cpukit/rtems/src/clockset.c|   9 +-
> >  cpukit/score/src/coretodhookdata.c |  45 +++
> >  cpukit/score/src/coretodhookregister.c |  60 
> >  cpukit/score/src/coretodhookrun.c  |  69 +
> >  cpukit/score/src/coretodhookunregister.c   |  59 
> >  cpukit/score/src/coretodset.c  |  10 +-
> >  testsuites/sptests/Makefile.am |   9 +
> >  testsuites/sptests/configure.ac|   1 +
> >  testsuites/sptests/spclock_todhook01/init.c| 334
> +
> >  .../spclock_todhook01/spclock_todhook01.doc|  35 +++
> >  .../spclock_todhook01/spclock_todhook01.scn|   0
> >  14 files changed, 740 insertions(+), 8 deletions(-)
> >  create mode 100644 cpukit/score/src/coretodhookdata.c
> >  create mode 100644 cpukit/score/src/coretodhookregister.c
> >  create mode 100644 cpukit/score/src/coretodhookrun.c
> >  create mode 100644 cpukit/score/src/coretodhookunregister.c
> >  create mode 100644 testsuites/sptests/spclock_todhook01/init.c
> >  create mode 100644
> testsuites/sptests/spclock_todhook01/spclock_todhook01.doc
> >  create mode 100644
> testsuites/sptests/spclock_todhook01/spclock_todhook01.scn
> >
> > diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
> > index 7698fe5..8cf5fb8 100644
> > --- a/cpukit/Makefile.am
> > +++ b/cpukit/Makefile.am
> > @@ -981,6 +981,10 @@ librtemscpu_a_SOURCES += score/src/coretodset.c
> >  librtemscpu_a_SOURCES += score/src/coretodtickspersec.c
> >  librtemscpu_a_SOURCES += score/src/coretodadjust.c
> >  librtemscpu_a_SOURCES += score/src/watchdoginsert.c
> > +librtemscpu_a_SOURCES += score/src/coretodhookdata.c
> > +librtemscpu_a_SOURCES += score/src/coretodhookregister.c
> > +librtemscpu_a_SOURCES += score/src/coretodhookrun.c
> > +librtemscpu_a_SOURCES += score/src/coretodhookunregister.c
> >  librtemscpu_a_SOURCES += score/src/watchdogremove.c
> >  librtemscpu_a_SOURCES += score/src/watchdogtick.c
> >  librtemscpu_a_SOURCES += score/src/watchdogtickssinceboot.c
> > diff --git a/cpukit/include/rtems/score/todimpl.h
> b/cpukit/include/rtems/score/todimpl.h
> > index 0d4faac..36e66a0 100644
> > --- a/cpukit/include/rtems/score/todimpl.h
> > +++ b/cpukit/include/rtems/score/todimpl.h
> > @@ -141,6 +141,9 @@ typedef struct {
> >bool is_set;
> >  } TOD_Control;
> >
> > +/**
> > + * @brief TOD Management information
> > + */
> >  extern TOD_Control _TOD;
> >
> >  /**
> > @@ -183,8 +186,11 @@ static inline void _TOD_Acquire( ISR_lock_Context
> *lock_context )
> >   * @param lock_context The ISR lock context used for the corresponding
> >   *   _TOD_Acquire().  The caller must be the owner of the TOD lock.
> This
> >   *   function will release the TOD lock.
> > + *
> > + * @retval true on success
> > + * @retval false on failure
> >   */
> > -void _TOD_Set(
> > +bool _TOD_Set(
> >const struct timespec *tod,
> >ISR_lock_Context  *lock_context
> >  );
> > @@ -320,6 +326,95 @@ RTEMS_INLINE_ROUTINE bool _TOD_Is_set( void )
> >
> >  /** @} */
> >
> > +/**
> > + * @defgroup RTEMSScoreTODHooks Time of Day Handler Action Hooks
> > + *
> > + * @ingroup RTEMSScoreTOD
> > + *
> > + * @brief Time of Day Handler Action Hooks
> > + *
> > + * The following support registering a hook which is invoked
> > + * when the TOD is set. These can be used by a paravirtualized
> > + * BSP to mirror time changes to the hosting environment or a
> > + * regular BSP to program a real-time clock when the RTEMS TOD
> > + * is set.
> > + *
> > + * @{
> > + */
> > +
> > +/**
> > + *  @brief Possible actions where a registered hook could be invoked
> > + */
> > +typedef enum {
> > +  /**
> > +   *  @brief Constant to indicate the TOD is being set.
> > +   */
> > +  TOD_ACTION_SET_CLOCK
> > +} TOD_Action;
> >

Re: [PATCH] Add TOD Hooks to allow BSP to take action when TOD is set

2019-11-13 Thread Chris Johns

On 14/11/19 12:46 am, Joel Sherrill wrote:
> Two use cases were envisioned for this.
> 
> 1) a BSP or application which desires to update a real-time clock
>when the RTEMS TOD is set.
> 
> 2) a paravirtualized BSP can use this to propagate setting the time
>in an RTEMS application to the hosting environment. This enables
>the entire set of applications in the virtualized environments
>to have a single consistent TOD.
> ---
>  cpukit/Makefile.am |   4 +
>  cpukit/include/rtems/score/todimpl.h   |  97 +-
>  cpukit/posix/src/clocksettime.c|  16 +-
>  cpukit/rtems/src/clockset.c|   9 +-
>  cpukit/score/src/coretodhookdata.c |  45 +++
>  cpukit/score/src/coretodhookregister.c |  60 
>  cpukit/score/src/coretodhookrun.c  |  69 +
>  cpukit/score/src/coretodhookunregister.c   |  59 
>  cpukit/score/src/coretodset.c  |  10 +-
>  testsuites/sptests/Makefile.am |   9 +
>  testsuites/sptests/configure.ac|   1 +
>  testsuites/sptests/spclock_todhook01/init.c| 334 
> +
>  .../spclock_todhook01/spclock_todhook01.doc|  35 +++
>  .../spclock_todhook01/spclock_todhook01.scn|   0
>  14 files changed, 740 insertions(+), 8 deletions(-)
>  create mode 100644 cpukit/score/src/coretodhookdata.c
>  create mode 100644 cpukit/score/src/coretodhookregister.c
>  create mode 100644 cpukit/score/src/coretodhookrun.c
>  create mode 100644 cpukit/score/src/coretodhookunregister.c
>  create mode 100644 testsuites/sptests/spclock_todhook01/init.c
>  create mode 100644 testsuites/sptests/spclock_todhook01/spclock_todhook01.doc
>  create mode 100644 testsuites/sptests/spclock_todhook01/spclock_todhook01.scn
> 
> diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
> index 7698fe5..8cf5fb8 100644
> --- a/cpukit/Makefile.am
> +++ b/cpukit/Makefile.am
> @@ -981,6 +981,10 @@ librtemscpu_a_SOURCES += score/src/coretodset.c
>  librtemscpu_a_SOURCES += score/src/coretodtickspersec.c
>  librtemscpu_a_SOURCES += score/src/coretodadjust.c
>  librtemscpu_a_SOURCES += score/src/watchdoginsert.c
> +librtemscpu_a_SOURCES += score/src/coretodhookdata.c
> +librtemscpu_a_SOURCES += score/src/coretodhookregister.c
> +librtemscpu_a_SOURCES += score/src/coretodhookrun.c
> +librtemscpu_a_SOURCES += score/src/coretodhookunregister.c
>  librtemscpu_a_SOURCES += score/src/watchdogremove.c
>  librtemscpu_a_SOURCES += score/src/watchdogtick.c
>  librtemscpu_a_SOURCES += score/src/watchdogtickssinceboot.c
> diff --git a/cpukit/include/rtems/score/todimpl.h 
> b/cpukit/include/rtems/score/todimpl.h
> index 0d4faac..36e66a0 100644
> --- a/cpukit/include/rtems/score/todimpl.h
> +++ b/cpukit/include/rtems/score/todimpl.h
> @@ -141,6 +141,9 @@ typedef struct {
>bool is_set;
>  } TOD_Control;
>  
> +/**
> + * @brief TOD Management information
> + */
>  extern TOD_Control _TOD;
>  
>  /**
> @@ -183,8 +186,11 @@ static inline void _TOD_Acquire( ISR_lock_Context 
> *lock_context )
>   * @param lock_context The ISR lock context used for the corresponding
>   *   _TOD_Acquire().  The caller must be the owner of the TOD lock.  This
>   *   function will release the TOD lock.
> + *
> + * @retval true on success
> + * @retval false on failure
>   */
> -void _TOD_Set(
> +bool _TOD_Set(
>const struct timespec *tod,
>ISR_lock_Context  *lock_context
>  );
> @@ -320,6 +326,95 @@ RTEMS_INLINE_ROUTINE bool _TOD_Is_set( void )
>  
>  /** @} */
>  
> +/**
> + * @defgroup RTEMSScoreTODHooks Time of Day Handler Action Hooks
> + *
> + * @ingroup RTEMSScoreTOD
> + *
> + * @brief Time of Day Handler Action Hooks
> + *
> + * The following support registering a hook which is invoked
> + * when the TOD is set. These can be used by a paravirtualized
> + * BSP to mirror time changes to the hosting environment or a
> + * regular BSP to program a real-time clock when the RTEMS TOD
> + * is set.
> + *
> + * @{
> + */
> +
> +/**
> + *  @brief Possible actions where a registered hook could be invoked
> + */
> +typedef enum {
> +  /**
> +   *  @brief Constant to indicate the TOD is being set.
> +   */
> +  TOD_ACTION_SET_CLOCK
> +} TOD_Action;
> +
> +/**
> + * @brief Structure to manage each TOD action hook
> + */
> +typedef struct TOD_Hook {
> +  /** This is the chain node portion of an object. */
> +  Chain_Node Node;
> +
> +  /** This is the TOD action hook that is invoked. */
> +  bool (*handler)(TOD_Action, const struct timespec *);
> +} TOD_Hook;
> +
> +/**
> + * @brief Set of registered methods for TOD Actions
> + */
> +extern Chain_Control _TOD_Hooks;
> +
> +/**
> + * @brief Add a TOD Action Hook
> + *
> + * This method is used to add a hook to the TOD action set.
> + *
> + * @brief hook is the action hook to register.
> + *
> + * @retval true if the hook is added. 
> + * @retval false if the hook cannot be

Re: *.tcfg specification?

2019-11-13 Thread Chris Johns

On 13/11/19 5:22 pm, Sebastian Huber wrote:
> On 13/11/2019 01:39, Chris Johns wrote:
>>>  > Ok, it seems a test program has exactly one state for a given BSP.
>>>
>>>  Yes, this is driven by the ABI, hardware profile and similar 
>>> constraints.
>>>
>>>
>>> This is generally the case but we have a few BSPs where the same executable
>>> runs on real hardware and multiple simulators. The SPARC BSPs are at the
>>> top of this list. The pc386 is another example.
>>>
>>> We currently have no way to specify that a test could pass on real hardware,
>>> fail on simulator 1 and pass on simulator 2. For the SPARC BSPs, we now
>>> have real HW, sis, qemu and tsim.
>>>
>>> The .tcfg files don't begin to address this and I really don't have any good
>>> ideas myself. It is just a very real life case that it would be nice to 
>>> address
>>> so we have 100% expected passes on all execution platforms.
>> I think it is a difficult problem to try and solve in RTEMS with test 
>> states. I
>> think this is best handled in the eco-system with rtems-test and anything 
>> that
>> processes the results it generates. In the eco-system we have more 
>> flexibility
>> to define a hardware profile and assign a BSP to it.
>>
>> A hardware test result is of higher importance that a simulator result and a
>> simulator test result is of higher importance than no test results. The
>> expected-fail state is feedback driven and we cannot set this state without a
>> suitable set of results. The tier a BSP resides in defines how you view the 
>> test
>> state for a specific BSP.
>>
>> Here are some observations ...
>>
>> 1. By definition an accurate simulator will always match the hardware test
>> results
> 
> This depends on the goals of the simulator. In Qemu for example there is by
> design no preservation of the timing properties of the simulated hardware. We
> see this in the spintrcritical* tests for example.

No doubt however the assertion is still true. Having tests that pass on
simulator and fail on hardware then flagging them as valid does not make sense.

>> 2. We need to provide a workable way to capture the test results and feedback
>> this back into the tiers
>>
>> 3. The tiers need to be current and visible to be meaningful to our users
>>
>> 4. We have no expected-fail states in any tests and we should ...
>>
>>    $ grep 'expected-fail' `find . -name \*.tcfg`` | wc -l
>>     0
> 
> One approach to capture the actual expectations on a particular target system
> (e.g. real hardware H, simulator A, simulator B) would be to split the state
> definitions. The build system would just build the test or not. 

I am not following why you would want this.

> A particular
> test runner which knows if the test runs on H, A, or B could use a test runner
> specific data set to get the runtime states (pass, expected-fail, user-input,
> indeterminate, benchmark).

We should always build and run a test that can be executed. We need to know if a
test flagged as expected-fail is now passing.

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

Re: Hello World Patch

2019-11-13 Thread Christian Mauderer

Hello Shubham Bhagat,

welcome to RTEMS and congratulations for completing the Hello World task.

You are quite early for GSoC 2020. So just to be sure let me ask: Do you
plan to participate as a GSoC student or do you want to start just out
of interest outside of a program like GSoC?

If you want to start for GSoC: Most of us are not in GSoC mode and the
infrastructure isn't prepared yet. That's not really a problem but you
might don't find the information that well prepared at the moment.

Regarding tasks to do: You can either have a look at the Open Projects
page in the wiki [1] or suggest some topics yourself. If you find
something just discuss it on the mailing list. Someone will show up and
help with how to approach the topic. Again: Please note that some of the
open projects might still have some left over from last year. But even
if you pick something that is solved yet we can then find something similar.

Another possible starting point at this time could be to have a look at
some of the tickets at [2]. A lot of stuff piled up there and we are
always happy if someone starts to work on the less active tickets. Just
tell the mailing list that you want to work on a ticket to avoid
duplicate work.

Note that most tickets are not really well suited for the time frame of
a GSoC project. But you might find some topics that you are interested
in and we can then find a GSoC project in that area.

Best regards

Christian

[1] https://devel.rtems.org/wiki/Developer/OpenProjects
[2] https://devel.rtems.org/query

On 13/11/2019 10:45, Shubham Bhagat wrote:
> Hi!
> I've completed the Hello World task for GSOC and have included the patch
> and screenshot in the attachments. Please do check. I am a sophomore
> Computer Science student from India looking to gain more knowledge in
> Operating Systems. Please do share with me interesting projects/issues
> that I can tackle!
> 
> Thank you Ravindra Kumar Meena for writing a very detailed blog so I
> could successfully build :)
> 
> ___
> 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: RFC: Building RTEMS/RISC-V with LLVM/Clang

2019-11-13 Thread Hesham Almatary

On Wed, 13 Nov 2019 at 14:48, Sebastian Huber
 wrote:
>
> Hello Hesham,
>
> On 23/10/2019 15:50, Hesham Almatary wrote:
> > Hi,
> >
> > I submitted a RFC patch series to be able to build RTEMS/RISC-V with
> > LLVM/Clang. I'd appreciate your feedback on that.
> >
> > A sample configure line to build RTEMS with LLVM/Clang is:
> >
> > ../rtems/configure --target=riscv-rtems6
> > --enable-rtemsbsp=rv64imafdc_clang  CC_FOR_TARGET="clang"
> > CXX_FOR_TARGET="clang++" AR_FOR_TARGET="llvm-ar"
>
> Could you provide me a 64-bit Linux binary installation of your clang
> toolchain so that I can test it locally?
>
https://drive.google.com/file/d/1I0WHOMT2CCkxn_9mz7_WxEXXgCp6yNab/view?usp=sharing

You can you also to build it yourself from source here
https://github.com/CTSRD-CHERI/llvm-project

> >
> > NEWLIB_SYSROOT env variable needs to point to where newlib is
> > installed while configuring/building RTEMS.
>
> To which directory NEWLIB_SYSROOT in the /opt/rtems/5 installation tree
> must this point?
>
riscv-rtems5. Or the corresponding multilib directory for your RISC-V BSP.

You'll also need to copy or symlink libgcc.a to
NEWLIB_SYSROOT/lib/libclang_rt.builtins-riscv32.a

> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RFC: Building RTEMS/RISC-V with LLVM/Clang

2019-11-13 Thread Sebastian Huber


Hello Hesham,

On 23/10/2019 15:50, Hesham Almatary wrote:

Hi,

I submitted a RFC patch series to be able to build RTEMS/RISC-V with
LLVM/Clang. I'd appreciate your feedback on that.

A sample configure line to build RTEMS with LLVM/Clang is:

../rtems/configure --target=riscv-rtems6
--enable-rtemsbsp=rv64imafdc_clang  CC_FOR_TARGET="clang"
CXX_FOR_TARGET="clang++" AR_FOR_TARGET="llvm-ar"


Could you provide me a 64-bit Linux binary installation of your clang 
toolchain so that I can test it locally?




NEWLIB_SYSROOT env variable needs to point to where newlib is
installed while configuring/building RTEMS.


To which directory NEWLIB_SYSROOT in the /opt/rtems/5 installation tree 
must this point?


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add TOD Hooks to allow BSP to take action when TOD is set

2019-11-13 Thread Sebastian Huber


Hello Joel,

there are a couple of

On 13/11/2019 14:46, Joel Sherrill wrote:

_TOD_Acquire( _context );


which I don't understand. Please run the tests with SMP and debug 
enabled. You should see some failed assertions in your code.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Add TOD Hooks to allow BSP to take action when TOD is set

2019-11-13 Thread Joel Sherrill

Two use cases were envisioned for this.

1) a BSP or application which desires to update a real-time clock
   when the RTEMS TOD is set.

2) a paravirtualized BSP can use this to propagate setting the time
   in an RTEMS application to the hosting environment. This enables
   the entire set of applications in the virtualized environments
   to have a single consistent TOD.
---
 cpukit/Makefile.am |   4 +
 cpukit/include/rtems/score/todimpl.h   |  97 +-
 cpukit/posix/src/clocksettime.c|  16 +-
 cpukit/rtems/src/clockset.c|   9 +-
 cpukit/score/src/coretodhookdata.c |  45 +++
 cpukit/score/src/coretodhookregister.c |  60 
 cpukit/score/src/coretodhookrun.c  |  69 +
 cpukit/score/src/coretodhookunregister.c   |  59 
 cpukit/score/src/coretodset.c  |  10 +-
 testsuites/sptests/Makefile.am |   9 +
 testsuites/sptests/configure.ac|   1 +
 testsuites/sptests/spclock_todhook01/init.c| 334 +
 .../spclock_todhook01/spclock_todhook01.doc|  35 +++
 .../spclock_todhook01/spclock_todhook01.scn|   0
 14 files changed, 740 insertions(+), 8 deletions(-)
 create mode 100644 cpukit/score/src/coretodhookdata.c
 create mode 100644 cpukit/score/src/coretodhookregister.c
 create mode 100644 cpukit/score/src/coretodhookrun.c
 create mode 100644 cpukit/score/src/coretodhookunregister.c
 create mode 100644 testsuites/sptests/spclock_todhook01/init.c
 create mode 100644 testsuites/sptests/spclock_todhook01/spclock_todhook01.doc
 create mode 100644 testsuites/sptests/spclock_todhook01/spclock_todhook01.scn

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index 7698fe5..8cf5fb8 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -981,6 +981,10 @@ librtemscpu_a_SOURCES += score/src/coretodset.c
 librtemscpu_a_SOURCES += score/src/coretodtickspersec.c
 librtemscpu_a_SOURCES += score/src/coretodadjust.c
 librtemscpu_a_SOURCES += score/src/watchdoginsert.c
+librtemscpu_a_SOURCES += score/src/coretodhookdata.c
+librtemscpu_a_SOURCES += score/src/coretodhookregister.c
+librtemscpu_a_SOURCES += score/src/coretodhookrun.c
+librtemscpu_a_SOURCES += score/src/coretodhookunregister.c
 librtemscpu_a_SOURCES += score/src/watchdogremove.c
 librtemscpu_a_SOURCES += score/src/watchdogtick.c
 librtemscpu_a_SOURCES += score/src/watchdogtickssinceboot.c
diff --git a/cpukit/include/rtems/score/todimpl.h 
b/cpukit/include/rtems/score/todimpl.h
index 0d4faac..36e66a0 100644
--- a/cpukit/include/rtems/score/todimpl.h
+++ b/cpukit/include/rtems/score/todimpl.h
@@ -141,6 +141,9 @@ typedef struct {
   bool is_set;
 } TOD_Control;
 
+/**
+ * @brief TOD Management information
+ */
 extern TOD_Control _TOD;
 
 /**
@@ -183,8 +186,11 @@ static inline void _TOD_Acquire( ISR_lock_Context 
*lock_context )
  * @param lock_context The ISR lock context used for the corresponding
  *   _TOD_Acquire().  The caller must be the owner of the TOD lock.  This
  *   function will release the TOD lock.
+ *
+ * @retval true on success
+ * @retval false on failure
  */
-void _TOD_Set(
+bool _TOD_Set(
   const struct timespec *tod,
   ISR_lock_Context  *lock_context
 );
@@ -320,6 +326,95 @@ RTEMS_INLINE_ROUTINE bool _TOD_Is_set( void )
 
 /** @} */
 
+/**
+ * @defgroup RTEMSScoreTODHooks Time of Day Handler Action Hooks
+ *
+ * @ingroup RTEMSScoreTOD
+ *
+ * @brief Time of Day Handler Action Hooks
+ *
+ * The following support registering a hook which is invoked
+ * when the TOD is set. These can be used by a paravirtualized
+ * BSP to mirror time changes to the hosting environment or a
+ * regular BSP to program a real-time clock when the RTEMS TOD
+ * is set.
+ *
+ * @{
+ */
+
+/**
+ *  @brief Possible actions where a registered hook could be invoked
+ */
+typedef enum {
+  /**
+   *  @brief Constant to indicate the TOD is being set.
+   */
+  TOD_ACTION_SET_CLOCK
+} TOD_Action;
+
+/**
+ * @brief Structure to manage each TOD action hook
+ */
+typedef struct TOD_Hook {
+  /** This is the chain node portion of an object. */
+  Chain_Node Node;
+
+  /** This is the TOD action hook that is invoked. */
+  bool (*handler)(TOD_Action, const struct timespec *);
+} TOD_Hook;
+
+/**
+ * @brief Set of registered methods for TOD Actions
+ */
+extern Chain_Control _TOD_Hooks;
+
+/**
+ * @brief Add a TOD Action Hook
+ *
+ * This method is used to add a hook to the TOD action set.
+ *
+ * @brief hook is the action hook to register.
+ *
+ * @retval true if the hook is added. 
+ * @retval false if the hook cannot be added. 
+ */
+bool _TOD_Hook_Register(
+  TOD_Hook *hook
+);
+
+/**
+ * @brief Remove a TOD Action Hook
+ *
+ * This method is used to remove a hook from the TOD action set.
+ *
+ * @brief hook is the action hook to unregister.
+ *
+ * @retval true if the hook is unregister. 
+ * @retval false if the hook cannot

Re: sparc-rtems-gdb doesn't recognize target "sim"

2019-11-13 Thread Shubham Bhagat

 Thank you for the help! sparc-rtems5-sis works well for me.
On Wednesday, 13 November, 2019, 2:46:02 pm IST, Jiri Gaisler 
 wrote:  
 
  

 
 On 11/13/19 9:48 AM, Vaibhav Gupta wrote:
  
 
You can also use "sis" 
  1- Open Terminal 1 and write: 
  $ sparc-rtems5-sis -gdb         # It will print 'gdb: listening on port 
1234'.         # Note you can define port number with '-port' option. 
  2-Open Terminal 2 and write: 
  $ sparc-rtems5-gdb hello.exe         # gdb asks for several inputs            
     $ target extended-remote localhost:1234                 $ load             
    $ r 
  Use the notes here: 
https://github.com/VARoDeK/MyNotes/blob/master/RTEMS/run_a_testsuite.md

 
 
Note that the procedure for RISC-V can be exactly the same, usings 
riscv-rtems5-sis and the RTEMS griscv bsp ..
 
Jiri.
 
 

 
 

  On Wed, Nov 13, 2019, 1:06 PM Vijay Kumar Banerjee  
wrote:
  
  
  
  On Wed, Nov 13, 2019 at 12:39 AM Shubham Bhagat  
wrote:
  
   Hello everyone,  I've been trying to  run the hello world example in source 
tree to get started with sparc/erc32 but after building all that is required ( 
followed POSIX Compliance (Getting started challenge for RTEMS beginners)). I  
followed all the commands. But, when gdb starts and I set "tar sim" it says: 
  
  Undefined target command: "sim".  Try "help target".
  
  I also tried running hello.exe from the testsuites sample using 
sparc-rtems5-run but it doesn't recognize the  command. NOTE: The make and make 
install steps didn't finish with a "SUCCESS" or anything. They exited without 
showing any  error.
  
  Am I missing out anything here?
   
 
 I guess this thread will be helpful for you: 
https://lists.rtems.org/pipermail/devel/2019-September/055671.html  
 
|  
|  
| 
  |  
POSIX Compliance (Getting started challenge for RTEMS beginners)
 
Ravindra Kumar Meena
 
POSIX stands for Portable Operating System Interface for uni-X. POSIX 
Compliance allows us to port  the source co...
  |

  |

  |

  
  
 ___
 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 
 ___
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: sparc-rtems-gdb doesn't recognize target "sim"

2019-11-13 Thread Jiri Gaisler


On 11/13/19 9:48 AM, Vaibhav Gupta wrote:
> You can also use "sis"
>
> 1- Open Terminal 1 and write:
>
> $ sparc-rtems5-sis -gdb
>         # It will print 'gdb: listening on port 1234'.
>         # Note you can define port number with '-port' option.
>
> 2-Open Terminal 2 and write:
>
> $ sparc-rtems5-gdb hello.exe
>         # gdb asks for several inputs
>                 $ target extended-remote localhost:1234
>                 $ load
>                 $ r
>
> Use the notes here: 
> https://github.com/VARoDeK/MyNotes/blob/master/RTEMS/run_a_testsuite.md


Note that the procedure for RISC-V can be exactly the same, usings 
riscv-rtems5-sis and the RTEMS griscv bsp ..

Jiri.


>
> On Wed, Nov 13, 2019, 1:06 PM Vijay Kumar Banerjee  > wrote:
>
>
>
> On Wed, Nov 13, 2019 at 12:39 AM Shubham Bhagat 
> mailto:shubhambhagat...@yahoo.com>> wrote:
>
> Hello everyone,
> I've been trying to run the hello world example in source tree 
>  to get 
> started with sparc/erc32 but after building all that is required ( followed 
> POSIX Compliance (Getting started challenge for RTEMS beginners) 
> ). I
> followed all the commands. But, when gdb starts and I set "tar sim" 
> it says:
>
> Undefined target command: "sim".  Try "help target".
>
> I also tried running hello.exe from the testsuites sample using 
> sparc-rtems5-run but it doesn't recognize the command.
> NOTE: The make and make install steps didn't finish with a "SUCCESS" 
> or anything. They exited without showing any error.
>
> Am I missing out anything here?
>
> I guess this thread will be helpful for you:
> https://lists.rtems.org/pipermail/devel/2019-September/055671.html 
>
>
>   
>
>
> POSIX Compliance (Getting started challenge for RTEMS beginners)
>
> Ravindra Kumar Meena
>
> POSIX stands for Portable Operating System Interface for uni-X. POSIX 
> Compliance allows us to port the source co...
>
> 
>
>
> ___
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: sparc-rtems-gdb doesn't recognize target "sim"

2019-11-13 Thread Vaibhav Gupta

You can also use "sis"

1- Open Terminal 1 and write:

$ sparc-rtems5-sis -gdb
# It will print 'gdb: listening on port 1234'.
# Note you can define port number with '-port' option.

2-Open Terminal 2 and write:

$ sparc-rtems5-gdb hello.exe
# gdb asks for several inputs
$ target extended-remote localhost:1234
$ load
$ r

Use the notes here:
https://github.com/VARoDeK/MyNotes/blob/master/RTEMS/run_a_testsuite.md

On Wed, Nov 13, 2019, 1:06 PM Vijay Kumar Banerjee 
wrote:

>
>
> On Wed, Nov 13, 2019 at 12:39 AM Shubham Bhagat <
> shubhambhagat...@yahoo.com> wrote:
>
>> Hello everyone,
>> I've been trying to run the hello world example in source tree
>>  to get
>> started with sparc/erc32 but after building all that is required ( followed 
>> POSIX
>> Compliance (Getting started challenge for RTEMS beginners)
>> ). I
>> followed all the commands. But, when gdb starts and I set "tar sim" it
>> says:
>>
>> Undefined target command: "sim".  Try "help target".
>>
>> I also tried running hello.exe from the testsuites sample using
>> sparc-rtems5-run but it doesn't recognize the command.
>> NOTE: The make and make install steps didn't finish with a "SUCCESS" or
>> anything. They exited without showing any error.
>>
>> Am I missing out anything here?
>>
>> I guess this thread will be helpful for you:
> https://lists.rtems.org/pipermail/devel/2019-September/055671.html
>
>> POSIX Compliance (Getting started challenge for RTEMS beginners)
>>
>> Ravindra Kumar Meena
>>
>> POSIX stands for Portable Operating System Interface for uni-X. POSIX
>> Compliance allows us to port the source co...
>> 
>>
>>
>> ___
>> 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: RFC: Building RTEMS/RISC-V with LLVM/Clang

Re: *.tcfg specification?

Re: [PATCH] Add TOD Hooks to allow BSP to take action when TOD is set

Re: [PATCH] Add TOD Hooks to allow BSP to take action when TOD is set

Re: *.tcfg specification?

Re: Hello World Patch

Re: RFC: Building RTEMS/RISC-V with LLVM/Clang

Re: RFC: Building RTEMS/RISC-V with LLVM/Clang

Re: [PATCH] Add TOD Hooks to allow BSP to take action when TOD is set

[PATCH] Add TOD Hooks to allow BSP to take action when TOD is set

Re: sparc-rtems-gdb doesn't recognize target "sim"

Re: sparc-rtems-gdb doesn't recognize target "sim"

Re: sparc-rtems-gdb doesn't recognize target "sim"

13 matches

Site Navigation

Mail list logo

Footer information