Re: Review Request for DCAN patches

[Prashanth S]

Hi Christian,

I squashed the commits and pushed to the same branch.
https://gitlab.com/slpp95prashanth/gsoc-2022/-/tree/can-dev-squashed1

Regards
Prashanth S


On Wed, 26 Oct, 2022, 10:56 pm ,  wrote:

> Hello Prashanth,
>
> from my point of view the patches look good and I think you processed
> Gedares feedback too. So if no one objects I'll pus the patches on the
> weekend.
>
> Last version is this one:
>
>
> https://gitlab.com/slpp95prashanth/gsoc-2022/-/commits/30199c2af1c65f05f820a/
>
> Like discussed in Discord, it would be good to squash the canqueueimpl.h
> into the CAN support. Either you can do that or I'll do it right before
> pushing.
>
> Best regards
>
> Christian
>
> Am 16.10.22 um 19:12 schrieb Prashanth S:
> > Hi All,
> >
> > This is a review request for the DCAN patch, I have updated the files
> > based on review comments.
> > Attaching the patch as a zip file.
> >
> > Regards
> > Prashanth S
> >
> > ___
> > 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: Review Request for DCAN patches

[oss]

Hello Prashanth,

from my point of view the patches look good and I think you processed 
Gedares feedback too. So if no one objects I'll pus the patches on the 
weekend.


Last version is this one:

https://gitlab.com/slpp95prashanth/gsoc-2022/-/commits/30199c2af1c65f05f820a/

Like discussed in Discord, it would be good to squash the canqueueimpl.h 
into the CAN support. Either you can do that or I'll do it right before 
pushing.


Best regards

Christian

Am 16.10.22 um 19:12 schrieb Prashanth S:

Hi All,

This is a review request for the DCAN patch, I have updated the files 
based on review comments.

Attaching the patch as a zip file.

Regards
Prashanth S

___
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: Increase Frequency of Updates of RTEMS GitHub Tools Mirroring

[Christian MAUDERER]

Am 26.10.22 um 01:06 schrieb Chris Johns:

On 26/10/2022 4:46 am, Joel Sherrill wrote:

 In general, our current approach is quite a hack. We should do things
 more event driven. For example, if you want to update the RSB, then you
 create a pull request. This pull request starts a CI script which
 updates the mirrors and builds the RSB on a selected set of platforms.
 If everything is all right, the pull request can be merged.

Just getting to the point where a pull request triggered an update would
be useful. Assuming a pull request with no content would be ok.


I feel starting to have pull requests will only result in changes being posted
there by users who see pull requests as active. It is reasonable for a user to
think this. Who will then field those and merge them?

Chris


Hello Chris,

I agree that as long as the RTEMS project doesn't officially use pull 
requests, it's not a good idea to have something that looks official but 
isn't used. On the other hand, I think that it would be a really good 
idea for the RTEMS project to migrate to a patch management system where 
a pull-request with automated CI run is the official method for 
contributing. That would take a lot of work from the shoulders of the 
maintainers because for a lot of patches, no more manual tests whether 
the patch builds would be necessary. Of course the patch would still 
need review.


Beneath that, a system with pull requests usually has a nice overview 
over pending patches. At the moment we have patches on the mailing list 
mixed with discussions. A user has to get the attention of a maintainer 
to get a patch merged. Users that don't want to be pushy maybe don't 
ping such patches or some might just forget that they send a patch to 
the list. I'm sure that we lost quite a few patches due to that because 
no one felt responsible, no one noted the patch or no one had the time 
to test the patches before merging them.


I know that I have even lost some of my own patches on the list because 
no one acknoledged them and I started to work on something else and 
forget them. I found some a few months later and was surprised that I 
didn't push them. I wouldn't guarantee that I found all of them. A patch 
management system should help to see whether there are still open ones.


PS: I already mentioned it in another mail: I started to build some 
github CI scripts that we at embedded brains want to use for testing our 
own public patches. Github doesn't seem to limit the CI time on public 
projects so everyone who wants to play a bit with it: Feel free to 
create pull requests to see how something like that works. Just select 
the "ci" branch on


  https://github.com/embedded-brains/rtems

That repo is clearly a fork (marked with "forked from RTEMS/rtems" so I 
don't see the risk that someone mixes it up with the official repos. But 
if unknown users will use it to create pull requests, I'll add a comment 
to the pull requests, that patches should be sent to the mailing list 
instead. If there are a lot of unknown users, I'll automate the comments.


Best regards

Christian
--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email:  christian.maude...@embedded-brains.de
phone:  +49-89-18 94 741 - 18
mobile: +49-176-152 206 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 2/2] user: Add documentation for leon2 and leon3 BSP

