Re: [PATCH] fsnofs01/init.c: Check for ENOENT from utime().

On 08/06/2021 20:16, Joel Sherrill wrote: The addition of the entire*utime*() family of functions resulted in this call returning ENOENT not ENXIO. This is better aligned with the POSIX definition of the methods. Does this utime(path, NULL) call essentially fail because the fstat_h handler ret

Re: [PATCH] bsps/zynqmp: Allow any or all CGEMs to be enabled

On 08/06/2021 22:18, Kinsey Moore wrote: Provide the options necessary to enable any combination of CGEM ethernet interfaces in LibBSD. The default is still CGEM3, so this should continue to operate as expected on typical Zynq Ultrascale+ MPSoC development hardware. An alternative to this confi

Re: [PATCH rtems-docs 2/2] user: add bsps/aarch64/a72.rst

Looks good. On 6/8/2021 15:44, Gedare Bloom wrote: --- user/bsps/aarch64/a72.rst | 35 +++ user/bsps/bsps-aarch64.rst | 1 + 2 files changed, 36 insertions(+) create mode 100644 user/bsps/aarch64/a72.rst diff --git a/user/bsps/aarch64/a72.rst b/user/bsps/

Re: [PATCH rtems-docs 1/2] user: fix typo in aarch64/a53.rst

On 6/8/2021 15:44, Gedare Bloom wrote: --- user/bsps/aarch64/a53.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/user/bsps/aarch64/a53.rst b/user/bsps/aarch64/a53.rst index 02891e0..52e1509 100644 --- a/user/bsps/aarch64/a53.rst +++ b/user/bsps/aarch64/a53.rst @@ -32,4

Re: [PATCH rtems-tools] tester: Add a72_lp64_qemu.ini

Looks good. On 6/8/2021 15:33, Gedare Bloom wrote: --- tester/rtems/testing/bsps/a72_lp64_qemu.ini | 38 + 1 file changed, 38 insertions(+) create mode 100644 tester/rtems/testing/bsps/a72_lp64_qemu.ini diff --git a/tester/rtems/testing/bsps/a72_lp64_qemu.ini b/tester/

Re: [PATCH] aarch64: add qemu bsps for cortex-a72

Looks good. On 6/8/2021 15:32, Gedare Bloom wrote: The a72 BSPs are identical to the a53 BSPs just changing a53 to a72. --- bsps/aarch64/a72/console/console.c| 69 + bsps/aarch64/a72/include/bsp.h| 74 +++ bsps/aarch64/a72/include/b

Re: [PATCH rtems 2/2] bsps/imxrt: Simplify linkcmds and make it flexible

On 8/6/21 8:26 pm, Sebastian Huber wrote: > On 08/06/2021 05:07, Chris Johns wrote: >> On 7/6/21 6:40 pm, Christian Mauderer wrote:> I think the Options don't need >> documentation changes because the options in the >>> waf based build system are now documented directly in the yaml files and >>> p

Re: code review: help implementing clock_montonic

hello, I used rtems_timespec_subtract to do all the arithmetic, I think that I have addressed the thing you wanted me to fix. Should I send a patch for you to look at? Zack Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, June 8th, 2021 at 4:34 PM, Gedare Bloo

[PATCH rtems-docs 1/2] user: fix typo in aarch64/a53.rst

--- user/bsps/aarch64/a53.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/user/bsps/aarch64/a53.rst b/user/bsps/aarch64/a53.rst index 02891e0..52e1509 100644 --- a/user/bsps/aarch64/a53.rst +++ b/user/bsps/aarch64/a53.rst @@ -32,4 +32,4 @@ Running Executables Executables g

[PATCH rtems-docs 2/2] user: add bsps/aarch64/a72.rst

--- user/bsps/aarch64/a72.rst | 35 +++ user/bsps/bsps-aarch64.rst | 1 + 2 files changed, 36 insertions(+) create mode 100644 user/bsps/aarch64/a72.rst diff --git a/user/bsps/aarch64/a72.rst b/user/bsps/aarch64/a72.rst new file mode 100644 index 000..e8e4b3

Re: [PATCH rtems-tools] tester: Add a72_lp64_qemu.ini

test results: Passed:546 Failed: 1 User Input: 5 Expected Fail: 0 Indeterminate: 1 Benchmark: 3 Timeout: 2 Test too long: 0 Invalid: 0 Wrong Version: 0 Wrong Build: 0 Wrong Tools: 0 -- Total: 558 Failures: fsnofs0

[PATCH rtems-tools] tester: Add a72_lp64_qemu.ini

--- tester/rtems/testing/bsps/a72_lp64_qemu.ini | 38 + 1 file changed, 38 insertions(+) create mode 100644 tester/rtems/testing/bsps/a72_lp64_qemu.ini diff --git a/tester/rtems/testing/bsps/a72_lp64_qemu.ini b/tester/rtems/testing/bsps/a72_lp64_qemu.ini new file mode 100644

