Re: Libbsd situation.

[Sebastian Huber]

Hello Karel,

On 17.07.23 13:12, Karel Gardas wrote:


   Hello,

if I'm right than RTEMS 6 should be accompanied with libbsd from 
6-freebsd-12 branch which should be based on freebsd-12 (stable/12 
branch). Please correct me if I'm wrong here.


If I'm right above, then there are few things which worries me a bit:

(1) FreeBSD's 12 branch is going to be EoLed soon, e.g. December 31, 
2023 as claimed on https://www.freebsd.org/security/#sup


(2) 6-freebsd-12 branch latest commit in freebsd-org is from Feb 9 
22:15:35 2020. Based on that it looks like 6-freebsd-12 branch is >6k 
commits behind the FreeBSD's stable/12 branch.


May this outage be solved by using libbsd master branch? It does not 
look like as:


(i) latest commit in freebsd-org in libbsd master branch is even older 
than in 6-freebsd-12 and it is from Sep 24 01:58:54 2019.


(ii) even if I consider Sebastian's own master-update branch available 
on his github.com account, it seem this branch synced with what is in 
6-freebsd-12 and ends exactly on 2020-02-09. So, it looks like master is 
also missing few thousands patches from FreeBSD development...


Anyway, my biggest worry is that RTEMS 6 libbsd may be based on source 
code which will lose upstream project support soon after the RTEMS 6 
release (assuming RTEMS 6 will happen before Dec 31 2023). So I'm 
curious if with all those outdatnes it would not be good to jump and 
update master which would be supported by another 5 years (assuming this 
is stable/14 branch).
E.g. the situation is exactly like with GCC where Sebastian clearly 
warned about it and project moved from 10 to 12 and now it looks like we 
will even move to GCC 13 release for RTEMS 6... Except that in case of 
libbsd it has not happened yet.


Am I missing something or is this really a situation with libbsd as of 
today?


your assessment is unfortunately correct. I made some attempts to update 
libbsd, but other maintainers disagreed with my approach. We have 
internal plans to rework the libbsd to be able to synchronize more 
easily with the FreeBSD upstream. The current infrastructure in libbsd 
was set up to work with Subversion. With Git we have now much better 
capabilities.


--
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] score: Move _IO_Relax() to new

[Sebastian Huber]

This function is not a super core service.
---
 bsps/shared/grlib/uart/apbuart_polled.c |  2 +-
 cpukit/{score/src => dev}/iorelax.c |  4 +-
 cpukit/include/rtems/dev/io.h   | 68 +
 cpukit/include/rtems/score/io.h |  8 ---
 spec/build/cpukit/librtemscpu.yml   |  4 +-
 5 files changed, 73 insertions(+), 13 deletions(-)
 rename cpukit/{score/src => dev}/iorelax.c (97%)
 create mode 100644 cpukit/include/rtems/dev/io.h

