date:20220316

Re: Movement of confdefs instance into a static library

2022-03-16 Thread Sebastian Huber


Hello Kinsey,

On 16/03/2022 22:57, Kinsey Moore wrote:

Is moving the confdefs instance into a shared library supported and expected to 
work?


yes, but the order in which the linker resolves the dependencies is very 
important. You have to make sure that the custom configuration is 
resolved before the default configuration.




I was also able to resolve the linker errors by specifying some of the link 
flags multiple times or creating a linker group.


These are ways to address the ordering. It would help if you can show 
the linker command lines and the error messages.


--
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: Support for test coverage analysis in RTEMS 6

2022-03-16 Thread VALDEZ Jose

Hello Jerzy,

Actually, the same configuration can be adapted to run in SIS (which is what we 
use most of the times). Inside the QDP you have the file 
qual-tool/config-variants/sparc-gr712rc-smp-user-qual.yml. Change the file to 
the following (you can copy and paste the content, replacing the current one):

build-directory: build-sparc-gr712rc-smp-user-qual
post-process-items:
- uid: /dirs/djf-svr-deploy/dir
  path: /directory
  action: set
  value: ${/variant:/deployment-directory}/user_doc/djf/svr
- uid: /dirs/ddf-sdd-deploy/dir
  path: /directory
  action: set
  value: ${/variant:/deployment-directory}/user_doc/ddf/sdd
- uid: /steps/build-djf-svr
  path: /config-file
  action: set
  value: rtems/djf/svr/config_user.yml
- uid: /package-build
  path: /links
  action: set
  value:
  - role: build-step
uid: steps/build-bsp-qual-only
  - role: build-step
uid: steps/build-bsp-qual-only-coverage
  - role: build-step
uid: steps/run-local-target-qual-only
  - role: build-step
uid: steps/run-local-target-qual-only-coverage
  - role: build-step
uid: steps/build-ddf-sdd
  - role: build-step
uid: steps/build-djf-svr
spec-paths:
- spec-spec
- spec-glossary
- config

Then follow the steps as described in section “11.3 Guidance for RTEMS 
Qualification in User’s Environment” to generate your own SVR. After you have 
this working example, it would be easier to see how the things work. The 
scripts/configuration files in the qual-tool folder could be adapted to what 
you want (i.e: just generate coverage for your tests). Feel free to ask me if 
you have any difficulty!

Best regards

José

From: Jerzy Jaskuc 
Sent: 16 de março de 2022 19:16
To: VALDEZ Jose 
Cc: devel@rtems.org
Subject: Re: Support for test coverage analysis in RTEMS 6

Hi José,

I'm aware of the QDP, although it is pretty big so I got confused and only 
followed  `11.3 Guidance for RTEMS Qualification in User’s Environment`, which 
didn't work as I assume it needs actual board for tests to not be`Invalid`
The reports generated are exactly what I'm looking for and steps you mentioned 
seems much more manageable!

I can see gcno files and I can see gcda bytes within the logs of the test run.
I will take a look at adapting the python scripts then.

Thanks a lot for your help!

All the best,
Jerzy



On Wed, 16 Mar 2022 at 17:05, VALDEZ Jose 
mailto:jose.val...@edisoft.pt>> wrote:
Hello Jerzy,

Recently we concluded a project, the RTEMS SMP Qualification which also needed 
to gather coverage for RTEMS (which had the participation of Andrew Butterfield 
from TCD/LERO). I suggest that you take a look at  
https://rtems-qual.io.esa.int/, download one of the QDPs (maybe you want the 
GR712RC, SMP) and look for the docs/djf/svr document. There you may find the 
coverage folder, with the html coverage reports and in the svr.pdf the coverage 
summary table.

If this is what you want for your test, I suggest to take a look at 
qual-tool/svrmanager.py and qual-tool/ccoverage_process.py.

Basically for this what you need to do:

* Compile RTEMS with coverage flags. This will generate the gcno files
* Run your test, the reports should generate the gcda bytes (Sebastian Huber 
added support for coverage in RTEMS itself)
* Use/adapt ccoverage_process.py to generate the coverage reports, which makes 
use of the gcovr tool.

Hope this helps

José

-Original Message-
From: devel mailto:devel-boun...@rtems.org>> On Behalf 
Of Jerzy Jaskuc
Sent: 16 de março de 2022 16:46
To: devel@rtems.org
Subject: Support for test coverage analysis in RTEMS 6

Hi,

