Re: [rtems-source-builder PATCH] rtems: Update tools, kernel and legacy network packages
Hi Chris,
The updates look good to me. Thanks.
On Fri, Apr 14, 2023 at 7:10 PM wrote:
>
> From: Chris Johns
>
> - Tools picks up the stm32h7-stlink to handle SIGTRAP fix.
>
> - RTEMS picks up the motorola_powerpc updates including the mvme2700
> BSP and Makefile.inc fixes for building EPICS.
>
> - Legacy networking picks up a number of build system fixes,
> network configuration changes and more tests.
> ---
> rtems/config/tools/rtems-kernel-6.cfg | 6 +++---
> rtems/config/tools/rtems-net-legacy-6.cfg | 8
> rtems/config/tools/rtems-tools-6.cfg | 4 ++--
> 3 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/rtems/config/tools/rtems-kernel-6.cfg
> b/rtems/config/tools/rtems-kernel-6.cfg
> index 0ee1d04..e2f1d68 100644
> --- a/rtems/config/tools/rtems-kernel-6.cfg
> +++ b/rtems/config/tools/rtems-kernel-6.cfg
> @@ -1,11 +1,11 @@
> #
> -# RTEMS 5
> +# RTEMS 6
> #
>
> -%define rtems_kernel_version d0b92735b0dfd509e1edb82c7145042b67714f43
> +%define rtems_kernel_version 5a37722b066f5792aad80fb5b32fb3c056cf1607
>
> %hash sha512 rtems-kernel-%{rtems_kernel_version}.tar.bz2 \
> -
> XyW9t5NSWAU8eAz1HdbFwOWmLMkAHeheeATznvag57QjP4rZYFeHfIws4ttzmSvODHDI16OJw/CLWQQ9l58SIg==
> +
> UcZlhl2FZhvDKXZnPLnJSYnMQwSgWluTBGfoLII9vNbx4ypxQPE+egN4dZ06H3l5MprrJY96mgNZTfLjI2itcQ==
> #
> # The RTEMS build instructions.
> #
> diff --git a/rtems/config/tools/rtems-net-legacy-6.cfg
> b/rtems/config/tools/rtems-net-legacy-6.cfg
> index fbc7ab8..984ba09 100644
> --- a/rtems/config/tools/rtems-net-legacy-6.cfg
> +++ b/rtems/config/tools/rtems-net-legacy-6.cfg
> @@ -3,10 +3,10 @@
> #
>
> # branch: main
> -%define rtems_net_version 5713f7027984012ea17cdd582e6d0258ee7aa58a
> +%define rtems_net_version d22fbcb0412e309850c0f49ab61bc410184b9b5c
> %hash sha512 rtems-net-legacy-%{rtems_net_version}.tar.bz2 \
> -
> 0dwnqZP+j9b2IZ7rqiEBndVkqIsURal4L/47pSI4pe0rz48hmWa78DE0915Gf+/+nvsCMB2I/sFAMj+P6AjeeA==
> -%define rtems_waf_version 1a118bbcd52138dbdc3236e64bc23fd430a064b1
> +
> eKESsJ4ra5kbF+IjMvhlLriGUxC2vCfKy/7bnkZyrhcBnfkpIWWqzEj1eB2iqfpy/1p+hcnxIh00ysJF66ptkw==
> +%define rtems_waf_version 2c15b90de5c369aa78cd2252a50bba677e9b13f3
> %hash sha512 rtems-waf-%{rtems_waf_version}.tar.bz2 \
> -
> wHiMBCaJjnNd8EEnbl5A9qyGwcQ5E+BcG9Q5SwJmlbarcrQ4U6//Q2ni2XNyXtWQzzy959o6YSg8PvVjgEi0vg==
> +
> gSpj/vTcB9T985HC9xi//gMcYj9rl6AedULvPdFppJ7D1CFIueE+MyfGn+okVtZvnG+tZk1JkR2gvIQNV3mXbQ==
> %include tools/rtems-net-legacy-common.cfg
> diff --git a/rtems/config/tools/rtems-tools-6.cfg
> b/rtems/config/tools/rtems-tools-6.cfg
> index 042e0fa..b786a47 100644
> --- a/rtems/config/tools/rtems-tools-6.cfg
> +++ b/rtems/config/tools/rtems-tools-6.cfg
> @@ -10,14 +10,14 @@
> %define rtems_tools_source rtems-tools-%{rtems_tools_version}
> %define rtems_tools_ext xz
> %else
> - %define rtems_tools_version c8bf7309332990a52ae98ed3926c0f62984e8193
> + %define rtems_tools_version eaf14a654b528b44de14f9da9919555e54324e0d
> %define rtems_tools_ext bz2
> %endif
>
> %define rtems_tools_source rtems-tools-%{rtems_tools_version}
> %source set rtems-tools
> https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
> %hash sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
> -
> XOCIuPQ65yZOvPkiTZb3r2T9YAPBg6az3xz5Z2ivkfygSYZgaymSkmpv5yF3QbCXK1Y+2LRUuEp73oymj7vnbA==
> +
> bcjVLITKdjQLKlalfUptMKLAmvDT0FidARukQHP4rK/8SWpYckPAc8BMMRhS3RX+Ga6NDuxD1Ss/bRlxG6qsdg==
>
> #
> # Optionally enable/disable building the RTEMS Tools via the command line.
> --
> 2.31.1
>
> ___
> 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
[rtems-source-builder PATCH] rtems: Update tools, kernel and legacy network packages
From: Chris Johns
- Tools picks up the stm32h7-stlink to handle SIGTRAP fix.
- RTEMS picks up the motorola_powerpc updates including the mvme2700
BSP and Makefile.inc fixes for building EPICS.
- Legacy networking picks up a number of build system fixes,
network configuration changes and more tests.
---
rtems/config/tools/rtems-kernel-6.cfg | 6 +++---
rtems/config/tools/rtems-net-legacy-6.cfg | 8
rtems/config/tools/rtems-tools-6.cfg | 4 ++--
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/rtems/config/tools/rtems-kernel-6.cfg
b/rtems/config/tools/rtems-kernel-6.cfg
index 0ee1d04..e2f1d68 100644
--- a/rtems/config/tools/rtems-kernel-6.cfg
+++ b/rtems/config/tools/rtems-kernel-6.cfg
@@ -1,11 +1,11 @@
#
-# RTEMS 5
+# RTEMS 6
#
-%define rtems_kernel_version d0b92735b0dfd509e1edb82c7145042b67714f43
+%define rtems_kernel_version 5a37722b066f5792aad80fb5b32fb3c056cf1607
%hash sha512 rtems-kernel-%{rtems_kernel_version}.tar.bz2 \
-
XyW9t5NSWAU8eAz1HdbFwOWmLMkAHeheeATznvag57QjP4rZYFeHfIws4ttzmSvODHDI16OJw/CLWQQ9l58SIg==
+
UcZlhl2FZhvDKXZnPLnJSYnMQwSgWluTBGfoLII9vNbx4ypxQPE+egN4dZ06H3l5MprrJY96mgNZTfLjI2itcQ==
#
# The RTEMS build instructions.
#
diff --git a/rtems/config/tools/rtems-net-legacy-6.cfg
b/rtems/config/tools/rtems-net-legacy-6.cfg
index fbc7ab8..984ba09 100644
--- a/rtems/config/tools/rtems-net-legacy-6.cfg
+++ b/rtems/config/tools/rtems-net-legacy-6.cfg
@@ -3,10 +3,10 @@
#
# branch: main
-%define rtems_net_version 5713f7027984012ea17cdd582e6d0258ee7aa58a
+%define rtems_net_version d22fbcb0412e309850c0f49ab61bc410184b9b5c
%hash sha512 rtems-net-legacy-%{rtems_net_version}.tar.bz2 \
-
0dwnqZP+j9b2IZ7rqiEBndVkqIsURal4L/47pSI4pe0rz48hmWa78DE0915Gf+/+nvsCMB2I/sFAMj+P6AjeeA==
-%define rtems_waf_version 1a118bbcd52138dbdc3236e64bc23fd430a064b1
+
eKESsJ4ra5kbF+IjMvhlLriGUxC2vCfKy/7bnkZyrhcBnfkpIWWqzEj1eB2iqfpy/1p+hcnxIh00ysJF66ptkw==
+%define rtems_waf_version 2c15b90de5c369aa78cd2252a50bba677e9b13f3
%hash sha512 rtems-waf-%{rtems_waf_version}.tar.bz2 \
-
wHiMBCaJjnNd8EEnbl5A9qyGwcQ5E+BcG9Q5SwJmlbarcrQ4U6//Q2ni2XNyXtWQzzy959o6YSg8PvVjgEi0vg==
+
gSpj/vTcB9T985HC9xi//gMcYj9rl6AedULvPdFppJ7D1CFIueE+MyfGn+okVtZvnG+tZk1JkR2gvIQNV3mXbQ==
%include tools/rtems-net-legacy-common.cfg
diff --git a/rtems/config/tools/rtems-tools-6.cfg
b/rtems/config/tools/rtems-tools-6.cfg
index 042e0fa..b786a47 100644
--- a/rtems/config/tools/rtems-tools-6.cfg
+++ b/rtems/config/tools/rtems-tools-6.cfg
@@ -10,14 +10,14 @@
%define rtems_tools_source rtems-tools-%{rtems_tools_version}
%define rtems_tools_ext xz
%else
- %define rtems_tools_version c8bf7309332990a52ae98ed3926c0f62984e8193
+ %define rtems_tools_version eaf14a654b528b44de14f9da9919555e54324e0d
%define rtems_tools_ext bz2
%endif
%define rtems_tools_source rtems-tools-%{rtems_tools_version}
%source set rtems-tools
https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
%hash sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
-
XOCIuPQ65yZOvPkiTZb3r2T9YAPBg6az3xz5Z2ivkfygSYZgaymSkmpv5yF3QbCXK1Y+2LRUuEp73oymj7vnbA==
+
bcjVLITKdjQLKlalfUptMKLAmvDT0FidARukQHP4rK/8SWpYckPAc8BMMRhS3RX+Ga6NDuxD1Ss/bRlxG6qsdg==
#
# Optionally enable/disable building the RTEMS Tools via the command line.
--
2.31.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: FreeBSD libefi import -- how to proceed?
On Fri, Apr 14, 2023, 3:00 PM Gedare Bloom wrote: > On Tue, Mar 28, 2023 at 4:27 AM Karel Gardas > wrote: > > > > > >Folks, > > > > I'm using FreeBSD's libefi on my hacked multiboot2 based amd64 BSP which > > I'd like to push for review (at least). > > > > Now, I'd like to prepare libefi for import but I'm still in doubts if to > > do that in: > > > > - as intact form as possible, import even files which will not be used > > in foreseeable future or even ever > > > It looks like a lot to import wholesale. usually within RTEMS itself > we have been selective and prefer to avoid bringing in dead > code/files. > I think this is a pretty solid guide to follow. Unless you find yourself importing all but a handful anyway. Or there is a clear near term path to needing it. Avoid dead code but don't make it harder to maintain in the future. I like a file named ORIGIN which identifies the source info/hash. > > > - as minimalistic as possible. Include only files really needed by > > RTEMS. Where making compilation issues #ifdef __rtems__ as usual. > > > This would be preferred I think, in rtems.git at least. > Hopefully you can just follow the rules that we use for libbsd. > > > What exactly I need to import is: > > > > https://github.com/freebsd/freebsd-src/tree/main/stand/efi/include > > https://github.com/freebsd/freebsd-src/tree/main/stand/efi/libefi > > > > In 'include' I'd like to omit risc/arm/arm64 platform specific > > subdirectories for now. > > > > Anyway, plan is to put both those directories into > > bsps/shared/freebsd/stand/efi to mimic perfectly location in FBSD tree > > and to have them ready to be reusable later for arm64 and risc-v BSPs > > consumption. > > > I think it makes sense. The only issue to me is that usually the > bootloader stuff is in start/ directory. You might put any > rtems-flavored interfaces to use the efi services into shared/start > perhaps. > Agreed on location. Keeping the FreeBSD source as intact as possible even if it's a subset is critical. Leave architecture specific code under the top shared/.../efi since that's what they did. Maintain source transparency back to the original code. When in doubt, ask yourself: when I revisit this in 5 years to try to update it, will I know what happened? And answer that question with whatever makes life easier for future Karel. :) --joel > > > > > Thanks! > > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-source-builder PATCH] rtems: Add back gsed that was remove by mistake
Sure. Obviously needed. Push it
On Fri, Apr 14, 2023, 5:56 PM wrote:
> From: Chris Johns
>
> - Build GNU sed for hosts that it is not installed on for the MIPS
> tools.
> ---
> rtems/config/tools/rtems-default-tools.bset | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/rtems/config/tools/rtems-default-tools.bset
> b/rtems/config/tools/rtems-default-tools.bset
> index 0291786..35c9235 100644
> --- a/rtems/config/tools/rtems-default-tools.bset
> +++ b/rtems/config/tools/rtems-default-tools.bset
> @@ -6,7 +6,7 @@
> # available
> #
> %define _internal_gsed_path %{_tmpinternal}
> -%defineifnot with_rtems_gmp textproc/gsed-internal
> +%defineifnot with_rtems_gsed textproc/gsed-internal
>
> # GNU tools need texinfo for makeinfo to build documentation
> %define _internal_texinfo_path %{_tmpinternal}
> @@ -21,6 +21,7 @@
> %{with_rtems_dtc}
> %{with_rtems_expat}
> %{with_rtems_gmp}
> +%{with_rtems_gsed}
> %{with_rtems_texinfo}
> %{with_rtems_gdb}
> %{with_rtems_binutils}
> --
> 2.37.1
>
> ___
> 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
[rtems-source-builder PATCH] rtems: Add back gsed that was remove by mistake
From: Chris Johns
- Build GNU sed for hosts that it is not installed on for the MIPS
tools.
---
rtems/config/tools/rtems-default-tools.bset | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/rtems/config/tools/rtems-default-tools.bset
b/rtems/config/tools/rtems-default-tools.bset
index 0291786..35c9235 100644
--- a/rtems/config/tools/rtems-default-tools.bset
+++ b/rtems/config/tools/rtems-default-tools.bset
@@ -6,7 +6,7 @@
# available
#
%define _internal_gsed_path %{_tmpinternal}
-%defineifnot with_rtems_gmp textproc/gsed-internal
+%defineifnot with_rtems_gsed textproc/gsed-internal
# GNU tools need texinfo for makeinfo to build documentation
%define _internal_texinfo_path %{_tmpinternal}
@@ -21,6 +21,7 @@
%{with_rtems_dtc}
%{with_rtems_expat}
%{with_rtems_gmp}
+%{with_rtems_gsed}
%{with_rtems_texinfo}
%{with_rtems_gdb}
%{with_rtems_binutils}
--
2.37.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: FreeBSD libefi import -- how to proceed?
On Tue, Mar 28, 2023 at 4:27 AM Karel Gardas wrote: > > >Folks, > > I'm using FreeBSD's libefi on my hacked multiboot2 based amd64 BSP which > I'd like to push for review (at least). > > Now, I'd like to prepare libefi for import but I'm still in doubts if to > do that in: > > - as intact form as possible, import even files which will not be used > in foreseeable future or even ever > It looks like a lot to import wholesale. usually within RTEMS itself we have been selective and prefer to avoid bringing in dead code/files. > - as minimalistic as possible. Include only files really needed by > RTEMS. Where making compilation issues #ifdef __rtems__ as usual. > This would be preferred I think, in rtems.git at least. > What exactly I need to import is: > > https://github.com/freebsd/freebsd-src/tree/main/stand/efi/include > https://github.com/freebsd/freebsd-src/tree/main/stand/efi/libefi > > In 'include' I'd like to omit risc/arm/arm64 platform specific > subdirectories for now. > > Anyway, plan is to put both those directories into > bsps/shared/freebsd/stand/efi to mimic perfectly location in FBSD tree > and to have them ready to be reusable later for arm64 and risc-v BSPs > consumption. > I think it makes sense. The only issue to me is that usually the bootloader stuff is in start/ directory. You might put any rtems-flavored interfaces to use the efi services into shared/start perhaps. > > Thanks! > 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
Re: [PATCH v2] eng: Add register block specification types
I read this discussion, and it's pretty fascinating. I just want to point out that "linear address" and "linear address space" are both terms defined in Intel documentation for the address you get after doing segmentation but before paging. Just to further complicate the choice of terminology. :) On Tue, Mar 28, 2023 at 2:16 AM Sebastian Huber wrote: > > On 28.03.23 07:53, Chris Johns wrote: > > On 23/3/2023 3:59 am, Sebastian Huber wrote: > >> Hello Chris, > >> > >> I would like to come back to this topic, because it blocks the integration > >> of > >> the sparc/gr712rc and sparc/gr740 changes we have done for the > >> pre-qualification > >> activity. > >> > >> On 27.09.21 02:23, Chris Johns wrote: > >>> On 24/9/21 11:09 pm, Sebastian Huber wrote: > A register block may be used to specify the interface of devices which > use a linear address space. Register blocks consist of register block > >>> Can we please move away from the "linear address" in the definitions? As > >>> stated > >>> previously it only serves a specialized version of a bus and > >>> register-block. > >>> What about something like this: > >>> > >>> A register block specifies a word addressable set of elements in a device > >>> software is required to access and manipulate. The mechanics software > >>> uses to > >>> access a register element in a register-block is defined by the > >>> bus-interface. > >>> The software and register may be a direct coupling to the CPU bus as > >>> found in a > >>> linear cache coherent memory mapped device or the access may be indirect > >>> through > >>> a bus hierarchy that may require more than one software action to > >>> complete. > >>> Device and register specifications are independent of the CPU > >>> architecture and > >>> connecting bus architectures. > >> A linear address space is just an address space in which a single integer > >> is > >> sufficient to address something. So a word addressable set of elements in a > >> device is a linear address space. In contrast to for example the AArch32 > >> system > >> register space, which uses a coprocessor index, Opcode_1, CRn, CRm, and > >> Opcode_2. An address space granule is the smallest block of memory that > >> can be > >> addressed. This could be a subword depending on what a word is and the bus > >> system capabilities. > > I am sorry I have read and reread this and I do not follow. I do not know > > if you > > are saying the aarch64 cp access and addressing is an example for or a > > counter > > example? > > The AArch32 system registers are an example for a not linear or > segmented address space. > > > > > The term "linear address" offers no value. An address bus at any point in a > > circuit is are collection of signals wired to the address decoder of a > > device so > > by the nature of how that works it is going to resolve itself to a number > > and to > > be accurate it is a whole number because the concept of negative addressing > > would be interesting. The wiring of the interfacing address to a device's > > address bus does not have to be 1:1 and it does not need to be continuous > > in the > > external interface's addressing scheme. If linear is saying there is a > > series of > > numbers then again I wonder what the value is. You can view this in > > datasheets > > and code that maps struct to memory mapping devices because reserved (or > > what > > ever they get called) are added. Adding these reserved etc fields is doing > > nothing more than making a memory mapped struct work as you hope and I mean > > hope. That logic needs a continuous address space. > > The register block specification is used to specify a device which > consists of registers with an address. Each register consists of bit > fields. We need a name for the address space of the register block > specification and linear address space is from my point of view the best > name for an address space in which an address is simply an unsigned > integer. How would you name it? > > The register block specification does not specify a bus system. It just > transfers what you have documented in a datasheet of a device. I did > read quite a lot of datasheets and the register block specification > resulted from this experience. Do you have a datasheet which would be > difficult to translate into the proposed scheme? > > Actually the register block specification for the Gailser IP Library was > done by translating the PDF > > https://www.gaisler.com/products/grlib/grip.pdf > > into a text file, parsing the text file with a Python script and then > generating the specification files: > > https://git.rtems.org/rtems-central/tree/spec/dev/grlib/if > > This work was reviewed by the ISVV activity: > > https://devel.rtems.org/ticket/4842 > > > > >> The offsets in the register block specification are just the offset you > >> find in > >> the corresponding datasheet. > >> > >>> I know this is just the commit message but I think this should be in the >
Re: [PATCH 0/3] bsp-howto/console: Remove obsolete references / Fix typos
These look fine. On Thu, Mar 30, 2023 at 6:51 AM Matthew Joyce wrote: > > From: Matt Joyce > > Hello, > > Please find the following edits to bsp-howto/console attached. > > Thanks very much! > > Sincerely, > Matt > > Matt Joyce (3): > bsp-howto/console: Remove reference to old build system > bsp-howto/console: Remove reference to deprecated function > bsp-howto/console: Fix typos > > bsp-howto/console.rst | 32 > 1 file changed, 8 insertions(+), 24 deletions(-) > > -- > 2.35.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: [PATCH 2/2] user/microblaze: Document device tree support
these doc patches ok. please use --subject-prefix to add repo tags in future. https://docs.rtems.org/branches/master/eng/vc-users.html#creating-a-patch On Tue, Apr 4, 2023 at 9:01 AM Alex White wrote: > > --- > user/bsps/bsps-microblaze.rst | 29 - > 1 file changed, 24 insertions(+), 5 deletions(-) > > diff --git a/user/bsps/bsps-microblaze.rst b/user/bsps/bsps-microblaze.rst > index 2a8a6dd..864b3c8 100644 > --- a/user/bsps/bsps-microblaze.rst > +++ b/user/bsps/bsps-microblaze.rst > @@ -21,13 +21,21 @@ Clock Driver > > > The clock driver supports the QEMU emulated Xilinx AXI Timer v2.0. It is > -implemented as a simple downcounter. > +implemented as a simple downcounter. If device tree support is enabled in the > +build configuration, the clock driver will use the node that is compatible > with > +`xlnx,xps-timer-1.00.a` from the device tree to configure the clock. The > +following device tree node properties are used to configure the clock driver: > +``reg``, ``clock-frequency``, and ``interrupts``. > > Console Driver > -- > > The console driver supports the QEMU emulated Xilinx AXI UART Lite v2.0. It > is > -initialized to a baud rate of 115200. > +initialized to a baud rate of 115200. If device tree support is enabled in > the > +build configuration, the console driver will use the node that is compatible > +with `xlnx,xps-uartlite-1.00.a` from the device tree to configure the > console. > +The following device tree node properties are used to configure the console > +driver: ``reg``, ``status``, ``port-number``, and ``interrupts``. > > Network Driver > -- > @@ -68,7 +76,9 @@ The QSPI NOR JFFS2 driver supports the QEMU emulated > n25q512a11 QSPI NOR flash > device. It is initialized to a page size of 256 bytes and a sector size of 64 > KiB. If device tree support is enabled in the build configuration, the QSPI > NOR > JFFS2 driver will use the node that is compatible with `xlnx,xps-spi-2.00.a` > -from the device tree to configure the QSPI NOR JFFS2 driver. > +from the device tree to configure the QSPI NOR JFFS2 driver. The following > +device tree node properties are used to configure the QSPI NOR JFFS2 driver: > +``reg`` and ``interrupts``. > > > Running Executables > @@ -124,12 +134,21 @@ Clock Driver > > > The clock driver supports the Xilinx AXI Timer v2.0. It is implemented as a > -simple downcounter. > +simple downcounter. If device tree support is enabled in the > +build configuration, the clock driver will use the node that is compatible > with > +`xlnx,xps-timer-1.00.a` from the device tree to configure the clock. The > +following device tree node properties are used to configure the clock driver: > +``reg``, ``clock-frequency``, and ``interrupts``. > > Console Driver > -- > > -The console driver supports the Xilinx AXI UART Lite v2.0. > +The console driver supports the Xilinx AXI UART Lite v2.0. It is initialized > to > +a baud rate of 115200. If device tree support is enabled in the build > +configuration, the console driver will use the node that is compatible with > +`xlnx,xps-uartlite-1.00.a` from the device tree to configure the console. The > +following device tree node properties are used to configure the console > driver: > +``reg``, ``status``, ``port-number``, and ``interrupts``. > > Debugging > - > -- > 2.34.1 > > ___ > 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: [lwip 0/6] Add basic support for TMS570LC4357
These patches look good. If time permits, https://docs.rtems.org/branches/master/user/bsps/arm/tms570.html could be improved. On Tue, Apr 4, 2023 at 8:55 AM Sebastian Huber wrote: > > In general, the lwIP stack lacks a generic MDIO/Phy framework. > > Sebastian Huber (6): > Generalize MDIO support > tms570: Fix warning > tms570: Use new pin configuration API > tms570: Add EMACUse100Mbps() > tms570: Add endianess support > tms570: Add data cache support > > cpsw/src/include/hw_mdio.h | 21 ++ > cpsw/src/include/mdio.h | 59 +++-- > cpsw/src/include/phy.h | 26 ++- > cpsw/src/netif/cpswif.c | 47 ++-- > cpsw/src/netif/mdio.c| 58 ++--- > cpsw/src/netif/phy.c | 100 > uLan/ports/driver/tms570_emac/phy_dp83848h.c | 80 +++ > uLan/ports/driver/tms570_emac/phy_dp83848h.h | 26 +-- > uLan/ports/driver/tms570_emac/ti_drv_emac.h | 19 ++ > uLan/ports/driver/tms570_emac/ti_drv_mdio.h | 167 -- > uLan/ports/driver/tms570_emac/tms570_emac.h | 5 +- > uLan/ports/driver/tms570_emac/tms570_netif.c | 231 +++ > 12 files changed, 377 insertions(+), 462 deletions(-) > delete mode 100644 uLan/ports/driver/tms570_emac/ti_drv_mdio.h > > -- > 2.35.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: [PATCH 7/8] bsp/tms570: Add TMS570_VARIANT
nit: would it make sense to include the LS/LC prefixes?
On Tue, Apr 4, 2023 at 8:53 AM Sebastian Huber
wrote:
>
> ---
> spec/build/bsps/arm/tms570/grp.yml| 2 ++
> spec/build/bsps/arm/tms570/optvariant.yml | 21 +
> 2 files changed, 23 insertions(+)
> create mode 100644 spec/build/bsps/arm/tms570/optvariant.yml
>
> diff --git a/spec/build/bsps/arm/tms570/grp.yml
> b/spec/build/bsps/arm/tms570/grp.yml
> index 578cba29ee..1acd00f84b 100644
> --- a/spec/build/bsps/arm/tms570/grp.yml
> +++ b/spec/build/bsps/arm/tms570/grp.yml
> @@ -10,6 +10,8 @@ includes: []
> install: []
> ldflags: []
> links:
> +- role: build-dependency
> + uid: optvariant
> - role: build-dependency
>uid: ../grp
> - role: build-dependency
> diff --git a/spec/build/bsps/arm/tms570/optvariant.yml
> b/spec/build/bsps/arm/tms570/optvariant.yml
> new file mode 100644
> index 00..2925b4bf04
> --- /dev/null
> +++ b/spec/build/bsps/arm/tms570/optvariant.yml
> @@ -0,0 +1,21 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- get-integer: null
> +- assert-in-set:
> + - 3137
> + - 4357
> +- define: null
> +build-type: option
> +copyrights:
> +- Copyright (C) 2023 embedded brains GmbH (http://www.embedded-brains.de)
> +default:
> +- enabled-by: true
> + value: 3137
> +description: |
> + Defines the TMS570 family variant. Use 3137 for the TMS570LS3137 and 4357
> + for the TMSLC4357.
> +enabled-by: true
> +format: '{}'
> +links: []
> +name: TMS570_VARIANT
> +type: build
> --
> 2.35.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: [rtems-net-legacy PATCH] bsd: Add iface calls to help user manage the iface state
On 15/4/2023 12:14 am, Gedare Bloom wrote: > two nits below Thanks for the review. I appreciate you doing it. I will clean these up and push the result. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-net-legacy commit] waf: Generate a version header called rtems-net-legacy.h
On 15/4/2023 12:06 am, Gedare Bloom wrote: > On Thu, Apr 13, 2023 at 11:59 PM Chris Johns wrote: >> +#ifndef _RTEMS_NET_LGEACY_H_ > typo in the header guard Nice catch. Thanks. I will fix this. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 1/3] cpukit/flash: Add API for Flash devices
I focused my review on the API. See below.
On Thu, Apr 6, 2023 at 1:08 AM wrote:
>
> From: Aaron Nyholm
>
[...]
> diff --git a/cpukit/include/dev/flash/flashdev.h
> b/cpukit/include/dev/flash/flashdev.h
> new file mode 100644
> index 00..5d53ea7b97
> --- /dev/null
> +++ b/cpukit/include/dev/flash/flashdev.h
> @@ -0,0 +1,437 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup Flash
> + *
> + * @brief Generic Flash API
> + */
> +
> +/*
> + * Copyright (C) 2023 Aaron Nyholm
> + *
> + * 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 _DEV_FLASHDEV_H
> +#define _DEV_FLASHDEV_H
> +
> +#include
> +#include
> +
> +typedef struct rtems_flashdev rtems_flashdev;
> +
> +/**
> + * @defgroup Generic Flash API
> + *
> + * @ingroup RTEMSDeviceDrivers
> + *
> + * @brief Generic Flash API to wrap specific device drivers.
> + *
> + * @{
> + */
> +
> +/* IOCTL Calls */
> +
> +/**
> + * @brief Obtains the flash device.
> + *
> + * This command has no argument.
> + */
> +#define RTEMS_FLASHDEV_IOCTL_OBTAIN 0
> +/**
> + * @brief Releases the flash device.
> + *
> + * This command has no argument.
> + */
> +#define RTEMS_FLASHDEV_IOCTL_RELEASE 1
> +/**
> + * @brief Returns the JEDEC ID of the flash device.
> + *
> + * @param[out] jedec_id Pointer to uint32_t in which the JEDEC ID is
> + * returned in.
> + */
> +#define RTEMS_FLASHDEV_IOCTL_JEDEC_ID 2
> +/**
> + * @brief Erases flash device.
> + *
> + * @param[in] erase_args Pointer to rtems_flashdev_ioctl_erase_args struct
> + * containing offset and size of erase to be performed.
> + */
> +#define RTEMS_FLASHDEV_IOCTL_ERASE 3
> +/**
> + * @brief Set a region that limits read, write and erase calls to within it.
> + * Regions are file descriptor specific and limited to a single region per
> + * file descriptor and 32 regions total per flash device. Regions can be
> + * changed or updated by calling this IOCTL again.
> + *
> + * @param[in] region Pointer to rtems_flashdev_ioctl_region struct containing
> + * base and length of defined region.
> + */
> +#define RTEMS_FLASHDEV_IOCTL_REGION_SET 4
> +/**
> + * @brief Removes the set region on the file descriptor.
> + *
> + * This command has no argument.
> + */
> +#define RTEMS_FLASHDEV_IOCTL_REGION_UNSET 5
> +/**
> + * @brief Returns the type of flash device (e.g. NOR or NAND).
> + *
> + * @param[out] flash_type Pointer to integer which is set to the flash
> + * type macro value.
> + */
> +#define RTEMS_FLASHDEV_IOCTL_TYPE 6
> +
> +/**
> + * @brief Get the size and address of flash page at given offset
> + *
> + * The offset ignores the region limiting. To find page of region
> + * limited offset add the base of the region to the desired offset.
> + *
> + * @param[in,out] rtems_flashdev_ioctl_page_info arg Pointer to struct
> + * with offset and space for return values.
> + */
> +#define RTEMS_FLASHDEV_IOCTL_PAGEINFO_BY_OFFSET 7
> +
> +/**
> + * @brief Get the size and address of nth flash page where n is index passed
> in.
> + *
> + * The index ignores the region limiting.
> + *
> + * @param[in,out] rtems_flashdev_ioctl_page_info arg Pointer to struct
> + * with index and space for return values.
> + */
> +#define RTEMS_FLASHDEV_IOCTL_PAGEINFO_BY_INDEX 8
> +
> +/**
> + * @brief Get the number of pages in flash device.
> + *
> + * @param[out] count Integer containing the number of pages.
> + */
> +#define RTEMS_FLASHDEV_IOCTL_PAGE_COUNT 9
> +
> +/**
> + * @brief Get the minimum write size supported by the driver.
> + *
> + * @param[out] count Integer containing the minimum write size.
> + */
> +#define RTEMS_FLASHDEV_IOCTL_WRITE_BLOCK_SIZE 10
> +
> +/* Flash Types */
>
Re: [PATCH 0/1] Improve coherence of user/start docs
Merged, thank you. On Thu, Apr 6, 2023 at 5:45 PM Utkarsh Verma wrote: > > Hi, > > This is just a gentle reminder for this patch. Please let me know if I could > improve anything. > > Regards, > Utkarsh > > On Wed, Mar 29, 2023 at 6:08 AM Utkarsh Verma wrote: >> >> This patch improves consistency of the documentation in the user/start >> section. In app.rst, absolute path has been removed because the PATH had >> already been set appropriately in the previous page, i.e. bsp-buil. In >> bsp-build.rst, instructions have been removed for manually creating a >> build directory as it is unnecessary. Apart from that, minor grammatical >> fixes have been made. >> >> Utkarsh Verma (1): >> bsp-howto: Fix grammar and improve coherence. >> >> user/start/app.rst | 2 +- >> user/start/bsp-build.rst | 17 + >> 2 files changed, 6 insertions(+), 13 deletions(-) >> >> -- >> 2.40.0 >> >> > ___ > 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] README for raspberry pi 4 AArch64 BSP
Thanks, for the confirmation. I'll add it to the docs. On Fri, 14 Apr 2023 at 19:52, Gedare Bloom wrote: > On Mon, Apr 10, 2023 at 4:05 AM Noor Aman wrote: > > > > Thanks for the suggestions, > > > > I'll wait for a few days to receive a confirmation or so and after that, > I'll update the documentation instead of adding a README to RTEMS if > required. > > > Yes, it is preferred to put this information to the docs as linked by > Karel. Ask if you need help with that. > > > Thanks, > > > > On Sun, Apr 9, 2023, 10:39 PM Karel Gardas > wrote: > >> > >> > >> Hi, > >> > >> nice patch. I'm not sure if I'm right here, but I've thought the idea is > >> to get rid of BSPs specific README files and move all the information > >> into the RTEMS user docs. If I'm right, then it would be great if you > >> merge your changes to the doc you already pointed out: > >> > >> > https://docs.rtems.org/branches/master/user/bsps/bsps-aarch64.html#raspberry-pi-4b > >> > >> If you would like to work on that, then please clone the docs repo from > >> here: git://git.rtems.org/rtems-docs.git > >> > >> and edit user/bsps/aarch64/raspberrypi4.rst file > >> > >> You will also need to have some tools installed in order to work on > >> that, it is well described in the first paragraph here: > >> https://docs.rtems.org/ > >> > >> If you are unsure, wait for official deny or confirmation of the info > >> provided by me... > >> > >> Thanks, > >> Karel > >> > >> On 4/9/23 09:53, Mohd Noor Aman wrote: > >> > The readme file includes all links and steps for setting up > developping > >> > environment for the raspberry pi 4. Added cheap JTAG adapters list > which are > >> > tried and tested. Links for references for raspberry pi 4 are also > added. > >> > --- > >> > bsps/aarch64/raspberrypi/README | 86 > + > >> > 1 file changed, 86 insertions(+) > >> > create mode 100644 bsps/aarch64/raspberrypi/README > >> > > >> > diff --git a/bsps/aarch64/raspberrypi/README > b/bsps/aarch64/raspberrypi/README > >> > new file mode 100644 > >> > index 00..9c6465fd5e > >> > --- /dev/null > >> > +++ b/bsps/aarch64/raspberrypi/README > >> > @@ -0,0 +1,86 @@ > >> > +BSP for the Raspberry Pi aarch64 ArmV8 board > >> > + > >> > +It currently supports the following peripheral: > >> > +-- Console using the PL011 UART0 Raspberry Pi 4 has 6 UARTs, 5 PL011 > based and 1 > >> > + miniuart based. Only PL011 UART0 is supported. No support for > Mini-UART. The > >> > + console driver only works with polled mode right now. > >> > + > >> > +-- The clock driver uses the ARM Generic Timer. > >> > + > >> > +-- GIC-400 is compatible with gicv2 headers and is supported by bsp > >> > + > >> > + > >> > +How to boot: Steps on how to boot RTEMS on raspberry pi 4B is given > here. > >> > + > >> > + > https://docs.rtems.org/branches/master/user/bsps/bsps-aarch64.html#raspberry-pi-4b > >> > + > >> > + > >> > +To do list: It would be nice to get support in the BSP for the > following: > >> > +-- SD card > >> > +-- SPI > >> > +-- I2C > >> > +-- GPIO > >> > +-- Graphics console > >> > +-- Sound > >> > + > >> > + > >> > +JTAG debugging: OpenOCD supports bcm2711 as a target. Many > interfaces are > >> > +supported to work with bcm2711. A few of them which I have tested > personally > >> > +are. > >> > + > >> > +FT232H: Nice and cheap adapter which supports SPI, I2C JTAG using > MPSSE engine. > >> > +It can either be used as a UART-to-USB or JTAG adapter at a time. > >> > + > >> > +Esp-prog: its just a FT2232H breakout board which can connect using > FT2232H > >> > +derivatives cfg > >> > + > >> > +Raspberry Pi SBC: Yes, you can use a raspberry pi to debug another > raspberry pi > >> > + > >> > +Raspberry Pi Pico: As of now, openocd support for Raspberry pi Pico > is under > >> > +review, in the meantime you can just build forked version of > OpenOCD, and use > >> > +pico-dirtyJTAG.uf2 for raspberry pi pico. > >> > +https://sourceforge.net/u/phdussud/openocd > >> > +https://github.com/phdussud/pico-dirtyJtag > >> > + > >> > +Some of the interfaces which I have not used personally but can most > probably be > >> > +used are: > >> > + > >> > +FT2XXXH series : They are of same family as FT232H, just have > different amount > >> > +of MPSSE engine, Which determines how many many protocols can be ran > >> > +simultaneously. > >> > + > >> > +BeagleBone Black: It can be used with OpenOCDs am335xgpio drivers to > be used as > >> > +JTAG/SWD programmer > >> > + > >> > +Almost every SBC with GPIO: It can be used by openOCD through > libgpiod library > >> > + > >> > + > >> > +Openocd compilation steps for Raspberry pi: > >> > + > >> > +git clone http://openocd.zylin.com/openocd > >> > +cd openocd > >> > +./bootstrap > >> > +./configure --enable-sysfsgpio --enable-bcm2835gpio > >> > +make -j$(nproc) > >> > + > >> > + > >> > +Credits and links: > >> > + > >> > + A bare metal example which includes examples
Re: [PATCH] README for raspberry pi 4 AArch64 BSP
On Mon, Apr 10, 2023 at 4:05 AM Noor Aman wrote: > > Thanks for the suggestions, > > I'll wait for a few days to receive a confirmation or so and after that, I'll > update the documentation instead of adding a README to RTEMS if required. > Yes, it is preferred to put this information to the docs as linked by Karel. Ask if you need help with that. > Thanks, > > On Sun, Apr 9, 2023, 10:39 PM Karel Gardas wrote: >> >> >> Hi, >> >> nice patch. I'm not sure if I'm right here, but I've thought the idea is >> to get rid of BSPs specific README files and move all the information >> into the RTEMS user docs. If I'm right, then it would be great if you >> merge your changes to the doc you already pointed out: >> >> https://docs.rtems.org/branches/master/user/bsps/bsps-aarch64.html#raspberry-pi-4b >> >> If you would like to work on that, then please clone the docs repo from >> here: git://git.rtems.org/rtems-docs.git >> >> and edit user/bsps/aarch64/raspberrypi4.rst file >> >> You will also need to have some tools installed in order to work on >> that, it is well described in the first paragraph here: >> https://docs.rtems.org/ >> >> If you are unsure, wait for official deny or confirmation of the info >> provided by me... >> >> Thanks, >> Karel >> >> On 4/9/23 09:53, Mohd Noor Aman wrote: >> > The readme file includes all links and steps for setting up developping >> > environment for the raspberry pi 4. Added cheap JTAG adapters list which >> > are >> > tried and tested. Links for references for raspberry pi 4 are also added. >> > --- >> > bsps/aarch64/raspberrypi/README | 86 + >> > 1 file changed, 86 insertions(+) >> > create mode 100644 bsps/aarch64/raspberrypi/README >> > >> > diff --git a/bsps/aarch64/raspberrypi/README >> > b/bsps/aarch64/raspberrypi/README >> > new file mode 100644 >> > index 00..9c6465fd5e >> > --- /dev/null >> > +++ b/bsps/aarch64/raspberrypi/README >> > @@ -0,0 +1,86 @@ >> > +BSP for the Raspberry Pi aarch64 ArmV8 board >> > + >> > +It currently supports the following peripheral: >> > +-- Console using the PL011 UART0 Raspberry Pi 4 has 6 UARTs, 5 PL011 >> > based and 1 >> > + miniuart based. Only PL011 UART0 is supported. No support for >> > Mini-UART. The >> > + console driver only works with polled mode right now. >> > + >> > +-- The clock driver uses the ARM Generic Timer. >> > + >> > +-- GIC-400 is compatible with gicv2 headers and is supported by bsp >> > + >> > + >> > +How to boot: Steps on how to boot RTEMS on raspberry pi 4B is given here. >> > + >> > + >> > https://docs.rtems.org/branches/master/user/bsps/bsps-aarch64.html#raspberry-pi-4b >> > + >> > + >> > +To do list: It would be nice to get support in the BSP for the following: >> > +-- SD card >> > +-- SPI >> > +-- I2C >> > +-- GPIO >> > +-- Graphics console >> > +-- Sound >> > + >> > + >> > +JTAG debugging: OpenOCD supports bcm2711 as a target. Many interfaces are >> > +supported to work with bcm2711. A few of them which I have tested >> > personally >> > +are. >> > + >> > +FT232H: Nice and cheap adapter which supports SPI, I2C JTAG using MPSSE >> > engine. >> > +It can either be used as a UART-to-USB or JTAG adapter at a time. >> > + >> > +Esp-prog: its just a FT2232H breakout board which can connect using >> > FT2232H >> > +derivatives cfg >> > + >> > +Raspberry Pi SBC: Yes, you can use a raspberry pi to debug another >> > raspberry pi >> > + >> > +Raspberry Pi Pico: As of now, openocd support for Raspberry pi Pico is >> > under >> > +review, in the meantime you can just build forked version of OpenOCD, and >> > use >> > +pico-dirtyJTAG.uf2 for raspberry pi pico. >> > +https://sourceforge.net/u/phdussud/openocd >> > +https://github.com/phdussud/pico-dirtyJtag >> > + >> > +Some of the interfaces which I have not used personally but can most >> > probably be >> > +used are: >> > + >> > +FT2XXXH series : They are of same family as FT232H, just have different >> > amount >> > +of MPSSE engine, Which determines how many many protocols can be ran >> > +simultaneously. >> > + >> > +BeagleBone Black: It can be used with OpenOCDs am335xgpio drivers to be >> > used as >> > +JTAG/SWD programmer >> > + >> > +Almost every SBC with GPIO: It can be used by openOCD through libgpiod >> > library >> > + >> > + >> > +Openocd compilation steps for Raspberry pi: >> > + >> > +git clone http://openocd.zylin.com/openocd >> > +cd openocd >> > +./bootstrap >> > +./configure --enable-sysfsgpio --enable-bcm2835gpio >> > +make -j$(nproc) >> > + >> > + >> > +Credits and links: >> > + >> > + A bare metal example which includes examples for interrupts, SMP, >> > bluetooth >> > + https://github.com/isometimes/rpi4-osdev/ >> > + >> > + A Raspberry pi 4 port for RT-Thread which support Ethernet, mailbox and >> > UARTs >> > + >> > https://github.com/RT-Thread/rt-thread/tree/master/bsp/raspberry-pi/raspi4-64 >> > + >> > + Vxworks is a
Re: [rtems-net-legacy PATCH] bsd: Add iface calls to help user manage the iface state
two nits below
On Wed, Apr 12, 2023 at 8:17 PM wrote:
>
> From: Chris Johns
>
> ---
> include/rtems/bsd/iface.h | 62 +++
> netsources.py | 26 +++
> rtems/rtems-bsd-iface.c | 154 ++
> testsuites/wscript| 8 ++
> wscript | 7 +-
> 5 files changed, 236 insertions(+), 21 deletions(-)
> create mode 100755 include/rtems/bsd/iface.h
> create mode 100755 rtems/rtems-bsd-iface.c
>
> diff --git a/include/rtems/bsd/iface.h b/include/rtems/bsd/iface.h
> new file mode 100755
> index 000..9e583b8
> --- /dev/null
> +++ b/include/rtems/bsd/iface.h
> @@ -0,0 +1,62 @@
> +/**
> + * @file
> + *
> + * @ingroup rtems_bsd_rtems
> + *
> + * @brief This file provide a high level interface to simple interface
> + * support calls.
> + */
> +
> +/*
> + * Copyright (c) 2021. 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 AUTHOR 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 AUTHOR 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_BSD_IFACE_H_
> +#define _RTEMS_BSD_IFACE_H_
> +
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +
> +struct rtems_bsd_iface {
> + char name[IFNAMSIZ];
> + int unit;
> + struct in_addr address;
> + size_t hw_len;
> + uint8_t hw_address[16];
> + struct ifreq ifr;
> + int linkstate;
> +};
> +
> +/*
> + * These calls return 0 is successful and -1 and errno set on error.
> + */
> +int rtems_bsd_iface_get(const char *name, struct rtems_bsd_iface *iface);
> +int rtems_bsd_iface_link_state(const char *name, bool *state);
> +
> +#endif
> diff --git a/netsources.py b/netsources.py
> index be9334d..9f1b7ff 100644
> --- a/netsources.py
> +++ b/netsources.py
> @@ -31,6 +31,7 @@ class source:
> # rtems
> 'rtems/mkrootfs.c',
> 'rtems/rtems_bootp.c',
> +'rtems/rtems-bsd-iface.c',
> 'rtems/rtems_bsdnet_malloc_starvation.c',
> 'rtems/rtems_dhcp.c',
> 'rtems/rtems_dhcp_failsafe.c',
> @@ -223,22 +224,12 @@ class source:
> ]
>
> nfsclient = [
> -'pppd/auth.c',
> -'pppd/ccp.c',
> -'pppd/chap.c',
> -'pppd/chap_ms.c',
> -'pppd/chat.c',
> -'pppd/demand.c',
> -'pppd/fsm.c',
> -'pppd/ipcp.c',
> -'pppd/lcp.c',
> -'pppd/magic.c',
> -'pppd/options.c',
> -'pppd/rtemsmain.c',
> -'pppd/rtemspppd.c',
> -'pppd/sys-rtems.c',
> -'pppd/upap.c',
> -'pppd/utils.c',
> +'nfsclient/proto/mount_prot_xdr.c',
> +'nfsclient/proto/nfs_prot_xdr.c',
> +'nfsclient/src/nfs.c',
> +'nfsclient/src/rpcio.c',
> +'nfsclient/src/sock_mbuf.c',
> +'nfsclient/src/xdr_mbuf.c',
> ]
>
> pppd = [
> @@ -316,6 +307,9 @@ header = {
> 'rtems/rtems_mii_ioctl.h', 'rtems/rtems_netdb.h',
> 'rtems/rtems_netinet_in.h', 'rtems/rtems_syscall.h'
> ],
> +'rtems/bsd': [
> +'include/rtems/bsd/iface.h',
> +],
> 'rtems/bsdnet': ['rtems/bsdnet/_types.h', 'rtems/bsdnet/servers.h'],
> 'sys': [
> 'sys/callout.h', 'sys/conf.h', 'sys/domain.h', 'sys/kernel.h',
> diff --git a/rtems/rtems-bsd-iface.c b/rtems/rtems-bsd-iface.c
> new file mode 100755
> index 000..0f6432f
> --- /dev/null
> +++ b/rtems/rtems-bsd-iface.c
> @@ -0,0 +1,154 @@
> +/**
> + * @file
> + *
> + * @ingroup rtems_bsd_rtems
> + *
> + * @brief Interface support routines
> + */
> +
> +/*
> + * Copyright (c) 2021. 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:
Re: [rtems-net-legacy commit] waf: Generate a version header called rtems-net-legacy.h
On Thu, Apr 13, 2023 at 11:59 PM Chris Johns wrote:
>
> Module:rtems-net-legacy
> Branch:main
> Commit:bef50b9ff76d3f6231e3c92bb35d47ee5bc7f0cb
> Changeset:
> http://git.rtems.org/rtems-net-legacy/commit/?id=bef50b9ff76d3f6231e3c92bb35d47ee5bc7f0cb
>
> Author:Chris Johns
> Date: Thu Apr 13 18:28:47 2023 -1000
>
> waf: Generate a version header called rtems-net-legacy.h
>
> ---
>
> include/rtems/rtems-net-legacy.h.in | 42
> +
> netlegacy.py| 35 ---
> rtems_waf | 2 +-
> 3 files changed, 75 insertions(+), 4 deletions(-)
>
> diff --git a/include/rtems/rtems-net-legacy.h.in
> b/include/rtems/rtems-net-legacy.h.in
> new file mode 100755
> index 000..a17ec21
> --- /dev/null
> +++ b/include/rtems/rtems-net-legacy.h.in
> @@ -0,0 +1,42 @@
> +/**
> + * @file
> + *
> + * @ingroup rtems_net_legacy
> + *
> + * @brief This file is generated
> + */
> +
> +/*
> + * Copyright (c) 2023. 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 AUTHOR 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 AUTHOR 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_NET_LGEACY_H_
typo in the header guard
> +#define _RTEMS_NET_LEGACY_H_
> +
> +#define RTEMS_NET_LEGACY_VERSION @RTEMS_NET_LEGACY_VERSION@
> +
> +#define RTEMS_NET_LEGACY_MAJOR@RTEMS_NET_LEGACY_MAJOR@
> +#define RTEMS_NET_LEGACY_REVISION @RTEMS_NET_LEGACY_REVISION@
> +
> +#endif /* _RTEMS_NET_LGEACY_H_ */
> diff --git a/netlegacy.py b/netlegacy.py
> index 60775dc..9f27ffc 100644
> --- a/netlegacy.py
> +++ b/netlegacy.py
> @@ -29,12 +29,31 @@
> import os
> import os.path
>
> +from rtems_waf import git
> from rtems_waf import rtems
> +from rtems_waf import version
>
> import bsp_drivers
> import netsources
>
>
> +def version_header(bld):
> +versions = {
> +'RTEMS_NET_LEGACY_VERSION':
> +'"' + bld.env.RTEMS_NET_LEGACY_VERSION + '"',
> +'RTEMS_NET_LEGACY_MAJOR': bld.env.RTEMS_NET_LEGACY_MAJOR,
> +'RTEMS_NET_LEGACY_REVISION':
> +'"' + bld.env.RTEMS_NET_LEGACY_REVISION + '"',
> +}
> +sed = 'sed '
> +for cfg in versions:
> +sed += "-e 's/@%s@/%s/' " % (cfg, versions[cfg])
> +bld(target='include/rtems/rtems-net-legacy.h',
> +source='include/rtems/rtems-net-legacy.h.in',
> +rule=sed + ' < ${SRC} > ${TGT}',
> +update_outputs=True)
> +
> +
> def net_config_header(bld):
> if not os.path.exists(bld.env.NET_CONFIG):
> bld.fatal('network configuraiton \'%s\' not found' %
> @@ -88,7 +107,14 @@ def options(opt):
>
>
> def bsp_configure(conf, arch_bsp, mandatory=True):
> -ab = rtems.arch(arch_bsp) + '/' + rtems.bsp(arch_bsp)
> +conf.start_msg('Checking version')
> +version.load_rtems_version_header(conf, conf.env.RTEMS_VERSION, arch_bsp,
> + conf.env.IFLAGS)
> +conf.env.RTEMS_NET_LEGACY_VERSION = version.string(conf)
> +conf.env.RTEMS_NET_LEGACY_MAJOR = version.version(conf)
> +conf.env.RTEMS_NET_LEGACY_REVISION = version.revision(conf)
> +conf.end_msg(conf.env.RTEMS_NET_LEGACY_VERSION)
> +ab = rtems.arch_bsp_name(arch_bsp)
> includes = [
> '.',
> 'include',
> @@ -125,9 +151,9 @@ def bsp_configure(conf, arch_bsp, mandatory=True):
>
>
> def build(bld):
> -arch_bsp = bld.env.RTEMS_ARCH_BSP
> -ab = rtems.arch(arch_bsp) + '/' + rtems.bsp(arch_bsp)
> +ab = rtems.arch_bsp_name(bld.env.RTEMS_ARCH_BSP)
>
> +version_header(bld)
> net_config_header(bld)
>
> if ab in bsp_drivers.source:
> @@ -173,3 +199,6 @@ def build(bld):
> bld.install_as(
> os.path.join(bld.env.PREFIX,
Re: AW: [PATCH 02/18] ptpd: Add VERSION file
On 13.04.23 12:20, gabriel.moy...@dlr.de wrote: But before submitting the patches again, is there any other change suggested? Not from my side. -- 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