diff --git a/bsps/shared/grlib/uart/apbuart_polled.c 
b/bsps/shared/grlib/uart/apbuart_polled.c
index f3e4997a12..84c31795df 100644
--- a/bsps/shared/grlib/uart/apbuart_polled.c
+++ b/bsps/shared/grlib/uart/apbuart_polled.c
@@ -38,7 +38,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 void apbuart_outbyte_wait( const apbuart *regs )
 {
diff --git a/cpukit/score/src/iorelax.c b/cpukit/dev/iorelax.c
similarity index 97%
rename from cpukit/score/src/iorelax.c
rename to cpukit/dev/iorelax.c
index 1b155377a9..5fdefac151 100644
--- a/cpukit/score/src/iorelax.c
+++ b/cpukit/dev/iorelax.c
@@ -3,7 +3,7 @@
 /**
  * @file
  *
- * @ingroup RTEMSScoreIO
+ * @ingroup RTEMSDeviceIO
  *
  * @brief This source file contains the implementation of _IO_Relax().
  */
@@ -37,7 +37,7 @@
 #include "config.h"
 #endif
 
-#include 
+#include 
 #include 
 
 void _IO_Relax( void )
diff --git a/cpukit/include/rtems/dev/io.h b/cpukit/include/rtems/dev/io.h
new file mode 100644
index 00..b3f59eae30
--- /dev/null
+++ b/cpukit/include/rtems/dev/io.h
@@ -0,0 +1,68 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSDeviceIO
+ *
+ * @brief This header file provides the interfaces of the
+ *   @ref RTEMSDeviceIO.
+ */
+
+/*
+ * Copyright (C) 2021 embedded brains GmbH & Co. KG
+ *
+ * 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 _RTEMS_DEV_IO_H
+#define _RTEMS_DEV_IO_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+/**
+ * @defgroup RTEMSDeviceIO Device I/O Support
+ *
+ * @ingroup RTEMSDeviceDrivers
+ *
+ * @brief This group contains the Device I/O Support API and implementation.
+ *
+ * @{
+ */
+
+/**
+ * @brief Issues a couple of no-operation instructions.
+ *
+ * This function may be used to burn a couple of processor cycles with minimum
+ * impact on the system bus.  It may be used in busy wait loops.
+ */
+void _IO_Relax( void );
+
+/** @} */ 
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* _RTEMS_DEV_IO_H */
diff --git a/cpukit/include/rtems/score/io.h b/cpukit/include/rtems/score/io.h
index 9cd401eb1d..7fe69841e8 100644
--- a/cpukit/include/rtems/score/io.h
+++ b/cpukit/include/rtems/score/io.h
@@ -133,14 +133,6 @@ int _IO_Base64url(
   int  wordlen
 );
 
-/**
- * @brief Issues a couple of no-operation instructions.
- *
- * This function may be used to burn a couple of processor cycles with minimum
- * impact on the system bus.  It may be used in busy wait loops.
- */
-void _IO_Relax( void );
-
 /** @} */ 
 
 #ifdef __cplusplus
diff --git a/spec/build/cpukit/librtemscpu.yml 
b/spec/build/cpukit/librtemscpu.yml
index 3654e7f94a..d556c95bc8 100644
--- a/spec/build/cpukit/librtemscpu.yml
+++ b/spec/build/cpukit/librtemscpu.yml
@@ -528,6 +528,7 @@ source:
 - cpukit/compression/xz/xz_crc32.c
 - cpukit/compression/xz/xz_dec_lzma2.c
 - cpukit/compression/xz/xz_dec_stream.c
+- cpukit/dev/can/can.c
 - cpukit/dev/flash/flashdev.c
 - cpukit/dev/i2c/eeprom.c
 - cpukit/dev/i2c/fpga-i2c-slave.c
@@ -540,10 +541,10 @@ source:
 - cpukit/dev/i2c/ti-lm25066a.c
 - cpukit/dev/i2c/ti-tmp112.c
 - cpukit/dev/i2c/xilinx-axi-i2c.c
+- cpukit/dev/iorelax.c
 - cpukit/dev/serial/sc16is752-spi.c
 - cpukit/dev/serial/sc16is752.c
 - cpukit/dev/spi/spi-bus.c

[PATCH rtems-docs] user: Update @rtems-ver-major@ to use sphinx substitution extention

[Muhammad Sulthan Mazaya]

 Using sphinx-substitution-extensions to manage the variable @rtems-ver-major@. 
 Originally Utkarsh's idea: 
 
https://discord.com/channels/82045382112799/82045848335924/1118416996606943302
 
 I have tested and built the docs to see if it works and it does 
 subtitute the variable. The changes are: the variable @rtems-ver-major@ 
 is now |rtems-ver-major|. For inline code block we use 
 :substitution-code:`{content}` and for multiline code block we use:

 .. code-block:: {language}
   :substitutions:
   
   {content}

---
 user/bsps/aarch64/raspberrypi4.rst  |  3 +-
 user/bsps/aarch64/xilinx-zynqmp.rst |  3 +-
 user/bsps/arm/altera-cyclone-v.rst  |  3 +-
 user/bsps/arm/beagle.rst|  3 +-
 user/bsps/arm/imx.rst   |  3 +-
 user/bsps/arm/imxrt.rst |  9 ++--
 user/bsps/arm/raspberrypi.rst   |  6 ++-
 user/bsps/arm/xen.rst   |  6 ++-
 user/bsps/bsps-microblaze.rst   |  6 ++-
 user/bsps/bsps-powerpc.rst  | 10 ++--
 user/bsps/bsps-riscv.rst| 12 +++--
 user/conf.py|  6 +++
 user/deployment/index.rst   | 71 ++
 user/exe/initialization.rst | 13 ++---
 user/exe/loader.rst | 15 +++---
 user/installation/developer.rst |  9 ++--
 user/installation/releases.rst  |  6 ++-
 user/start/app.rst  | 60 --
 user/start/bsp-build.rst| 79 -
 19 files changed, 185 insertions(+), 138 deletions(-)

diff --git a/user/bsps/aarch64/raspberrypi4.rst 
b/user/bsps/aarch64/raspberrypi4.rst
index efb09b6..616cc3f 100644
--- a/user/bsps/aarch64/raspberrypi4.rst
+++ b/user/bsps/aarch64/raspberrypi4.rst
@@ -79,8 +79,9 @@ can be processed in a similar way.
 To create the kernel image:
 
 .. code-block:: shell
+   :substitutions:
 
-  $ aarch64-rtems@rtems-ver-major@-objcopy -Obinary hello.exe kernel8.img
+  $ aarch64-rtems|rtems-ver-major|-objcopy -Obinary hello.exe kernel8.img
 
 Copy the kernel image to the SD card.
 
diff --git a/user/bsps/aarch64/xilinx-zynqmp.rst 
b/user/bsps/aarch64/xilinx-zynqmp.rst
index 4de0115..255628a 100644
--- a/user/bsps/aarch64/xilinx-zynqmp.rst
+++ b/user/bsps/aarch64/xilinx-zynqmp.rst
@@ -143,8 +143,9 @@ Prepare the RTEMS image
 Prepare your RTEMS image to boot from u-boot with the following commands:
 
 .. code-block:: shell
+   :substitutions:
 
-  $ aarch64-rtems@rtems-ver-major@-objcopy -Obinary ticker.exe ticker.bin
+  $ aarch64-rtems|rtems-ver-major|-objcopy -Obinary ticker.exe ticker.bin
   $ gzip -9 ticker.bin
   $ mkimage -A arm64 -O rtems -T kernel -a 0x1000 -e 0x1000 -n RTEMS 
-d ticker.bin.gz rtems.img
 
diff --git a/user/bsps/arm/altera-cyclone-v.rst 
b/user/bsps/arm/altera-cyclone-v.rst
index 12e563e..5aaa841 100644
--- a/user/bsps/arm/altera-cyclone-v.rst
+++ b/user/bsps/arm/altera-cyclone-v.rst
@@ -26,8 +26,9 @@ The application executable file (ELF file) must be converted 
to an U-Boot
 image.  Use the following commands:
 
 .. code-block:: none
+   :substitutions:
 
-arm-rtems@rtems-ver-major@-objcopy -O binary app.exe app.bin
+arm-rtems|rtems-ver-major|-objcopy -O binary app.exe app.bin
 gzip -9 -f -c app.bin > app.bin.gz
 mkimage -A arm -O linux -T kernel -a 0x0030 -e 0x0030 -n RTEMS -d 
app.bin.gz app.img
 
diff --git a/user/bsps/arm/beagle.rst b/user/bsps/arm/beagle.rst
index 55f75c0..9da18e8 100644
--- a/user/bsps/arm/beagle.rst
+++ b/user/bsps/arm/beagle.rst
@@ -31,8 +31,9 @@ Boot via U-Boot
 To boot via uboot, the ELF must be converted to a U-Boot image like below:
 
 .. code-block:: none
+   :substitutions:
 
-arm-rtems@rtems-ver-major@-objcopy hello.exe -O binary app.bin
+arm-rtems|rtems-ver-major|-objcopy hello.exe -O binary app.bin
 gzip -9 app.bin
 mkimage -A arm -O linux -T kernel -a 0x8000 -e 0x8000 -n RTEMS -d 
app.bin.gz rtems-app.img
 
diff --git a/user/bsps/arm/imx.rst b/user/bsps/arm/imx.rst
index 47ad503..6c8cf49 100644
--- a/user/bsps/arm/imx.rst
+++ b/user/bsps/arm/imx.rst
@@ -74,8 +74,9 @@ The application executable file (ELF file) must be converted 
to an U-Boot
 image.  Use the following commands:
 
 .. code-block:: none
+   :substitutions:
 
-arm-rtems@rtems-ver-major@-objcopy -O binary app.exe app.bin
+arm-rtems|rtems-ver-major|-objcopy -O binary app.exe app.bin
 gzip -9 -f -c app.bin > app.bin.gz
 mkimage -A arm -O linux -T kernel -a 0x8020 -e 0x8020 -n RTEMS -d 
app.bin.gz app.img
 
diff --git a/user/bsps/arm/imxrt.rst b/user/bsps/arm/imxrt.rst
index 3df233f..4af603b 100644
--- a/user/bsps/arm/imxrt.rst
+++ b/user/bsps/arm/imxrt.rst
@@ -39,7 +39,7 @@ For programming the HyperFlash in case 1, you can use the on 
board debugger
 integrated into the IMXRT1050-EVKB. You can generate a flash image out of a
 compiled RTEMS application with for example::
 
-  arm-rtems@rtems-ver-major@-objcopy -O binary 
build/arm/imxrt1052/testsuites/samples/hello.exe

Re: Building leon3 prom image for testing on renode

[Alan Cudmore]

Hi Mazaya,
I wonder if it is possible to initialize the processor to the state where
it can run the RTEMS image in RAM without using the prom image? The
processor initialization would have to go in the resc script before the
image is loaded and started.
Also, as you mentioned, the renode Zephyr example runs directly from RAM
without a prom image. Is it that the RTEMS LEON3 BSP relies on
initialization done by the boot prom (GRMON or MKPROM2 based boot code)?
https://github.com/renode/renode/blob/master/scripts/single-node/leon3_zephyr.resc

I guess it ends up being a trade off of tooling vs. trying to program the
necessary initialization in the resc script.

Regards,
Alan

On Tue, Jul 18, 2023 at 2:46 AM Muhammad Sulthan Mazaya <
msulthanmaz...@gmail.com> wrote:

> Hi,
>
> I was trying to implement renode for testing leon3 using rtems-test. I
> noticed that from the example they provide
> https://github.com/antmicro/renode-rtems-leon3/blob/main/leon3_rtems.resc,
> it seems like the renode simulator needs the prom image of leon3 to do so.
> I don't think an additional build step before testing a particular bsp is
> something supported by the build config of rtems-tools + my mentors also
> said it shouldn't be on the rtems-tools. Is it okay to have RSB build that
> for us as part of the BSP?
>
> Thank you,
> Mazaya
> ___
> 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

HEADS UP: git repo WRONG push landed.

[Karel Gardas]

  Folks,

I've completely screwed up and pushed wrong repository to the git.rtems.org.

I don't know how that happen as this should land on github.com...

So please do not commit anything for now, I'll try to lookup help on 
discord.com and see what can be done to unpush...


Thanks and really sorry for this mess...

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

Re: HEADS UP: git repo WRONG push landed.

[Sebastian Huber]

On 18.07.23 15:40, Karel Gardas wrote:


   Folks,

I've completely screwed up and pushed wrong repository to the 
git.rtems.org.


I don't know how that happen as this should land on github.com...


Maybe check your configuration for this option:

https://git-scm.com/docs/git-config#Documentation/git-config.txt-pushdefault



So please do not commit anything for now, I'll try to lookup help on 
discord.com and see what can be done to unpush...


Thanks and really sorry for this mess...


Don't worry, you are not the first one causing such an issue ;-)

I think we should revert the history on the master with a forced push.

--
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: HEADS UP: git repo WRONG push landed.

[Karel Gardas]

Follow-up:

Amar decided to fix that properly. It'll take some time for which I 
personally apologize and thank you Amar for dealing with this!


Thanks,
Karel

On 7/18/23 15:40, Karel Gardas wrote:


   Folks,

I've completely screwed up and pushed wrong repository to the 
git.rtems.org.


I don't know how that happen as this should land on github.com...

So please do not commit anything for now, I'll try to lookup help on 
discord.com and see what can be done to unpush...


Thanks and really sorry for this mess...

Karel
___
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 rtems-net-legacy] powerpc/beatnik: Add mv643xx_eth.c driver from RTEMS 5