I've been looking into generating code coverage reports from RTEMS tests in 
RTEMS 6.
I'm using SPARC with gr712rc BSP.

I'm following the steps outlined in the coverage analysis documentation 
https://docs.rtems.org/branches/master/user/testing/coverage.html

However, when I run it on any tests, even sample/hello.exe I get the logs in 
lines of the following:

`RTEMS Testing - Tester, 6.0.not_released  Command Line: ./rtems-test 
--rtems-tools=/home/yoman/RTEMS/rtems/6
--log=log_leon3_sis --rtems-bsp=leon3-sis-cov --coverage 
/home/yoman/RTEMS/src/rtems/build/sparc/gr712rc/testsuites/validation/ts-validation-0.exe
 Host: Linux ubuntu 5.13.0-35-generic #40~20.04.1-Ubuntu SMP Mon Mar 7
09:18:32 UTC 2022 x86_64
 Python: 3.8.10 (default, Nov 26 2021, 20:14:08) [GCC 9.3.0]
Host: Linux-5.13.0-35-generic-x86_64-with-glibc2.29 (Linux ubuntu 
5.13.0-35-generic #40~20.04.1-Ubuntu SMP Mon Mar 7 09:18:32 UTC 2022 x86_64
x86_64)
[1/1] p:0 f:0 u:0 e:0 I:0 B:0 t:0 L:0 i:0 W:0 | sparc/leon3-sis:
ts-validation-0.exe

Passed:1
Failed:0
User Input:0
Expected Fail: 0
Indeterminate: 0
Benchmark: 0
Timeout:   0
Test too long: 0
Invalid:   0
Wrong Version: 0
Wrong Build:   0
Wrong Tools:   0
Wrong Header:  0

Total: 1

Average test time: 0:00:02.008333
Testing time : 0:00:02.008333

Running coverage analysis

Movement of confdefs instance into a static library

2022-03-16 Thread Kinsey Moore

Hi,
I'm working on porting Deos integration from RTEMS 5 to RTEMS 6. This requires 
linking with their shared objects and I've run into a few linking issues with 
the testsuite. I've narrowed the problems down to the way that some of the 
tests are built: any test that has its confdefs instance in a static library 
throws linker errors (missing/duplicate symbols) with the extra linking that 
occurs. This includes most of the tests under testsuites/fstests as well as 
quite a few in libtests (and possibly more). If I reintegrate the source files 
from the new static libraries directly into the executable generation step 
(i.e. imfsfserror.yml instead of libimfs.yml) as is done in RTEMS 5, the linker 
errors go away.


Is moving the confdefs instance into a shared library supported and expected to 
work?

I was also able to resolve the linker errors by specifying some of the link 
flags multiple times or creating a linker group.

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

Re: Support for test coverage analysis in RTEMS 6

2022-03-16 Thread Jerzy Jaskuc

Hi José,

I'm aware of the QDP, although it is pretty big so I got confused and only
followed  `11.3 Guidance for RTEMS Qualification in User’s Environment`,
which didn't work as I assume it needs actual board for tests to not
be`Invalid`
The reports generated are exactly what I'm looking for and steps you
mentioned seems much more manageable!

I can see gcno files and I can see gcda bytes within the logs of the test
run.
I will take a look at adapting the python scripts then.

Thanks a lot for your help!

All the best,
Jerzy



On Wed, 16 Mar 2022 at 17:05, VALDEZ Jose  wrote:

> Hello Jerzy,
>
> Recently we concluded a project, the RTEMS SMP Qualification which also
> needed to gather coverage for RTEMS (which had the participation of Andrew
> Butterfield from TCD/LERO). I suggest that you take a look at
> https://rtems-qual.io.esa.int/, download one of the QDPs (maybe you want
> the GR712RC, SMP) and look for the docs/djf/svr document. There you may
> find the coverage folder, with the html coverage reports and in the svr.pdf
> the coverage summary table.
>
> If this is what you want for your test, I suggest to take a look at
> qual-tool/svrmanager.py and qual-tool/ccoverage_process.py.
>
> Basically for this what you need to do:
>
> * Compile RTEMS with coverage flags. This will generate the gcno files
> * Run your test, the reports should generate the gcda bytes (Sebastian
> Huber added support for coverage in RTEMS itself)
> * Use/adapt ccoverage_process.py to generate the coverage reports, which
> makes use of the gcovr tool.
>
> Hope this helps
>
> José
>
> -Original Message-
> From: devel  On Behalf Of Jerzy Jaskuc
> Sent: 16 de março de 2022 16:46
> To: devel@rtems.org
> Subject: Support for test coverage analysis in RTEMS 6
>
> Hi,
>
> I've been looking into generating code coverage reports from RTEMS tests
> in RTEMS 6.
> I'm using SPARC with gr712rc BSP.
>
> I'm following the steps outlined in the coverage analysis documentation
> https://docs.rtems.org/branches/master/user/testing/coverage.html
>
> However, when I run it on any tests, even sample/hello.exe I get the logs
> in lines of the following:
>
> `RTEMS Testing - Tester, 6.0.not_released  Command Line: ./rtems-test
> --rtems-tools=/home/yoman/RTEMS/rtems/6
> --log=log_leon3_sis --rtems-bsp=leon3-sis-cov --coverage
> /home/yoman/RTEMS/src/rtems/build/sparc/gr712rc/testsuites/validation/ts-validation-0.exe
>  Host: Linux ubuntu 5.13.0-35-generic #40~20.04.1-Ubuntu SMP Mon Mar 7
> 09:18:32 UTC 2022 x86_64
>  Python: 3.8.10 (default, Nov 26 2021, 20:14:08) [GCC 9.3.0]
> Host: Linux-5.13.0-35-generic-x86_64-with-glibc2.29 (Linux ubuntu
> 5.13.0-35-generic #40~20.04.1-Ubuntu SMP Mon Mar 7 09:18:32 UTC 2022 x86_64
> x86_64)
> [1/1] p:0 f:0 u:0 e:0 I:0 B:0 t:0 L:0 i:0 W:0 | sparc/leon3-sis:
> ts-validation-0.exe
>
> Passed:1
> Failed:0
> User Input:0
> Expected Fail: 0
> Indeterminate: 0
> Benchmark: 0
> Timeout:   0
> Test too long: 0
> Invalid:   0
> Wrong Version: 0
> Wrong Build:   0
> Wrong Tools:   0
> Wrong Header:  0
> 
> Total: 1
>
> Average test time: 0:00:02.008333
> Testing time : 0:00:02.008333
>
> Running coverage analysis
> (/home/yoman/RTEMS/rtems/6/bin/leon3-sis-coverage)
> Function is both external and inlined: _Message_queue_Create Function is
> both external and inlined: _Message_queue_Create Function is both external
> and inlined: _Message_queue_Create Function is both external and inlined:
> _Thread_Initialize_information Function is both external and inlined:
> _Thread_Initialize_information Function is both external and inlined:
> _Thread_queue_Initialize Function is both external and inlined:
> _Thread_queue_Initialize Function is both external and inlined:
> _Thread_queue_Resume Function is both external and inlined:
> _Thread_queue_FIFO_first Function is both external and inlined:
> _Thread_queue_FIFO_first Function is both external and inlined:
> _Thread_CPU_budget_consume_and_yield
> Function is both external and inlined: _Thread_CPU_budget_consume_and_yield
> Function is both external and inlined: _Thread_Join Function is both
> external and inlined: _Thread_Join Function is both external and inlined:
> _Thread_Set_state_locked Function is both external and inlined:
> _Thread_Set_state_locked Function is both external and inlined:
> _Thread_Set_state_locked Function is both external and inlined:
> _Thread_Set_state_locked Function is both external and inlined:
> _Timecounter_Binuptime Function is both external and inlined:
> _Timecounter_Bintime Function is both external and inlined:
> _Timecounter_Getboottimebin Function is both external and inlined:
> _Thread_Priority_perform_actions Function is both external and inlined:
> _Thread_Priority_perform_actions Function is both external and inlined:
> _Thread_Clear_state_locked Function is both external and inlined:
> _Thread_Clear_state_locked Function is both external and inlined:
>