[PATCH] aarch64: add qemu bsps for cortex-a72

The a72 BSPs are identical to the a53 BSPs just changing a53 to a72. --- bsps/aarch64/a72/console/console.c| 69 + bsps/aarch64/a72/include/bsp.h| 74 +++ bsps/aarch64/a72/include/bsp/irq.h| 67 + bsps/aarch64/

Re: [PATCH] rtemsbsd: Make ZynqMP CGEM interfaces selectable

Please use the the --subject-prefix="PATCH rtems-libbsd" as mentioned in https://docs.rtems.org/branches/master/eng/vc-users.html#creating-a-patch This helps set the context of the patch review better for non-rtems.git patches. This patch looks good to me. On Tue, Jun 8, 2021 at 2:19 PM Kinsey M

Re: [PATCH] bsps/zynqmp: Allow any or all CGEMs to be enabled

ok On Tue, Jun 8, 2021 at 2:18 PM Kinsey Moore wrote: > > Provide the options necessary to enable any combination of CGEM ethernet > interfaces in LibBSD. The default is still CGEM3, so this should > continue to operate as expected on typical Zynq Ultrascale+ MPSoC > development hardware. > --- >

[PATCH] rtemsbsd: Make ZynqMP CGEM interfaces selectable

Use the new options from the ZynqMP BSPs to allow selection of the available CGEM ethernet interfaces. --- rtemsbsd/include/bsp/nexus-devices.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/rtemsbsd/include/bsp/nexus-devices.h b/rtemsbsd/include/bsp/nexus-devices.h index 5b51de

[PATCH] bsps/zynqmp: Allow any or all CGEMs to be enabled

Provide the options necessary to enable any combination of CGEM ethernet interfaces in LibBSD. The default is still CGEM3, so this should continue to operate as expected on typical Zynq Ultrascale+ MPSoC development hardware. --- spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml| 8 .../

Re: code review: help implementing clock_montonic

