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 returns an error? Does this mean that the utimes_h handler is unreachable for the null node (null_op_utimens)? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [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 configuration approach would be to enable the device tree support for this BSP. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [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/aarch64/a72.rst new file mode 100644 index 000..e8e4b3d --- /dev/null +++ b/user/bsps/aarch64/a72.rst @@ -0,0 +1,35 @@ +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +.. Copyright (C) 2020 On-Line Applications Research Corporation (OAR) + +.. _BSP_aarch64_qemu_a72_ilp32: +.. _BSP_aarch64_qemu_a72_lp64: + +Qemu A72 + + +This BSP supports two variants, `qemu_a72_ilp32` and `qemu_a72_lp64`. The basic +hardware initialization is performed by the BSP. These BSPs support the GICv3 +interrupt controller. + +Boot via ELF + +The executable image is booted by Qemu in ELF format. + +Clock Driver + + +The clock driver uses the `ARM Generic Timer`. + +Console Driver +-- + +The console driver supports the default Qemu emulated ARM PL011 PrimeCell UART. + +Running Executables +--- + +Executables generated by these BSPs can be run using the following command:: + +qemu-system-aarch64 -no-reboot -nographic -serial mon:stdio \ + -machine virt,gic-version=3 -cpu cortex-a72 -m 4096 -kernel example.exe diff --git a/user/bsps/bsps-aarch64.rst b/user/bsps/bsps-aarch64.rst index 0d4b23c..566a750 100644 --- a/user/bsps/bsps-aarch64.rst +++ b/user/bsps/bsps-aarch64.rst @@ -6,4 +6,5 @@ aarch64 (AArch64) * .. include:: aarch64/a53.rst +.. include:: aarch64/a72.rst .. include:: aarch64/xilinx-zynqmp.rst ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
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 +32,4 @@ Running Executables Executables generated by these BSPs can be run using the following command:: qemu-system-aarch64 -no-reboot -nographic -serial mon:stdio \ - -machine virt,gic_version=3 -cpu cortex-a53 -m 4096 -kernel example.exe + -machine virt,gic-version=3 -cpu cortex-a53 -m 4096 -kernel example.exe Thanks for the fix, I missed this when I fixed it in the tester config. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
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/rtems/testing/bsps/a72_lp64_qemu.ini
new file mode 100644
index 000..9b1eb8e
--- /dev/null
+++ b/tester/rtems/testing/bsps/a72_lp64_qemu.ini
@@ -0,0 +1,38 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright 2020 Kinsey Moore(kinsey.mo...@oarcorp.com)
+# All rights reserved.
+#
+# This file is part of the RTEMS Tools package in 'rtems-tools'.
+#
+# 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 HOLDER 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.
+#
+
+#
+# The AArch64 Cortex-A72 LP64 BSP.
+#
+[a72_lp64_qemu]
+bsp = a72_lp64_qemu
+arch = aarch64
+tester= %{_rtscripts}/qemu.cfg
+bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine
virt,gic-version=3 -cpu cortex-a72 -m 4096
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
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/bsp/irq.h| 67 +
bsps/aarch64/a72/include/tm27.h | 46
bsps/aarch64/a72/start/bspstart.c | 49
bsps/aarch64/a72/start/bspstarthooks.c| 50 +
spec/build/bsps/aarch64/a72/abi.yml | 22 ++
.../bsps/aarch64/a72/bspa72ilp32qemu.yml | 19 +
.../build/bsps/aarch64/a72/bspa72lp64qemu.yml | 19 +
spec/build/bsps/aarch64/a72/grp.yml | 42 +++
.../build/bsps/aarch64/a72/linkcmds_ilp32.yml | 71 ++
spec/build/bsps/aarch64/a72/linkcmds_lp64.yml | 71 ++
spec/build/bsps/aarch64/a72/obj.yml | 37 ++
spec/build/bsps/aarch64/a72/optloadoff.yml| 18 +
spec/build/bsps/aarch64/a72/optnocachelen.yml | 18 +
spec/build/bsps/aarch64/a72/optramlen.yml | 18 +
spec/build/bsps/aarch64/a72/optramori.yml | 18 +
spec/build/bsps/aarch64/a72/tsta72.yml| 41 ++
18 files changed, 749 insertions(+)
create mode 100644 bsps/aarch64/a72/console/console.c
create mode 100644 bsps/aarch64/a72/include/bsp.h
create mode 100644 bsps/aarch64/a72/include/bsp/irq.h
create mode 100644 bsps/aarch64/a72/include/tm27.h
create mode 100644 bsps/aarch64/a72/start/bspstart.c
create mode 100644 bsps/aarch64/a72/start/bspstarthooks.c
create mode 100644 spec/build/bsps/aarch64/a72/abi.yml
create mode 100644 spec/build/bsps/aarch64/a72/bspa72ilp32qemu.yml
create mode 100644 spec/build/bsps/aarch64/a72/bspa72lp64qemu.yml
create mode 100644 spec/build/bsps/aarch64/a72/grp.yml
create mode 100644 spec/build/bsps/aarch64/a72/linkcmds_ilp32.yml
create mode 100644 spec/build/bsps/aarch64/a72/linkcmds_lp64.yml
create mode 100644 spec/build/bsps/aarch64/a72/obj.yml
create mode 100644 spec/build/bsps/aarch64/a72/optloadoff.yml
create mode 100644 spec/build/bsps/aarch64/a72/optnocachelen.yml
create mode 100644 spec/build/bsps/aarch64/a72/optramlen.yml
create mode 100644 spec/build/bsps/aarch64/a72/optramori.yml
create mode 100644 spec/build/bsps/aarch64/a72/tsta72.yml
diff --git a/bsps/aarch64/a72/console/console.c
b/bsps/aarch64/a72/console/console.c
new file mode 100644
index 00..08532d68cd
--- /dev/null
+++ b/bsps/aarch64/a72/console/console.c
@@ -0,0 +1,69 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSBSPsAArch64A72
+ *
+ * @brief Console Configuration
+ */
+
+/*
+ * Copyright (C) 2020 On-Line Applications Research Corporation (OAR)
+ * Written by Kinsey Moore
+ *
+ * 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
+
+arm_pl011_context a72_qemu_vpl011_context = {
+ .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER("PL011"),
+ .regs = (volatile pl011 *) BSP_A72_QEMU_VPL011_BASE,
+ .initial_baud = 115200
+};
+
+const console_device console_device_table[] = {
+ {
+.device_file = "/dev/ttyS0",
+.probe = console_device_probe_default,
+.handler = &arm_pl011_fns,
+.context = &a72_qemu_vpl011_context.base
+ }
+};
+
+const size_t console_device_count = RTEMS_ARRAY_SIZE(console_device_table);
+
+static void output_char( char c )
+{
+ arm_pl011_write_polled(&a72_qemu_vpl011_context.base, c);
+}
+
+BSP_output_char_function_type BSP_output_char = output_char;
+
+BSP_polling_getchar_function_type BSP_poll_char = NULL;
diff -
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 >>> printed >>> if you generate the default config. >> Hmm I am not sure I agree with the premise the YAML is the documentation. The >> user manual exists for this purpose and user wanting to explore RTEMS would >> look >> there rather than cloning the repo, running commands etc. >> >> I accept the current defaults etc work flow is a good place to start for the >> waf >> conversion project but we need to do a lot more to make accessing the YAML >> easier. The wscript contains the only rtems.git repo means to read the YAML >> and >> the pickled data and that limits how we can change and evolve this. > > We could use rtems-central to generate sections for the user manual from the > build specification. This would be similar to the generation of the > glossaries, > application configuration option documentation, and the directive > documentation. Of course we could use it and there are a number of other possible ways we do this as well without that repo. The rtems-central repo and work flows have clear and defined boundary we have put in place for very good reasons. A move that way would be considered creep. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
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 Bloom wrote: > 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 > > zack_on_the_speed_cha...@protonmail.ch wrote: > > > ping > > > > Sent with ProtonMail Secure Email. > > > > ‐‐‐ Original Message ‐‐‐ > > > > On Saturday, May 15th, 2021 at 9:22 PM, zack_on_the_speed_chanel > > zack_on_the_speed_cha...@protonmail.ch wrote: > > > > > Use helper functions in rtems/timespec.h or score/timespec.h > > > > > > > (depending where you implement your code, in this case, you probably > > > > > > > > use the score services). > > > > > > I did it using rtems subtract function. > > > > > > rtems_timespec_subtract (now, expire, result); > > > > > > where now expire and result are all timespec > > > > > > _TOD_Get(now); or _Timecounter_Nanouptime(now ); > > > > > > and expire is > > > > > > rtems_timespec_from_ticks (ptimer->Timer.expire,expire ); > > > > > > also i'm getting this compiler warning I don't know if i have to resolve > > > it, I get that my timespec variable may not be initialized. > > > > > > warning: 'result' may be used uninitialized in this function > > > [-Wmaybe-uninitialized] > > > > > > > The monotonic clock cannot be set. > > > > > > Were you talking about the fact that the monotonic clock only can go up > > > in time? > > > > > > Yes, settime is an important function to distinguish between MONOTONIC > > > > > > > > > and REALTIME cases. That is going to be tricky to think through. > > > > > > i don't understand what you mean since i have added a clock type field to > > > the POSIX_TIMER_CONTROL > > > > > > Thanks > > > > > > Zack > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > > > On Thursday, May 13, 2021 3:05 PM, Gedare Bloom ged...@rtems.org wrote: > > > > > > > On Wed, May 12, 2021 at 2:42 PM zack_on_the_speed_chanel > > > > > > > > zack_on_the_speed_cha...@protonmail.ch wrote: > > > > > > > > > > This ticket mostly references the need for a test. Have you tried to > > > > > > > > > > > > write a test for the missing functionality? > > > > > > > > > > How I made a test for it was to create the timer using timer_create() > > > > > . It also said to use a previous test with timer_realtime and i > > > > > tested it with sometime similar to PSXtimer02 test. I got a invalid > > > > > argument error when I tried it. Joel told me i also have to impliment > > > > > the monotonic clock > > > > > > > > > > > his math doesn't make sense to me. explain what you're trying to do? > > > > > > > > > > I wanted calculate the remaining time with the timespec. I assumed > > > > > that the timespec contained the total time seconds+miliseconds. I > > > > > knew that a cpu tick is an uint32. So i converted to timspec > > > > > > > > > > remaining = (uint32_t) ( ptimer->Timer.expire - now ); > > > > > > > > > > > > > > > to something like > > > > > > > > > > expire->tv.nsec+expire->tv.sec - spec->tv.nsec+spec->tv.sec); > > > > > > > > This doesn't work. Example: > > > > > > > > now = 0s 9ns > > > > > > > > expire = 1s 0ns > > > > > > > > expire - now = 1ns > > > > > > > > expire.nsec + expire.sec - now.nsec + now.sec = -9 cast to > > > > > > > > uint32_t is 3294967297ns or so. > > > > > > > > Use helper functions in rtems/timespec.h or score/timespec.h > > > > > > > > (depending where you implement your code, in this case, you probably > > > > > > > > use the score services). > > > > > > > > > > > Yes, settime is an important function to distinguish between > > > > > > > MONOTONIC > > > > > > > > > > > > > > and REALTIME cases. That is going to be tricky to think through. > > > > > > > > > > Where do you want to check the clock type. I though I only need to > > > > > distinguish between both when getting the value of the clock. I don't > > > > > exactly know what needs to be done me being really new to posix and > > > > > operating system development. > > > > > > > > The monotonic clock cannot be set. > > > > > > > > > Zack > > > > > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > > > > > > > On Tuesday, May 11, 2021 6:23 AM, Gedare Bloom ged...@rtems.org wrote: > > > > > > > > > > > On Fri, May 7, 2021 at 12:53 PM zack_on_the_speed_chanel > > > > > > > > > > > > zack_on_the_speed_cha...@protonmail.ch wrote: > > > > > > > > > > > > > hello, > > > > > > > > > > > > > > Currenttly i'm trying to implement the clock_monotonic which was > > > > > > > part of ticket #3889. So far these are the changes are as follows > > > > > > > > > > > > This ticket mostly ref
[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 generated by these BSPs can be run using the following command:: qemu-system-aarch64 -no-reboot -nographic -serial mon:stdio \ - -machine virt,gic_version=3 -cpu cortex-a53 -m 4096 -kernel example.exe + -machine virt,gic-version=3 -cpu cortex-a53 -m 4096 -kernel example.exe -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[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..e8e4b3d --- /dev/null +++ b/user/bsps/aarch64/a72.rst @@ -0,0 +1,35 @@ +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +.. Copyright (C) 2020 On-Line Applications Research Corporation (OAR) + +.. _BSP_aarch64_qemu_a72_ilp32: +.. _BSP_aarch64_qemu_a72_lp64: + +Qemu A72 + + +This BSP supports two variants, `qemu_a72_ilp32` and `qemu_a72_lp64`. The basic +hardware initialization is performed by the BSP. These BSPs support the GICv3 +interrupt controller. + +Boot via ELF + +The executable image is booted by Qemu in ELF format. + +Clock Driver + + +The clock driver uses the `ARM Generic Timer`. + +Console Driver +-- + +The console driver supports the default Qemu emulated ARM PL011 PrimeCell UART. + +Running Executables +--- + +Executables generated by these BSPs can be run using the following command:: + +qemu-system-aarch64 -no-reboot -nographic -serial mon:stdio \ + -machine virt,gic-version=3 -cpu cortex-a72 -m 4096 -kernel example.exe diff --git a/user/bsps/bsps-aarch64.rst b/user/bsps/bsps-aarch64.rst index 0d4b23c..566a750 100644 --- a/user/bsps/bsps-aarch64.rst +++ b/user/bsps/bsps-aarch64.rst @@ -6,4 +6,5 @@ aarch64 (AArch64) * .. include:: aarch64/a53.rst +.. include:: aarch64/a72.rst .. include:: aarch64/xilinx-zynqmp.rst -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
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:
fsnofs01.exe
User Input:
monitor.exe
fileio.exe
capture.exe
top.exe
termios.exe
Indeterminate:
psxtimes01.exe
Benchmark:
dhrystone.exe
linpack.exe
whetstone.exe
Timeouts:
psxmsgq01.exe
psx10.exe
On Tue, Jun 8, 2021 at 2:33 PM 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/rtems/testing/bsps/a72_lp64_qemu.ini
> new file mode 100644
> index 000..9b1eb8e
> --- /dev/null
> +++ b/tester/rtems/testing/bsps/a72_lp64_qemu.ini
> @@ -0,0 +1,38 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright 2020 Kinsey Moore(kinsey.mo...@oarcorp.com)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# 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 HOLDER 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.
> +#
> +
> +#
> +# The AArch64 Cortex-A72 LP64 BSP.
> +#
> +[a72_lp64_qemu]
> +bsp = a72_lp64_qemu
> +arch = aarch64
> +tester= %{_rtscripts}/qemu.cfg
> +bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine
> virt,gic-version=3 -cpu cortex-a72 -m 4096
> --
> 2.25.1
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[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
index 000..9b1eb8e
--- /dev/null
+++ b/tester/rtems/testing/bsps/a72_lp64_qemu.ini
@@ -0,0 +1,38 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright 2020 Kinsey Moore(kinsey.mo...@oarcorp.com)
+# All rights reserved.
+#
+# This file is part of the RTEMS Tools package in 'rtems-tools'.
+#
+# 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 HOLDER 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.
+#
+
+#
+# The AArch64 Cortex-A72 LP64 BSP.
+#
+[a72_lp64_qemu]
+bsp = a72_lp64_qemu
+arch = aarch64
+tester= %{_rtscripts}/qemu.cfg
+bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine
virt,gic-version=3 -cpu cortex-a72 -m 4096
--
2.25.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[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/a72/include/tm27.h | 46
bsps/aarch64/a72/start/bspstart.c | 49
bsps/aarch64/a72/start/bspstarthooks.c| 50 +
spec/build/bsps/aarch64/a72/abi.yml | 22 ++
.../bsps/aarch64/a72/bspa72ilp32qemu.yml | 19 +
.../build/bsps/aarch64/a72/bspa72lp64qemu.yml | 19 +
spec/build/bsps/aarch64/a72/grp.yml | 42 +++
.../build/bsps/aarch64/a72/linkcmds_ilp32.yml | 71 ++
spec/build/bsps/aarch64/a72/linkcmds_lp64.yml | 71 ++
spec/build/bsps/aarch64/a72/obj.yml | 37 ++
spec/build/bsps/aarch64/a72/optloadoff.yml| 18 +
spec/build/bsps/aarch64/a72/optnocachelen.yml | 18 +
spec/build/bsps/aarch64/a72/optramlen.yml | 18 +
spec/build/bsps/aarch64/a72/optramori.yml | 18 +
spec/build/bsps/aarch64/a72/tsta72.yml| 41 ++
18 files changed, 749 insertions(+)
create mode 100644 bsps/aarch64/a72/console/console.c
create mode 100644 bsps/aarch64/a72/include/bsp.h
create mode 100644 bsps/aarch64/a72/include/bsp/irq.h
create mode 100644 bsps/aarch64/a72/include/tm27.h
create mode 100644 bsps/aarch64/a72/start/bspstart.c
create mode 100644 bsps/aarch64/a72/start/bspstarthooks.c
create mode 100644 spec/build/bsps/aarch64/a72/abi.yml
create mode 100644 spec/build/bsps/aarch64/a72/bspa72ilp32qemu.yml
create mode 100644 spec/build/bsps/aarch64/a72/bspa72lp64qemu.yml
create mode 100644 spec/build/bsps/aarch64/a72/grp.yml
create mode 100644 spec/build/bsps/aarch64/a72/linkcmds_ilp32.yml
create mode 100644 spec/build/bsps/aarch64/a72/linkcmds_lp64.yml
create mode 100644 spec/build/bsps/aarch64/a72/obj.yml
create mode 100644 spec/build/bsps/aarch64/a72/optloadoff.yml
create mode 100644 spec/build/bsps/aarch64/a72/optnocachelen.yml
create mode 100644 spec/build/bsps/aarch64/a72/optramlen.yml
create mode 100644 spec/build/bsps/aarch64/a72/optramori.yml
create mode 100644 spec/build/bsps/aarch64/a72/tsta72.yml
diff --git a/bsps/aarch64/a72/console/console.c
b/bsps/aarch64/a72/console/console.c
new file mode 100644
index 00..08532d68cd
--- /dev/null
+++ b/bsps/aarch64/a72/console/console.c
@@ -0,0 +1,69 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSBSPsAArch64A72
+ *
+ * @brief Console Configuration
+ */
+
+/*
+ * Copyright (C) 2020 On-Line Applications Research Corporation (OAR)
+ * Written by Kinsey Moore
+ *
+ * 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
+
+arm_pl011_context a72_qemu_vpl011_context = {
+ .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER("PL011"),
+ .regs = (volatile pl011 *) BSP_A72_QEMU_VPL011_BASE,
+ .initial_baud = 115200
+};
+
+const console_device console_device_table[] = {
+ {
+.device_file = "/dev/ttyS0",
+.probe = console_device_probe_default,
+.handler = &arm_pl011_fns,
+.context = &a72_qemu_vpl011_context.base
+ }
+};
+
+const size_t console_device_count = RTEMS_ARRAY_SIZE(console_device_table);
+
+static void output_char( char c )
+{
+ arm_pl011_write_polled(&a72_qemu_vpl011_context.base, c);
+}
+
+BSP_output_char_function_type BSP_output_char = output_char;
+
+BSP_polling_getchar_function_type BSP_poll_char = NULL;
diff --git a/bsps/aarch64/a72/include/bsp.h b/bsps/aarch64/a72/include/bsp.h
new file mode 100644
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 Moore wrote: > > 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 5b51de7e..5c1bab42 100644 > --- a/rtemsbsd/include/bsp/nexus-devices.h > +++ b/rtemsbsd/include/bsp/nexus-devices.h > @@ -115,7 +115,18 @@ RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SLCR; > * CGEM3 is used for LibBSD because all Zynq Ultrascale+ MPSoC dev boards > treat > * the highest-mapped CGEM as the primary interface. > */ > +#if BSP_XILINX_ZYNQMP_USE_CGEM0 > +RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM0(ZYNQMP_IRQ_ETHERNET_0); > +#endif > +#if BSP_XILINX_ZYNQMP_USE_CGEM1 > +RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM1(ZYNQMP_IRQ_ETHERNET_1); > +#endif > +#if BSP_XILINX_ZYNQMP_USE_CGEM2 > +RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM2(ZYNQMP_IRQ_ETHERNET_2); > +#endif > +#if BSP_XILINX_ZYNQMP_USE_CGEM3 > RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM3(ZYNQMP_IRQ_ETHERNET_3); > +#endif > RTEMS_BSD_DRIVER_E1000PHY; > RTEMS_BSD_DRIVER_UKPHY; > > -- > 2.20.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: [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. > --- > spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml| 8 > .../bsps/aarch64/xilinx-zynqmp/optcgem0.yml | 16 > .../bsps/aarch64/xilinx-zynqmp/optcgem1.yml | 16 > .../bsps/aarch64/xilinx-zynqmp/optcgem2.yml | 16 > .../bsps/aarch64/xilinx-zynqmp/optcgem3.yml | 16 > 5 files changed, 72 insertions(+) > create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optcgem0.yml > create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optcgem1.yml > create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optcgem2.yml > create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optcgem3.yml > > diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml > b/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml > index 16e2b8a7e9..1b6b756912 100644 > --- a/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml > +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml > @@ -27,6 +27,14 @@ links: >uid: optramori > - role: build-dependency >uid: optclkuart > +- role: build-dependency > + uid: optcgem0 > +- role: build-dependency > + uid: optcgem1 > +- role: build-dependency > + uid: optcgem2 > +- role: build-dependency > + uid: optcgem3 > - role: build-dependency >uid: ../../optconminor > - role: build-dependency > diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem0.yml > b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem0.yml > new file mode 100644 > index 00..fc878fda60 > --- /dev/null > +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem0.yml > @@ -0,0 +1,16 @@ > +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause > +actions: > +- get-boolean: null > +- env-enable: null > +- define-condition: null > +build-type: option > +copyrights: > +- Copyright (C) 2021 On-Line Applications Research > +default: false > +default-by-variant: [] > +description: | > + Enable support for CGEM0 > +enabled-by: true > +links: [] > +name: BSP_XILINX_ZYNQMP_USE_CGEM0 > +type: build > diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem1.yml > b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem1.yml > new file mode 100644 > index 00..6d5096bbde > --- /dev/null > +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem1.yml > @@ -0,0 +1,16 @@ > +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause > +actions: > +- get-boolean: null > +- env-enable: null > +- define-condition: null > +build-type: option > +copyrights: > +- Copyright (C) 2021 On-Line Applications Research > +default: false > +default-by-variant: [] > +description: | > + Enable support for CGEM1 > +enabled-by: true > +links: [] > +name: BSP_XILINX_ZYNQMP_USE_CGEM1 > +type: build > diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem2.yml > b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem2.yml > new file mode 100644 > index 00..a8aca3ebbd > --- /dev/null > +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem2.yml > @@ -0,0 +1,16 @@ > +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause > +actions: > +- get-boolean: null > +- env-enable: null > +- define-condition: null > +build-type: option > +copyrights: > +- Copyright (C) 2021 On-Line Applications Research > +default: false > +default-by-variant: [] > +description: | > + Enable support for CGEM2 > +enabled-by: true > +links: [] > +name: BSP_XILINX_ZYNQMP_USE_CGEM2 > +type: build > diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem3.yml > b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem3.yml > new file mode 100644 > index 00..8275ad3440 > --- /dev/null > +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem3.yml > @@ -0,0 +1,16 @@ > +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause > +actions: > +- get-boolean: null > +- env-enable: null > +- define-condition: null > +build-type: option > +copyrights: > +- Copyright (C) 2021 On-Line Applications Research > +default: true > +default-by-variant: [] > +description: | > + Enable support for CGEM3 > +enabled-by: true > +links: [] > +name: BSP_XILINX_ZYNQMP_USE_CGEM3 > +type: build > -- > 2.20.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
[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 5b51de7e..5c1bab42 100644 --- a/rtemsbsd/include/bsp/nexus-devices.h +++ b/rtemsbsd/include/bsp/nexus-devices.h @@ -115,7 +115,18 @@ RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SLCR; * CGEM3 is used for LibBSD because all Zynq Ultrascale+ MPSoC dev boards treat * the highest-mapped CGEM as the primary interface. */ +#if BSP_XILINX_ZYNQMP_USE_CGEM0 +RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM0(ZYNQMP_IRQ_ETHERNET_0); +#endif +#if BSP_XILINX_ZYNQMP_USE_CGEM1 +RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM1(ZYNQMP_IRQ_ETHERNET_1); +#endif +#if BSP_XILINX_ZYNQMP_USE_CGEM2 +RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM2(ZYNQMP_IRQ_ETHERNET_2); +#endif +#if BSP_XILINX_ZYNQMP_USE_CGEM3 RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM3(ZYNQMP_IRQ_ETHERNET_3); +#endif RTEMS_BSD_DRIVER_E1000PHY; RTEMS_BSD_DRIVER_UKPHY; -- 2.20.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[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 .../bsps/aarch64/xilinx-zynqmp/optcgem0.yml | 16 .../bsps/aarch64/xilinx-zynqmp/optcgem1.yml | 16 .../bsps/aarch64/xilinx-zynqmp/optcgem2.yml | 16 .../bsps/aarch64/xilinx-zynqmp/optcgem3.yml | 16 5 files changed, 72 insertions(+) create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optcgem0.yml create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optcgem1.yml create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optcgem2.yml create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optcgem3.yml diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml b/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml index 16e2b8a7e9..1b6b756912 100644 --- a/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml @@ -27,6 +27,14 @@ links: uid: optramori - role: build-dependency uid: optclkuart +- role: build-dependency + uid: optcgem0 +- role: build-dependency + uid: optcgem1 +- role: build-dependency + uid: optcgem2 +- role: build-dependency + uid: optcgem3 - role: build-dependency uid: ../../optconminor - role: build-dependency diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem0.yml b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem0.yml new file mode 100644 index 00..fc878fda60 --- /dev/null +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem0.yml @@ -0,0 +1,16 @@ +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause +actions: +- get-boolean: null +- env-enable: null +- define-condition: null +build-type: option +copyrights: +- Copyright (C) 2021 On-Line Applications Research +default: false +default-by-variant: [] +description: | + Enable support for CGEM0 +enabled-by: true +links: [] +name: BSP_XILINX_ZYNQMP_USE_CGEM0 +type: build diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem1.yml b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem1.yml new file mode 100644 index 00..6d5096bbde --- /dev/null +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem1.yml @@ -0,0 +1,16 @@ +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause +actions: +- get-boolean: null +- env-enable: null +- define-condition: null +build-type: option +copyrights: +- Copyright (C) 2021 On-Line Applications Research +default: false +default-by-variant: [] +description: | + Enable support for CGEM1 +enabled-by: true +links: [] +name: BSP_XILINX_ZYNQMP_USE_CGEM1 +type: build diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem2.yml b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem2.yml new file mode 100644 index 00..a8aca3ebbd --- /dev/null +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem2.yml @@ -0,0 +1,16 @@ +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause +actions: +- get-boolean: null +- env-enable: null +- define-condition: null +build-type: option +copyrights: +- Copyright (C) 2021 On-Line Applications Research +default: false +default-by-variant: [] +description: | + Enable support for CGEM2 +enabled-by: true +links: [] +name: BSP_XILINX_ZYNQMP_USE_CGEM2 +type: build diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem3.yml b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem3.yml new file mode 100644 index 00..8275ad3440 --- /dev/null +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem3.yml @@ -0,0 +1,16 @@ +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause +actions: +- get-boolean: null +- env-enable: null +- define-condition: null +build-type: option +copyrights: +- Copyright (C) 2021 On-Line Applications Research +default: true +default-by-variant: [] +description: | + Enable support for CGEM3 +enabled-by: true +links: [] +name: BSP_XILINX_ZYNQMP_USE_CGEM3 +type: build -- 2.20.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
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
> >
> > use the score services).
>
> I did it using rtems subtract function.
>
> rtems_timespec_subtract (now, expire, result);
>
> where now expire and result are all timespec
>
> _TOD_Get(now); or _Timecounter_Nanouptime(now );
>
> and expire is
>
> rtems_timespec_from_ticks (ptimer->Timer.expire,expire );
>
> also i'm getting this compiler warning I don't know if i have to resolve it,
> I get that my timespec variable may not be initialized.
>
> warning: 'result' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
>
> > The monotonic clock cannot be set.
>
> Were you talking about the fact that the monotonic clock only can go up in
> time?
>
> Yes, settime is an important function to distinguish between MONOTONIC
>
> > > > and REALTIME cases. That is going to be tricky to think through.
>
> i don't understand what you mean since i have added a clock type field to the
> POSIX_TIMER_CONTROL
>
> Thanks
>
> Zack
>
> ‐‐‐ Original Message ‐‐‐
>
> On Thursday, May 13, 2021 3:05 PM, Gedare Bloom ged...@rtems.org wrote:
>
> > On Wed, May 12, 2021 at 2:42 PM zack_on_the_speed_chanel
> >
> > zack_on_the_speed_cha...@protonmail.ch wrote:
> >
> > > > This ticket mostly references the need for a test. Have you tried to
> > > >
> > > > write a test for the missing functionality?
> > >
> > > How I made a test for it was to create the timer using timer_create() .
> > > It also said to use a previous test with timer_realtime and i tested it
> > > with sometime similar to PSXtimer02 test. I got a invalid argument error
> > > when I tried it. Joel told me i also have to impliment the monotonic clock
> > >
> > > > his math doesn't make sense to me. explain what you're trying to do?
> > >
> > > I wanted calculate the remaining time with the timespec. I assumed that
> > > the timespec contained the total time seconds+miliseconds. I knew that a
> > > cpu tick is an uint32. So i converted to timspec
> > >
> > > remaining = (uint32_t) ( ptimer->Timer.expire - now );
> > >
> > >
> > > to something like
> > >
> > > expire->tv.nsec+expire->tv.sec - spec->tv.nsec+spec->tv.sec);
> >
> > This doesn't work. Example:
> >
> > now = 0s 9ns
> >
> > expire = 1s 0ns
> >
> > expire - now = 1ns
> >
> > expire.nsec + expire.sec - now.nsec + now.sec = -9 cast to
> >
> > uint32_t is 3294967297ns or so.
> >
> > Use helper functions in rtems/timespec.h or score/timespec.h
> >
> > (depending where you implement your code, in this case, you probably
> >
> > use the score services).
> >
> > > > > Yes, settime is an important function to distinguish between MONOTONIC
> > > > >
> > > > > and REALTIME cases. That is going to be tricky to think through.
> > >
> > > Where do you want to check the clock type. I though I only need to
> > > distinguish between both when getting the value of the clock. I don't
> > > exactly know what needs to be done me being really new to posix and
> > > operating system development.
> >
> > The monotonic clock cannot be set.
> >
> > > Zack
> > >
> > > ‐‐‐ Original Message ‐‐‐
> > >
> > > On Tuesday, May 11, 2021 6:23 AM, Gedare Bloom ged...@rtems.org wrote:
> > >
> > > > On Fri, May 7, 2021 at 12:53 PM zack_on_the_speed_chanel
> > > >
> > > > zack_on_the_speed_cha...@protonmail.ch wrote:
> > > >
> > > > > hello,
> > > > >
> > > > > Currenttly i'm trying to implement the clock_monotonic which was part
> > > > > of ticket #3889. So far these are the changes are as follows
> > > >
> > > > This ticket mostly references the need for a test. Have you tried to
> > > >
> > > > write a test for the missing functionality?
> > > >
> > > > > ptimer->clock_type= &clock_id;
> > > > >
> > > > > in the timer create i added a field for the timer id and saved it
> > > > > when the timer was made. Then in getttime I used the appropriate
> > > > > timers to get the time.
> > > > >
> > > > > for example.
> > > > >
> > > > > if (ptimer->clock_type ==CLOCK_REALTIME) {
> > > > >
> > > > > Per_CPU_Control *cpu;
> > > > >
> > > > > struct timespec spec;
> > > > >
> > > > > struct timespec expire;
> > > > >
> > > > > cpu = _POSIX_Timer_Acquire_critical( ptimer, &lock_context );
> > > > >
> > > >
> > > > Maybe move the clock_type check to here?
> > > >
> > > > > _TOD_Get(spec);
> > > > > _Timespec_From_ticks( expire, &ptimer->Timer.expire);
> > > > >
> > > > >
> > > > > if (spec->tv.nsec+spec->tv.sec > expire->tv.nsec+expire->tv.sec )
> > > > > {
> > > > >
> > > > > remaining = (uint32_t) (expire->tv.nsec+expire->tv.sec -
> > > > > spec->tv.nsec+spec->tv.sec);
> > > > >
> > > >
> > > > this math doesn't make sense to me. explain what you're trying to do?
> > > >
> > > > >
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 questions to ask related to your code, we need to be able to see the code to help. > Zack > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > > On Tuesday, June 8th, 2021 at 4:34 PM, Gedare Bloom wrote: > > > 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 > > > > zack_on_the_speed_cha...@protonmail.ch wrote: > > > > > ping > > > > > > Sent with ProtonMail Secure Email. > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > > > On Saturday, May 15th, 2021 at 9:22 PM, zack_on_the_speed_chanel > > > zack_on_the_speed_cha...@protonmail.ch wrote: > > > > > > > Use helper functions in rtems/timespec.h or score/timespec.h > > > > > > > > > (depending where you implement your code, in this case, you probably > > > > > > > > > > use the score services). > > > > > > > > I did it using rtems subtract function. > > > > > > > > rtems_timespec_subtract (now, expire, result); > > > > > > > > where now expire and result are all timespec > > > > > > > > _TOD_Get(now); or _Timecounter_Nanouptime(now ); > > > > > > > > and expire is > > > > > > > > rtems_timespec_from_ticks (ptimer->Timer.expire,expire ); > > > > > > > > also i'm getting this compiler warning I don't know if i have to > > > > resolve it, I get that my timespec variable may not be initialized. > > > > > > > > warning: 'result' may be used uninitialized in this function > > > > [-Wmaybe-uninitialized] > > > > > > > > > The monotonic clock cannot be set. > > > > > > > > Were you talking about the fact that the monotonic clock only can go up > > > > in time? > > > > > > > > Yes, settime is an important function to distinguish between MONOTONIC > > > > > > > > > > > and REALTIME cases. That is going to be tricky to think through. > > > > > > > > i don't understand what you mean since i have added a clock type field > > > > to the POSIX_TIMER_CONTROL > > > > > > > > Thanks > > > > > > > > Zack > > > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > > > > > On Thursday, May 13, 2021 3:05 PM, Gedare Bloom ged...@rtems.org wrote: > > > > > > > > > On Wed, May 12, 2021 at 2:42 PM zack_on_the_speed_chanel > > > > > > > > > > zack_on_the_speed_cha...@protonmail.ch wrote: > > > > > > > > > > > > This ticket mostly references the need for a test. Have you tried > > > > > > > to > > > > > > > > > > > > > > write a test for the missing functionality? > > > > > > > > > > > > How I made a test for it was to create the timer using > > > > > > timer_create() . It also said to use a previous test with > > > > > > timer_realtime and i tested it with sometime similar to PSXtimer02 > > > > > > test. I got a invalid argument error when I tried it. Joel told me > > > > > > i also have to impliment the monotonic clock > > > > > > > > > > > > > his math doesn't make sense to me. explain what you're trying to > > > > > > > do? > > > > > > > > > > > > I wanted calculate the remaining time with the timespec. I assumed > > > > > > that the timespec contained the total time seconds+miliseconds. I > > > > > > knew that a cpu tick is an uint32. So i converted to timspec > > > > > > > > > > > > remaining = (uint32_t) ( ptimer->Timer.expire - now ); > > > > > > > > > > > > > > > > > > to something like > > > > > > > > > > > > expire->tv.nsec+expire->tv.sec - spec->tv.nsec+spec->tv.sec); > > > > > > > > > > This doesn't work. Example: > > > > > > > > > > now = 0s 9ns > > > > > > > > > > expire = 1s 0ns > > > > > > > > > > expire - now = 1ns > > > > > > > > > > expire.nsec + expire.sec - now.nsec + now.sec = -9 cast to > > > > > > > > > > uint32_t is 3294967297ns or so. > > > > > > > > > > Use helper functions in rtems/timespec.h or score/timespec.h > > > > > > > > > > (depending where you implement your code, in this case, you probably > > > > > > > > > > use the score services). > > > > > > > > > > > > > Yes, settime is an important function to distinguish between > > > > > > > > MONOTONIC > > > > > > > > > > > > > > > > and REALTIME cases. That is going to be tricky to think through. > > > > > > > > > > > > Where do you want to check the clock type. I though I only need to > > > > > > distinguish between both when getting the value of the clock. I > > > > > > don't exactly know what needs to be done me being really new to > > > > > > posix and operating system development. > > > > > > > > > > The monotonic clock cannot be set. > > > > > > > > > > > Zack > > > > > > > > > > > > ‐‐‐ Original Message ‐‐
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). If the data copy is really necessary, then an application can still add this step as a very early system initialization step, since boot_card() and the system initialization loop doesn't use global data (only read-only and BSS data). However, the SMP startup would still not work in this case. A boot loader is a better place to load the sections. The code is an artifact from the old erc32 days, when we would boot and execute from ROM and the .data had to be copied over to RAM. With leon1/2/3, this is not used anymore as a boot loader is made from the RAM image using a custom tool (mkprom). Jiri. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[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/fstests/fsnofs01/init.c b/testsuites/fstests/fsnofs01/init.c index 6260697..659ee44 100644 --- a/testsuites/fstests/fsnofs01/init.c +++ b/testsuites/fstests/fsnofs01/init.c @@ -187,7 +187,6 @@ static void test_path_ops(void) char buf [32]; ssize_t n = 0; const char *path = "/"; - const struct utimbuf times; errno = 0; rv = open(path, O_RDONLY); @@ -294,10 +293,14 @@ static void test_path_ops(void) rtems_test_assert(rv == -1); rtems_test_assert(errno == ENXIO); + /* + * Pass in NULL so the new access and modification time are interpreted + * as being the current time. Otherwise, the value has to be validated. + */ errno = 0; - rv = utime(path, ×); + rv = utime(path, NULL); rtems_test_assert(rv == -1); - rtems_test_assert(errno == ENXIO); + rtems_test_assert(errno == ENOENT); } static void test_user_env(void) -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
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 running benchmarks. It
takes a Tx and Rx side to run. One is on your host.
I have no idea how to mark things like this
The old version was clone and own. This may just be a newer version of that
but it needs to run on various hosts and RTEMS.
>
> Why not import from network-demos?
I thought it would be best to do a fresh port using that as guidance so
there was less chance of picking up cruft along the way.
--joel
>
>
> 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 (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.c
> > index 305a7c7d..dc62c64b 100644
> > --- a/rtemsbsd/ttcp/ttcp.c
> > +++ b/rtemsbsd/ttcp/ttcp.c
> > @@ -35,8 +35,9 @@
> > * Distribution Status -
> > * Public Domain. Distribution Unlimited.
> > */
> > +
> > #ifndef lint
> > -static char RCSid[] = "ttcp.c $Revision$";
> > +/* static char RCSid[] = "ttcp.c $Revision$"; */
> > #endif
> >
> > #define BSD43
> > @@ -44,6 +45,8 @@ static char RCSid[] = "ttcp.c $Revision$";
> > /* #define BSD41a */
> > /* #define SYSV */ /* required on SGI IRIX releases before 3.3 */
> >
> > +#define ENABLE_NANOSLEEP_DELAY
> > +
> > #include
> > #include
> > #include
> > @@ -54,8 +57,12 @@ static char RCSid[] = "ttcp.c $Revision$";
> > #include
> > #include
> > #include
> > +#include
> > #include /* struct timeval */
> >
> > +#include
> > +#include
> > +
> > #if defined(SYSV)
> > #include
> > #include
> > @@ -71,7 +78,13 @@ struct sockaddr_in sinme;
> > struct sockaddr_in sinhim;
> > struct sockaddr_in frominet;
> >
> > -int domain, fromlen;
> > +/* these make it easier to avoid warnings */
> > +struct sockaddr *sinhim_p = (struct sockaddr *) &sinhim;
> > +struct sockaddr *sinme_p = (struct sockaddr *) &sinme;
> > +struct sockaddr *frominet_p = (struct sockaddr *) &frominet;
> > +
> > +int domain;
> > +socklen_t fromlen;
> > int fd;/* fd of network socket */
> >
> > int buflen = 8 * 1024; /* length of buffer */
> > @@ -97,6 +110,7 @@ char fmt = 'K'; /* output
> format: k = kilobits, K = kilobytes,
> > * m = megabits, M = megabytes,
> > * g = gigabits, G = gigabytes */
> > int touchdata = 0; /* access data after reading */
> > +long milliseconds = 0; /* delay in milliseconds */
> >
> > struct hostent *addr;
> > extern int errno;
> > @@ -124,6 +138,7 @@ Options specific to -t:\n\
> > Options specific to -r:\n\
> > -B for -s, only output full blocks as specified by -l (for
> TAR)\n\
> > -T \"touch\": access each byte as it's read\n\
> > + -m ## delay for specified milliseconds between each write\n\
> > ";
> >
> > char stats[128];
> > @@ -133,7 +148,7 @@ double cput, realt; /* user, real time
> (seconds) */
> >
> > void err();
> > void mes();
> > -int pattern();
> > +void pattern();
> > void prep_timer();
> > double read_timer();
> > int Nread();
> > @@ -147,7 +162,18 @@ sigpipe()
> > {
> > }
> >
> > -main(argc,argv)
> > +void millisleep(long msec)
> > +{
> > +#if defined(ENABLE_NANOSLEEP_DELAY)
> > + struct timespec req;
> > +
> > + req.tv_sec = msec / 1000;
> > + req.tv_nsec = (msec % 1000) * 100;
> > +
> > + nanosleep( &req, NULL );
> > +#endif
> > +}
> > +int main(argc,argv)
> > int argc;
> > char **argv;
> > {
> > @@ -156,7 +182,7 @@ char **argv;
> >
> > if (argc < 2) goto usage;
> >
> > - while ((c = getopt(argc, argv, "drstuvBDTb:f:l:n:p:A:O:")) !=
> -1) {
> > + while ((c = getopt(argc, argv, "drstuvBDTb:f:l:m:n:p:A:O:")) !=
> -1) {
> > switch (c) {
> >
> > case 'B':
> > @@ -179,6 +205,12 @@ char **argv;
> > "ttcp: -D option ignored: TCP_NODELAY socket option not
> supported\n");
> > #endif
> > break;
> > + case 'm':
> > + milliseconds = atoi(optarg);
> > + #if !defined(ENABLE_NANOSLEEP_DELAY)
> > + fprintf(stderr, "millisecond delay
> disabled\n");
> > + #endif
> > + break;
> > case 'n':
> > nbuf = atoi(optarg);
> > break;
> > @@ -285,7 +317,7 @@ char **argv;
> > err("socket");
> > mes("socket");
> >
> > - if (
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 (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.c
> index 305a7c7d..dc62c64b 100644
> --- a/rtemsbsd/ttcp/ttcp.c
> +++ b/rtemsbsd/ttcp/ttcp.c
> @@ -35,8 +35,9 @@
> * Distribution Status -
> * Public Domain. Distribution Unlimited.
> */
> +
> #ifndef lint
> -static char RCSid[] = "ttcp.c $Revision$";
> +/* static char RCSid[] = "ttcp.c $Revision$"; */
> #endif
>
> #define BSD43
> @@ -44,6 +45,8 @@ static char RCSid[] = "ttcp.c $Revision$";
> /* #define BSD41a */
> /* #define SYSV */ /* required on SGI IRIX releases before 3.3 */
>
> +#define ENABLE_NANOSLEEP_DELAY
> +
> #include
> #include
> #include
> @@ -54,8 +57,12 @@ static char RCSid[] = "ttcp.c $Revision$";
> #include
> #include
> #include
> +#include
> #include /* struct timeval */
>
> +#include
> +#include
> +
> #if defined(SYSV)
> #include
> #include
> @@ -71,7 +78,13 @@ struct sockaddr_in sinme;
> struct sockaddr_in sinhim;
> struct sockaddr_in frominet;
>
> -int domain, fromlen;
> +/* these make it easier to avoid warnings */
> +struct sockaddr *sinhim_p = (struct sockaddr *) &sinhim;
> +struct sockaddr *sinme_p = (struct sockaddr *) &sinme;
> +struct sockaddr *frominet_p = (struct sockaddr *) &frominet;
> +
> +int domain;
> +socklen_t fromlen;
> int fd;/* fd of network socket */
>
> int buflen = 8 * 1024; /* length of buffer */
> @@ -97,6 +110,7 @@ char fmt = 'K'; /* output format: k =
> kilobits, K = kilobytes,
> * m = megabits, M = megabytes,
> * g = gigabits, G = gigabytes */
> int touchdata = 0; /* access data after reading */
> +long milliseconds = 0; /* delay in milliseconds */
>
> struct hostent *addr;
> extern int errno;
> @@ -124,6 +138,7 @@ Options specific to -t:\n\
> Options specific to -r:\n\
> -B for -s, only output full blocks as specified by -l (for
> TAR)\n\
> -T \"touch\": access each byte as it's read\n\
> + -m ## delay for specified milliseconds between each write\n\
> ";
>
> char stats[128];
> @@ -133,7 +148,7 @@ double cput, realt; /* user, real time (seconds)
> */
>
> void err();
> void mes();
> -int pattern();
> +void pattern();
> void prep_timer();
> double read_timer();
> int Nread();
> @@ -147,7 +162,18 @@ sigpipe()
> {
> }
>
> -main(argc,argv)
> +void millisleep(long msec)
> +{
> +#if defined(ENABLE_NANOSLEEP_DELAY)
> + struct timespec req;
> +
> + req.tv_sec = msec / 1000;
> + req.tv_nsec = (msec % 1000) * 100;
> +
> + nanosleep( &req, NULL );
> +#endif
> +}
> +int main(argc,argv)
> int argc;
> char **argv;
> {
> @@ -156,7 +182,7 @@ char **argv;
>
> if (argc < 2) goto usage;
>
> - while ((c = getopt(argc, argv, "drstuvBDTb:f:l:n:p:A:O:")) != -1) {
> + while ((c = getopt(argc, argv, "drstuvBDTb:f:l:m:n:p:A:O:")) != -1) {
> switch (c) {
>
> case 'B':
> @@ -179,6 +205,12 @@ char **argv;
> "ttcp: -D option ignored: TCP_NODELAY socket option not supported\n");
> #endif
> break;
> + case 'm':
> + milliseconds = atoi(optarg);
> + #if !defined(ENABLE_NANOSLEEP_DELAY)
> + fprintf(stderr, "millisecond delay
> disabled\n");
> + #endif
> + break;
> case 'n':
> nbuf = atoi(optarg);
> break;
> @@ -285,7 +317,7 @@ char **argv;
> err("socket");
> mes("socket");
>
> - if (bind(fd, &sinme, sizeof(sinme)) < 0)
> + if (bind(fd, sinme_p, sizeof(sinme)) < 0)
> err("bind");
>
> #if defined(SO_SNDBUF) || defined(SO_RCVBUF)
> @@ -305,7 +337,9 @@ char **argv;
> #endif
>
> if (!udp) {
> +#if !defined(__rtems__)
> signal(SIGPIPE, sigpipe);
> +#endif
> if (trans) {
> /* We are the client if transmitting */
> if (options) {
> @@ -326,7 +360,7 @@ char **argv;
> mes("nodelay");
> }
> #endif
> - if(connect(fd, &sinhim, sizeof(sinhim) ) < 0)
> + if(connect(fd, sinhim_p, sizeof(sinhim) ) < 0)
> err("connect");
> mes("connect");
> } else {
> @@ -348,11 +382,11 @@ char **argv;
> }
>
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:
>
> 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 100644 rtemsbsd/ttcp/ttcp.c
>
> diff --git a/rtemsbsd/ttcp/README b/rtemsbsd/ttcp/README
> new file mode 100644
> index ..215ddacc
> --- /dev/null
> +++ b/rtemsbsd/ttcp/README
> @@ -0,0 +1,27 @@
> +TTCP is a benchmarking tool for determining TCP and UDP performance
> +between 2 systems.
> +
> +The program was created at the US Army Ballistics Research Lab (BRL)
> +and is in the public domain. Feel free to distribute this program
> +but please do leave the credit notices in the source and man page intact.
> +
> +Contents of this directory:
> +
> +ttcp.c Source that runs on IRIX 3.3.x and 4.0.x systems
> +and BSD-based systems. This version also uses getopt(3)
> +and has 2 new options: -f and -T.
> +
> +ttcp.c-brl Original source from BRL.
> +
> +ttcp.1 Manual page (describes ttcp.c options, which are a
> +superset of the other version).
> +
> +
> +How to get TCP performance numbers:
> +
> +receiversender
> +
> +host1% ttcp -r -s host2% ttcp -t -s host1
> +
> +-n and -l options change the number and size of the buffers.
> +
Does this code come from somewhere that should be documented in the README?
> diff --git a/rtemsbsd/ttcp/ttcp.c b/rtemsbsd/ttcp/ttcp.c
> new file mode 100644
> index ..305a7c7d
> --- /dev/null
> +++ b/rtemsbsd/ttcp/ttcp.c
> @@ -0,0 +1,841 @@
> +/*
> + * T T C P . C
> + *
> + * Test TCP connection. Makes a connection on port 5001
> + * and transfers fabricated buffers or data copied from stdin.
> + *
> + * Usable on 4.2, 4.3, and 4.1a systems by defining one of
> + * BSD42 BSD43 (BSD41a)
> + * Machines using System V with BSD sockets should define SYSV.
> + *
> + * Modified for operation under 4.2BSD, 18 Dec 84
> + * T.C. Slattery, USNA
> + * Minor improvements, Mike Muuss and Terry Slattery, 16-Oct-85.
> + * Modified in 1989 at Silicon Graphics, Inc.
> + * catch SIGPIPE to be able to print stats when receiver has died
> + * for tcp, don't look for sentinel during reads to allow small transfers
> + * increased default buffer size to 8K, nbuf to 2K to transfer 16MB
> + * moved default port to 5001, beyond IPPORT_USERRESERVED
> + * make sinkmode default because it is more popular,
> + * -s now means don't sink/source
> + * count number of read/write system calls to see effects of
> + * blocking from full socket buffers
> + * for tcp, -D option turns off buffered writes (sets TCP_NODELAY
> sockopt)
> + * buffer alignment options, -A and -O
> + * print stats in a format that's a bit easier to use with grep & awk
> + * for SYSV, mimic BSD routines to use most of the existing timing code
> + * Modified by Steve Miller of the University of Maryland, College Park
> + * -b sets the socket buffer size (SO_SNDBUF/SO_RCVBUF)
> + * Modified Sept. 1989 at Silicon Graphics, Inc.
> + * restored -s sense at request of tcs@brl
> + * Modified Oct. 1991 at Silicon Graphics, Inc.
> + * use getopt(3) for option processing, add -f and -T options.
> + * SGI IRIX 3.3 and 4.0 releases don't need #define SYSV.
> + *
> + * Distribution Status -
> + * Public Domain. Distribution Unlimited.
> + */
> +#ifndef lint
> +static char RCSid[] = "ttcp.c $Revision$";
> +#endif
> +
> +#define BSD43
> +/* #define BSD42 */
> +/* #define BSD41a */
> +/* #define SYSV */ /* required on SGI IRIX releases before 3.3 */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include /* struct timeval */
> +
> +#if defined(SYSV)
> +#include
> +#include
> +struct rusage {
> +struct timeval ru_utime, ru_stime;
> +};
> +#define RUSAGE_SELF 0
> +#else
> +#include
> +#endif
> +
> +struct sockaddr_in sinme;
> +struct sockaddr_in sinhim;
> +struct sockaddr_in frominet;
> +
> +int domain, fromlen;
> +int fd;/* fd of network socket */
> +
> +int buflen = 8 * 1024; /* length of buffer */
> +char *buf; /* ptr to dynamic buffer */
> +int nbuf = 2 * 1024; /* number of buffers to send in sinkmode */
> +
> +int bufoffset = 0; /* align buffer to this */
> +int bufalign = 16*1024;/* modulo this */
> +
> +int udp = 0;
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 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
> > >
> > > use the score services).
> >
> > I did it using rtems subtract function.
> >
> > rtems_timespec_subtract (now, expire, result);
> >
> > where now expire and result are all timespec
> >
> > _TOD_Get(now); or _Timecounter_Nanouptime(now );
> >
> > and expire is
> >
> > rtems_timespec_from_ticks (ptimer->Timer.expire,expire );
> >
> > also i'm getting this compiler warning I don't know if i have to resolve
> > it, I get that my timespec variable may not be initialized.
> >
> > warning: 'result' may be used uninitialized in this function
> > [-Wmaybe-uninitialized]
> >
> > > The monotonic clock cannot be set.
> >
> > Were you talking about the fact that the monotonic clock only can go up in
> > time?
> >
> > Yes, settime is an important function to distinguish between MONOTONIC
> >
> > > > > and REALTIME cases. That is going to be tricky to think through.
> >
> > i don't understand what you mean since i have added a clock type field to
> > the POSIX_TIMER_CONTROL
> >
> > Thanks
> >
> > Zack
> >
> > ‐‐‐ Original Message ‐‐‐
> >
> > On Thursday, May 13, 2021 3:05 PM, Gedare Bloom ged...@rtems.org wrote:
> >
> > > On Wed, May 12, 2021 at 2:42 PM zack_on_the_speed_chanel
> > >
> > > zack_on_the_speed_cha...@protonmail.ch wrote:
> > >
> > > > > This ticket mostly references the need for a test. Have you tried to
> > > > >
> > > > > write a test for the missing functionality?
> > > >
> > > > How I made a test for it was to create the timer using timer_create() .
> > > > It also said to use a previous test with timer_realtime and i tested it
> > > > with sometime similar to PSXtimer02 test. I got a invalid argument
> > > > error when I tried it. Joel told me i also have to impliment the
> > > > monotonic clock
> > > >
> > > > > his math doesn't make sense to me. explain what you're trying to do?
> > > >
> > > > I wanted calculate the remaining time with the timespec. I assumed that
> > > > the timespec contained the total time seconds+miliseconds. I knew that
> > > > a cpu tick is an uint32. So i converted to timspec
> > > >
> > > > remaining = (uint32_t) ( ptimer->Timer.expire - now );
> > > >
> > > >
> > > > to something like
> > > >
> > > > expire->tv.nsec+expire->tv.sec - spec->tv.nsec+spec->tv.sec);
> > >
> > > This doesn't work. Example:
> > >
> > > now = 0s 9ns
> > >
> > > expire = 1s 0ns
> > >
> > > expire - now = 1ns
> > >
> > > expire.nsec + expire.sec - now.nsec + now.sec = -9 cast to
> > >
> > > uint32_t is 3294967297ns or so.
> > >
> > > Use helper functions in rtems/timespec.h or score/timespec.h
> > >
> > > (depending where you implement your code, in this case, you probably
> > >
> > > use the score services).
> > >
> > > > > > Yes, settime is an important function to distinguish between
> > > > > > MONOTONIC
> > > > > >
> > > > > > and REALTIME cases. That is going to be tricky to think through.
> > > >
> > > > Where do you want to check the clock type. I though I only need to
> > > > distinguish between both when getting the value of the clock. I don't
> > > > exactly know what needs to be done me being really new to posix and
> > > > operating system development.
> > >
> > > The monotonic clock cannot be set.
> > >
> > > > Zack
> > > >
> > > > ‐‐‐ Original Message ‐‐‐
> > > >
> > > > On Tuesday, May 11, 2021 6:23 AM, Gedare Bloom ged...@rtems.org wrote:
> > > >
> > > > > On Fri, May 7, 2021 at 12:53 PM zack_on_the_speed_chanel
> > > > >
> > > > > zack_on_the_speed_cha...@protonmail.ch wrote:
> > > > >
> > > > > > hello,
> > > > > >
> > > > > > Currenttly i'm trying to implement the clock_monotonic which was
> > > > > > part of ticket #3889. So far these are the changes are as follows
> > > > >
> > > > > This ticket mostly references the need for a test. Have you tried to
> > > > >
> > > > > write a test for the missing functionality?
> > > > >
> > > > > > ptimer->clock_type= &clock_id;
> > > > > >
> > > > > > in the timer create i added a field for the timer id and saved it
> > > > > > when the timer was made. Then in getttime I used the appropriate
> > > > > > timers to get the time.
> > > > > >
> > > > > > for example.
> > > > > >
> > > > > > if (ptimer->clock_type ==CLOCK_REALTIME) {
> > > > > >
> > > > > > Per_CPU_Control *cpu;
> > > > > >
> > > > > > struct timespec spec;
> > > > > >
> > > > > > struct timespec expire;
> > > > > >
> > > > > > cpu = _POSIX_
[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/test_main.c | 55 +++
3 files changed, 63 insertions(+)
create mode 100644 testsuite/ttcpshell01/test_main.c
diff --git a/libbsd.py b/libbsd.py
index 2badfdee..cb310770 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -5189,6 +5189,7 @@ class tests(builder.Module):
def generate(self):
mm = self.manager
+self.addTest(mm.generator['test']('ttcpshell01', ['test_main'],
netTest = True, runTest = False))
self.addTest(mm.generator['test']('epoch01', ['test_main'], extraLibs
= ['rtemstest']))
self.addTest(mm.generator['test']('nfs01', ['test_main'],
netTest = True, modules = ['nfsv2']))
diff --git a/testsuite/include/rtems/bsd/test/default-network-init.h
b/testsuite/include/rtems/bsd/test/default-network-init.h
index b367d956..20c0b2e7 100644
--- a/testsuite/include/rtems/bsd/test/default-network-init.h
+++ b/testsuite/include/rtems/bsd/test/default-network-init.h
@@ -318,9 +318,16 @@ Init(rtems_task_argument arg)
#define SHELL_WPA_SUPPLICANT_COMMAND
#endif
+#ifdef SHELL_TTCP_COMMAND_ENABLE
+ #define SHELL_TTCP_COMMAND &rtems_shell_TTCP_Command,
+#else
+ #define SHELL_TTCP_COMMAND
+#endif
+
#define CONFIGURE_SHELL_USER_COMMANDS \
SHELL_WLANSTATS_COMMAND \
SHELL_WPA_SUPPLICANT_COMMAND \
+ SHELL_TTCP_COMMAND \
&bsp_interrupt_shell_command, \
&rtems_shell_ARP_Command, \
&rtems_shell_HOSTNAME_Command, \
diff --git a/testsuite/ttcpshell01/test_main.c
b/testsuite/ttcpshell01/test_main.c
new file mode 100644
index ..c7631d14
--- /dev/null
+++ b/testsuite/ttcpshell01/test_main.c
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @brief RTEMS shell is started with DHCP client. It is possible to run TTCP.
+ */
+
+/*
+ * COPYRIGHT (c) 2021. On-Line Applications Research Corporation (OAR).
+ * 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.
+ */
+
+#include
+
+#include
+#include
+#include
+
+#define TEST_NAME "LIBBSD TTCP 1"
+#define TEST_STATE_USER_INPUT 1
+
+static void
+test_main(void)
+{
+ rtems_task_delete(RTEMS_SELF);
+ assert(0);
+}
+
+#define SHELL_TTCP_COMMAND_ENABLE
+#define DEFAULT_NETWORK_DHCPCD_ENABLE
+#define DEFAULT_NETWORK_SHELL
+
+#include
--
2.27.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[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.
---
libbsd.py | 2 +
rtemsbsd/include/machine/rtems-bsd-commands.h | 2 +
rtemsbsd/include/rtems/netcmds-config.h | 2 +
rtemsbsd/rtems/rtems-bsd-shell-ttcp.c | 39 +++
rtemsbsd/ttcp/ttcp.c | 266 ++
5 files changed, 259 insertions(+), 52 deletions(-)
create mode 100644 rtemsbsd/rtems/rtems-bsd-shell-ttcp.c
diff --git a/libbsd.py b/libbsd.py
index b367d94e..2badfdee 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -269,6 +269,7 @@ class rtems(builder.Module):
'rtems/rtems-bsd-shell-tcpdump.c',
'rtems/rtems-bsd-shell-vmstat.c',
'rtems/rtems-bsd-shell-wlanstats.c',
+'rtems/rtems-bsd-shell-ttcp.c',
'rtems/rtems-kvm.c',
'rtems/rtems-program.c',
'rtems/rtems-program-socket.c',
@@ -292,6 +293,7 @@ class rtems(builder.Module):
'pppd/upap.c',
'pppd/utils.c',
'telnetd/telnetd-service.c',
+'ttcp/ttcp.c',
],
mm.generator['source']()
)
diff --git a/rtemsbsd/include/machine/rtems-bsd-commands.h
b/rtemsbsd/include/machine/rtems-bsd-commands.h
index d314471f..d82c274c 100644
--- a/rtemsbsd/include/machine/rtems-bsd-commands.h
+++ b/rtemsbsd/include/machine/rtems-bsd-commands.h
@@ -84,6 +84,8 @@ int rtems_bsd_command_setkey(int argc, char **argv);
int rtems_bsd_command_openssl(int argc, char **argv);
+int rtems_shell_main_ttcp(int argc, char **argv);
+
__END_DECLS
#endif /* _RTEMS_BSD_MACHINE_RTEMS_BSD_COMMANDS_H_ */
diff --git a/rtemsbsd/include/rtems/netcmds-config.h
b/rtemsbsd/include/rtems/netcmds-config.h
index bc493af4..c1d56eb3 100644
--- a/rtemsbsd/include/rtems/netcmds-config.h
+++ b/rtemsbsd/include/rtems/netcmds-config.h
@@ -29,6 +29,8 @@ extern rtems_shell_cmd_t rtems_shell_PFCTL_Command;
extern rtems_shell_cmd_t rtems_shell_PING_Command;
extern rtems_shell_cmd_t rtems_shell_PING6_Command;
+extern rtems_shell_cmd_t rtems_shell_TTCP_Command;
+
extern rtems_shell_cmd_t rtems_shell_IFCONFIG_Command;
extern rtems_shell_cmd_t rtems_shell_IFMCSTAT_Command;
diff --git a/rtemsbsd/rtems/rtems-bsd-shell-ttcp.c
b/rtemsbsd/rtems/rtems-bsd-shell-ttcp.c
new file mode 100644
index ..babaa011
--- /dev/null
+++ b/rtemsbsd/rtems/rtems-bsd-shell-ttcp.c
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * COPYRIGHT (c) 2021. On-Line Applications Research Corporation (OAR).
+ * 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.
+ */
+
+#include
+#include
+
+rtems_shell_cmd_t rtems_shell_TTCP_Command = {
+ "ttcp", /* name */
+ "ttcp -h # to get help", /* usage */
+ "net",/* topic */
+ rtems_shell_main_ttcp,/* command */
+ NULL, /* alias */
+ NULL /* next */
+};
diff --git a/rtemsbsd/ttcp/ttcp.c b/rtemsbsd/ttcp/ttcp.c
index dc62c64b..46e0f3fc 100644
--- a/rtemsbsd/ttcp/ttcp.c
+++ b/rtemsbsd/ttcp/ttcp.c
@@ -74,48 +74,95 @@ struct rusage {
#include
#endif
-struct sockaddr_in sinme;
-struct sockaddr_in sinhim;
-struct sockaddr_in frominet;
+#if defined(__rtems__)
+#define __need_getopt_newlib
+#inc
[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.c
index 305a7c7d..dc62c64b 100644
--- a/rtemsbsd/ttcp/ttcp.c
+++ b/rtemsbsd/ttcp/ttcp.c
@@ -35,8 +35,9 @@
* Distribution Status -
* Public Domain. Distribution Unlimited.
*/
+
#ifndef lint
-static char RCSid[] = "ttcp.c $Revision$";
+/* static char RCSid[] = "ttcp.c $Revision$"; */
#endif
#define BSD43
@@ -44,6 +45,8 @@ static char RCSid[] = "ttcp.c $Revision$";
/* #define BSD41a */
/* #define SYSV */ /* required on SGI IRIX releases before 3.3 */
+#define ENABLE_NANOSLEEP_DELAY
+
#include
#include
#include
@@ -54,8 +57,12 @@ static char RCSid[] = "ttcp.c $Revision$";
#include
#include
#include
+#include
#include /* struct timeval */
+#include
+#include
+
#if defined(SYSV)
#include
#include
@@ -71,7 +78,13 @@ struct sockaddr_in sinme;
struct sockaddr_in sinhim;
struct sockaddr_in frominet;
-int domain, fromlen;
+/* these make it easier to avoid warnings */
+struct sockaddr *sinhim_p = (struct sockaddr *) &sinhim;
+struct sockaddr *sinme_p = (struct sockaddr *) &sinme;
+struct sockaddr *frominet_p = (struct sockaddr *) &frominet;
+
+int domain;
+socklen_t fromlen;
int fd;/* fd of network socket */
int buflen = 8 * 1024; /* length of buffer */
@@ -97,6 +110,7 @@ char fmt = 'K'; /* output format: k =
kilobits, K = kilobytes,
* m = megabits, M = megabytes,
* g = gigabits, G = gigabytes */
int touchdata = 0; /* access data after reading */
+long milliseconds = 0; /* delay in milliseconds */
struct hostent *addr;
extern int errno;
@@ -124,6 +138,7 @@ Options specific to -t:\n\
Options specific to -r:\n\
-B for -s, only output full blocks as specified by -l (for TAR)\n\
-T \"touch\": access each byte as it's read\n\
+ -m ## delay for specified milliseconds between each write\n\
";
char stats[128];
@@ -133,7 +148,7 @@ double cput, realt; /* user, real time (seconds) */
void err();
void mes();
-int pattern();
+void pattern();
void prep_timer();
double read_timer();
int Nread();
@@ -147,7 +162,18 @@ sigpipe()
{
}
-main(argc,argv)
+void millisleep(long msec)
+{
+#if defined(ENABLE_NANOSLEEP_DELAY)
+ struct timespec req;
+
+ req.tv_sec = msec / 1000;
+ req.tv_nsec = (msec % 1000) * 100;
+
+ nanosleep( &req, NULL );
+#endif
+}
+int main(argc,argv)
int argc;
char **argv;
{
@@ -156,7 +182,7 @@ char **argv;
if (argc < 2) goto usage;
- while ((c = getopt(argc, argv, "drstuvBDTb:f:l:n:p:A:O:")) != -1) {
+ while ((c = getopt(argc, argv, "drstuvBDTb:f:l:m:n:p:A:O:")) != -1) {
switch (c) {
case 'B':
@@ -179,6 +205,12 @@ char **argv;
"ttcp: -D option ignored: TCP_NODELAY socket option not supported\n");
#endif
break;
+ case 'm':
+ milliseconds = atoi(optarg);
+ #if !defined(ENABLE_NANOSLEEP_DELAY)
+ fprintf(stderr, "millisecond delay disabled\n");
+ #endif
+ break;
case 'n':
nbuf = atoi(optarg);
break;
@@ -285,7 +317,7 @@ char **argv;
err("socket");
mes("socket");
- if (bind(fd, &sinme, sizeof(sinme)) < 0)
+ if (bind(fd, sinme_p, sizeof(sinme)) < 0)
err("bind");
#if defined(SO_SNDBUF) || defined(SO_RCVBUF)
@@ -305,7 +337,9 @@ char **argv;
#endif
if (!udp) {
+#if !defined(__rtems__)
signal(SIGPIPE, sigpipe);
+#endif
if (trans) {
/* We are the client if transmitting */
if (options) {
@@ -326,7 +360,7 @@ char **argv;
mes("nodelay");
}
#endif
- if(connect(fd, &sinhim, sizeof(sinhim) ) < 0)
+ if(connect(fd, sinhim_p, sizeof(sinhim) ) < 0)
err("connect");
mes("connect");
} else {
@@ -348,11 +382,11 @@ char **argv;
}
fromlen = sizeof(frominet);
domain = AF_INET;
- if((fd=accept(fd, &frominet, &fromlen) ) < 0)
+ if((fd=accept(fd, frominet_p, &fromlen) ) < 0)
err("accept");
{ struct sockaddr_in peer;
- int peerlen = sizeof(peer);
- if (getpeername(fd, (struct sockaddr_in *) &peer,
+ socklen_t peerlen = sizeof(peer);
+ if (getpeername(fd, (struct socka
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 the return code should align with the other methods in the family. https://pubs.opengroup.org/onlinepubs/9699919799/functions/futimens.html [ENOENT]A component of *path* does not name an existing file or *path* is an empty string. That should be the error being returned now and it seems right. I will update the test accordingly. --joel On Tue, Jun 8, 2021 at 7:09 AM Joel Sherrill wrote: > > > 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 >> ea881bf7a15721916d4adcc5f117ebf6acc6d2a3 >> 335f7050822262f029e7945b31b0f2bb2d889bcc >> 6171a88d9c7f90bac9a076edf3655f7c9e2efb94 >> ea41722c92313e884368106832d3454114ba88b3 >> We cannot bisect more! >> >> broke this test: >> >> *** BEGIN OF TEST FSNOFS 1 *** >> *** TEST VERSION: 6.0.0.ea41722c92313e884368106832d3454114ba88b3 >> *** TEST STATE: EXPECTED_PASS >> *** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API >> *** TEST TOOLS: 10.3.1 20210409 (RTEMS 6, RSB >> 4e6dc6431435821a534da6307e72ecbd7e42b82a, Newlib 0c0f3df) >> /home/EB/sebastian_h/src/rtems/testsuites/fstests/fsnofs01/init.c: 300 >> errno == ENXIO >> >> *** FATAL *** >> fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT) >> fatal code: 0 (0x) >> RTEMS version: 6.0.0.ea41722c92313e884368106832d3454114ba88b3 >> RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB >> 4e6dc6431435821a534da6307e72ecbd7e42b82a, Newlib 0c0f3df) >> executing thread ID: 0x08a010001 >> executing thread name: UI1 > > >> >> >> Not all commits of the patch set build. This is prevented a proper git >> bisect. >> > > The toolset has to change at some point. > > I'll see if I can reproduce this today > > --joel > >> >> -- >> 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 > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[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 100644 rtemsbsd/ttcp/ttcp.c
diff --git a/rtemsbsd/ttcp/README b/rtemsbsd/ttcp/README
new file mode 100644
index ..215ddacc
--- /dev/null
+++ b/rtemsbsd/ttcp/README
@@ -0,0 +1,27 @@
+TTCP is a benchmarking tool for determining TCP and UDP performance
+between 2 systems.
+
+The program was created at the US Army Ballistics Research Lab (BRL)
+and is in the public domain. Feel free to distribute this program
+but please do leave the credit notices in the source and man page intact.
+
+Contents of this directory:
+
+ttcp.c Source that runs on IRIX 3.3.x and 4.0.x systems
+and BSD-based systems. This version also uses getopt(3)
+and has 2 new options: -f and -T.
+
+ttcp.c-brl Original source from BRL.
+
+ttcp.1 Manual page (describes ttcp.c options, which are a
+superset of the other version).
+
+
+How to get TCP performance numbers:
+
+receiversender
+
+host1% ttcp -r -s host2% ttcp -t -s host1
+
+-n and -l options change the number and size of the buffers.
+
diff --git a/rtemsbsd/ttcp/ttcp.c b/rtemsbsd/ttcp/ttcp.c
new file mode 100644
index ..305a7c7d
--- /dev/null
+++ b/rtemsbsd/ttcp/ttcp.c
@@ -0,0 +1,841 @@
+/*
+ * T T C P . C
+ *
+ * Test TCP connection. Makes a connection on port 5001
+ * and transfers fabricated buffers or data copied from stdin.
+ *
+ * Usable on 4.2, 4.3, and 4.1a systems by defining one of
+ * BSD42 BSD43 (BSD41a)
+ * Machines using System V with BSD sockets should define SYSV.
+ *
+ * Modified for operation under 4.2BSD, 18 Dec 84
+ * T.C. Slattery, USNA
+ * Minor improvements, Mike Muuss and Terry Slattery, 16-Oct-85.
+ * Modified in 1989 at Silicon Graphics, Inc.
+ * catch SIGPIPE to be able to print stats when receiver has died
+ * for tcp, don't look for sentinel during reads to allow small transfers
+ * increased default buffer size to 8K, nbuf to 2K to transfer 16MB
+ * moved default port to 5001, beyond IPPORT_USERRESERVED
+ * make sinkmode default because it is more popular,
+ * -s now means don't sink/source
+ * count number of read/write system calls to see effects of
+ * blocking from full socket buffers
+ * for tcp, -D option turns off buffered writes (sets TCP_NODELAY sockopt)
+ * buffer alignment options, -A and -O
+ * print stats in a format that's a bit easier to use with grep & awk
+ * for SYSV, mimic BSD routines to use most of the existing timing code
+ * Modified by Steve Miller of the University of Maryland, College Park
+ * -b sets the socket buffer size (SO_SNDBUF/SO_RCVBUF)
+ * Modified Sept. 1989 at Silicon Graphics, Inc.
+ * restored -s sense at request of tcs@brl
+ * Modified Oct. 1991 at Silicon Graphics, Inc.
+ * use getopt(3) for option processing, add -f and -T options.
+ * SGI IRIX 3.3 and 4.0 releases don't need #define SYSV.
+ *
+ * Distribution Status -
+ * Public Domain. Distribution Unlimited.
+ */
+#ifndef lint
+static char RCSid[] = "ttcp.c $Revision$";
+#endif
+
+#define BSD43
+/* #define BSD42 */
+/* #define BSD41a */
+/* #define SYSV */ /* required on SGI IRIX releases before 3.3 */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include /* struct timeval */
+
+#if defined(SYSV)
+#include
+#include
+struct rusage {
+struct timeval ru_utime, ru_stime;
+};
+#define RUSAGE_SELF 0
+#else
+#include
+#endif
+
+struct sockaddr_in sinme;
+struct sockaddr_in sinhim;
+struct sockaddr_in frominet;
+
+int domain, fromlen;
+int fd;/* fd of network socket */
+
+int buflen = 8 * 1024; /* length of buffer */
+char *buf; /* ptr to dynamic buffer */
+int nbuf = 2 * 1024; /* number of buffers to send in sinkmode */
+
+int bufoffset = 0; /* align buffer to this */
+int bufalign = 16*1024;/* modulo this */
+
+int udp = 0; /* 0 = tcp, !0 = udp */
+int options = 0; /* socket options */
+int one = 1;/* for 4.3 BSD style setsockopt() */
+short port = 5001; /* TCP port number */
+char *host;/* ptr to name of host */
+int trans; /* 0=receive, !0=transmit mode */
+int sinkmode = 0; /* 0=normal I/O, !0=sink/source mode */
+int verbose = 0; /* 0=print basic info, 1=print cpu rate, proc
+* resource usage. */
+int nodelay = 0; /* set TCP_NODELAY socket option */
+int b_flag = 0;
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 an application can still add this step as a very early system initialization step, since boot_card() and the system initialization loop doesn't use global data (only read-only and BSS data). However, the SMP startup would still not work in this case. A boot loader is a better place to load the sections. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [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 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 _Memory_Allocate() even before the system initialization is started.
>
> Change license to BSD-2-Clause according to file history and
> re-licensing agreement.
>
> Update #3053.
> ---
> bsps/sparc/shared/start/bspgetworkarea.c | 59 ++--
> bsps/sparc/shared/start/start.S | 14 ++
> 2 files changed, 39 insertions(+), 34 deletions(-)
>
> diff --git a/bsps/sparc/shared/start/bspgetworkarea.c
> b/bsps/sparc/shared/start/bspgetworkarea.c
> index 3fbeb824f2..6ceda38c07 100644
> --- a/bsps/sparc/shared/start/bspgetworkarea.c
> +++ b/bsps/sparc/shared/start/bspgetworkarea.c
> @@ -1,44 +1,55 @@
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreMemory
> + *
> + * @brief This source file contains an implementation of _Memory_Get().
> + */
> +
> /*
> - * This set of routines are the BSP specific initialization
> - * support routines.
> + * SPDX-License-Identifier: BSD-2-Clause
> *
> - * COPYRIGHT (c) 1989-2008.
> - * On-Line Applications Research Corporation (OAR).
> + * Copyright (C) 2019, 2021 embedded brains GmbH
> *
> - * The license and distribution terms for this file may be
> - * found in the file LICENSE in this distribution or at
> - * http://www.rtems.org/license/LICENSE.
> + * 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
>
> -/* Tells us where to put the workspace in case remote debugger is present.
> */
> -extern uintptr_t rdb_start;
> +/* This function is called only by the start sequence defined in start.S */
> +void _SPARC_Memory_initialize( void *end_of_usable_ram );
>
> static Memory_Area _Memory_Areas[ 1 ];
>
> static const Memory_Information _Memory_Information =
>MEMORY_INFORMATION_INITIALIZER( _Memory_Areas );
>
> -static void bsp_memory_initialize( void )
> +void _SPARC_Memory_initialize( void *end_of_usable_ram )
> {
> - void *begin;
> - uintptr_t size;
> -
> - begin = &end;
> - size = rdb_start - (uintptr_t)begin;
> - _Memory_Initialize_by_size( &_Memory_Areas[ 0 ], begin, size );
> + _Memory_Initialize( &_Memory_Areas[ 0 ], &end, end_of_usable_ram );
> }
>
> -RTEMS_SYSINIT_ITEM(
> - bsp_memory_initialize,
> - RTEMS_SYSINIT_MEMORY,
> - RTEMS_SYSINIT_ORDER_MIDDLE
> -);
> -
> const Memory_Information *_Memory_Get( void )
> {
>return &_Memory_Information;
> diff --git a/bsps/sparc/shared/start/start.S b/bsps/sparc/shared/start/start.S
> index 807e5d1ca3..8a5830ae03 100644
> --- a/bsps/sparc/shared/start/start.S
> +++ b/bsps/sparc/shared/start/start.S
> @@ -178,16 +178,10 @@ SYM(trap_table):
> MEC timer control register mirror is so we can stop the timers
> from an external debugger. It is needed because the control
> register is write-only. Trap 0x7C cannot occure in ERC32...
> -
> - We also use this location to store the last location of the
> - usable RAM in order not to overwrite the remote debugger with
> - the RTEMS work-space area.
> -
> */
>
> - .global SYM(_ERC32_MEC_Timer_Control_Mirror), SYM(rdb_start),
> SYM(CLOCK_SPEED)
> + .global SYM(_ERC32_MEC_Timer_Control_Mirror), SYM(CLOCK_SPEED)
>
> -SYM(rdb_start):
> SYM(_ERC32_
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 Bloom ; Sommer, Jan > > Cc: devel@rtems.org > Subject: Re: [PATCH v2 2/2] i386: Remove unneeded include header files > > I agree this is the way to solve this issue. > > Chris > > On 8/6/21 3:09 am, Gedare Bloom wrote: > > This looks like a much better solution :) If no one complains by > > Thursday go ahead and push it. > > > > On Mon, Jun 7, 2021 at 2:53 AM Jan Sommer wrote: > >> > >> --- > >> .../sys/i386/include/machine/intr_machdep.h |6 - > >> rtemsbsd/include/x86/bus.h| 1109 > >> rtemsbsd/include/x86/specialreg.h | 1143 - > >> 3 files changed, 2258 deletions(-) > >> delete mode 100644 freebsd/sys/i386/include/machine/intr_machdep.h > >> delete mode 100644 rtemsbsd/include/x86/bus.h > >> delete mode 100644 rtemsbsd/include/x86/specialreg.h > >> > >> diff --git a/freebsd/sys/i386/include/machine/intr_machdep.h > b/freebsd/sys/i386/include/machine/intr_machdep.h > >> deleted file mode 100644 > >> index a0b28387.. > >> --- a/freebsd/sys/i386/include/machine/intr_machdep.h > >> +++ /dev/null > >> @@ -1,6 +0,0 @@ > >> -/*- > >> - * This file is in the public domain. > >> - */ > >> -/* $FreeBSD$ */ > >> - > >> -#include > >> diff --git a/rtemsbsd/include/x86/bus.h b/rtemsbsd/include/x86/bus.h > >> deleted file mode 100644 > >> index 2427ae51.. > >> --- a/rtemsbsd/include/x86/bus.h > >> +++ /dev/null > >> @@ -1,1109 +0,0 @@ > >> -/*- > >> - * SPDX-License-Identifier: BSD-3-Clause AND BSD-2-Clause-NetBSDE > >> - * > >> - * Copyright (c) KATO Takenori, 1999. > >> - * > >> - * All rights reserved. Unpublished rights reserved under the copyright > >> - * laws of Japan. > >> - * > >> - * 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 as > >> - *the first lines of this file unmodified. > >> - * 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. > >> - * 3. The name of the author may not be used to endorse or promote > products > >> - *derived from this software without specific prior written > >> permission. > >> - * > >> - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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 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. > >> - * > >> - * $FreeBSD$ > >> - */ > >> - > >> -/* $NetBSD: bus.h,v 1.12 1997/10/01 08:25:15 fvdl Exp $*/ > >> - > >> -/*- > >> - * Copyright (c) 1996, 1997 The NetBSD Foundation, Inc. > >> - * All rights reserved. > >> - * > >> - * This code is derived from software contributed to The NetBSD > Foundation > >> - * by Jason R. Thorpe of the Numerical Aerospace Simulation Facility, > >> - * NASA Ames Research Center. > >> - * > >> - * 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 NETBSD FOUNDATION, INC. 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 FOUNDATION OR > CONTRIBUTORS > >> - * BE LIABLE FOR ANY DIR
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 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 sure I agree with the premise the YAML is the documentation. > >>> The > >>> user manual exists for this purpose and user wanting to explore RTEMS > >>> would look > >>> there rather than cloning the repo, running commands etc. > >> > >> The alternative would be to duplicate documentation of the BSP options in > >> the > >> user manual. And (manual) duplication is always a bad idea if you ask me. > >> Or > >> move the description from the yaml to the documentation entirely which > >> means > >> that you need to pick the correct version of the documentation for the > >> sources. > >> It also means that you have to look up the meaning of each option in the > >> right > >> version of the manual instead of in the default config. > > > > At the moment users need to work too hard to find it. Maybe manual changes > > can > > be added if someone wants to added them until a better solution is > > provided. I > > think it is better that blocking changes until it is. > > At the moment for the i.MXRT BSP all BSP options are documented in the > yaml files. In the user manual there is a section > > === > > 8.2.10.1. Build Configuration Options > > Please see the documentation of the IMXRT_* and BSP_* configuration > options for that. You can generate a default set of options with: > > ./waf bsp_defaults --rtems-bsps=arm/imxrt1052 > config.ini > > === > > That's one command that a user has to call to see the BSP options > including their meaning _and_ get a default config.ini (a file that he > needs anyway also not necessarily with all options). > This is satisfactory to me. At least for now, this pattern should be well-documented/generalized for all BSPs though. > There are some (very few) BSPs that have a list of Build Configuration > Options in the manual. The i.mx (without RT) and the i386 are two of > them. The description of the options is slightly different from the ones > in the yaml files and I really don't want to review them. A lot of other > BSPs don't have any description at all (for example beagle, xen, > raspberrypi, nearly all powerpc, qemu A53 (aarch64), ...). > We should avoid the explicit listing, unless it is a completely auto-generated manual, as mentioned elsewhere. For now, I'm fine with instructing the user how to generate those build configuration options, since they would need to be doing that to build rtems anyway. > If you want, I can replace the call in the manual by a inlined > config.ini for that BSP. I _hope_ that everyone remembers that he has to > update that file in the manual too. But I wouldn't guarantee that. I > think the call is a lot more user friendly than an possibly outdated > user manual where the exact right version has to be used. > No, let's not do that. Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
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...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [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 > ea881bf7a15721916d4adcc5f117ebf6acc6d2a3 > 335f7050822262f029e7945b31b0f2bb2d889bcc > 6171a88d9c7f90bac9a076edf3655f7c9e2efb94 > ea41722c92313e884368106832d3454114ba88b3 > We cannot bisect more! > > broke this test: > > *** BEGIN OF TEST FSNOFS 1 *** > *** TEST VERSION: 6.0.0.ea41722c92313e884368106832d3454114ba88b3 > *** TEST STATE: EXPECTED_PASS > *** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API > *** TEST TOOLS: 10.3.1 20210409 (RTEMS 6, RSB > 4e6dc6431435821a534da6307e72ecbd7e42b82a, Newlib 0c0f3df) > /home/EB/sebastian_h/src/rtems/testsuites/fstests/fsnofs01/init.c: 300 > errno == ENXIO > > *** FATAL *** > fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT) > fatal code: 0 (0x) > RTEMS version: 6.0.0.ea41722c92313e884368106832d3454114ba88b3 > RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB > 4e6dc6431435821a534da6307e72ecbd7e42b82a, Newlib 0c0f3df) > executing thread ID: 0x08a010001 > executing thread name: UI1 > > > Not all commits of the patch set build. This is prevented a proper git > bisect. > The toolset has to change at some point. I'll see if I can reproduce this today --joel > > -- > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
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/?id=527848d5cc8b60c499e712153ac1f81a60e6a631 > > > > Author:Ryan Long > > Date: Fri May 14 15:25:38 2021 -0400 > > > > rtems-bsp-builder: Change to waf build system > > > > Closes #4124 > > Since this is fixed now, what is missing to remove the old build system? > rtems-tools needs to be bumped and we need to see full automated results from the bsp builder. Alex has a patch for that pending. Is the kernel rsb recipe fixed yet? That was a blocker. Ray is working on a docs patch to catch the lingering 4.11, bootstrap, and configure references. Hopefully this weekend RTEMS tools will be updated and my test sweep will work. If thats ok and the kernel recipe is fixed, we should be there. > -- > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
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 system are now documented directly in the yaml files and printed if you generate the default config. Hmm I am not sure I agree with the premise the YAML is the documentation. The user manual exists for this purpose and user wanting to explore RTEMS would look there rather than cloning the repo, running commands etc. The alternative would be to duplicate documentation of the BSP options in the user manual. And (manual) duplication is always a bad idea if you ask me. Or move the description from the yaml to the documentation entirely which means that you need to pick the correct version of the documentation for the sources. It also means that you have to look up the meaning of each option in the right version of the manual instead of in the default config. At the moment users need to work too hard to find it. Maybe manual changes can be added if someone wants to added them until a better solution is provided. I think it is better that blocking changes until it is. At the moment for the i.MXRT BSP all BSP options are documented in the yaml files. In the user manual there is a section === 8.2.10.1. Build Configuration Options Please see the documentation of the IMXRT_* and BSP_* configuration options for that. You can generate a default set of options with: ./waf bsp_defaults --rtems-bsps=arm/imxrt1052 > config.ini === That's one command that a user has to call to see the BSP options including their meaning _and_ get a default config.ini (a file that he needs anyway also not necessarily with all options). There are some (very few) BSPs that have a list of Build Configuration Options in the manual. The i.mx (without RT) and the i386 are two of them. The description of the options is slightly different from the ones in the yaml files and I really don't want to review them. A lot of other BSPs don't have any description at all (for example beagle, xen, raspberrypi, nearly all powerpc, qemu A53 (aarch64), ...). If you want, I can replace the call in the manual by a inlined config.ini for that BSP. I _hope_ that everyone remembers that he has to update that file in the manual too. But I wouldn't guarantee that. I think the call is a lot more user friendly than an possibly outdated user manual where the exact right version has to be used. I think the only reasonable option (with the current structure) would be to somehow automatically generate that documentation part. For example by creating the default BSP config.ini for each BSP and adding it to the user manual. But that has to be an automatic process. Otherwise it will be out of date right from the beginning. or something else. I don't think we need to solve the problem here and now as we do not have enough support in rtems.git to handle it. I do not want to depend on rtems-central at this point in time. It needs to mature, it needs to exist for a while and be supported before we can integrate it. If you _want_ config.ini files in the manuals (or some other format for the options) I think the repo would be exactly the right place to hold a script to generate that kind of stuff. How should it become mature otherwise? I accept the current defaults etc work flow is a good place to start for the waf conversion project but we need to do a lot more to make accessing the YAML easier. The wscript contains the only rtems.git repo means to read the YAML and the pickled data and that limits how we can change and evolve this. We could merge documentation and code again. From my point of view that would make it simpler to add documentation for new features right when they are implemented and there would be always the right version for a source commit. I don't really know the reason why it was split up in 2015 / 2016 so we would have to look that up before discussing further into that direction. Additionally it would need discussion how and where (for example) network stacks would be documented. It was split because it did not work as it did not handle the whole project so please lets not be distracted revisiting old problems. That argument is about the same point that I added as a contra argument in the second sentence: I wouldn't be sure where to put the additional mauals. I'm not a fan of split documentation and code but I'm OK with not discussing that here and now. Best regards Christian Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
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 rtems-bsp-builder: Change to waf build system Closes #4124 Since this is fixed now, what is missing to remove the old build system? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [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 sure I agree with the premise the YAML is the documentation. The user manual exists for this purpose and user wanting to explore RTEMS would look there rather than cloning the repo, running commands etc. I accept the current defaults etc work flow is a good place to start for the waf conversion project but we need to do a lot more to make accessing the YAML easier. The wscript contains the only rtems.git repo means to read the YAML and the pickled data and that limits how we can change and evolve this. We could use rtems-central to generate sections for the user manual from the build specification. This would be similar to the generation of the glossaries, application configuration option documentation, and the directive documentation. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [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 ea41722c92313e884368106832d3454114ba88b3 We cannot bisect more! broke this test: *** BEGIN OF TEST FSNOFS 1 *** *** TEST VERSION: 6.0.0.ea41722c92313e884368106832d3454114ba88b3 *** TEST STATE: EXPECTED_PASS *** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API *** TEST TOOLS: 10.3.1 20210409 (RTEMS 6, RSB 4e6dc6431435821a534da6307e72ecbd7e42b82a, Newlib 0c0f3df) /home/EB/sebastian_h/src/rtems/testsuites/fstests/fsnofs01/init.c: 300 errno == ENXIO *** FATAL *** fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT) fatal code: 0 (0x) RTEMS version: 6.0.0.ea41722c92313e884368106832d3454114ba88b3 RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB 4e6dc6431435821a534da6307e72ecbd7e42b82a, Newlib 0c0f3df) executing thread ID: 0x08a010001 executing thread name: UI1 Not all commits of the patch set build. This is prevented a proper git bisect. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [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 yaml files and >>> printed >>> if you generate the default config. >> >> Hmm I am not sure I agree with the premise the YAML is the documentation. The >> user manual exists for this purpose and user wanting to explore RTEMS would >> look >> there rather than cloning the repo, running commands etc. > > The alternative would be to duplicate documentation of the BSP options in the > user manual. And (manual) duplication is always a bad idea if you ask me. Or > move the description from the yaml to the documentation entirely which means > that you need to pick the correct version of the documentation for the > sources. > It also means that you have to look up the meaning of each option in the right > version of the manual instead of in the default config. At the moment users need to work too hard to find it. Maybe manual changes can be added if someone wants to added them until a better solution is provided. I think it is better that blocking changes until it is. > I think the only reasonable option (with the current structure) would be to > somehow automatically generate that documentation part. For example by > creating > the default BSP config.ini for each BSP and adding it to the user manual. But > that has to be an automatic process. Otherwise it will be out of date right > from > the beginning. or something else. I don't think we need to solve the problem here and now as we do not have enough support in rtems.git to handle it. I do not want to depend on rtems-central at this point in time. It needs to mature, it needs to exist for a while and be supported before we can integrate it. >> I accept the current defaults etc work flow is a good place to start for the >> waf >> conversion project but we need to do a lot more to make accessing the YAML >> easier. The wscript contains the only rtems.git repo means to read the YAML >> and >> the pickled data and that limits how we can change and evolve this. >> > > We could merge documentation and code again. From my point of view that would > make it simpler to add documentation for new features right when they are > implemented and there would be always the right version for a source commit. I > don't really know the reason why it was split up in 2015 / 2016 so we would > have > to look that up before discussing further into that direction. Additionally it > would need discussion how and where (for example) network stacks would be > documented. It was split because it did not work as it did not handle the whole project so please lets not be distracted revisiting old problems. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
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/sparc/shared/start/start.S index 369ef72a94..4922a97d6d 100644 --- a/bsps/sparc/shared/start/start.S +++ b/bsps/sparc/shared/start/start.S @@ -306,13 +306,12 @@ SYM(hard_reset): nop ld [%g6 + PER_CPU_INTERRUPT_STACK_HIGH], %sp ! set stack pointer - sub %sp, 4, %sp ! stack starts at end of area - 4 - andn%sp, 0x0f, %sp ! align stack on 16-byte boundary + andn%sp, CPU_STACK_ALIGNMENT - 1, %sp + sub %sp, SPARC_MINIMUM_STACK_FRAME_SIZE, %sp mov %sp, %fp! set frame pointer - mov %g6, %o0 callSYM(bsp_start_on_secondary_processor) ! does not return -sub%sp, SPARC_MINIMUM_STACK_FRAME_SIZE, %sp +mov%g6, %i0 Sorry, this should be "mov %g6, %o0". .Lbootcpu: st %o0, [%o1] #endif @@ -326,8 +325,8 @@ SYM(hard_reset): #endif set SYM(_ISR_Stack_area_begin), %sp add %sp, %g5, %sp - sub %sp, 4, %sp ! stack starts at end of area - 4 - andn%sp, 0x0f, %sp ! align stack on 16-byte boundary + andn%sp, CPU_STACK_ALIGNMENT - 1, %sp + sub %sp, SPARC_MINIMUM_STACK_FRAME_SIZE, %sp mov %sp, %fp! Set frame pointer nop @@ -346,8 +345,7 @@ SYM(hard_reset): bleu,a .Lzerobss nop -mov %g0, %o0! command line callSYM(boot_card) ! does not return - sub %sp, 0x60, %sp ! room for boot_card to save args + mov%g0, %i0! command line Sorry, this should be "mov %g0, %o0". -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 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 _Memory_Allocate() even before the system initialization is started.
Change license to BSD-2-Clause according to file history and
re-licensing agreement.
Update #3053.
---
bsps/sparc/shared/start/bspgetworkarea.c | 59 ++--
bsps/sparc/shared/start/start.S | 14 ++
2 files changed, 39 insertions(+), 34 deletions(-)
diff --git a/bsps/sparc/shared/start/bspgetworkarea.c
b/bsps/sparc/shared/start/bspgetworkarea.c
index 3fbeb824f2..6ceda38c07 100644
--- a/bsps/sparc/shared/start/bspgetworkarea.c
+++ b/bsps/sparc/shared/start/bspgetworkarea.c
@@ -1,44 +1,55 @@
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreMemory
+ *
+ * @brief This source file contains an implementation of _Memory_Get().
+ */
+
/*
- * This set of routines are the BSP specific initialization
- * support routines.
+ * SPDX-License-Identifier: BSD-2-Clause
*
- * COPYRIGHT (c) 1989-2008.
- * On-Line Applications Research Corporation (OAR).
+ * Copyright (C) 2019, 2021 embedded brains GmbH
*
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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
-/* Tells us where to put the workspace in case remote debugger is present. */
-extern uintptr_t rdb_start;
+/* This function is called only by the start sequence defined in start.S */
+void _SPARC_Memory_initialize( void *end_of_usable_ram );
static Memory_Area _Memory_Areas[ 1 ];
static const Memory_Information _Memory_Information =
MEMORY_INFORMATION_INITIALIZER( _Memory_Areas );
-static void bsp_memory_initialize( void )
+void _SPARC_Memory_initialize( void *end_of_usable_ram )
{
- void *begin;
- uintptr_t size;
-
- begin = &end;
- size = rdb_start - (uintptr_t)begin;
- _Memory_Initialize_by_size( &_Memory_Areas[ 0 ], begin, size );
+ _Memory_Initialize( &_Memory_Areas[ 0 ], &end, end_of_usable_ram );
}
-RTEMS_SYSINIT_ITEM(
- bsp_memory_initialize,
- RTEMS_SYSINIT_MEMORY,
- RTEMS_SYSINIT_ORDER_MIDDLE
-);
-
const Memory_Information *_Memory_Get( void )
{
return &_Memory_Information;
diff --git a/bsps/sparc/shared/start/start.S b/bsps/sparc/shared/start/start.S
index 807e5d1ca3..8a5830ae03 100644
--- a/bsps/sparc/shared/start/start.S
+++ b/bsps/sparc/shared/start/start.S
@@ -178,16 +178,10 @@ SYM(trap_table):
MEC timer control register mirror is so we can stop the timers
from an external debugger. It is needed because the control
register is write-only. Trap 0x7C cannot occure in ERC32...
-
- We also use this location to store the last location of the
- usable RAM in order not to overwrite the remote debugger with
- the RTEMS work-space area.
-
*/
- .global SYM(_ERC32_MEC_Timer_Control_Mirror), SYM(rdb_start),
SYM(CLOCK_SPEED)
+ .global SYM(_ERC32_MEC_Timer_Control_Mirror), SYM(CLOCK_SPEED)
-SYM(rdb_start):
SYM(_ERC32_MEC_Timer_Control_Mirror):
BAD_TRAP; BAD_TRAP; ! 7C - 7D undefined
@@ -320,9 +314,6 @@ SYM(hard_reset):
st %l7, [%l0]
#endif
- set SYM(rdb_start), %g5 ! End of RAM
- st %o0, [%g5]
-
/* clear the bss */
sethi %hi(__bss_start), %g2 ! g2 = start of bss
@@ -338,6 +329,9 @@ SYM(hard_reset):
bleu,a .Lzerobss
nop
+callS
[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(-) diff --git a/bsps/sparc/shared/start/start.S b/bsps/sparc/shared/start/start.S index 4922a97d6d..807e5d1ca3 100644 --- a/bsps/sparc/shared/start/start.S +++ b/bsps/sparc/shared/start/start.S @@ -288,47 +288,40 @@ SYM(hard_reset): nop nop - sethi %hi(_Per_CPU_Information), %g6 ! get per-CPU control - add %g6, %lo(_Per_CPU_Information), %g6 +mov %sp, %o0 ! save initial stack pointer (end of usable RAM) +set SYM(_Per_CPU_Information), %g6 ! set per-CPU control +set SYM(_ISR_Stack_size), %l0 ! set ISR stack size #if defined(START_LEON3_ENABLE_SMP) - rd %asr17, %o0 ! get CPU identifier - srl %o0, LEON3_ASR17_PROCESSOR_INDEX_SHIFT, %o0 - - sll %o0, PER_CPU_CONTROL_SIZE_LOG2, %l0 - add %g6, %l0, %g6 +rd %asr17, %l7 ! get CPU identifier +srl %l7, LEON3_ASR17_PROCESSOR_INDEX_SHIFT, %l7 +add %l7, 1, %l1 ! get ISR stack offset for this CPU +smul%l1, %l0, %l0 +sll %l7, PER_CPU_CONTROL_SIZE_LOG2, %l2 ! per-CPU for this CPU +add %g6, %l2, %g6 +#endif +set SYM(_ISR_Stack_area_begin), %sp +add %sp, %l0, %sp ! set stack pointer +andn%sp, CPU_STACK_ALIGNMENT - 1, %sp +sub %sp, SPARC_MINIMUM_STACK_FRAME_SIZE, %sp +mov %sp, %fp ! set frame pointer +#if defined(START_LEON3_ENABLE_SMP) /* If LEON3_Boot_Cpu < 0 then assign us as boot CPU and continue. */ - set SYM(LEON3_Boot_Cpu), %o1 - ld [%o1], %o2 - tst %o2 +set SYM(LEON3_Boot_Cpu), %l0 +ld [%l0], %l1 +tst %l1 bneg.Lbootcpu nop - ld [%g6 + PER_CPU_INTERRUPT_STACK_HIGH], %sp ! set stack pointer - andn%sp, CPU_STACK_ALIGNMENT - 1, %sp - sub %sp, SPARC_MINIMUM_STACK_FRAME_SIZE, %sp - mov %sp, %fp! set frame pointer - callSYM(bsp_start_on_secondary_processor) ! does not return mov%g6, %i0 .Lbootcpu: - st %o0, [%o1] + st %l7, [%l0] #endif set SYM(rdb_start), %g5 ! End of RAM - st %sp, [%g5] - set SYM(_ISR_Stack_size), %g5 -#if defined(START_LEON3_ENABLE_SMP) - add %o0, 1, %o0 - smul%o0, %g5, %g5 -#endif - set SYM(_ISR_Stack_area_begin), %sp - add %sp, %g5, %sp - andn%sp, CPU_STACK_ALIGNMENT - 1, %sp - sub %sp, SPARC_MINIMUM_STACK_FRAME_SIZE, %sp -mov %sp, %fp! Set frame pointer -nop + st %o0, [%g5] /* clear the bss */ -- 2.26.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[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 the start sequence. --- bsps/sparc/shared/start/start.S | 36 - 1 file changed, 4 insertions(+), 32 deletions(-) diff --git a/bsps/sparc/shared/start/start.S b/bsps/sparc/shared/start/start.S index f7caacf0e4..369ef72a94 100644 --- a/bsps/sparc/shared/start/start.S +++ b/bsps/sparc/shared/start/start.S @@ -331,47 +331,19 @@ SYM(hard_reset): mov %sp, %fp! Set frame pointer nop -/* - * Copy the initialized data to RAM - * - * FROM: _data_load_start - * TO: _data_start - * LENGTH: (__bss_start - _data_start) bytes - */ - -sethi %hi(_data_load_start),%g1 ! g1 = start of initialized data in ROM -or%g1,%lo(_data_load_start),%g1 - -sethi %hi(_data_start),%g3 ! g3 = start of initialized data in RAM -or%g3,%lo(_data_start),%g3 +/* clear the bss */ -sethi %hi(__bss_start), %g2 ! g2 = end of initialized data in RAM +sethi %hi(__bss_start), %g2 ! g2 = start of bss or%g2,%lo(__bss_start),%g2 - cmp %g1, %g3 - be1f - nop - -copy_data: -ldd [%g1], %g4 -std %g4 , [%g3] ! copy this double word -add %g3, 8, %g3 ! bump the destination pointer -add %g1, 8, %g1 ! bump the source pointer -cmp %g3, %g2 ! Is the pointer past the end of dest? -blcopy_data -nop - -/* clear the bss */ -1: - sethi %hi(_end),%g3 or%g3,%lo(_end),%g3 ! g3 = end of bss mov %g0,%g1 ! so std has two zeros -zerobss: +.Lzerobss: std%g0,[%g2] add%g2,8,%g2 cmp%g2,%g3 -bleu,a zerobss +bleu,a .Lzerobss nop mov %g0, %o0! command line -- 2.26.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[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 @@ .section".text" PUBLIC(start) - .global start, __bsp_mem_init + .global start SYM(start): #if SYM(start) != start -- 2.26.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[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..4922a97d6d 100644 --- a/bsps/sparc/shared/start/start.S +++ b/bsps/sparc/shared/start/start.S @@ -306,13 +306,12 @@ SYM(hard_reset): nop ld [%g6 + PER_CPU_INTERRUPT_STACK_HIGH], %sp ! set stack pointer - sub %sp, 4, %sp ! stack starts at end of area - 4 - andn%sp, 0x0f, %sp ! align stack on 16-byte boundary + andn%sp, CPU_STACK_ALIGNMENT - 1, %sp + sub %sp, SPARC_MINIMUM_STACK_FRAME_SIZE, %sp mov %sp, %fp! set frame pointer - mov %g6, %o0 callSYM(bsp_start_on_secondary_processor) ! does not return -sub%sp, SPARC_MINIMUM_STACK_FRAME_SIZE, %sp +mov%g6, %i0 .Lbootcpu: st %o0, [%o1] #endif @@ -326,8 +325,8 @@ SYM(hard_reset): #endif set SYM(_ISR_Stack_area_begin), %sp add %sp, %g5, %sp - sub %sp, 4, %sp ! stack starts at end of area - 4 - andn%sp, 0x0f, %sp ! align stack on 16-byte boundary + andn%sp, CPU_STACK_ALIGNMENT - 1, %sp + sub %sp, SPARC_MINIMUM_STACK_FRAME_SIZE, %sp mov %sp, %fp! Set frame pointer nop @@ -346,8 +345,7 @@ SYM(hard_reset): bleu,a .Lzerobss nop -mov %g0, %o0! command line callSYM(boot_card) ! does not return - sub %sp, 0x60, %sp ! room for boot_card to save args + mov%g0, %i0! command line /* end of file */ -- 2.26.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[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 memory initialization bsps/sparc/shared/start/bspgetworkarea.c | 59 +++-- bsps/sparc/shared/start/start.S | 105 +++ 2 files changed, 66 insertions(+), 98 deletions(-) -- 2.26.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
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. Hmm I am not sure I agree with the premise the YAML is the documentation. The user manual exists for this purpose and user wanting to explore RTEMS would look there rather than cloning the repo, running commands etc. The alternative would be to duplicate documentation of the BSP options in the user manual. And (manual) duplication is always a bad idea if you ask me. Or move the description from the yaml to the documentation entirely which means that you need to pick the correct version of the documentation for the sources. It also means that you have to look up the meaning of each option in the right version of the manual instead of in the default config. I think the only reasonable option (with the current structure) would be to somehow automatically generate that documentation part. For example by creating the default BSP config.ini for each BSP and adding it to the user manual. But that has to be an automatic process. Otherwise it will be out of date right from the beginning. I accept the current defaults etc work flow is a good place to start for the waf conversion project but we need to do a lot more to make accessing the YAML easier. The wscript contains the only rtems.git repo means to read the YAML and the pickled data and that limits how we can change and evolve this. We could merge documentation and code again. From my point of view that would make it simpler to add documentation for new features right when they are implemented and there would be always the right version for a source commit. I don't really know the reason why it was split up in 2015 / 2016 so we would have to look that up before discussing further into that direction. Additionally it would need discussion how and where (for example) network stacks would be documented. Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