GSoC-2022 Introduction

2022-03-16 Thread Yuto Kaihara

Hello, I'm Yuto Kaihara.
I'm student of master course in Japan. and My discord name is acerola243.

I was interested in RTOS and wanted to contribute.
In GSoC-2022, I would like to improve BSP support for Raspberry pi 4.

I have 2 years of experience in MCU development. However, I have no
experience in SoC bare metal development.

I'm going to send Patch and screenshot via discord.

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

RE: Support for test coverage analysis in RTEMS 6

2022-03-16 Thread VALDEZ Jose

Hello Jerzy,

Recently we concluded a project, the RTEMS SMP Qualification which also needed 
to gather coverage for RTEMS (which had the participation of Andrew Butterfield 
from TCD/LERO). I suggest that you take a look at  
https://rtems-qual.io.esa.int/, download one of the QDPs (maybe you want the 
GR712RC, SMP) and look for the docs/djf/svr document. There you may find the 
coverage folder, with the html coverage reports and in the svr.pdf the coverage 
summary table.

If this is what you want for your test, I suggest to take a look at 
qual-tool/svrmanager.py and qual-tool/ccoverage_process.py.

Basically for this what you need to do:

* Compile RTEMS with coverage flags. This will generate the gcno files
* Run your test, the reports should generate the gcda bytes (Sebastian Huber 
added support for coverage in RTEMS itself)
* Use/adapt ccoverage_process.py to generate the coverage reports, which makes 
use of the gcovr tool.

