Re: [PATCH v5 2/4] bsps: New GPIO API & peripherals API framework
Hello Christian, On Mon, 2022-08-01 at 20:29 +0200, o...@c-mauderer.de wrote: > Hello Duc, > > Am 01.08.22 um 05:50 schrieb Duc Doan: > > Hello Christian, > > > > On Sat, 2022-07-30 at 17:50 +0200, o...@c-mauderer.de wrote: > > > Hello Duc, > > > > > > Am 24.07.22 um 14:01 schrieb Duc Doan: > > > > --- > > > > bsps/include/bsp/gpio2.h | 528 > > > > > > > > bsps/include/bsp/periph_api.h | 142 +++ > > > > bsps/shared/dev/gpio/gpio.c | 212 ++ > > > > bsps/shared/dev/periph_api/periph_api.c | 101 + > > > > spec/build/bsps/obj.yml | 4 +- > > > > 5 files changed, 986 insertions(+), 1 deletion(-) > > > > create mode 100644 bsps/include/bsp/gpio2.h > > > > create mode 100644 bsps/include/bsp/periph_api.h > > > > create mode 100644 bsps/shared/dev/gpio/gpio.c > > > > create mode 100644 bsps/shared/dev/periph_api/periph_api.c > > > > > > > > diff --git a/bsps/include/bsp/gpio2.h > > > > b/bsps/include/bsp/gpio2.h > > > > > > I'm not really happy with the "2" in the name. But at the moment > > > I > > > don't > > > have a much better idea either. But if you call it "gpio2", you > > > should > > > call the C files "gpio2" too. Maybe "dev/gpio/gpio.h" similar to > > > the > > > "dev/i2c/i2c.h"? > > > > > > > I will rename the C file to "gpio2.c" for now. > > > > > > new file mode 100644 > > > > index 00..9cb1c720ab > > > > --- /dev/null > > > > +++ b/bsps/include/bsp/gpio2.h > > > > @@ -0,0 +1,528 @@ > > > > +/* SPDX-License-Identifier: BSD-2-Clause */ > > > > + > > > > > > Your file is missing some general doxygen group information. Take > > > a > > > look > > > at for example bsps/include/ofw/ofw.h. > > > > > > > Thanks for the reminder, I will add that. > > > > > > +/* > > > > + * Copyright (C) 2022 Duc Doan (dtbpkmte at gmail.com) > > > > + * > > > > + * 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 LIBBSP_BSP_GPIO2_H > > > > +#define LIBBSP_BSP_GPIO2_H > > > > + > > > > +#include > > > > +#include > > > > + > > > > +/** > > > > + * Configure the maximum number of GPIO controllers used in > > > > + * a application. > > > > + * > > > > + * The macro CONFIGURE_GPIO_MAXIMUM_CONTROLLERS can be > > > > + * defined in application code. If it is not defined, > > > > + * it will default to BSP_GPIO_NUM_CONTROLLERS. If BSP's > > > > + * number of controllers is not defined, it will default > > > > + * to 1. > > > > + */ > > > > +#ifndef CONFIGURE_GPIO_MAXIMUM_CONTROLLERS > > > > > > How do you manage that the CONFIGURE_GPIO_MAXIMUM_CONTROLLERS > > > from > > > the > > > application is visible here? > > > > > > > I forgot to remove this CONFIGURE_GPIO_MAXIMUM_CONTROLLERS thing. > > At > > first I wanted to do something like confdef but couldn't, so I > > changed > > to use BSP_GPIO_NUM_CONTROLLERS, which is a build option. I will > > delete > > that code. However, if you have a document about how confdef works, > > it > > would be helpful for me and I may be able to make that > > CONFIGURE_GPIO_MAXIMUM_CONTROLLERS work. > > I haven't checked since the new build system either. The official way > is > still to just add them to confdefs.h similar like all other options. > Not > sure whether that is documented somewhere. The better mut much more > difficult way is to
[PATCH] libmisc/shell: Add an 'rtems' command to report a running build
From: Chris Johns
- Report version, cpu, bsp, tools and options.
---
cpukit/include/rtems/shellconfig.h | 6 ++
cpukit/libmisc/shell/main_rtems.c | 156 +
spec/build/cpukit/objshell.yml | 1 +
3 files changed, 163 insertions(+)
create mode 100644 cpukit/libmisc/shell/main_rtems.c
diff --git a/cpukit/include/rtems/shellconfig.h
b/cpukit/include/rtems/shellconfig.h
index b09d5ae1d3..a013840ee7 100644
--- a/cpukit/include/rtems/shellconfig.h
+++ b/cpukit/include/rtems/shellconfig.h
@@ -110,6 +110,7 @@ extern rtems_shell_cmd_t rtems_shell_STACKUSE_Command;
extern rtems_shell_cmd_t rtems_shell_PERIODUSE_Command;
extern rtems_shell_cmd_t rtems_shell_PROFREPORT_Command;
extern rtems_shell_cmd_t rtems_shell_WKSPACE_INFO_Command;
+extern rtems_shell_cmd_t rtems_shell_RTEMS_Command;
extern rtems_shell_cmd_t rtems_shell_MALLOC_INFO_Command;
extern rtems_shell_cmd_t rtems_shell_RTRACE_Command;
#if RTEMS_NETWORKING
@@ -489,6 +490,11 @@ extern rtems_shell_alias_t * const
rtems_shell_Initial_aliases[];
defined(CONFIGURE_SHELL_COMMAND_WKSPACE_INFO)
&rtems_shell_WKSPACE_INFO_Command,
#endif
+#if (defined(CONFIGURE_SHELL_COMMANDS_ALL) && \
+ !defined(CONFIGURE_SHELL_NO_COMMAND_RTEMS)) || \
+defined(CONFIGURE_SHELL_COMMAND_RTEMS)
+ &rtems_shell_RTEMS_Command,
+#endif
/*
* Malloc family commands
diff --git a/cpukit/libmisc/shell/main_rtems.c
b/cpukit/libmisc/shell/main_rtems.c
new file mode 100644
index 00..e24287ccc4
--- /dev/null
+++ b/cpukit/libmisc/shell/main_rtems.c
@@ -0,0 +1,156 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup
+ *
+ * @brief This source file contains the kernel command.
+ */
+
+/*
+ * Copyright (c) 2022 Chris Johns. All rights reserved.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static void kernel_summary(void) {
+ printf(
+"RTEMS: %d.%d.%d",
+rtems_version_major(), rtems_version_minor(), rtems_version_revision());
+ if (rtems_version_control_key_is_valid(rtems_version_control_key())) {
+printf(" (%s)", rtems_version_control_key());
+ }
+#if RTEMS_SMP
+printf(" SMP:%d cores", );
+#endif
+printf("\n");
+}
+
+static void cpu_summary(void) {
+ printf("CPU: " CPU_NAME " (" CPU_MODEL_NAME ")\n");
+}
+
+static void bsp_summary(void) {
+ printf("BSP: %s\n", rtems_board_support_package());
+}
+
+static void tools_summary(void) {
+ printf( "Tools: " __VERSION__ "\n");
+}
+
+static void opts_summary(void) {
+ printf("Options:"
+#if RTEMS_DEBUG
+ " DEBUG"
+#endif
+#if RTEMS_MULTIPROCESSING
+ " MULTIPROCESSING"
+#endif
+#if RTEMS_NETWORKING
+ " NETWORKING"
+#endif
+#if RTEMS_PARAVIRT
+ " PARAVIRT"
+#endif
+#if RTEMS_POSIX_API
+ " POSIX"
+#endif
+#if RTEMS_PROFILING
+ " PROFILING"
+#endif
+#if RTEMS_SMP
+ " SMP"
+#endif
+ "\n");
+}
+
+static void help(void) {
+ printf( "Usage:: rtems \n");
+ printf( " where is:\n");
+ printf( " help : this help\n");
+ printf( " ver: kernel version\n");
+ printf( " cpu: kernel version\n");
+ printf( " bsp: BSP name\n");
+ printf( " tools : tools version\n");
+ printf( " opts : options\n");
+ printf( " all: all commands\n");
+}
+
+static int rtems_shell_main_rtems(
+ int argc, char *argv[]) {
+
+ if (argc == 1) {
+kernel_summary();
+ } else if (argc == 2) {
+if (strcmp(argv[1], "help") == 0) {
+ help();
+} else if (strcmp(argv[1], "ver") == 0) {
+ kernel_summary();
+} else if (strcmp(argv[1], "cpu") == 0) {
+ cpu_summary();
+
Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL
Hello Christian, On Tue, 2022-08-02 at 07:26 +0200, Christian MAUDERER wrote: > That page most likely ignores line endings. Try it with `file` or > `dos2unix -i`: > > > sh> git co master > [...] > sh> file bsps/arm/include/cmsis_gcc.h > bsps/arm/include/cmsis_gcc.h: C source, ASCII text, with CRLF, LF > line > terminators > sh> dos2unix -i bsps/arm/include/cmsis_gcc.h > 1374 1 0 no_bom text > bsps/arm/include/cmsis_gcc.h > sh> git co duc/master > [...] > sh> file bsps/arm/include/cmsis_gcc.h > bsps/arm/include/cmsis_gcc.h: C source, ASCII text > sh> dos2unix -i bsps/arm/include/cmsis_gcc.h > 0 2085 0 no_bom text > bsps/arm/include/cmsis_gcc.h > sh> > > > The three numbers of dos2unix output is (in this order): Number of > DOS > line endings, number of UNIX line endings, number of MAC line > endings. > > So line endings changed from CRLF to only LF. Either make that two > steps > (first changing the old one to LF in one commit and then updating it > in > another) or change the new file to use the CRLF format of the old > one. > > Best regards > > Christian > > Thank you, this knowledge is new to me. I will change them to LF. Best, Duc ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL
Hello Duc, Am 02.08.22 um 05:00 schrieb Duc Doan: Hello Christian, On Mon, 2022-08-01 at 20:32 +0200, o...@c-mauderer.de wrote: Hello Duc, Am 01.08.22 um 04:13 schrieb Duc Doan: Hello Christian, On Sun, 2022-07-31 at 20:01 +0200, o...@c-mauderer.de wrote: Hello Duc, Am 31.07.22 um 17:07 schrieb Duc Doan: Hello Christian, On Sat, 2022-07-30 at 16:32 +0200, o...@c-mauderer.de wrote: Hello Duc, general note for the patch: Please write in the commit message where you got the sources from. That can be a link to a github repo including a commit ID or a link to the zip file from ST (including a date, version or similar information). If you moved some stuff around compared to the original structure: Please describe about what you did. For example in the imxrt I just added the cp commands that I used: https://git.rtems.org/rtems/commit/bsps/arm/imxrt?id=48f6a6c302a3e1a3f8915e2503d0fe618d1af285 Not the best solution but at least someone else can find out roughly what I did. Ah yes, I will do that. I thought I only needed to put the description in the email before. Am 24.07.22 um 14:01 schrieb Duc Doan: This patch is too large so I cannot send via email. Please find it here: https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/6f1fbc7dd7a5e0877d8bff11e1b21558928dbc16 --- .gitignore | 1 + You added a "patches" directory to the gitignore. That looks like a change that is specific to your method of working. These kind of changes should normall not be pushed. If you want to ignore stuff specific to your work environment, I recommend to use a global .gitignore file. Git has a "core.excludesfile" config for that. Thanks for the suggestion, I will fix that. bsps/arm/include/cmsis_compiler.h | 266 + bsps/arm/include/cmsis_gcc.h | 3460 +-- bsps/arm/include/cmsis_version.h | 39 + bsps/arm/include/core_cm4.h | 524 +- bsps/arm/include/core_cm7.h | 5186 ++-- bsps/arm/include/mpu_armv7.h | 270 + Are the cmsis files from the same source or directly from ARM? They are from the same source (STM HAL v1.27.1). The cmsis_gcc.h has a lot of changes compared to the earlier version that has been present in RTEMS. A lot of the changes seem to be whitespace changes. Can these be avoided somehow (for example by using dos2unix before overwriting the file)? From what I've just read about dos2unix, it converts line breaks from CRLF to LF (please correct me if I'm wrong). How will this command resolve the whitespace changes? I haven't looked at the exact type of whitespace changes. I had the impression that the difference is most likely only the line ending. It didn't look like tab / space issue. Is it a tab / space issue? I've looked at the some files and noticed that the difference is mostly additional code/code change (e.g. adding support for ARMv8), but not whitespace changes. Hm. Odd. In that case: Why does the diff show a complete removal and complete adding of (for example) cmsis_gcc.h: https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/6f1fbc7dd7a5e0877d8bff11e1b21558928dbc16#diff-9632086ec773f52fc69a99f2d7fad711c51aad138e6449e01b4737f80201d185 I'm not sure why that happens. I used this page to compare line-by- line: https://www.diffchecker.com/xMCBtxbt This is the diff for cmsis_gcc. That page most likely ignores line endings. Try it with `file` or `dos2unix -i`: sh> git co master [...] sh> file bsps/arm/include/cmsis_gcc.h bsps/arm/include/cmsis_gcc.h: C source, ASCII text, with CRLF, LF line terminators sh> dos2unix -i bsps/arm/include/cmsis_gcc.h 1374 1 0 no_bomtextbsps/arm/include/cmsis_gcc.h sh> git co duc/master [...] sh> file bsps/arm/include/cmsis_gcc.h bsps/arm/include/cmsis_gcc.h: C source, ASCII text sh> dos2unix -i bsps/arm/include/cmsis_gcc.h 02085 0 no_bomtextbsps/arm/include/cmsis_gcc.h sh> The three numbers of dos2unix output is (in this order): Number of DOS line endings, number of UNIX line endings, number of MAC line endings. So line endings changed from CRLF to only LF. Either make that two steps (first changing the old one to LF in one commit and then updating it in another) or change the new file to use the CRLF format of the old one. Best regards Christian Best, Duc In the discord chat there was one suggestion from Ho Kaido to move the files one level down and make them BSP specific. I'm not sure whether I'm for or against that idea. Advantage is that it makes BSPs independant from each other. Disadvantage is that it duplicates code. I think I would try to avoid moving them down due to the code duplication but it raises the question: Which BSPs use the files too and did you try whether they still compile after the upgrade? Until now I only know of STM32H7 BSP that is using the CMSIS files. I
Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL
Hello Christian, On Sat, 2022-07-30 at 22:19 +0200, o...@c-mauderer.de wrote: > > > > Am 30.07.22 um 21:41 schrieb Karel Gardas: > > On 7/30/22 16:32, o...@c-mauderer.de wrote: > > > > bsps/arm/include/cmsis_compiler.h | 266 + > > > > bsps/arm/include/cmsis_gcc.h | 3460 +-- > > > > bsps/arm/include/cmsis_version.h | 39 + > > > > bsps/arm/include/core_cm4.h | 524 +- > > > > bsps/arm/include/core_cm7.h | 5186 ++-- > > > > bsps/arm/include/mpu_armv7.h | 270 + > > > > > > Are the cmsis files from the same source or directly from ARM? > > > > > > The cmsis_gcc.h has a lot of changes compared to the earlier > > > version > > > that has been present in RTEMS. A lot of the changes seem to be > > > whitespace changes. Can these be avoided somehow (for example by > > > using > > > dos2unix before overwriting the file)? > > > > > > In the discord chat there was one suggestion from Ho Kaido to > > > move the > > > files one level down and make them BSP specific. I'm not sure > > > whether > > > I'm for or against that idea. Advantage is that it makes BSPs > > > independant from each other. Disadvantage is that it duplicates > > > code. > > > > > > I think I would try to avoid moving them down due to the code > > > duplication but it raises the question: Which BSPs use the files > > > too > > > and did you try whether they still compile after the upgrade? > > > > We have had this dicussion with Duc on discord IIRC when he > > started. He > > needed new CMSIS (v5) version due to new HAL which Duc claims > > depends on > > them. I have not verified that claim personally. > > > > New CMSIS v5 brings obviously: > > > > - by ARM maintained code (v4 is unmaintained IIRC) > > > > but also: > > > > - license change from BSD to Apache-2 > > > > At that time I've told Duc to continue with the code and not to > > worry > > about license changes -- as this would be longer discussion anyway. > > Not > > sure, but IIRC he also wrote to Sebastian asking for clarification > > -- > > well, not sure about that. Certainly IIRC I suggested that. > > > > Anyway, I took Duc code and try H7 BSPs and to my surprise they > > compiles > > more or less all without any compilation related issue. Well, I've > > not > > tried M4 variants. So far I've not run full tester on this. I'll, > > but > > first I'd like to test his API if it's possible to also use with > > H7. > > > > BTW: if RTEMS prefer old unmaintained BSD-3 ARM CSMIS code, then > > it's > > perhaps possible to go in F4 HAL history back and grab just the > > three > > with the v4 dependency. On the other hand, for ARM Apache-2 seems > > to be > > the way forward and for some ST.com depended code too -- so I guess > > RTEMS project will need to live with that fact somehow. > > > > Thanks, > > Karel > > > > Hello Karel, > > thanks for the clarification. I have to be honest: I missed the > license > change. That is a bit of a difficult one and will cause a discussion. > @Duc: We need a new LICENSE file in the top level that represents > that. Maybe split the CMSIS update into a separate patch so that it > is > clear why there is a new license file (if the license is only for the > CMSIS and not for the STM HAL too). > Do you mean I need to add a LICENSE.Apache-2.0 file in rtems source root? I found this file being shipped with STM HAL: https://github.com/STMicroelectronics/STM32CubeF4/blob/master/Drivers/CMSIS/LICENSE.txt Should I copy this file and rename it to LICENSE.Apache-2.0? Best, Duc > But my main concern was another one: Which BSPs use the CMSIS files? > Beneath the stm32 variants, that's at least the atsam and imxrt. > Maybe I > missed some more. We should at least make sure that these BSPs are > compile-clean with the updated cmsis headers. > > Best regards > > Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit/dev/can: Added CAN support
Hello Duc,
general note: You add an API to cpukit. Most APIs there should have a
test case in the testsuite. In this case the test case would have to
create some dummy CAN driver and check whether everything works like
expected. As an example take a look at the SPI test:
https://git.rtems.org/rtems/tree/testsuites/libtests/spi01/init.c
It creates a dummy device and checks whether the SPI layer does
everything as expected. Would be great if you could add something like
this. Target of such a test should be more or less that every branch in
your code is triggered at least once (code coverage). It doesn't has to
be every combination but it shows that the code is at least reachable
and works as expected.
Am 31.07.22 um 13:53 schrieb Prashanth S:
---
cpukit/dev/can/can.c | 514 +
cpukit/include/dev/can/can-msg.h | 55 +++
cpukit/include/dev/can/can-queue.h | 127 +++
cpukit/include/dev/can/can.h | 102 ++
spec/build/cpukit/librtemscpu.yml | 6 +
5 files changed, 804 insertions(+)
create mode 100644 cpukit/dev/can/can.c
create mode 100644 cpukit/include/dev/can/can-msg.h
create mode 100644 cpukit/include/dev/can/can-queue.h
create mode 100644 cpukit/include/dev/can/can.h
diff --git a/cpukit/dev/can/can.c b/cpukit/dev/can/can.c
new file mode 100644
index 00..8feec8800b
--- /dev/null
+++ b/cpukit/dev/can/can.c
@@ -0,0 +1,514 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup CANBus
+ *
+ * @brief Controller Area Network (CAN) Bus Implementation
+ *
+ */
+
+/*
+ * Copyright (C) 2022 Prashanth S (fishesprasha...@gmail.com)
+ *
+ * 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.
+ */
+
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+
+#include
+
+static ssize_t
+can_bus_open(rtems_libio_t *iop, const char *path, int oflag, mode_t mode);
+static ssize_t
+can_bus_read(rtems_libio_t *iop, void *buffer, size_t count);
+static ssize_t
+can_bus_write(rtems_libio_t *iop, const void *buffer, size_t count);
+static ssize_t
+can_bus_ioctl(rtems_libio_t *iop, ioctl_command_t request, void *buffer);
+
+static int can_xmit(struct can_bus *bus);
+
+static int can_create_sem(struct can_bus *);
+static int try_sem(struct can_bus *);
+static int take_sem(struct can_bus *);
+static int give_sem(struct can_bus *);
+
+/* sem_count this is for debug purpose, for debugging
+the take_sem and give_sem
+*/
+static int sem_count = 0;
+
+static void can_bus_obtain(can_bus *bus)
+{
+ rtems_recursive_mutex_lock(&bus->mutex);
+}
+
+static void can_bus_release(can_bus *bus)
+{
+ rtems_recursive_mutex_unlock(&bus->mutex);
+}
+
+int can_create_sem(struct can_bus *bus)
+{
+ int ret = 0;
+
+ ret = rtems_semaphore_create(rtems_build_name('c', 'a', 'n', bus->index),
+ CAN_TX_BUF_COUNT, RTEMS_FIFO | RTEMS_COUNTING_SEMAPHORE | RTEMS_LOCAL,
+ 0, &bus->tx_fifo_sem_id);
+
+ if (ret != 0) {
+printf("can_create_sem: rtems_semaphore_create failed %d\n", ret);
+ }
+
+ return ret;
+}
+
+static void can_interrupt_lock_acquire(struct can_bus *bus)
+{
+ can_bus_obtain(bus);
+ bus->can_dev_ops->dev_int(bus->priv, false);
+}
+
+static void can_interrupt_lock_release(struct can_bus *bus)
+{
+ bus->can_dev_ops->dev_int(bus->priv, true);
+ can_bus_release(bus);
+}
+
+static int take_sem(struct can_bus *bus)
+{
+ int ret = rtems_semaphore_obtain(bus->tx_fifo_sem_id, RTEMS_WAIT,
+RTEMS_NO_TIMEOUT);
+ if (ret == RTEMS_SUCCESSFUL) {
+CAN_DEBUG_LOCK("take_sem: Counting semaphore count = %d\n", ++sem_count);
Do you really mean "LOCK" or should it be a "LOG"? Both is reasonable
here so I'm not entirely sure. But you use
Re: [PATCH v5 2/4] bsps: New GPIO API & peripherals API framework
Hello Duc, Am 02.08.22 um 09:17 schrieb Duc Doan: [...] diff --git a/bsps/include/bsp/periph_api.h b/bsps/include/bsp/periph_api.h new file mode 100644 index 00..fb02b701dc --- /dev/null +++ b/bsps/include/bsp/periph_api.h Isn't it an API just because you add it here. Is it really necessary to add the "API" in the name? I was thinking that this periph_api is the base for other APIs, so I added "api" in the name. I'm not entirely sure yet whether this API is really something separate from your GPIO API. The "gpio_start" calls the "periph_api_start" and the periph_api functions use gpio internal structures. I think I would just add these few functions to the GPIO API. That is also an option. The reason I separated them is that I thought these additional functions should be somehow separated from the basic GPIO to avoid making GPIO API too complicated. Also, this API is mostly for adding new peripheral APIs and not targetting user application. Users only need to use one function, set_api(). Please note that in our case a user can and often will add his own drivers to an application too. Not all drivers are in the BSP. Some applications need specialy tuned drivers and therefor will bring their own ones. I'm still not convinced that this is necessary at all. A peripheral has to know it's pins. But the pin doesn't have to know anything about the connected peripheral. So why do we need that? At the moment it seems to add mainly some complexity and uses some memory. Logically, a pin doesn't have to know about the connected peripheral. However, this newly added API is just a way to make things easier for users. Without this API, for each peripheral, users need to create new objects that hold information about both the GPIO pins and the handlers of that peripheral. They would have to maintain those objects all the time during the use of that peripheral. If users want to change the functionality, they have to create new objects of that peripheral type. If the functionallity does not change, the peripheral can just know it's pin and the user just has to know and handle the peripheral. Only during the initialization he has to init the pin first and the peripheral afterwards. But that's the case with your API too, isn't it? If the functionality of a pin changes (which is a really rare use case) the user will need two APIs. So if I understand your code correctly, he would have to: - Init GPIO pin. - Add API for example for ADC. - Use that pin. - Remove API for ADC. - Add API for example for DAC. - Use the pin. - Remove API for DAC. ... So he has to switch in or out the API. For this switching he eitherhas to provide memory for the ADC / DAC API or the memory is dynamically allocated on every switch. I think I would rather keep multiple pointers in my application instead of allocating something every time. This API avoids that by reusing the already-existing GPIO pin objects. Users only need a single GPIO object for a pin for all operations, be it basic GPIO or additional peripherals. This creates simplicity for user application at the cost of added memory (one additional pointer member, which is not much in my opinion). For a single use pin that doesn't have to switch function, the user needs only one pointer. The one to the object of the driver with the function he uses. The pin can be a part of that object. By the way, this newly added API is mostly targeting peripherals that require a single pin like ADC or DAC. That doesn't make it better. Now you added complexity for very special cases ;-) Hmm your reasoning makes sense. Should I change so that ADC contains the pin as a member (and thus remove the peripheral API)? From my point of view, that would be better. You maybe could think about hinting on that point in the meeting tomorrow. Maybe someone else will add an oppinion too. Best regards Christian Best, Duc [...] ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL
Hello Duc, Am 02.08.22 um 12:37 schrieb Duc Doan: Hello Christian, On Sat, 2022-07-30 at 22:19 +0200, o...@c-mauderer.de wrote: Am 30.07.22 um 21:41 schrieb Karel Gardas: On 7/30/22 16:32, o...@c-mauderer.de wrote: bsps/arm/include/cmsis_compiler.h | 266 + bsps/arm/include/cmsis_gcc.h | 3460 +-- bsps/arm/include/cmsis_version.h | 39 + bsps/arm/include/core_cm4.h | 524 +- bsps/arm/include/core_cm7.h | 5186 ++-- bsps/arm/include/mpu_armv7.h | 270 + Are the cmsis files from the same source or directly from ARM? The cmsis_gcc.h has a lot of changes compared to the earlier version that has been present in RTEMS. A lot of the changes seem to be whitespace changes. Can these be avoided somehow (for example by using dos2unix before overwriting the file)? In the discord chat there was one suggestion from Ho Kaido to move the files one level down and make them BSP specific. I'm not sure whether I'm for or against that idea. Advantage is that it makes BSPs independant from each other. Disadvantage is that it duplicates code. I think I would try to avoid moving them down due to the code duplication but it raises the question: Which BSPs use the files too and did you try whether they still compile after the upgrade? We have had this dicussion with Duc on discord IIRC when he started. He needed new CMSIS (v5) version due to new HAL which Duc claims depends on them. I have not verified that claim personally. New CMSIS v5 brings obviously: - by ARM maintained code (v4 is unmaintained IIRC) but also: - license change from BSD to Apache-2 At that time I've told Duc to continue with the code and not to worry about license changes -- as this would be longer discussion anyway. Not sure, but IIRC he also wrote to Sebastian asking for clarification -- well, not sure about that. Certainly IIRC I suggested that. Anyway, I took Duc code and try H7 BSPs and to my surprise they compiles more or less all without any compilation related issue. Well, I've not tried M4 variants. So far I've not run full tester on this. I'll, but first I'd like to test his API if it's possible to also use with H7. BTW: if RTEMS prefer old unmaintained BSD-3 ARM CSMIS code, then it's perhaps possible to go in F4 HAL history back and grab just the three with the v4 dependency. On the other hand, for ARM Apache-2 seems to be the way forward and for some ST.com depended code too -- so I guess RTEMS project will need to live with that fact somehow. Thanks, Karel Hello Karel, thanks for the clarification. I have to be honest: I missed the license change. That is a bit of a difficult one and will cause a discussion. @Duc: We need a new LICENSE file in the top level that represents that. Maybe split the CMSIS update into a separate patch so that it is clear why there is a new license file (if the license is only for the CMSIS and not for the STM HAL too). Do you mean I need to add a LICENSE.Apache-2.0 file in rtems source root? I found this file being shipped with STM HAL: https://github.com/STMicroelectronics/STM32CubeF4/blob/master/Drivers/CMSIS/LICENSE.txt Should I copy this file and rename it to LICENSE.Apache-2.0? Short answer: Yes. A bit longer answer: Please make sure that it's really an unchanged Apache license before you copy it. I assume it is but just to be sure, I would use a diff with the one from opensource.org: https://opensource.org/licenses/Apache-2.0 Best regards Christian Best, Duc But my main concern was another one: Which BSPs use the CMSIS files? Beneath the stm32 variants, that's at least the atsam and imxrt. Maybe I missed some more. We should at least make sure that these BSPs are compile-clean with the updated cmsis headers. Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[DOCS] Add versioning support
Hi, These patches add versioning support that can be used in code blocks. It will allow us to move to RTEMS 7 without needing wide ranging version number changes. The documentation does have some things like the version of a compiler or list of files that do change but we should look to refine what we have in the documentation so we do not need endless updates. I have done some of the changes and we have a lot more todo so please send in patches. Chris In-Reply-To: ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/5] building: Add support for an RTEMS version number
From: Chris Johns
- Support using a version number for RTEMS documentation
Updates #4695
---
README.txt| 31 +
common/conf.py| 12 +++-
common/rtemsdomain.py | 64 +++
common/version.py | 5 +++-
4 files changed, 85 insertions(+), 27 deletions(-)
diff --git a/README.txt b/README.txt
index 828c9e7..07bae0d 100644
--- a/README.txt
+++ b/README.txt
@@ -504,6 +504,9 @@ existing documentation for an example and if unsure ask.
identifed by the standard shell prompt characters where '$' is a
user prompt and '#' is a 'root' prompt.
+ Do not embed the version or version major number in the literal
+ commands or examples. Use the replacements listed in 10.
+
6. Use the directives for 'note', 'warning', and 'topic'. Do not add 'TIP',
'Important' or 'Warning' to the text. Let the mark-up language handle
this. The supported directives are:
@@ -582,3 +585,31 @@ existing documentation for an example and if unsure ask.
bugs : https://devel.rtems.org/wiki/Bugs/
gsoc : https://devel.rtems.org/wiki/GSoC/
socis: https://devel.rtems.org/wiki/SOCIS/
+
+10. Use the following to embed the version number in any part of the
+documentation source:
+
+ 1. @rtems-version@
+
+The complete version string of the documentation.
+
+ 2. @rtems-ver-major@
+
+The version major number.
+
+ 2. @rtems-ver-minor@
+
+The version minor number.
+
+ 2. @rtems-ver-revision@
+
+The version revision number.
+
+The replacement happens during the source read phase of the build
+and is not context specific. The subsituation will happen in code
+blocks and other normally quoated area.
+
+It is a requirement these be used then embedded commands or
+related text in the documentation to let the documentatoin track
+the release. For example `microblaze-rtems6-gdb` should be written
+as `microblaze-rtems@rtems-ver-major@-gdb`.
diff --git a/common/conf.py b/common/conf.py
index a652e2a..565e06d 100644
--- a/common/conf.py
+++ b/common/conf.py
@@ -1,4 +1,4 @@
-import version as rtems_version
+import datetime
extensions = [
"sphinx.ext.autodoc",
@@ -30,21 +30,17 @@ master_doc = 'index'
# General information about the project.
project = u'RTEMS Documentation Project'
-copyright = u'1988, 2020 RTEMS Project and contributors'
+copyright = u'1988, ' + str(datetime.datetime.now().year) + ' RTEMS Project
and contributors'
# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
# built documents.
#
# The short X.Y version.
-version = rtems_version.version()
+#version = rtems_version.version()
# The full version, including alpha/beta/rc tags.
-release = rtems_version.string()
-
-major = rtems_version.major()
-minor = rtems_version.minor()
-revision = rtems_version.revision()
+#release = rtems_version.string()
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
diff --git a/common/rtemsdomain.py b/common/rtemsdomain.py
index 9b092a3..630f1e3 100644
--- a/common/rtemsdomain.py
+++ b/common/rtemsdomain.py
@@ -8,6 +8,8 @@ from sphinx.domains import Domain, ObjType, Index
from sphinx.util.nodes import make_refnode
from sphinx.util.docfields import Field, TypedField
+import version as rtems_version
+
"""
:r:bsp:`sparc/sis`
@@ -30,28 +32,28 @@ role_name = {
}
role_url = {
- "trac": ("Trac",
"https://devel.rtems.org";),
- "devel":("Developer Site",
"https://devel.rtems.org";),
- "www": ("RTEMS Home",
"https://www.rtems.org/";),
- "buildbot": ("Buildbot Instance",
"https://buildbot.rtems.org/";),
- "builder": ("Builder Site",
"https://builder.rtems.org/";),
- "docs": ("Documentation Site",
"https://docs.rtems.org/";),
- "lists":("Mailing Lists",
"https://lists.rtems.org/";),
- "git": ("Git Repositories",
"https://git.rtems.org/";),
- "ftp": ("FTP File Server",
"https://ftp.rtems.org/";),
- "review": ("Gerrit Code Review",
"https://review.rtems.org/";),
- "bugs": ("Bugs Database",
"https://devel.rtems.org/wiki/Bugs/";),
- "gsoc": ("Google Summer of Code",
"https://devel.rtems.org/wiki/GSoC/";),
- "socis":("ESA SOCIS",
"https://devel.rtems.org/wiki/SOCIS/";)
+ "trac": ("Trac",
"https://devel.rte
[PATCH 3/5] versions: Update arm
From: Chris Johns
Updates #4695
---
user/bsps/arm/altera-cyclone-v.rst | 2 +-
user/bsps/arm/beagle.rst | 11 +++
user/bsps/arm/imx.rst | 6 ++--
user/bsps/arm/imxrt.rst| 33 +++--
user/bsps/arm/raspberrypi.rst | 24
user/bsps/arm/xen.rst | 4 +--
user/bsps/bsps-arm.rst | 46 --
7 files changed, 67 insertions(+), 59 deletions(-)
diff --git a/user/bsps/arm/altera-cyclone-v.rst
b/user/bsps/arm/altera-cyclone-v.rst
index 14c026c..eaa02e3 100644
--- a/user/bsps/arm/altera-cyclone-v.rst
+++ b/user/bsps/arm/altera-cyclone-v.rst
@@ -27,7 +27,7 @@ image. Use the following commands:
.. code-block:: none
-arm-rtems5-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 696b89d..3a5c06f 100644
--- a/user/bsps/arm/beagle.rst
+++ b/user/bsps/arm/beagle.rst
@@ -32,7 +32,7 @@ To boot via uboot, the ELF must be converted to a U-Boot
image like below:
.. code-block:: none
-arm-rtems5-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
@@ -77,7 +77,8 @@ overlay has to be provided. The overlay must add an
additional attribute
For example,
-.. code-block::
+.. code-block:: none
+
/dts-v1/;
/ {
@@ -109,7 +110,7 @@ For registering with a custom path, the
``bsp_register_spi()`` can be used.
The function prototype is given below:
-.. code-block:: C
+.. code-block:: c
rtems_status_code bsp_register_spi(
const char *bus_path,
@@ -153,7 +154,7 @@ The modification is:
The resulting wiring is:
-.. code-block::
+.. code-block:: none
1 === /--=== 2
3 === | === 4
@@ -198,7 +199,7 @@ Cortex M only debuggers (like the Segger J-Link Edu Mini)
won't work.
If the debugger offers a gdb server (like OpenOCD or Segger J-Link) the
following gdb start script can be used:
-.. code-block::
+.. code-block:: none
define reset
echo -- Reset target and wait for U-Boot to start kernel.\n
diff --git a/user/bsps/arm/imx.rst b/user/bsps/arm/imx.rst
index e2fd7f2..f0ac928 100644
--- a/user/bsps/arm/imx.rst
+++ b/user/bsps/arm/imx.rst
@@ -15,7 +15,9 @@ U-Boot or barebox.
Build Configuration Options
---
-The following options are available at the configure command line.
+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_PRESS_KEY_FOR_RESET``
If defined to a non-zero value, then print a message and wait until pressed
@@ -73,7 +75,7 @@ image. Use the following commands:
.. code-block:: none
-arm-rtems5-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 6dacfd9..e185823 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-rtems6-objcopy -O binary
build/arm/imxrt1052/testsuites/samples/hello.exe hello.bin
+ arm-rtems@rtems-ver-major@-objcopy -O binary
build/arm/imxrt1052/testsuites/samples/hello.exe hello.bin
Then just copy the generated binary to the mass storage provided by the
debugger. Wait a bit till the mass storage vanishes and re-appears. After that,
@@ -91,25 +91,26 @@ The BSP uses a FDT based initialization. The FDT is linked
into the application.
You can find the default FDT used in the BSP in
`bsps/arm/imxrt/dts/imxrt1050-evkb.dts`. The FDT is split up into two parts.
The
core part is put into an `dtsi` file and is installed together with normal
-headers into `${PREFIX}/arm-rtems6/imxrt1052/lib/include`. You can use that to
-create your own device tree based on that. Basically use something like::
+headers into `${PREFIX}/arm-rtems@rtems-ver-major@/imxrt1052/lib/include`. You
+can use that to create your own device tree based on that. Basically use
+something like::
/dts-v1/;
-
+
#include
#include
-
+
&lpuart1 {
pinctrl-0 = <&pinctrl_lpuart1>;
status = "okay";
};
-
+
&chosen {
stdout-path = &lpuart1;
};
-
+
/* put your further devices here */
-
+
&iomuxc {
[PATCH 2/5] versions: Update aarch64
From: Chris Johns Updates #4695 --- user/bsps/aarch64/xilinx-zynqmp.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/user/bsps/aarch64/xilinx-zynqmp.rst b/user/bsps/aarch64/xilinx-zynqmp.rst index 239ebe4..2b28132 100644 --- a/user/bsps/aarch64/xilinx-zynqmp.rst +++ b/user/bsps/aarch64/xilinx-zynqmp.rst @@ -116,7 +116,7 @@ Prepare your RTEMS image to boot from u-boot with the following commands: .. code-block:: shell - $ aarch64-rtems6-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 @@ -179,7 +179,7 @@ This is the entire boot sequence: ## Transferring control to RTEMS (at address 1000) ... *** BEGIN OF TEST CLOCK TICK *** - *** TEST VERSION: 6.0.0.f381e9bab29278e4434b1a93e70d17a7562dc64c + *** TEST VERSION: @rtems-version@.f381e9bab29278e4434b1a93e70d17a7562dc64c *** TEST STATE: EXPECTED_PASS *** TEST BUILD: RTEMS_POSIX_API RTEMS_SMP *** TEST TOOLS: 10.3.1 20210409 (RTEMS 6, RSB ad54d1dd3cf8249d9d39deb1dd28b2f294df062d, Newlib eb03ac1) -- 2.24.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 4/5] versions: Update microblaze, powerpc, riscv and x86_64
From: Chris Johns Updates #4695 --- user/bsps/bsps-microblaze.rst | 10 +- user/bsps/bsps-powerpc.rst| 8 user/bsps/bsps-riscv.rst | 3 ++- user/bsps/bsps-x86_64.rst | 2 +- 4 files changed, 12 insertions(+), 11 deletions(-) diff --git a/user/bsps/bsps-microblaze.rst b/user/bsps/bsps-microblaze.rst index e20df53..32aad90 100644 --- a/user/bsps/bsps-microblaze.rst +++ b/user/bsps/bsps-microblaze.rst @@ -53,8 +53,8 @@ The name ``system_dtb`` is significant as it is the name expected by the BSP. $ rtems-bin2c -C -A 8 -N system_dtb my_device_tree.dtb my_dtb The ``BSP_MICROBLAZE_FPGA_DTB_HEADER_PATH`` BSP configuration option can then be -set to the path of the resulting source file, ``my_dtb.c``, to include it in the -BSP build. +set to the path of the resulting source file, ``my_dtb.c``, in the waf INI file +to include it in the BSP build. .. code-block:: none @@ -64,7 +64,7 @@ BSP build. Running Executables --- -A .dtb (device tree blob) file should be provided to QEMU via the ``-hw-dtb`` +A ``.dtb`` (device tree blob) file should be provided to QEMU via the ``-hw-dtb`` option. In the example command below, the device tree blob comes from the Xilinx Petalinux KCU105 MicroBlaze BSP (https://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/embedded-design-tools.html). @@ -94,7 +94,7 @@ Then start GDB and connect to QEMU. .. code-block:: none - $ microblaze-rtems6-gdb build/microblaze/kcu105_qemu/testsuites/samples/hello.exe + $ microblaze-rtems@rtems-ver-major@-gdb build/microblaze/kcu105_qemu/testsuites/samples/hello.exe (gdb) target remote localhost:1234 (gdb) break Init (gdb) continue @@ -146,7 +146,7 @@ application, and debug as usual. By default the GDB server listens on port 3002. .. code-block:: none - $ microblaze-rtems6-gdb example.exe + $ microblaze-rtems@rtems-ver-major@-gdb example.exe (gdb) target extended-remote localhost:3002 (gdb) load (gdb) break Init diff --git a/user/bsps/bsps-powerpc.rst b/user/bsps/bsps-powerpc.rst index 80edfae..3d1ce88 100644 --- a/user/bsps/bsps-powerpc.rst +++ b/user/bsps/bsps-powerpc.rst @@ -36,10 +36,10 @@ image. Use the following commands: .. code-block:: none -powerpc-rtems5-objcopy -O binary -R .comment -S ticker.exe rtems +powerpc-rtems@rtems-ver-major@-objcopy -O binary -R .comment -S ticker.exe rtems gzip -9 -f rtems -powerpc-rtems5-ld -o ticker.boot bootloader.o --just-symbols=ticker.exe -b binary rtems.gz -T ppcboot.lds -no-warn-mismatch -powerpc-rtems5-objcopy -O binary ticker.boot ticker.bin +powerpc-rtems@rtems-ver-major@-ld -o ticker.boot bootloader.o --just-symbols=ticker.exe -b binary rtems.gz -T ppcboot.lds -no-warn-mismatch +powerpc-rtems@rtems-ver-major@-objcopy -O binary ticker.boot ticker.bin mpc55xxevb == @@ -107,7 +107,7 @@ image. Use the following commands: .. code-block:: none -powerpc-rtems5-objcopy -O binary app.exe app.bin +powerpc-rtems@rtems-ver-major@-objcopy -O binary app.exe app.bin gzip -9 -f -c app.bin > app.bin.gz mkimage -A ppc -O linux -T kernel -a 0x4000 -e 0x4000 -n RTEMS -d app.bin.gz app.img diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rst index 0799ad6..5faa87b 100644 --- a/user/bsps/bsps-riscv.rst +++ b/user/bsps/bsps-riscv.rst @@ -50,7 +50,8 @@ The reference platform for this BSP is the Qemu `virt` machine. Build Configuration Options --- -The following options are available at the configure command line. +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_PRESS_KEY_FOR_RESET`` If defined to a non-zero value, then print a message and wait until pressed diff --git a/user/bsps/bsps-x86_64.rst b/user/bsps/bsps-x86_64.rst index eefffab..a7f7326 100644 --- a/user/bsps/bsps-x86_64.rst +++ b/user/bsps/bsps-x86_64.rst @@ -20,7 +20,7 @@ in the RTEMS testsuite. Build Configuration Options --- -There are no options available to ``configure`` at build time, at the moment. +There are no BSP configuration options available at build time. Testing with QEMU - -- 2.24.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 5/5] versions: Update user manual
From: Chris Johns Updates #4695 --- user/exe/initialization.rst | 10 +- user/exe/loader.rst | 12 +- user/hosts/os.rst| 2 +- user/installation/developer.rst | 287 --- user/installation/project-sandboxing.rst | 42 ++-- user/installation/releases.rst | 193 ++- user/start/app.rst | 100 user/start/bsp-build.rst | 95 8 files changed, 252 insertions(+), 489 deletions(-) diff --git a/user/exe/initialization.rst b/user/exe/initialization.rst index 6c9d657..f4b5d7e 100644 --- a/user/exe/initialization.rst +++ b/user/exe/initialization.rst @@ -87,15 +87,15 @@ sample application in the RTEMS kernel's testsuite:: .. code-block:: none - $ rtems-exeinfo --init arm-rtems5/c/xilinx_zynq_zedboard/testsuites/samples/hello.exe - RTEMS Executable Info 5.5416cfa39dd6 - $ rtems-exeinfo --init arm-rtems5/c/xilinx_zynq_zedboard/testsuites/samples/hello.exe - exe: arm-rtems5/c/xilinx_zynq_zedboard/testsuites/samples/hello.exe + $ rtems-exeinfo --init arm-rtems@rtems-ver-major@/c/xilinx_zynq_zedboard/testsuites/samples/hello.exe + RTEMS Executable Info @rtems-ver-major@.5416cfa39dd6 + $ rtems-exeinfo --init arm-rtems@rtems-ver-major@/c/xilinx_zynq_zedboard/testsuites/samples/hello.exe + exe: arm-rtems@rtems-ver-major@/c/xilinx_zynq_zedboard/testsuites/samples/hello.exe Compilation: Producers: 2 | GNU AS 2.31.1: 14 objects - | GNU C11 7.3.0 20180125 (RTEMS 5, RSB e55769c64cf1a201588565a5662deafe3f1ccdcc, Newlib 103b055035fea328f8bc7826801760fb1c055683): 284 objects + | GNU C11 7.3.0 20180125 (RTEMS @rtems-ver-major@, RSB e55769c64cf1a201588565a5662deafe3f1ccdcc, Newlib 103b055035fea328f8bc7826801760fb1c055683): 284 objects Common flags: 4 | -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard diff --git a/user/exe/loader.rst b/user/exe/loader.rst index c11f363..de77343 100644 --- a/user/exe/loader.rst +++ b/user/exe/loader.rst @@ -458,9 +458,9 @@ into the base image. .. code-block:: none - $ sparc-rtems5-gcc -mcpu=cypress foo.o -lrtemsbsp -lrtemscpu -o foo.pre - $ rtems-syms -e -C sparc-rtems5-gcc -c "-mcpu=cypress" -o foo-sym.o foo.pre - $ sparc-rtems5-gcc -mcpu=cypress foo.o foo-sym.o -lrtemsbsp -lrtemscpu -o foo.exe + $ sparc-rtems@rtems-ver-major@-gcc -mcpu=cypress foo.o -lrtemsbsp -lrtemscpu -o foo.pre + $ rtems-syms -e -C sparc-rtems@rtems-ver-major@-gcc -c "-mcpu=cypress" -o foo-sym.o foo.pre + $ sparc-rtems@rtems-ver-major@-gcc -mcpu=cypress foo.o foo-sym.o -lrtemsbsp -lrtemscpu -o foo.exe The link command line steps in this example are not complete. @@ -486,8 +486,8 @@ file. First create the symbol table's executable object file: .. code-block:: none - $ sparc-rtems5-gcc -mcpu=cypress foo.o -lrtemsbsp -lrtemscpu -o foo.exe - $ rtems-syms -C sparc-rtems5-gcc -c "-mcpu=cypress" -o foo-sym.o foo.exe + $ sparc-rtems@rtems-ver-major@-gcc -mcpu=cypress foo.o -lrtemsbsp -lrtemscpu -o foo.exe + $ rtems-syms -C sparc-rtems@rtems-ver-major@-gcc -c "-mcpu=cypress" -o foo-sym.o foo.exe The link command line steps in this example are not complete. @@ -632,7 +632,7 @@ in a library with a single command. .. code-block:: none - $ sparc-rtems5-strip libc.a + $ sparc-rtems@rtems-ver-major@-strip libc.a Large Memory diff --git a/user/hosts/os.rst b/user/hosts/os.rst index 4bb873e..49d7e7e 100644 --- a/user/hosts/os.rst +++ b/user/hosts/os.rst @@ -79,4 +79,4 @@ proven over the years to be difficult to manage in production systems. $ git checkout -t origin/4.11 -Branches are available for the 4.9, 4.10, and 4.11 versions of RTEMS. +Branches are available for the 4.9, 4.10, 4.11 and 5 versions of RTEMS. diff --git a/user/installation/developer.rst b/user/installation/developer.rst index 1b2b785..8acd68c 100644 --- a/user/installation/developer.rst +++ b/user/installation/developer.rst @@ -34,8 +34,8 @@ you can do this without needing to be root. You can also use The location used to install the tools and kernel is called the `prefix`. It is best to have a `prefix` for each different version of RTEMS you are using. If -you are using RTEMS 4.11 in production it is not a good idea to install a -development version of 5 over the top. A separate `prefix` for each version +you are using RTEMS 5 in production it is not a good idea to install a +development version of 6 over the top. A separate `prefix` for each version avoids this. The RTEMS tool chain changes less often than the RTEMS kernel. One method of @@ -84,7 +84,7 @@ requires: $ cd rsb $ ./source-builder/sb-check - RTEMS Source Builder - Check, 5 (089327b5dcf9) + RTEMS Source Builder - Check, @rtems-ver-major@ (089327b5dcf9) Environment is ok If you are unsure how to specify the build set for the architecture you wish to @@ -93,58 +93,102 @@ build, just ask the tool: .. code-block::
[PATCH] commands: Add 'rtems' command
From: Chris Johns --- shell/rtems_specific_commands.rst | 95 +++ 1 file changed, 95 insertions(+) diff --git a/shell/rtems_specific_commands.rst b/shell/rtems_specific_commands.rst index c67f635..a8fcb9b 100644 --- a/shell/rtems_specific_commands.rst +++ b/shell/rtems_specific_commands.rst @@ -10,6 +10,8 @@ Introduction The RTEMS shell has the following RTEMS specific commands: +- rtems_ - Display RTEMS specific detail + - shutdown_ - Shutdown the system - cpuinfo_ - print per-processor information @@ -55,6 +57,99 @@ This section details the RTEMS Specific Commands available. A subsection is dedicated to each of the commands and describes the behavior and configuration of that command as well as providing an example usage. +.. raw:: latex + + \clearpage + +.. _rtems: + +rtems - RTEMS Details +- +.. index:: rtems + +SYNOPSYS: +.. code-block:: shell + +rtems + +DESCRIPTION: +This command reports various RTEMS specific details such as a the +version, CPU and CPU module, BSP name, version of tools and the +build options. + +EXIT STATUS: +This command returns 0 on success and non-zero if an error is encountered. + +NOTES: +The following commands are supported: + +- ``ver``: + Version of RTEMS running + +- ``cpu``: + CPU name and model + +- ``bsp``: + Name of the BSP + +- ``tools``: + Version of the tools used to build RTEMS + +- ``opts``: + RTEMS build options + +- ``all``: + All of the available commands + + +EXAMPLES: +The following is an example of how to use ``rtems``: + +.. code-block:: shell + +SHLL [/] # rtems +RTEMS: 6.0.0 (071640d310b432d15350188c2ebf086653a0d578) + +The version of RTEMS running is displayed. To see the CPU name and +moduel enter: + +.. code-block:: shell + +SHLL [/] # rtems cpu +CPU: SPARC (w/FPU) + +The ``help`` command will list all available commands. The ``all`` +command will display all avalable output: + +.. code-block:: shell + +SHLL [/] # rtems all +RTEMS: 6.0.0 (071640d310b432d15350188c2ebf086653a0d578) +CPU: SPARC (w/FPU) +BSP: erc32 +Tools: 12.1.1 20220622 (RTEMS 6, RSB f4f5d43a98051f7562103aaa2ec7723c628c6947, Newlib ea99f21) +Options: DEBUG POSIX + +.. index:: CONFIGURE_SHELL_NO_COMMAND_RTEMS +.. index:: CONFIGURE_SHELL_COMMAND_RTEMS + +CONFIGURATION: +This command is included in the default shell command set. When building a +custom command set, define ``CONFIGURE_SHELL_COMMAND_RTEMS`` to have +this command included. + +This command can be excluded from the shell command set by defining +``CONFIGURE_SHELL_NO_COMMAND_RTEMS`` when all shell commands have been +configured. + +PROGRAMMING INFORMATION: +The configuration structure for the ``rtems`` has the following +prototype: + +.. code-block:: c + +extern rtems_shell_cmd_t rtems_shell_RTEMS_Command; + .. raw:: latex \clearpage -- 2.24.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] libdl: Fix warnings on 64bit architectures
From: Chris Johns
Updates #4662
---
cpukit/libdl/rtl-elf.c| 2 +-
cpukit/libdl/rtl-obj-comp.c | 6 +++---
cpukit/libdl/rtl-shell.c | 4 ++--
cpukit/libdl/rtl-unresolved.c | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/cpukit/libdl/rtl-elf.c b/cpukit/libdl/rtl-elf.c
index 37d9f4575e..8a21c5df73 100644
--- a/cpukit/libdl/rtl-elf.c
+++ b/cpukit/libdl/rtl-elf.c
@@ -1171,7 +1171,7 @@ rtems_rtl_elf_symbols_load (rtems_rtl_obj* obj,
rtems_chain_set_off_chain (&osym->node);
memcpy (string, name, strlen (name) + 1);
osym->name = string;
-osym->value = (uint8_t*) value;
+osym->value = (void*) (intptr_t) value;
osym->data = symbol.st_shndx;
if (rtems_rtl_trace (RTEMS_RTL_TRACE_SYMBOL))
diff --git a/cpukit/libdl/rtl-obj-comp.c b/cpukit/libdl/rtl-obj-comp.c
index ea408527b7..001d416e80 100644
--- a/cpukit/libdl/rtl-obj-comp.c
+++ b/cpukit/libdl/rtl-obj-comp.c
@@ -115,7 +115,7 @@ rtems_rtl_obj_comp_read (rtems_rtl_obj_comp* comp,
}
if (rtems_rtl_trace (RTEMS_RTL_TRACE_COMP))
-printf ("rtl: comp: %2d: fd=%d length=%zu level=%u offset=%" PRIdoff_t "
area=[%"
+printf ("rtl: comp: %2d: fd=%d length=%zu level=%zu offset=%" PRIdoff_t "
area=[%"
PRIdoff_t ",%" PRIdoff_t "] read=%" PRIu32 " size=%zu\n",
comp->fd, comp->cache->fd, length, comp->level, comp->offset,
comp->offset, comp->offset + length,
@@ -143,7 +143,7 @@ rtems_rtl_obj_comp_read (rtems_rtl_obj_comp* comp,
if ((comp->level - buffer_level) != 0)
{
if (rtems_rtl_trace (RTEMS_RTL_TRACE_COMP))
- printf ("rtl: comp: copy-down: level=%u length=%zu\n",
+ printf ("rtl: comp: copy-down: level=%zu length=%zu\n",
comp->level, comp->level - buffer_level);
memmove (comp->buffer,
@@ -221,7 +221,7 @@ rtems_rtl_obj_comp_read (rtems_rtl_obj_comp* comp,
if (rtems_rtl_trace (RTEMS_RTL_TRACE_COMP))
printf ("rtl: comp: expand: offset=%" PRIdoff_t \
-" level=%u read=%" PRIu32 "\n",
+" level=%zu read=%" PRIu32 "\n",
comp->offset, comp->level, comp->read);
}
}
diff --git a/cpukit/libdl/rtl-shell.c b/cpukit/libdl/rtl-shell.c
index 732f66131e..69de6bad83 100644
--- a/cpukit/libdl/rtl-shell.c
+++ b/cpukit/libdl/rtl-shell.c
@@ -406,7 +406,7 @@ typedef struct
const rtems_rtl_obj_print* print; /**< The print data. */
bool first; /**< Is this the first line printed. */
bool show_name; /**< Show the object name. */
- size_t indent;/**< The indent. */
+ intindent;/**< The indent. */
} rtems_rtl_dep_data;
static bool
@@ -849,7 +849,7 @@ rtems_rtl_shell_archive (const rtems_printer* printer, int
argc, char* argv[])
while (!rtems_chain_is_tail (&rtl->archives.archives, node))
{
-#define SYM_DUPLICATE (1 << ((8 * sizeof (size_t)) - 1))
+#define SYM_DUPLICATE (((size_t) 1) << ((8 * sizeof (size_t)) - 1))
rtems_rtl_archive* archive = (rtems_rtl_archive*) node;
diff --git a/cpukit/libdl/rtl-unresolved.c b/cpukit/libdl/rtl-unresolved.c
index a774c7f1c9..43a05e9887 100644
--- a/cpukit/libdl/rtl-unresolved.c
+++ b/cpukit/libdl/rtl-unresolved.c
@@ -810,8 +810,8 @@ rtems_rtl_unresolved_dump_iterator (rtems_rtl_unresolv_rec*
rec,
case rtems_rtl_trampoline_reloc:
if (dd->show_relocs)
printf (" %3zu: 2:reloc%c: obj:%s name:%2d: sect:%d\n",
- rec->type == rtems_rtl_unresolved_reloc ? 'R' : 'T',
dd->rec,
+ rec->type == rtems_rtl_unresolved_reloc ? 'R' : 'T',
rec->rec.reloc.obj == NULL ? "resolved" :
rec->rec.reloc.obj->oname,
rec->rec.reloc.name,
rec->rec.reloc.sect);
--
2.24.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