ping Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, May 15th, 2021 at 9:22 PM, zack_on_the_speed_chanel wrote: > Use helper functions in rtems/timespec.h or score/timespec.h > > > (depending where you implement your code, in this case, you probably > > > > u

Re: code review: help implementing clock_montonic

On Tue, Jun 8, 2021 at 12:05 PM zack_on_the_speed_chanel wrote: > > hello, > I used rtems_timespec_subtract to do all the arithmetic, I think that I > have addressed the thing you wanted me to fix. Should I send a patch for you > to look at? > Sure, if you're happy with it and/or have specific

Re: [PATCH 5/5] bsps/sparc: Simplify memory initialization

On 6/8/21 4:14 PM, Sebastian Huber wrote: On 08/06/2021 16:03, Gedare Bloom wrote: I guess at some time, loading initialized data from the ROM was needed, but now it is not? I asked about this some time ago. I think these days the RTEMS application is always loaded by a boot loader (GRMON).

[PATCH] fsnofs01/init.c: Check for ENOENT from utime().

The addition of the entire *utime*() family of functions resulted in this call returning ENOENT not ENXIO. This is better aligned with the POSIX definition of the methods. --- testsuites/fstests/fsnofs01/init.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/testsuites

Re: [PATCH v1 2/4] rtemsbsd:Updated TTCP code with network demo code

On Tue, Jun 8, 2021, 12:12 PM Gedare Bloom wrote: > Are these updates from OAR? Do you want to scope them with #ifdef > #endif for RTEMS? Or this is clone-and-own software now? > Yes. The code is old a s has warnings which need to be fixed. Because this program gets compiled natively when runni

Re: [PATCH v1 2/4] rtemsbsd:Updated TTCP code with network demo code

Are these updates from OAR? Do you want to scope them with #ifdef #endif for RTEMS? Or this is clone-and-own software now? Why not import from network-demos? On Tue, Jun 8, 2021 at 10:12 AM Stephen Clark wrote: > > Updated the TTCP code to match the ttcp.c in RTEMS network-demos > repository (h

Re: [PATCH v1 1/4] rtemsbsd: Added original TTCP code

Minor note, please use the the --subject-prefix="PATCH rtems-libbsd" as mentioned in https://docs.rtems.org/branches/master/eng/vc-users.html#creating-a-patch This helps set the context of the patch review better for non-rtems.git patches. On Tue, Jun 8, 2021 at 9:50 AM Stephen Clark wrote: > >

Re: code review: help implementing clock_montonic

At this point, we probably need to see some more code. I can't piece together what you've done from the scattered emails here. Hopefully, the use of the helper methods fixes the previous concern I had. On Tue, Jun 8, 2021 at 9:20 AM zack_on_the_speed_chanel wrote: > > ping > > Sent with ProtonMa

[PATCH v1 4/4] rtemsbsd: Added a test for the TTCP command.

Added a new test for the TTCP command. Modified default-network-init.h to conditionally build the shell with TTCP. Modified libbsd.py to build the new TTCP test. --- libbsd.py | 1 + .../rtems/bsd/test/default-network-init.h | 7 +++ testsuite/ttcpshell01/

[PATCH v1 3/4] rtemsbsd: Made TTCP command build for RTEMS

Updated ttcp.c to build for RTEMS 6. Defined a shell command for TTCP in rtems-bsd-shell-ttcp.c. Added TTCP to the list of RTEMS network commands in netcmds-config.h. Added declaration of the TTCP shell command to rtems-bsd-commands.h Modified libbsd.py to make waf build TTCP and its shell command.

[PATCH v1 2/4] rtemsbsd:Updated TTCP code with network demo code

Updated the TTCP code to match the ttcp.c in RTEMS network-demos repository (https://git.rtems.org/network-demos/). --- rtemsbsd/ttcp/ttcp.c | 91 +++- 1 file changed, 65 insertions(+), 26 deletions(-) diff --git a/rtemsbsd/ttcp/ttcp.c b/rtemsbsd/ttcp/ttcp.

Re: [rtems commit] libcsupport: Implement utimes() in terms of utimensat()

I can reproduce this. I think the test should change. The null file system operation handlers only set -1 and assume the caller will set errno. The utime methods which include a stat() or fstat() call depending on the signature and return ENOENT if that fails. utime() is considered obsolete but th

[PATCH v1 1/4] rtemsbsd: Added original TTCP code

Added the original Test TCP (TTCP) program in unmodified form. Also added the associated README. --- rtemsbsd/ttcp/README | 27 ++ rtemsbsd/ttcp/ttcp.c | 841 +++ 2 files changed, 868 insertions(+) create mode 100644 rtemsbsd/ttcp/README create mode 10064

Re: [PATCH 5/5] bsps/sparc: Simplify memory initialization

On 08/06/2021 16:03, Gedare Bloom wrote: I guess at some time, loading initialized data from the ROM was needed, but now it is not? I asked about this some time ago. I think these days the RTEMS application is always loaded by a boot loader (GRMON). If the data copy is really necessary, then

Re: [PATCH 5/5] bsps/sparc: Simplify memory initialization

These patches look OK, with the register fixes you noted. I guess at some time, loading initialized data from the ROM was needed, but now it is not? Gedare On Tue, Jun 8, 2021 at 3:21 AM Sebastian Huber wrote: > > Directly initialize the memory in the start sequence defined by start.S > instead

RE: [PATCH v2 2/2] i386: Remove unneeded include header files

Thanks, I would also like to backport this to 5-freebsd-12 to solve this issue there as well. I created a corresponding ticket: https://devel.rtems.org/ticket/4452#ticket Best regards, Jan > -Original Message- > From: Chris Johns > Sent: Tuesday, June 8, 2021 4:59 AM > To: Gedare

Re: [PATCH rtems 2/2] bsps/imxrt: Simplify linkcmds and make it flexible

On Tue, Jun 8, 2021 at 5:37 AM Christian Mauderer wrote: > > Hello Chris, > > On 08/06/2021 12:05, Chris Johns wrote: > > On 8/6/21 7:08 pm, Christian Mauderer wrote: > >> Hello Chris, > >> > >> On 08/06/2021 05:07, Chris Johns wrote: > >>> On 7/6/21 6:40 pm, Christian Mauderer wrote:> I think the

Re: [rtems-tools commit] rtems-bsp-builder: Change to waf build system

On 08/06/2021 14:08, Joel Sherrill wrote: Is the kernel rsb recipe fixed yet? That was a blocker. Is this really a blocker? Can't this be done on demand when someone wants to update them? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...

Re: [rtems commit] libcsupport: Implement utimes() in terms of utimensat()

On Tue, Jun 8, 2021, 5:11 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello, > > one of these commits > > There are only 'skip'ped commits left to test. > The first bad commit could be any of: > bb7041230639894a924221ceb454d02c1ea84f66 > ea881bf7a15721916d4adcc5f117ebf6acc6d2

Re: [rtems-tools commit] rtems-bsp-builder: Change to waf build system

On Tue, Jun 8, 2021, 5:32 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 25/05/2021 19:41, Joel Sherrill wrote: > > Module:rtems-tools > > Branch:master > > Commit:527848d5cc8b60c499e712153ac1f81a60e6a631 > > Changeset: > http://git.rtems.org/rtems-tools/commit/?i

Re: [PATCH rtems 2/2] bsps/imxrt: Simplify linkcmds and make it flexible

Hello Chris, On 08/06/2021 12:05, Chris Johns wrote: On 8/6/21 7:08 pm, Christian Mauderer wrote: Hello Chris, On 08/06/2021 05:07, Chris Johns wrote: On 7/6/21 6:40 pm, Christian Mauderer wrote:> I think the Options don't need documentation changes because the options in the waf based build

Re: [rtems-tools commit] rtems-bsp-builder: Change to waf build system

On 25/05/2021 19:41, Joel Sherrill wrote: Module:rtems-tools Branch:master Commit:527848d5cc8b60c499e712153ac1f81a60e6a631 Changeset:http://git.rtems.org/rtems-tools/commit/?id=527848d5cc8b60c499e712153ac1f81a60e6a631 Author:Ryan Long Date: Fri May 14 15:25:38 2021 -0400 rt

Re: [PATCH rtems 2/2] bsps/imxrt: Simplify linkcmds and make it flexible

On 08/06/2021 05:07, Chris Johns wrote: On 7/6/21 6:40 pm, Christian Mauderer wrote:> I think the Options don't need documentation changes because the options in the waf based build system are now documented directly in the yaml files and printed if you generate the default config. Hmm I am not

Re: [rtems commit] libcsupport: Implement utimes() in terms of utimensat()

Hello, one of these commits There are only 'skip'ped commits left to test. The first bad commit could be any of: bb7041230639894a924221ceb454d02c1ea84f66 ea881bf7a15721916d4adcc5f117ebf6acc6d2a3 335f7050822262f029e7945b31b0f2bb2d889bcc 6171a88d9c7f90bac9a076edf3655f7c9e2efb94 ea41722c92313e88436

Re: [PATCH rtems 2/2] bsps/imxrt: Simplify linkcmds and make it flexible

On 8/6/21 7:08 pm, Christian Mauderer wrote: > Hello Chris, > > On 08/06/2021 05:07, Chris Johns wrote: >> On 7/6/21 6:40 pm, Christian Mauderer wrote:> I think the Options don't need >> documentation changes because the options in the >>> waf based build system are now documented directly in the

Re: [PATCH 3/5] bsps/sparc: Unifiy stack initialization

On 08/06/2021 11:20, Sebastian Huber wrote: Initialize the stacks in start.S in one place and identical to _CPU_Context_Initialize(). --- bsps/sparc/shared/start/start.S | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/bsps/sparc/shared/start/start.S b/bsps/sp

[PATCH 5/5] bsps/sparc: Simplify memory initialization

Directly initialize the memory in the start sequence defined by start.S instead of using a system initialization handler. This avoids using the global variable rdb_start which used a memory location which was shared with _ERC32_MEC_Timer_Control_Mirror. This change makes it possible to use _Memor

[PATCH 4/5] bsps/sparc: Simplify stack initialization

Initialize the stacks for all processors in one place. Do not rely on Per_CPU_Control::interrupt_stack_high and directly use the statically allocated interrupt stack area. --- bsps/sparc/shared/start/start.S | 49 ++--- 1 file changed, 21 insertions(+), 28 deletions(-)

[PATCH 2/5] bsps/sparc: Remove support to load data section

Remove the support to load the data section and rely on the boot loader. The support for the data section loading was dead code and not tested. In SMP configurations, this support was also broken since LEON3_Boot_Cpu (in the data section due to the -1 initialization value) was used quite early in t

[PATCH 1/5] bsps/sparc: Remove unused __bsp_mem_init symbol

--- bsps/sparc/shared/start/start.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsps/sparc/shared/start/start.S b/bsps/sparc/shared/start/start.S index 5fc1248a24..f7caacf0e4 100644 --- a/bsps/sparc/shared/start/start.S +++ b/bsps/sparc/shared/start/start.S @@ -85,7 +85,7 @

[PATCH 3/5] bsps/sparc: Unifiy stack initialization

Initialize the stacks in start.S in one place and identical to _CPU_Context_Initialize(). --- bsps/sparc/shared/start/start.S | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/bsps/sparc/shared/start/start.S b/bsps/sparc/shared/start/start.S index 369ef72a94..4922a

[PATCH 0/5] Simplify SPARC start sequence

This patch set simplifies the start sequence for all SPARC BSPs. Sebastian Huber (5): bsps/sparc: Remove unused __bsp_mem_init symbol bsps/sparc: Remove support to load data section bsps/sparc: Unifiy stack initialization bsps/sparc: Simplify stack initialization bsps/sparc: Simplify mem

Re: [PATCH rtems 2/2] bsps/imxrt: Simplify linkcmds and make it flexible

Hello Chris, On 08/06/2021 05:07, Chris Johns wrote: On 7/6/21 6:40 pm, Christian Mauderer wrote:> I think the Options don't need documentation changes because the options in the waf based build system are now documented directly in the yaml files and printed if you generate the default config.