Hope this helps

José

-Original Message-
From: devel  On Behalf Of Jerzy Jaskuc
Sent: 16 de março de 2022 16:46
To: devel@rtems.org
Subject: Support for test coverage analysis in RTEMS 6

Hi,

I've been looking into generating code coverage reports from RTEMS tests in 
RTEMS 6.
I'm using SPARC with gr712rc BSP.

I'm following the steps outlined in the coverage analysis documentation 
https://docs.rtems.org/branches/master/user/testing/coverage.html

However, when I run it on any tests, even sample/hello.exe I get the logs in 
lines of the following:

`RTEMS Testing - Tester, 6.0.not_released  Command Line: ./rtems-test 
--rtems-tools=/home/yoman/RTEMS/rtems/6
--log=log_leon3_sis --rtems-bsp=leon3-sis-cov --coverage 
/home/yoman/RTEMS/src/rtems/build/sparc/gr712rc/testsuites/validation/ts-validation-0.exe
 Host: Linux ubuntu 5.13.0-35-generic #40~20.04.1-Ubuntu SMP Mon Mar 7
09:18:32 UTC 2022 x86_64
 Python: 3.8.10 (default, Nov 26 2021, 20:14:08) [GCC 9.3.0]
Host: Linux-5.13.0-35-generic-x86_64-with-glibc2.29 (Linux ubuntu 
5.13.0-35-generic #40~20.04.1-Ubuntu SMP Mon Mar 7 09:18:32 UTC 2022 x86_64
x86_64)
[1/1] p:0 f:0 u:0 e:0 I:0 B:0 t:0 L:0 i:0 W:0 | sparc/leon3-sis:
ts-validation-0.exe

Passed:1
Failed:0
User Input:0
Expected Fail: 0
Indeterminate: 0
Benchmark: 0
Timeout:   0
Test too long: 0
Invalid:   0
Wrong Version: 0
Wrong Build:   0
Wrong Tools:   0
Wrong Header:  0

Total: 1

Average test time: 0:00:02.008333
Testing time : 0:00:02.008333

Running coverage analysis (/home/yoman/RTEMS/rtems/6/bin/leon3-sis-coverage)
Function is both external and inlined: _Message_queue_Create Function is both 
external and inlined: _Message_queue_Create Function is both external and 
inlined: _Message_queue_Create Function is both external and inlined: 
_Thread_Initialize_information Function is both external and inlined: 
_Thread_Initialize_information Function is both external and inlined: 
_Thread_queue_Initialize Function is both external and inlined: 
_Thread_queue_Initialize Function is both external and inlined: 
_Thread_queue_Resume Function is both external and inlined: 
_Thread_queue_FIFO_first Function is both external and inlined: 
_Thread_queue_FIFO_first Function is both external and inlined: 
_Thread_CPU_budget_consume_and_yield
Function is both external and inlined: _Thread_CPU_budget_consume_and_yield
Function is both external and inlined: _Thread_Join Function is both external 
and inlined: _Thread_Join Function is both external and inlined: 
_Thread_Set_state_locked Function is both external and inlined: 
_Thread_Set_state_locked Function is both external and inlined: 
_Thread_Set_state_locked Function is both external and inlined: 
_Thread_Set_state_locked Function is both external and inlined: 
_Timecounter_Binuptime Function is both external and inlined: 
_Timecounter_Bintime Function is both external and inlined: 
_Timecounter_Getboottimebin Function is both external and inlined: 
_Thread_Priority_perform_actions Function is both external and inlined: 
_Thread_Priority_perform_actions Function is both external and inlined: 
_Thread_Clear_state_locked Function is both external and inlined: 
_Thread_Clear_state_locked Function is both external and inlined: 
_Thread_Clear_state_locked Function is both external and inlined: 
_Thread_Clear_state_locked Function is both external and inlined: 
_Malloc_System_state Function is both external and inlined: 
_Malloc_System_state Function is both external and inlined: 
_Malloc_System_state Function is both external and inlined: 
rtems_counter_initialize_converter
Function is both external and inlined: rtems_counter_initialize_converter
Function is both external and inlined: rtems_version_minor Function is both 
external and inlined: _Heap_Get_first_and_last_block Function is both external 
and inlined: _Heap_Get_first_and_last_block Error while running 
sparc-rtems6-objdump on

Support for test coverage analysis in RTEMS 6

2022-03-16 Thread Jerzy Jaskuc

Hi,

I've been looking into generating code coverage reports from RTEMS tests in
RTEMS 6.
I'm using SPARC with gr712rc BSP.

I'm following the steps outlined in the coverage analysis documentation
https://docs.rtems.org/branches/master/user/testing/coverage.html

However, when I run it on any tests, even sample/hello.exe
I get the logs in lines of the following:

`RTEMS Testing - Tester, 6.0.not_released
 Command Line: ./rtems-test --rtems-tools=/home/yoman/RTEMS/rtems/6
