Re: Libbsd situation.
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
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
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
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.
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.
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.
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
--- 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
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
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
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
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
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
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
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
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
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