[Vijay Kumar Banerjee]

---
 bsp_drivers.py|2 +
 bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c | 3318 +
 2 files changed, 3320 insertions(+)
 create mode 100644 bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c

diff --git a/bsp_drivers.py b/bsp_drivers.py
index e2250aa..5628ff3 100644
--- a/bsp_drivers.py
+++ b/bsp_drivers.py
@@ -79,6 +79,7 @@ include = {
 'bsps/powerpc/beatnik/net',
 'bsps/powerpc/beatnik/net/if_em',
 'bsps/powerpc/beatnik/net/if_gfe',
+'bsps/powerpc/beatnik/net/if_mve',
 'bsps/powerpc/beatnik/net/porting',
 ],
 'powerpc/mpc8260ads': [
@@ -174,6 +175,7 @@ source = {
 'bsps/powerpc/beatnik/net/if_em/if_em_rtems.c',
 'bsps/powerpc/beatnik/net/if_gfe/if_gfe.c',
 'bsps/powerpc/beatnik/net/if_gfe/if_gfe_rtems.c',
+'bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c',
 'bsps/powerpc/beatnik/net/porting/if_xxx_rtems.c',
 'bsps/powerpc/beatnik/net/support/bsp_attach.c',
 'bsps/powerpc/beatnik/net/support/early_link_status.c',
diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c 
b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
new file mode 100644
index 000..85ab038
--- /dev/null
+++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
@@ -0,0 +1,3318 @@
+/* RTEMS driver for the mv643xx gigabit ethernet chip */
+
+/* Acknowledgement:
+ *
+ * Valuable information for developing this driver was obtained
+ * from the linux open-source driver mv643xx_eth.c which was written
+ * by the following people and organizations:
+ *
+ * Matthew Dharm 
+ * rab...@galileo.co.il
+ * PMC-Sierra, Inc., Manish Lachwani
+ * Ralf Baechle 
+ * MontaVista Software, Inc., Dale Farnsworth 
+ * Steven J. Hill /
+ *
+ * Note however, that in spite of the identical name of this file
+ * (and some of the symbols used herein) this file provides a
+ * new implementation and is the original work by the author.
+ */
+
+/* 
+ * Authorship
+ * --
+ * This software (mv643xx ethernet driver for RTEMS) was
+ * created by Till Straumann , 2005-2007,
+ *Stanford Linear Accelerator Center, Stanford University.
+ * 
+ * Acknowledgement of sponsorship
+ * --
+ * The 'mv643xx ethernet driver for RTEMS' was produced by
+ * the Stanford Linear Accelerator Center, Stanford University,
+ *under Contract DE-AC03-76SFO0515 with the Department of Energy.
+ * 
+ * Government disclaimer of liability
+ * --
+ * Neither the United States nor the United States Department of Energy,
+ * nor any of their employees, makes any warranty, express or implied, or
+ * assumes any legal liability or responsibility for the accuracy,
+ * completeness, or usefulness of any data, apparatus, product, or process
+ * disclosed, or represents that its use would not infringe privately owned
+ * rights.
+ * 
+ * Stanford disclaimer of liability
+ * 
+ * Stanford University makes no representations or warranties, express or
+ * implied, nor assumes any liability for the use of this software.
+ * 
+ * Stanford disclaimer of copyright
+ * 
+ * Stanford University, owner of the copyright, hereby disclaims its
+ * copyright and all other rights in this software.  Hence, anyone may
+ * freely use it for any purpose without restriction.  
+ * 
+ * Maintenance of notices
+ * --
+ * In the interest of clarity regarding the origin and status of this
+ * SLAC software, this and all the preceding Stanford University notices
+ * are to remain affixed to any copy or derivative of this software made
+ * or distributed by the recipient and are to be affixed to any copy of
+ * software made or distributed by the recipient that contains a copy or
+ * derivative of this software.
+ * 
+ * -- SLAC Software Notices, Set 4 OTT.002a, 2004 FEB 03
+ */ 
+
+/*
+ * NOTE: Some register (e.g., the SMI register) are SHARED among the
+ *   three devices. Concurrent access protection is provided by
+ *   the global networking semaphore.
+ *   If other drivers are running on a subset of IFs then proper
+ *   locking of all shared registers must be implemented!
+ *
+ *   Some things I learned about this hardware can be found
+ *   further down...
+ */
+
+#ifndef KERNEL
+#define KERNEL
+#endif
+#ifndef _KERNEL
+#define _KERNEL
+#endif
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Not so nice; would be more elegant not to depend on C library but the
+ * RTEMS-specific ioctl for dumping statistics needs stdio anyways.
+ */
+
+/*#define NDEBUG effectively removes all assertions
+ * If defining NDEBUG, MAKE SURE assert() EXPRESSION HAVE NO SIDE_EFFECTS!!
+ * This driver DOES have side-effects, so DONT DEFINE NDEBUG
+ * Performance-critical assertions are r

Tooling Needed to Build rtems-docs

[Joel Sherrill]

Hi

I ran into an issue with the output from rtems-docs. I tracked it down to a
commit which moved up the minimum version of Sphinx required but didn't
change the waf check. I will get to fixing that. In the mean time, I built
a new VM for documentation but the README isn't much help on some of the
tooling. Here is the paragraph above very nice examples for a virtualenv
and installing sphinx.

"HTML builds directly with Sphinx, PDF requires a full Latex (texlive)
install,
and building a Single HTML page requires the 'inliner' tool. The
sphinxcontrib-bibtex extension is mandatory. PlantUML requires the Node.js
package called 'node-plantuml' which installs the 'puml' command and Ditaa
needs
the 'ditaa' command and package. Ditaa images are built using the 'puml'
command."

Texlive is easy to install although time consuming. That leaves inliner,
plantuml-node, and ditaa.

I found a way to install plantuml-node using Rocky 9's npm but it does not
include puml as claimed.

Help appreciated knowing more about how to obtain and install these odd
tools.

Thanks.

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

[rtems-docs] user/bsp-build: Fix typo in BSP set builder command

[Zainab Olalekan]

From: Zainab Olalekan 

changed bsp to arch/bsp
---
 user/start/bsp-build.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/start/bsp-build.rst b/user/start/bsp-build.rst
index c62b6ba..962cd43 100644
--- a/user/start/bsp-build.rst
+++ b/user/start/bsp-build.rst
@@ -45,7 +45,7 @@ To build the BSP with all the tests run this command:
 
 cd $HOME/quick-start/src/rsb/rtems
 ../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5 \
---target=sparc-rtems@rtems-ver-major@ --with-rtems-bsp=erc32 
--with-rtems-tests=yes @rtems-ver-major@/rtems-kernel
+--target=sparc-rtems@rtems-ver-major@ --with-rtems-bsp=sparc/erc32 
--with-rtems-tests=yes @rtems-ver-major@/rtems-kernel
 
 This command should output something like:
 
-- 
2.39.3

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

Re: [rtems-docs] user/bsp-build: Fix typo in BSP set builder command

[Joel Sherrill]

Good catch. Thanks.

Committed.

On Tue, Jul 18, 2023 at 3:25 PM Zainab Olalekan 
wrote:

> From: Zainab Olalekan 
>
> changed bsp to arch/bsp
> ---
>  user/start/bsp-build.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/user/start/bsp-build.rst b/user/start/bsp-build.rst
> index c62b6ba..962cd43 100644
> --- a/user/start/bsp-build.rst
> +++ b/user/start/bsp-build.rst
> @@ -45,7 +45,7 @@ To build the BSP with all the tests run this command:
>
>  cd $HOME/quick-start/src/rsb/rtems
>  ../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5 \
> ---target=sparc-rtems@rtems-ver-major@ --with-rtems-bsp=erc32
> --with-rtems-tests=yes @rtems-ver-major@/rtems-kernel
> +--target=sparc-rtems@rtems-ver-major@
> --with-rtems-bsp=sparc/erc32 --with-rtems-tests=yes @rtems-ver-major@
> /rtems-kernel
>
>  This command should output something like:
>
> --
> 2.39.3
>
> ___
> 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: Building leon3 prom image for testing on renode

[Muhammad Sulthan Mazaya]

Hi Alan,

> Also, as you mentioned, the renode Zephyr example runs directly from RAM
without a prom image. Is it that the RTEMS LEON3 BSP relies on
initialization done by the boot prom (GRMON or MKPROM2 based boot code)?

Do you or anyone on the devel mailing list know where/how can I check which
kind of initialization rtems leon3 bsp rely on? Sorry, I am fairly new to
this

Thank you,
Mazaya

On Tue, Jul 18, 2023 at 11:27 PM Alan Cudmore 
wrote:

> Hi Mazaya,
> I wonder if it is possible to initialize the processor to the state where
> it can run the RTEMS image in RAM without using the prom image? The
> processor initialization would have to go in the resc script before the
> image is loaded and started.
> Also, as you mentioned, the renode Zephyr example runs directly from RAM
> without a prom image. Is it that the RTEMS LEON3 BSP relies on
> initialization done by the boot prom (GRMON or MKPROM2 based boot code)?
>
> https://github.com/renode/renode/blob/master/scripts/single-node/leon3_zephyr.resc
>
> I guess it ends up being a trade off of tooling vs. trying to program the
> necessary initialization in the resc script.
>
> Regards,
> Alan
>
> On Tue, Jul 18, 2023 at 2:46 AM Muhammad Sulthan Mazaya <
> msulthanmaz...@gmail.com> wrote:
>
>> Hi,
>>
>> I was trying to implement renode for testing leon3 using rtems-test. I
>> noticed that from the example they provide
>> https://github.com/antmicro/renode-rtems-leon3/blob/main/leon3_rtems.resc,
>> it seems like the renode simulator needs the prom image of leon3 to do so.
>> I don't think an additional build step before testing a particular bsp is
>> something supported by the build config of rtems-tools + my mentors also
>> said it shouldn't be on the rtems-tools. Is it okay to have RSB build that
>> for us as part of the BSP?
>>
>> Thank you,
>> Mazaya
>> ___
>> 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 rtems-docs] user: Update @rtems-ver-major@ to use sphinx substitution extention

[Chris Johns]

On 18/7/2023 6:16 pm, Muhammad Sulthan Mazaya wrote:
>  Using sphinx-substitution-extensions to manage the variable 
> @rtems-ver-major@. 
>  Originally Utkarsh's idea: 
>  
> https://discord.com/channels/82045382112799/82045848335924/1118416996606943302
>  
>  I have tested and built the docs to see if it works and it does 
>  subtitute the variable. The changes are: the variable @rtems-ver-major@ 
>  is now |rtems-ver-major|. For inline code block we use 
>  :substitution-code:`{content}` and for multiline code block we use:
> 
>  .. code-block:: {language}
>:substitutions:
>
>{content}

This is a welcome update to the documentation. Thank you for looking into it.

Does this patch require any additional sphinx modules to be installed?

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

Repository edit

[Amar Takhar]

There was a mistaken push to the RTEMS main repository earlier.  These things 
happen so we have rewound the repository back to the latest safe commit.

This is 1425735.

If anyone did checkout the repository afterwards they will get an error when 
trying to update as the repository has been rewound.  You can solve this by 
doing a fresh clone -- something I always recommend

Alternatively you can reset your own repository by doing

  git reset --hard 1425735

While on the master branch -- please keep in mind this will blow away any 
changes you have in your source tree.

Sebastian, I noticed you had two commits pushed after these will need to be 
re-applied as rewinding back is the safest and best way to handle this.


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

Re: Repository edit

[Gedare Bloom]

I had a local copy of the two commits that were dropped during the
rewinding. I have pushed them back. We are back to the state prior to
the accidental push. Hashes all look good. Thanks for handling this.

Gedare

On Tue, Jul 18, 2023 at 7:55 PM Amar Takhar  wrote:
>
> There was a mistaken push to the RTEMS main repository earlier.  These things
> happen so we have rewound the repository back to the latest safe commit.
>
> This is 1425735.
>
> If anyone did checkout the repository afterwards they will get an error when
> trying to update as the repository has been rewound.  You can solve this by
> doing a fresh clone -- something I always recommend
>
> Alternatively you can reset your own repository by doing
>
>   git reset --hard 1425735
>
> While on the master branch -- please keep in mind this will blow away any
> changes you have in your source tree.
>
> Sebastian, I noticed you had two commits pushed after these will need to be
> re-applied as rewinding back is the safest and best way to handle this.
>
>
> Amar.
> ___
> 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 rtems v2] Add the Regulator Interface and test

[Chris Johns]

On 15/7/2023 9:48 am, Joel Sherrill wrote:
> Updates #4924.
> 
> The Regulator is an application support class which is used to
> deal with the scenario where there is a bursty input source
> which needs to be metered out to a destination sink. The maximum
> size of bursts needs to be known and the delivery method must
> be configured to deliver messages at a rate that allows the
> traffic to not overflow.
> ---
>  cpukit/include/rtems/regulator.h  |  439 ++
>  cpukit/include/rtems/regulatorimpl.h  |  103 ++
>  cpukit/libmisc/regulator/regulator.c  |  522 
>  spec/build/cpukit/librtemscpu.yml |2 +
>  spec/build/cpukit/objregulator.yml|   18 +
>  spec/build/testsuites/libtests/grp.yml|2 +
>  .../build/testsuites/libtests/regulator01.yml |   21 +
>  testsuites/libtests/regulator01/regulator01.c | 1192 +
>  .../libtests/regulator01/regulator01.doc  |   68 +
>  .../libtests/regulator01/rtems_config.c   |   59 +
>  10 files changed, 2426 insertions(+)
>  create mode 100644 cpukit/include/rtems/regulator.h
>  create mode 100644 cpukit/include/rtems/regulatorimpl.h
>  create mode 100644 cpukit/libmisc/regulator/regulator.c
>  create mode 100644 spec/build/cpukit/objregulator.yml
>  create mode 100644 spec/build/testsuites/libtests/regulator01.yml
>  create mode 100644 testsuites/libtests/regulator01/regulator01.c
>  create mode 100644 testsuites/libtests/regulator01/regulator01.doc
>  create mode 100644 testsuites/libtests/regulator01/rtems_config.c
> 
> diff --git a/cpukit/include/rtems/regulator.h 
> b/cpukit/include/rtems/regulator.h
> new file mode 100644
> index 00..74f0d00f2e
> --- /dev/null
> +++ b/cpukit/include/rtems/regulator.h
> @@ -0,0 +1,439 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @defgroup RegulatorAPI Regulator API
> + *
> + * @brief Regulator APIs
> + *
> + * The Regulator provides a set of APIs to manage input sources which 
> + * produces bursts of message traffic.
> + */
> +
> +/**
> + * @mainpage
> + *
> + * The regulator is designed to sit logically between two entities -- a
> + * source and a sink/destination, where it limits the traffic sent to the
> + * destination to prevent it from being flooded with messages from the
> + * source. This can be used to accommodate bursts of input from a source
> + * and meter it out to a destination.  The maximum number of messages
> + * which can be buffered in the regulator is specified by the
> + * @a maximum_messages field in the @a rtems_regulator_attributes
> + * structure passed as an argument to @a rtems_regulator_create().
> + *
> + * The regulator library accepts an input stream of messages from a
> + * source and delivers them to a destination. The regulator assumes that the
> + * input stream from the source contains sporadic bursts of data which can
> + * exceed the acceptable rate of the destination. By limiting the message 
> rate,
> + * the regulator prevents an overflow of messages.
> + *
> + * The regulator can be configured for the input buffering required to manage
> + * the maximum burst and for the metering rate for the output. The output 
> rate
> + * is in messages per second. If the sender produces data too fast, the
> + * regulator will buffer the configured number of messages.
> + *
> + * A configuration capability is provided to allow for adaptation to 
> different
> + * message streams. The regulator can also support running multiple 
> instances,
> + * which could be used on independent message streams.
> + *
> + * The regulator provides a simple interface to the application for avoiding
> + * bursts of input from a fast source overflowing a slower output sink.
> + *
> + * It is assumed that the application has a design limit on the number of
> + * messages which may be buffered. All messages accepted by the regulator,
> + * assuming no overflow on input, will eventually be output by the delivery
> + * thread.
> + *
> + * A regulator instance is used as follows:
> + *
> + * @code
> + *   while (1)
> + * use rtems_regulator_obtain_buffer to obtain a buffer
> + * input operation to fetch data into the buffer
> + * rtems_regulator_send(buffer, size of message)
> + *   // rtems_regulator_send() will release the buffer automatically 
> when done

OK however ...

> + * @endcode
> + *
> + * The sequence diagram below shows the interaction between a message Source,
> + * a Regulator instance, and RTEMS, given the usage described in the above
> + * paragraphs.
> + *
> + * \startuml "Regulator Application Input Source Usage"
> + *   Source -> Regulator : rtems_regulator_obtain_buffer(regulator, buffer)
> + *   Regulator -> RTEMS : rtems_partition_get_buffer(id, buffer)
> + *   RTEMS --> Regulator : rtems_status_code
> + *   Regulator --> Source : rtems_status_code
> + *   Source -> Regulator : rtems_regulator_send(regulator, message, length)
> + *   Regulator -> RTEMS : rtems_mess

Re: Repository edit

[Sebastian Huber]

On 19.07.23 04:30, Gedare Bloom wrote:

I had a local copy of the two commits that were dropped during the
rewinding. I have pushed them back. We are back to the state prior to
the accidental push. Hashes all look good. Thanks for handling this.


Thanks, looks good.

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