--log=log_leon3_sis --rtems-bsp=leon3-sis-cov --coverage
/home/yoman/RTEMS/src/rtems/build/sparc/gr712rc/testsuites/validation/ts-validation-0.exe
 Host: Linux ubuntu 5.13.0-35-generic #40~20.04.1-Ubuntu SMP Mon Mar 7
09:18:32 UTC 2022 x86_64
 Python: 3.8.10 (default, Nov 26 2021, 20:14:08) [GCC 9.3.0]
Host: Linux-5.13.0-35-generic-x86_64-with-glibc2.29 (Linux ubuntu
5.13.0-35-generic #40~20.04.1-Ubuntu SMP Mon Mar 7 09:18:32 UTC 2022 x86_64
x86_64)
[1/1] p:0 f:0 u:0 e:0 I:0 B:0 t:0 L:0 i:0 W:0 | sparc/leon3-sis:
ts-validation-0.exe

Passed:1
Failed:0
User Input:0
Expected Fail: 0
Indeterminate: 0
Benchmark: 0
Timeout:   0
Test too long: 0
Invalid:   0
Wrong Version: 0
Wrong Build:   0
Wrong Tools:   0
Wrong Header:  0

Total: 1

Average test time: 0:00:02.008333
Testing time : 0:00:02.008333