[Daniel Cederman]

---
 user/bsps/bsps-sparc.rst | 74 ++--
 1 file changed, 72 insertions(+), 2 deletions(-)

diff --git a/user/bsps/bsps-sparc.rst b/user/bsps/bsps-sparc.rst
index d0316a9..a2c2a47 100644
--- a/user/bsps/bsps-sparc.rst
+++ b/user/bsps/bsps-sparc.rst
@@ -20,11 +20,81 @@ TODO.
 leon2
 =
 
-TODO.
+This BSP supports LEON2 systems, in particular the `Microchip AT697F
+`_. The following
+default build configurations are provided:
+
+* leon2 - A generic LEON2 system with memory at 0x400.
+
+* at697f - For the AT697F. Built with ``-mcpu=leon3 -mfix-ut700``.
+
+The BSP contains UART, timer, and interrupt controller drivers.
+Drivers for PCI are available through the :ref:`driver manager 
`.
 
 .. _BSP_sparc_leon3:
 
 leon3
 =
 
-TODO.
+This BSP supports the LEON3/4/5 systems from Cobham Gaisler.
+The following default build configurations are provided:
+
+* leon3 - A generic `LEON3/4/5 `_ system with 
memory at 0x400.
+
+* ut700 - For the `UT700 `_. Built with 
``-mcpu=leon3 -mfix-ut700``.
+
+* ut699 - For the `UT699 `_. Built with 
``-mcpu=leon -mfix-ut699``.
+
+* gr712rc - For the `GR712RC `_. Built with 
``-mcpu=leon3 -mfix-gr712rc``.
+
+* gr740 - For the `GR740  `_. Memory located at 
address 0x0.
+
+The BSP contains UART, timer, and interrupt controller drivers. Drivers for 
additional
+peripherals are available through the driver manager.
+
+.. _BSP_sparc_leon3_drv_mgr:
+
+Driver Manager
+--
+
+The leon3 BSP includes an optional driver manager that handles drivers and
+devices on the AMBA and PCI Plug & Play buses. The driver manager can either
+be initialized manually by the user, or started automatically on startup by
+setting the ``RTEMS_DRVMGR_STARTUP`` option. It can be configured to
+automatically instantiate a driver for each hardware device found.
+
+Drivers for the following devices are provided and handled via the driver 
manager:
+
+* SpaceWire (GRSPW, GRSPW2)
+* SpaceWire Router (GRSPWROUTER)
+* SpaceWire Time Distribution Protocol (SPWTDP)
+* CAN - non-DMA (OCCAN) and DMA (GRCAN, GRCANFD)
+- GPIO (GRGPIO)
+- L2 Cache (L2CACHE)
+- IOMMU (GRIOMMU)
+- ADC/DAC (GRADCDAC)
+- Timers (GPTIMER, GRTIMER)
+- 1553 BC, RT and BM support (GR1553B)
+- I2C Master (I2CMST)
+- PCI (GRPCI2, GRPCI, PCIF)
+- Memory Controller (MCTRL)
+- Memory Scrubber (MEMSCRUB)
+- Pulse Width Modulation Generator (GRPWM)
+- CCSDS/ECSS Telemetry Encoder/Decoder (GRTM/GRTC)
+- CSDS Time Manager (GRCTM)
+- Ethernet (GRETH 10/100/1000) (requires network stack)
+- Performance counters (L4STAT)
+- Serial Peripheral Interface (AHBSTAT)
+- AHB Status (AHBSTAT)
+
+Build Configuration Options
+---
+
+The following options can be used in the BSP section of the ``waf``
+configuration INI file. The ``waf`` defaults can be used to inspect the values.
+
+``CONSOLE_USE_INTERRUPTS``
+ Use the Termios interrupt mode in the console driver (false by default).
+
+``RTEMS_DRVMGR_STARTUP``
+ Enable the Driver Manager at startup (false by default).
-- 
2.34.1

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

[PATCH 1/2] user: Add documentation for NOEL-V BSP

[Daniel Cederman]

---
 user/bsps/bsps-riscv.rst | 57 
 1 file changed, 57 insertions(+)

diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rst
index 48e7ee7..73a6038 100644
--- a/user/bsps/bsps-riscv.rst
+++ b/user/bsps/bsps-riscv.rst
@@ -248,6 +248,63 @@ Serial terminal UART1 displays the SMP example messages
 
 *** END OF TEST SMP 1 ***
 