Running coverage analysis (/home/yoman/RTEMS/rtems/6/bin/leon3-sis-coverage)
Function is both external and inlined: _Message_queue_Create
Function is both external and inlined: _Message_queue_Create
Function is both external and inlined: _Message_queue_Create
Function is both external and inlined: _Thread_Initialize_information
Function is both external and inlined: _Thread_Initialize_information
Function is both external and inlined: _Thread_queue_Initialize
Function is both external and inlined: _Thread_queue_Initialize
Function is both external and inlined: _Thread_queue_Resume
Function is both external and inlined: _Thread_queue_FIFO_first
Function is both external and inlined: _Thread_queue_FIFO_first
Function is both external and inlined: _Thread_CPU_budget_consume_and_yield
Function is both external and inlined: _Thread_CPU_budget_consume_and_yield
Function is both external and inlined: _Thread_Join
Function is both external and inlined: _Thread_Join
Function is both external and inlined: _Thread_Set_state_locked
Function is both external and inlined: _Thread_Set_state_locked
Function is both external and inlined: _Thread_Set_state_locked
Function is both external and inlined: _Thread_Set_state_locked
Function is both external and inlined: _Timecounter_Binuptime
Function is both external and inlined: _Timecounter_Bintime
Function is both external and inlined: _Timecounter_Getboottimebin
Function is both external and inlined: _Thread_Priority_perform_actions
Function is both external and inlined: _Thread_Priority_perform_actions
Function is both external and inlined: _Thread_Clear_state_locked
Function is both external and inlined: _Thread_Clear_state_locked
Function is both external and inlined: _Thread_Clear_state_locked
Function is both external and inlined: _Thread_Clear_state_locked
Function is both external and inlined: _Malloc_System_state
Function is both external and inlined: _Malloc_System_state
Function is both external and inlined: _Malloc_System_state
Function is both external and inlined: rtems_counter_initialize_converter
Function is both external and inlined: rtems_counter_initialize_converter
Function is both external and inlined: rtems_version_minor
Function is both external and inlined: _Heap_Get_first_and_last_block
Function is both external and inlined: _Heap_Get_first_and_last_block
Error while running sparc-rtems6-objdump on
/home/yoman/RTEMS/src/rtems/build/sparc/gr712rc/testsuites/validation/ts-validation-0.exe
Objdump error in generating objdump
Coverage time: 0:00:01.085511
Coverage generating reports
Coverage analysis finished: /home/yoman/RTEMS/rtems/6/bin`

I've tried to do a fresh VM fresh RTEMS build, results are exactly the
same.
It seems like it's something to do with `objdump`? That would explain the
generated report containing only unreferenced symbols.

Any tips on what's wrong or where to start looking to try and fix it?
I wanted to generate coverage reports for the tests I developed, but not
sure if there's any other way than through making this part work.

Thanks and all the best!
Jerzy
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] microblaze: Add AXI GPIO driver

2022-03-16 Thread Alex White

On Wed, Mar 16, 2022 at 10:27 AM Gedare Bloom  wrote:
>
> On Tue, Mar 15, 2022 at 2:28 PM Alex White  wrote:
> >
> > ---
> >  bsps/include/dev/gpio/xilinx-axi-gpio.h       | 311 ++
> >  bsps/shared/dev/gpio/xilinx-axi-gpio.c        | 221 +
>
> Is this AXI GPIO interface consistent across Xilinx IP?

Hi Gedare,

Thanks for taking a look at this.

As long as the Xilinx AXI GPIO v2.0 IP is being used, this interface
should be usable across any platform.

I realize now that there is an older v1.0 AXI GPIO IP so it would be
wise to specify which version is being supported somewhere.


> > +  /*
> > +   * IP Interrupt Enable Register
> > +   *
> > +   * Provides the ability to independtly control whether interrupts for 
> > each
> typo: independently

Will fix.

>
> > +   * channel are enabled or disabled.
> > +   *
> > +   * 0 - No Channel input interrupt
> > +   * 1 - Channel input interrupt
> > +   */
> > +  uint32_t ip_ier;
> > +} xilinx_axi_gpio;
>
> This `xilinx_` is not a proper namespace for RTEMS. it doesn't
> correspond with any existing components and so it requires some
> discussion and approval to introduce it.

I used the same struct naming scheme as is used in 
bsps/include/dev/spi/xilinx-axi-spi-regs.h.

I guess this is different because it is exposed in the user-facing api?

>
> > +
> > +typedef struct {
> > +  volatile xilinx_axi_gpio *regs;
> > +  bool                      is_dual;
> > +  uint32_t                  irq;
> > +  bool                      has_interrupts;
> > +} xilinx_axi_gpio_context;
> > +
> > +/**
> > + * @brief Set pin configuration for the specified GPIO channel.
> > + *
> > + * Changes the pin configuration for a channel. Bits set to 0 are output, 
> > and
> > + * bits set to 1 are input.
> > + *
> > + * @param[in] ctx the GPIO context
> > + * @param[in] channel the GPIO channel
> > + * @param[in] mask the mask to be applied to @ channel
> > + *
> > + * @retval None
> > + */
> > +void axi_gpio_set_data_direction(
>
> neither is this `axi_`

I realize now that this makes less sense than something like
`xilinx_axi_gpio_set_data_direction` assuming the context struct name
above was accepted.

>
> > +  xilinx_axi_gpio_context *ctx,
>
> Mixing the newly proposed namespaces is also confusing.

I agree.

What would make this easiest? Should I start a new thread on Xilinx AXI
peripheral driver naming in the shared namespace?

Thanks,

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

Re: [PATCH] microblaze: Add AXI GPIO driver

2022-03-16 Thread Gedare Bloom

On Tue, Mar 15, 2022 at 2:28 PM Alex White  wrote:
>
> ---
>  bsps/include/dev/gpio/xilinx-axi-gpio.h   | 311 ++
>  bsps/shared/dev/gpio/xilinx-axi-gpio.c| 221 +

Is this AXI GPIO interface consistent across Xilinx IP?

>  .../bsps/microblaze/microblaze_fpga/obj.yml   |   2 +
>  3 files changed, 534 insertions(+)
>  create mode 100644 bsps/include/dev/gpio/xilinx-axi-gpio.h
>  create mode 100644 bsps/shared/dev/gpio/xilinx-axi-gpio.c
>
> diff --git a/bsps/include/dev/gpio/xilinx-axi-gpio.h 
> b/bsps/include/dev/gpio/xilinx-axi-gpio.h
> new file mode 100644
> index 00..dbd8748f34
> --- /dev/null
> +++ b/bsps/include/dev/gpio/xilinx-axi-gpio.h
> @@ -0,0 +1,311 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup RTEMSBSPsShared
> + *
> + * @brief Xilinx AXI GPIO definitions
> + */
> +
> +/*
> + * Copyright (C) 2022 On-Line Applications Research Corporation (OAR)
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifndef XILINX_AXI_GPIO_H
> +#define XILINX_AXI_GPIO_H
> +
> +#include 
> +#include 
> +#include 
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif /* __cplusplus */
> +
> +typedef struct {
> +  /* Channel 1 data values */
> +
> +  /*
> +   * Used to read general purpose input ports and write to general purpose
> +   * output ports from channel 1.
> +   */
> +  uint32_t gpio_data;
> +
> +  /*
> +   * The 3-state control register for channel 1 is used for the dynamic
> +   * configuration of ports as input or output. When a bit is set to 1, the
> +   * corresponding I/O port is an input port. When a bit is set to 0, it is 
> an
> +   * output port.
> +   */
> +  uint32_t gpio_tri;
> +
> +  /* Channel 2 data values */
> +
> +  /*
> +   * Used to read general purpose input ports and write to general purpose
> +   * output ports from channel 2.
> +   */
> +  uint32_t gpio2_data;
> +
> +  /*
> +   * The 3-state control register for channel 2 is used for the dynamic
> +   * configuration of ports as input or output. When a bit is set to 1, the
> +   * corresponding I/O port is an input port. When a bit is set to 0, it is 
> an
> +   * output port.
> +   */
> +  uint32_t gpio2_tri;
> +
> +  char _unused[272];
> +
> +  /* Only the 31st bit is used to enable interrupts globally */
> +  #define GLOBAL_INTERRUPT_REGISTER_ENABLE BSP_BIT32(31)
> +
> +  /*
> +   * Global Interrupt Enable Register
> +   *
> +   * Determines whether interrupts are enabled or disabled.
> +   *
> +   * 0 - Disabled
> +   * 1 - Enabled
> +   */
> +  uint32_t gier;
> +
> +  char _unused2[12];
> +
> +  /* Used with ip_isr and ip_ier member variables */
> +  #define CHANNEL_1_INTERRUPT_REGISTER BSP_BIT32(0)
> +  #define CHANNEL_2_INTERRUPT_REGISTER BSP_BIT32(1)
> +
> +  /*
> +   * IP Status Registers
> +   *
> +   * Contains the status bit for each channel.
> +   *
> +   * 0 - Disabled
> +   * 1 - Enabled
> +   */
> +  uint32_t ip_isr;
> +
> +  char _unused3[4];
> +
> +  /*
> +   * IP Interrupt Enable Register
> +   *
> +   * Provides the ability to independtly control whether interrupts for each
typo: independently

> +   * channel are enabled or disabled.
> +   *
> +   * 0 - No Channel input interrupt
> +   * 1 - Channel input interrupt
> +   */
> +  uint32_t ip_ier;
> +} xilinx_axi_gpio;

This `xilinx_` is not a proper namespace for RTEMS. it doesn't
correspond with any existing components and so it requires some
discussion and approval to introduce it.

> +
> +typedef struct {
> +  volatile xilinx_axi_gpio *regs;
> +  bool  is_dual;
> +  uint32_t  irq;
> +  bool  has_interrupts;
>

nfsclient rtems6 rtems-libbsd

2022-03-16 Thread Heinz Junkes

Hello,

I am trying the nfs-client with rtems6 and rtems-libbsd.
(on BSP “beatnik”)

I have not analyzed everything yet.
I just wanted to ask if, and how, someone has already managed it?

When I call mount_and_make_target_path().

rval = mount_and_make_target_path(dev, mntpoint,
  RTEMS_FILESYSTEM_TYPE_NFS, RTEMS_FILESYSTEM_READ_WRITE,
  mount_options);

and take as mount_options "nfsv2" comes this:

Mount 141.14.131.192:/Volume on /Volume
nfs: mount: nfs -> 141.14.131.192:/Volume (nfsv2)
nfs: mount: [tcp] 141.14.131.192:/Volume: RPCPROG_NFS: RPC: Port mapper failure 
- RPC: Server can't decode arguments

as mount_options "nfs3" comes that:

Mount 141.14.131.192:/Volume on /Volume
nfs: mount: nfs -> 141.14.131.192:/Volume (nfsv3)
nfs: mount: [tcp] 141.14.131.192:/Volume: RPCPROG_NFS: RPC: Port mapper failure 
- RPC: Server can't decode arguments
mount: 5: I/O error

as mount_options "nfsv4,minorversion=1" comes that:

Mount 141.14.131.192:/Volume on /Volume
nfs: mount: nfs -> 141.14.131.192:/Volume (nfsv4,minorversion=1)
nfs: mount args: 8
  16 addr=10 02 08 01 8d 0e 83 c0 00 00 00 00 00 00 00 00
   0 nfsv4
   8 dirpath=/Volume
   4 fstype=nfs
   7 fspath=Volume
  23 hostname=141.14.131.192:/Volume
   0 rw
   2 minorversion=1
nfs: mount: (2) No such file or directory
mount: 2: No such file or directory

Is it generally the case that the nfs cannot mount a subdir with the 
rtems-libbsd?
i.e.
Mount 141.14.131.192:/Volumes/Epics on /Volumes/Epics

Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.



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

Re: [PATCH] microblaze: Add AXI GPIO driver

2022-03-16 Thread Sebastian Huber


Hello Alex,

maybe someone from OAR should step in as a microblaze maintainer.

--
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: Update to Binutils 2.38

2022-03-16 Thread Sebastian Huber


On 13/03/2022 19:24, Joel Sherrill wrote:



On Sun, Mar 13, 2022, 12:56 PM Sebastian Huber 
> wrote:


On 12/03/2022 18:29, Joel Sherrill wrote:
 > Any news on the PowerPC build failures introduced?
 >
 > https://lists.rtems.org/pipermail/build/2022-March/032357.html

 > >

The fixes are on the GCC main branch since yesterday. I need permission
to back port them to GCC 10 and 11.


Ok. Just checking in on this.


One of the maintainer will back port the fixes:

https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591813.html

--
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

AW: Dependencies of PPS API in rtems-libbsd

2022-03-16 Thread Gabriel.Moyano

Hello Sebastian,

> On 15/03/2022 16:31, gabriel.moy...@dlr.de wrote:
> > I'm working on enabling PPS support in RTEMS
> 
> does this mean you want to define PPS_SYNC for kern_tc.c and kern_ntptime.c 
> in RTEMS?

yes

> I guess you want to enable tc_poll_pps in struct timecounter as well?

I didn't plan to do that but it can be done just removing some #ifndef, right? 

> For what do you need the sleep() and wakeup() support? Is this only used by 
> the RFC 2783 PPS-API implementation?

Yes, they are required by pps_fetch() and pps_event()

> If you want to keep implement this in RTEMS, then you can convert this to use 
> a condition variable from  or
> .

Do you mean to add a condition variable, for example in struct pps_state, and 
to replace sleep() and wakeup() by wait and signal? It is good idea if we don't 
want to use the first functions.

> All the uses of sleep() and wakeup() need to be clearly identified and if 
> possible avoided.

May I ask, what is the reason for avoiding them?

What do you think about coping the functions lmax()/qmin() and the define for 
ENOIOCTL? For lmax()/qmin() I saw that the file where are defined (libkern.h) 
is in libnetworking. Not sure what it is the best option here, I don't like 
when the things are duplicated.

What about tvtohz(), which is defined in 
rtemsbsd/rtems/rtems-kernel-timesupport.c?

Best regards,
Gabriel

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

Re: Movement of confdefs instance into a static library

RE: Support for test coverage analysis in RTEMS 6

Movement of confdefs instance into a static library

Re: Support for test coverage analysis in RTEMS 6

GSoC-2022 Introduction

RE: Support for test coverage analysis in RTEMS 6

Support for test coverage analysis in RTEMS 6

Re: [PATCH] microblaze: Add AXI GPIO driver

Re: [PATCH] microblaze: Add AXI GPIO driver

nfsclient rtems6 rtems-libbsd

Re: [PATCH] microblaze: Add AXI GPIO driver

Re: Update to Binutils 2.38

AW: Dependencies of PPS API in rtems-libbsd

13 matches

Site Navigation

Mail list logo

Footer information