+noel
+
+
+This BSP supports the `NOEL-V `_ systems from 
Cobham
+Gaisler. The NOEL-V is a synthesizable VHDL model of a processor that
+implements the RISC-V architecture. It is part of the open source
+`GRLIB `_ IP Library. The following BSP
+variants correspond to common NOEL-V configurations:
+
+* noel32im
+
+* noel32imafd
+
+* noel64imac
+
+* noel64imafd
+
+* noel64imafdc
+
+The start of the memory is set to 0x0 to match a standard NOEL-V system,
+but can be changed using the ``RISCV_RAM_REGION_BEGIN`` configuration
+option. The size of the memory is taken from the information available
+in the device tree.
+
+Reference Designs
+-
+
+The BSP has been tested with NOEL-V reference designs for
+`Digilent Arty A7 `_,
+`Microchip PolarFire Splash Kit `_,
+and `Xilinx KCU105 `_.
+See the accompanying quickstart guide for each reference design
+to determine which BSP configuration to use.
+
+Build Configuration Options
+---
+
+The following options can be used in the BSP section of the ``waf``
+configuration INI file. The ``waf`` defaults can be used to inspect the values.
+
+``BSP_CONSOLE_USE_INTERRUPTS``
+ Use the Termios interrupt mode in the console driver (true by default).
+
+``BSP_FDT_BLOB_SIZE_MAX``
+The maximum size of the device tree blob in bytes (262144 by default).
+
+``RISCV_CONSOLE_MAX_APBUART_DEVICES``
+ The maximum number of APBUART devices supported by the console driver
+ (2 by default).
+
+``RISCV_RAM_REGION_BEGIN``
+ The begin of the RAM region for linker command file (0x0 by default).
+
+``RISCV_MAXIMUM_EXTERNAL_INTERRUPTS``
+ The maximum number of external interrupts supported by the BSP (64 by
+ default).
+
 griscv
 ==
 
-- 
2.34.1

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

[PATCH] bsps/riscv: RISCV_MAXIMUM_EXTERNAL_INTERRUPTS

[Sebastian Huber]

Increase RISCV_MAXIMUM_EXTERNAL_INTERRUPTS to 128 to support recent Qemu
versions by default.
---
 spec/build/bsps/riscv/optextirqmax.yml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/spec/build/bsps/riscv/optextirqmax.yml 
b/spec/build/bsps/riscv/optextirqmax.yml
index 84dbbb7705..20b05b4aaf 100644
--- a/spec/build/bsps/riscv/optextirqmax.yml
+++ b/spec/build/bsps/riscv/optextirqmax.yml
@@ -5,13 +5,13 @@ actions:
 build-type: option
 copyrights:
 - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
-default: 64
+default: 128
 default-by-variant:
 - value: 187
   variants:
   - riscv/mpfs64.*
 description: |
-  maximum number of external interrupts supported by the BSP (default 64)
+  maximum number of external interrupts supported by the BSP (default 128)
 enabled-by: true
 format: '{}'
 links: []
-- 
2.35.3

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

Re: [PATCH] bsps/arm: fix Cortex-M7 systick reload value

[Sebastian Huber]

Hello Dariusz,

thanks for the fix. I added a ticket and checked it in. We definitely 
have to improve our clock driver validation tests. We will add a ticket 
for this.


Kind regards,
Sebastian

--
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] bsps/arm: fix Cortex-M7 systick reload value

[Dariusz Sabała]

>From e17fb5abf82d03baf25ee16433c9d6e9861e3e3a Mon Sep 17 00:00:00 2001
From: Dariusz Sabala 
Date: Tue, 25 Oct 2022 11:11:20 +0200
Subject: [PATCH] bsps/arm: fix Cortex-M7 systick reload value

- see ARM DUI 0646C Arm Cortex-M7 Devices Generic User Guide
  "The RELOAD value is calculated according to its use.
  For example, to generate a multi-shot timer with a period
  of N processor clock cycles, use a RELOAD value of N-1.
  If the SysTick interrupt is required every 100 clock pulses,
  set RELOAD to 99."
- see routines used in CMSIS project for reference
---
 bsps/arm/shared/clock/clock-armv7m.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsps/arm/shared/clock/clock-armv7m.c 
b/bsps/arm/shared/clock/clock-armv7m.c
index 255de1ca42..c870684980 100644
--- a/bsps/arm/shared/clock/clock-armv7m.c
+++ b/bsps/arm/shared/clock/clock-armv7m.c
@@ -90,7 +90,7 @@ static void _ARMV7M_Clock_initialize_early(void)

   interval = (uint32_t) ((freq * us_per_tick) / 100);

-  systick->rvr = interval;
+  systick->rvr = interval - 1;
   systick->cvr = 0;
   systick->csr = ARMV7M_SYSTICK_CSR_ENABLE | ARMV7M_SYSTICK_CSR_CLKSOURCE;
 }
--
2.34.1

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