RTEMS monitor commands and the shell
Hi, The monitor commands are registered automatically in `rtems_shell_init_once()` which means an application has no control over these being present, the command mix and naming, for example there is a `config` command in the monitor. I am not sure what to do, if it is removed some applications may break assuming these commands are present. A way to disable the command using shellconfig.h would be nice. Suggestions? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Waiting for approval of three patches
Hello, in the last three days I've sent a few patches to the mailing list. Would it be possible for one of our core maintainers to have a look at them and approve them (if they are OK) so that I can commit them? - 13.03.: [PATCH] openssl: Provide deprecated functions. This one enables some extra functions in the libbsd OpenSSL library. - 14.03.: [PATCH] bsp/atsam: Fix GMAC Rx Descriptor fields. A BSP specific patch that only fixes some register definitions. - 15.03.: [PATCH v2] if_atsam: Add checksum offload. Patch for the (BSP specific) if_atsam driver in libbsd. Best regards Christian -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS monitor commands and the shell
Hi, just my two cents: Would an additional call 'rtems_shell_init_once_commandset()' make sense, where the user can specify, which comamnds are available? I agree that changing the functionality of an existing call is not a good idea. Thomas. - Ursprüngliche Mail - Von: "Chris Johns" An: "Development" Gesendet: Freitag, 16. März 2018 08:01:14 Betreff: RTEMS monitor commands and the shell Hi, The monitor commands are registered automatically in `rtems_shell_init_once()` which means an application has no control over these being present, the command mix and naming, for example there is a `config` command in the monitor. I am not sure what to do, if it is removed some applications may break assuming these commands are present. A way to disable the command using shellconfig.h would be nice. Suggestions? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: RTEMS monitor commands and the shell
We have hit this problem with rtems 4.10. I think the monitor commands should be treated the same as the other shell commands. It should be possible to disable via shellconfig.h - by default all are enabled, but that can be disabled. In our application, the monitor 'exit' command was particularly problematic because customers connect to the monitor via telnet then type exit to end the telnet session. The exit command would trigger a fatal error exception, resulting in several bug reports that were 'device restarted for no reason'. :-( Regards Paul Whitfield Paul Whitfield -Original Message- From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Chris Johns Sent: Friday, 16 March 2018 3:01 PM To: Development Subject: RTEMS monitor commands and the shell Hi, The monitor commands are registered automatically in `rtems_shell_init_once()` which means an application has no control over these being present, the command mix and naming, for example there is a `config` command in the monitor. I am not sure what to do, if it is removed some applications may break assuming these commands are present. A way to disable the command using shellconfig.h would be nice. Suggestions? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel Scanned by Moncrieff Technology Solutions Secure Mail Appliance Scanned by Moncrieff Technology Solutions Secure Mail Appliance ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS monitor commands and the shell
On 16/03/18 08:01, Chris Johns wrote: Hi, The monitor commands are registered automatically in `rtems_shell_init_once()` which means an application has no control over these being present, the command mix and naming, for example there is a `config` command in the monitor. I am not sure what to do, if it is removed some applications may break assuming these commands are present. A way to disable the command using shellconfig.h would be nice. Suggestions? It would be nice to control all shell commands of RTEMS via the shellconfig.h. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Added Getentropy() support to beagle BSP
Thanks for pointing that out, I have rectified the indentation errors.
Here's the patch for atsam:
>From 8e5e17525a76e68bc4d869d0af9700aaa5628483 Mon Sep 17 00:00:00 2001
From: Udit agarwal
Date: Fri, 16 Mar 2018 14:54:53 +0530
Subject: [PATCH] arm/atsam: protect TRNG_GetRandData with mutex
---
c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
b/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
index 11e24dc..54a1cef 100644
--- a/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
+++ b/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
@@ -17,6 +17,9 @@
#include
#include
+static rtems_mutex atsam_trng_mutex =
+RTEMS_MUTEX_INITIALIZER("atsam_trng");
+
static void atsam_trng_enable(void)
{
PMC_EnablePeripheral(ID_TRNG);
@@ -25,6 +28,8 @@ static void atsam_trng_enable(void)
int getentropy(void *ptr, size_t n)
{
+ rtems_mutex_lock(&atsam_trng_mutex);
+
while (n > 0) {
uint32_t random;
size_t copy;
@@ -50,7 +55,7 @@ int getentropy(void *ptr, size_t n)
n -= copy;
ptr += copy;
}
-
+ rtems_mutex_unlock(&atsam_trng_mutex);
return 0;
}
--
1.9.1
On Thu, Mar 15, 2018 at 7:52 PM, Gedare Bloom wrote:
> On Thu, Mar 15, 2018 at 7:00 AM, Udit agarwal
> wrote:
> >
> >
> > On Thu, Mar 15, 2018 at 2:38 PM, Sebastian Huber
> > wrote:
> >>
> >> On 15/03/18 09:20, Udit agarwal wrote:
> >>>
> >>> Also, will it be ok to keep atsam_trng_mutex even after user has
> finished
> >>> using getentropy() i.e when we don't use destroy(&atsam_trng_mutex) at
> all?
> >>
> >>
> >> Why do you want to destroy the mutex?
> >
> > Just trying to reduce redundancy, but then i don't think that's a good
> idea.
> > BTW, here's atsam patch, please have a look:
> >
> > From 35313002ea19715c5914c5983a24471b0763aa68 Mon Sep 17 00:00:00 2001
> > From: Udit agarwal
> > Date: Thu, 15 Mar 2018 16:21:51 +0530
> > Subject: [PATCH] Added mutex across TRNG_GetRandData
>
> In the commit message, identify the rtems subsystem. I guess we don't
> have detailed advice on the wiki for this, but here I guess we usually
> would have something like "arm/atsam: protect TRNG_GetRandData with
> mutex"
>
> >
> > ---
> > c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
> > b/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
> > index 11e24dc..2789970 100644
> > --- a/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
> > +++ b/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
> > @@ -16,6 +16,9 @@
> > #include
> > #include
> > #include
> > +#include
> > +
> > +static rtems_mutex atsam_trng_mutex =
> > RTEMS_MUTEX_INITIALIZER("atsam_trng");
> >
> The second line should be indented 2 more levels (4 spaces).
> https://devel.rtems.org/wiki/Developer/Coding/80_characters_per_line
>
> > static void atsam_trng_enable(void)
> > {
> > @@ -25,6 +28,9 @@ static void atsam_trng_enable(void)
> >
> > int getentropy(void *ptr, size_t n)
> > {
> > +
> > +rtems_mutex_lock(&atsam_trng_mutex);
> The number of indent spaces here look wrong to me. It should be 2.
>
> > +
> > while (n > 0) {
> > uint32_t random;
> > size_t copy;
> > @@ -51,6 +57,7 @@ int getentropy(void *ptr, size_t n)
> > ptr += copy;
> > }
> >
> > +rtems_mutex_unlock(&atsam_trng_mutex);
> ditto.
>
> > return 0;
> > }
> >
> > --
> > 1.9.1
> >
> >
> >>
> >>
> >>
> >> --
> >> Sebastian Huber, embedded brains GmbH
> >>
> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> >> Phone : +49 89 189 47 41-16
> >> Fax : +49 89 189 47 41-09
> >> E-Mail : sebastian.hu...@embedded-brains.de
> >> PGP : Public key available on request.
> >>
> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> >>
> >
> >
> > ___
> > 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] Added Getentropy() support to beagle BSP
Patch for BBB:
>From a6b3b58a38a6925bf26b6573f36fc652708f9f32 Mon Sep 17 00:00:00 2001
From: Udit agarwal
Date: Fri, 16 Mar 2018 15:37:05 +0530
Subject: [PATCH] arm/beagle: add TRNG based getentropy implementation
---
bsps/arm/include/libcpu/am335x.h | 33 ++
c/src/lib/libbsp/arm/beagle/Makefile.am | 4 +-
c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c | 130
+++
3 files changed, 166 insertions(+), 1 deletion(-)
create mode 100644 c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
diff --git a/bsps/arm/include/libcpu/am335x.h
b/bsps/arm/include/libcpu/am335x.h
index 367e97c..a6fb8b8 100644
--- a/bsps/arm/include/libcpu/am335x.h
+++ b/bsps/arm/include/libcpu/am335x.h
@@ -14,11 +14,17 @@
* Modified by Ben Gras to add lots
* of beagleboard/beaglebone definitions, delete lpc32xx specific
* ones, and merge with some other header files.
+ *
+ * Modified by Udit agarwal to add true random
+ * number generating module definitions and TRNG register structure.
*/
#if !defined(_AM335X_H_)
#define _AM335X_H_
+/* For TRNG register definition */
+#include
+
/* Interrupt controller memory map */
#define OMAP3_DM37XX_INTR_BASE 0x4820 /* INTCPS physical address */
@@ -701,4 +707,31 @@
#define AM335X_CM_PER_OCPWP_L3_CLKSTCTRL_CLKACTIVITY_OCPWP_L4_GCLK
(0x0020u)
#define AM335X_I2C_INT_STOP_CONDITION AM335X_I2C_IRQSTATUS_BF
+/* TRNG Registers */
+/* TRNG base address */
+#define TRNG_BASE 0x4831
+/* Mask bits for trng clock status */
+#define AM335X_CLK_TRNG_BIT_MASK (0x3)
+/* Mask bits for output ready flag */
+#define TRNG_STATUS_RDY (1u << 0)
+/* Mask bits for FRO related error */
+#define TRNG_STATUS_ERR (1u << 1)
+/* Mask bits for clock status */
+#define TRNG_STATUS_CLK (1u << 31)
+/* enable module */
+#define AM335X_TRNG_ENABLE (1 << 10)
+
+/* TRNG module clock register */
+#define CM_PER_TRNG_CLKCTRL (AM335X_CM_PER_ADDR | (9 << 4))
+
+/* TRNG register structure */
+typedef struct {
+ uint64_t output; /* 00 */
+ uint32_t status; /* 08 */
+ uint32_t irq_en; /* 0c */
+ uint32_t status_clr; /* 10 */
+ uint32_t control;/* 14 */
+ uint32_t config; /* 18 */
+} am335x_trng_register;
+
#endif
diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am
b/c/src/lib/libbsp/arm/beagle/Makefile.am
index 8251660..c483dc4 100644
--- a/c/src/lib/libbsp/arm/beagle/Makefile.am
+++ b/c/src/lib/libbsp/arm/beagle/Makefile.am
@@ -40,7 +40,6 @@ libbsp_a_LIBADD =
# Shared
libbsp_a_SOURCES += ../../shared/bootcard.c
-libbsp_a_SOURCES += ../../shared/getentropy-cpucounter.c
libbsp_a_SOURCES += ../../shared/src/bsp-fdt.c
libbsp_a_SOURCES += ../../shared/bspclean.c
libbsp_a_SOURCES += ../../shared/bspgetworkarea.c
@@ -88,6 +87,9 @@ libbsp_a_SOURCES += gpio/bbb-gpio.c
#pwm
libbsp_a_SOURCES += pwm/pwm.c
+#getentropy
+libbsp_a_SOURCES += dev/bbb_getentropy.c
+
#RTC
libbsp_a_SOURCES += rtc.c
libbsp_a_SOURCES += ../../shared/tod.c
diff --git a/c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
b/c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
new file mode 100644
index 000..b3ea681
--- /dev/null
+++ b/c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
@@ -0,0 +1,130 @@
+/**
+* @file
+*
+* @ingroup arm_beagle
+*
+* @brief Getentropy implementation on BeagleBone Black BSP
+*/
+
+/*
+* Copyright (c) 2018 Udit agarwal
+* 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
+#include
+#include
+
+/* max refill 34 * 256 cycles */
+#define AM335X_TRNG_MAX_REFILL (34 << 16)
+/* min refill 33 * 64 cycles */
+#define AM335X_TRNG_MIN_REFILL (33 << 0)
+/* startup 33 * 256 cycles */
+#define AM335X_TRNG_STARTUP_CYCLES (33 << 16)
+
+static rtems_mutex am3
Re: [PATCH] Added Getentropy() support to beagle BSP
Hello Udit,
Now I think you should re-send this patch as a separate submission. In
this case, it would also be a good idea to tag it as "v2". You can use
for this the "-v 2" command line argument to git-format-patch, and
then git-send-email on the output file(s). Probably, you may want to
resend your ATSAM one too if it has undergone revisions.
Gedare
On Fri, Mar 16, 2018 at 6:10 AM, Udit agarwal wrote:
> Patch for BBB:
>
> From a6b3b58a38a6925bf26b6573f36fc652708f9f32 Mon Sep 17 00:00:00 2001
> From: Udit agarwal
> Date: Fri, 16 Mar 2018 15:37:05 +0530
> Subject: [PATCH] arm/beagle: add TRNG based getentropy implementation
>
> ---
> bsps/arm/include/libcpu/am335x.h | 33 ++
> c/src/lib/libbsp/arm/beagle/Makefile.am | 4 +-
> c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c | 130
> +++
> 3 files changed, 166 insertions(+), 1 deletion(-)
> create mode 100644 c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
>
> diff --git a/bsps/arm/include/libcpu/am335x.h
> b/bsps/arm/include/libcpu/am335x.h
> index 367e97c..a6fb8b8 100644
> --- a/bsps/arm/include/libcpu/am335x.h
> +++ b/bsps/arm/include/libcpu/am335x.h
> @@ -14,11 +14,17 @@
> * Modified by Ben Gras to add lots
> * of beagleboard/beaglebone definitions, delete lpc32xx specific
> * ones, and merge with some other header files.
> + *
> + * Modified by Udit agarwal to add true random
> + * number generating module definitions and TRNG register structure.
> */
>
> #if !defined(_AM335X_H_)
> #define _AM335X_H_
>
> +/* For TRNG register definition */
> +#include
> +
> /* Interrupt controller memory map */
> #define OMAP3_DM37XX_INTR_BASE 0x4820 /* INTCPS physical address */
>
> @@ -701,4 +707,31 @@
> #define AM335X_CM_PER_OCPWP_L3_CLKSTCTRL_CLKACTIVITY_OCPWP_L4_GCLK
> (0x0020u)
> #define AM335X_I2C_INT_STOP_CONDITION AM335X_I2C_IRQSTATUS_BF
>
> +/* TRNG Registers */
> +/* TRNG base address */
> +#define TRNG_BASE 0x4831
> +/* Mask bits for trng clock status */
> +#define AM335X_CLK_TRNG_BIT_MASK (0x3)
> +/* Mask bits for output ready flag */
> +#define TRNG_STATUS_RDY (1u << 0)
> +/* Mask bits for FRO related error */
> +#define TRNG_STATUS_ERR (1u << 1)
> +/* Mask bits for clock status */
> +#define TRNG_STATUS_CLK (1u << 31)
> +/* enable module */
> +#define AM335X_TRNG_ENABLE (1 << 10)
> +
> +/* TRNG module clock register */
> +#define CM_PER_TRNG_CLKCTRL (AM335X_CM_PER_ADDR | (9 << 4))
>
> +
> +/* TRNG register structure */
> +typedef struct {
> + uint64_t output; /* 00 */
> + uint32_t status; /* 08 */
> + uint32_t irq_en; /* 0c */
> + uint32_t status_clr; /* 10 */
> + uint32_t control;/* 14 */
> + uint32_t config; /* 18 */
> +} am335x_trng_register;
> +
> #endif
> diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am
> b/c/src/lib/libbsp/arm/beagle/Makefile.am
> index 8251660..c483dc4 100644
> --- a/c/src/lib/libbsp/arm/beagle/Makefile.am
> +++ b/c/src/lib/libbsp/arm/beagle/Makefile.am
> @@ -40,7 +40,6 @@ libbsp_a_LIBADD =
>
> # Shared
> libbsp_a_SOURCES += ../../shared/bootcard.c
> -libbsp_a_SOURCES += ../../shared/getentropy-cpucounter.c
> libbsp_a_SOURCES += ../../shared/src/bsp-fdt.c
> libbsp_a_SOURCES += ../../shared/bspclean.c
> libbsp_a_SOURCES += ../../shared/bspgetworkarea.c
> @@ -88,6 +87,9 @@ libbsp_a_SOURCES += gpio/bbb-gpio.c
> #pwm
> libbsp_a_SOURCES += pwm/pwm.c
>
> +#getentropy
> +libbsp_a_SOURCES += dev/bbb_getentropy.c
> +
> #RTC
> libbsp_a_SOURCES += rtc.c
> libbsp_a_SOURCES += ../../shared/tod.c
> diff --git a/c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
> b/c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
> new file mode 100644
> index 000..b3ea681
> --- /dev/null
> +++ b/c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
> @@ -0,0 +1,130 @@
>
> +/**
> +* @file
> +*
> +* @ingroup arm_beagle
> +*
> +* @brief Getentropy implementation on BeagleBone Black BSP
> +*/
> +
> +/*
> +* Copyright (c) 2018 Udit agarwal
> +* 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
Re: [PATCH v2] if_atsam: Add checksum offload.
Looks fine to me.
On Thu, Mar 15, 2018 at 4:09 AM, Christian Mauderer
wrote:
> ---
> rtemsbsd/sys/dev/atsam/if_atsam.c | 52
> +--
> 1 file changed, 44 insertions(+), 8 deletions(-)
>
> diff --git a/rtemsbsd/sys/dev/atsam/if_atsam.c
> b/rtemsbsd/sys/dev/atsam/if_atsam.c
> index 794937be..86e232ab 100644
> --- a/rtemsbsd/sys/dev/atsam/if_atsam.c
> +++ b/rtemsbsd/sys/dev/atsam/if_atsam.c
> @@ -454,6 +454,33 @@ static void if_atsam_interrupt_handler(void *arg)
> (void)if_atsam_event_send(sc->tx_daemon_tid, tx_event);
> }
> }
> +
> +static void rx_update_mbuf(struct mbuf *m, sGmacRxDescriptor *buffer_desc)
> +{
> + int frame_len;
> +
> + frame_len = (int) (buffer_desc->status.bm.len);
> +
> + m->m_data = mtod(m, char*)+ETHER_ALIGN;
> + m->m_len = frame_len;
> + m->m_pkthdr.len = frame_len;
> +
> + /* check checksum offload result */
> + m->m_pkthdr.csum_flags = 0;
> + switch (buffer_desc->status.bm.typeIDMatchOrCksumResult) {
> + case GMAC_RXDESC_ST_CKSUM_RESULT_IP_CHECKED:
> + m->m_pkthdr.csum_flags = CSUM_IP_CHECKED | CSUM_IP_VALID;
> + m->m_pkthdr.csum_data = 0x;
> + break;
> + case GMAC_RXDESC_ST_CKSUM_RESULT_IP_AND_TCP_CHECKED:
> + case GMAC_RXDESC_ST_CKSUM_RESULT_IP_AND_UDP_CHECKED:
> + m->m_pkthdr.csum_flags = CSUM_IP_CHECKED | CSUM_IP_VALID |
> + CSUM_L4_VALID | CSUM_L4_CALC;
> + m->m_pkthdr.csum_data = 0x;
> + break;
> + }
> +}
> +
> /*
> * Receive daemon
> */
> @@ -466,7 +493,6 @@ static void if_atsam_rx_daemon(void *arg)
> struct mbuf *m;
> struct mbuf *n;
> volatile sGmacRxDescriptor *buffer_desc;
> - int frame_len;
> uint32_t tmp_rx_bd_address;
> size_t i;
> Gmac *pHw = sc->Gmac_inst.gGmacd.pHw;
> @@ -547,13 +573,8 @@ static void if_atsam_rx_daemon(void *arg)
> /* New mbuf for desc */
> n = if_atsam_new_mbuf(ifp);
> if (n != NULL) {
> - frame_len = (int)
> - (buffer_desc->status.bm.len);
> + rx_update_mbuf(m, buffer_desc);
>
> - /* Update mbuf */
> - m->m_data = mtod(m,
> char*)+ETHER_ALIGN;
> - m->m_len = frame_len;
> - m->m_pkthdr.len = frame_len;
> IF_ATSAM_UNLOCK(sc);
> sc->ifp->if_input(ifp, m);
> IF_ATSAM_LOCK(sc);
> @@ -658,6 +679,7 @@ static bool if_atsam_send_packet(if_atsam_softc *sc,
> struct mbuf *m)
> uint32_t tmp_val = 0;
> Gmac *pHw = sc->Gmac_inst.gGmacd.pHw;
> bool success;
> + int csum_flags = m->m_pkthdr.csum_flags;
>
> if_atsam_tx_bd_cleanup(sc);
> /* Wait for interrupt in case no buffer descriptors are available */
> @@ -706,6 +728,12 @@ static bool if_atsam_send_packet(if_atsam_softc *sc,
> struct mbuf *m)
> if (m == NULL) {
> tmp_val |= GMAC_TX_SET_EOF;
> tmp_val &= ~GMAC_TX_SET_USED;
> + if ((csum_flags & (CSUM_IP | CSUM_TCP | CSUM_UDP |
> + CSUM_TCP_IPV6 | CSUM_UDP_IPV6)) != 0) {
> + start_packet_tx_bd->status.bm.bNoCRC = 0;
> + } else {
> + start_packet_tx_bd->status.bm.bNoCRC = 1;
> + }
> _ARM_Data_synchronization_barrier();
> cur->status.val = tmp_val;
> start_packet_tx_bd->status.val &= ~GMAC_TX_SET_USED;
> @@ -979,9 +1007,13 @@ static void if_atsam_init(void *arg)
>
> /* Configuration of DMAC */
> dmac_cfg = (GMAC_DCFGR_DRBS(GMAC_RX_BUFFER_SIZE >> 6)) |
> - GMAC_DCFGR_RXBMS(3) | GMAC_DCFGR_TXPBMS | GMAC_DCFGR_FBLDO_INCR16;
> + GMAC_DCFGR_RXBMS(3) | GMAC_DCFGR_TXPBMS | GMAC_DCFGR_FBLDO_INCR16
> |
> + GMAC_DCFGR_TXCOEN;
> GMAC_SetDMAConfig(sc->Gmac_inst.gGmacd.pHw, dmac_cfg, 0);
>
> + /* Enable hardware checksum offload for receive */
> + sc->Gmac_inst.gGmacd.pHw->GMAC_NCFGR |= GMAC_NCFGR_RXCOEN;
> +
> /* Shut down Transmit and Receive */
> GMAC_ReceiveEnable(sc->Gmac_inst.gGmacd.pHw, 0);
> GMAC_TransmitEnable(sc->Gmac_inst.gGmacd.pHw, 0);
> @@ -1461,6 +1493,10 @@ static int if_atsam_driver_attach(device_t dev)
> ifp->if_ioctl = if_atsam_ioctl;
> ifp->if_start = if_atsam_enet_start;
> ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX;
> + ifp->if_ca
Re: Waiting for approval of three patches
on it. On Fri, Mar 16, 2018 at 3:37 AM, Christian Mauderer wrote: > Hello, > > in the last three days I've sent a few patches to the mailing list. > Would it be possible for one of our core maintainers to have a look at > them and approve them (if they are OK) so that I can commit them? > > - 13.03.: [PATCH] openssl: Provide deprecated functions. > This one enables some extra functions in the libbsd OpenSSL library. > > - 14.03.: [PATCH] bsp/atsam: Fix GMAC Rx Descriptor fields. > A BSP specific patch that only fixes some register definitions. > > - 15.03.: [PATCH v2] if_atsam: Add checksum offload. > Patch for the (BSP specific) if_atsam driver in libbsd. > > Best regards > > Christian > -- > > embedded brains GmbH > Herr Christian Mauderer > Dornierstr. 4 > D-82178 Puchheim > Germany > email: christian.maude...@embedded-brains.de > Phone: +49-89-18 94 741 - 18 > Fax: +49-89-18 94 741 - 08 > PGP: Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > ___ > 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] bsp/atsam: Fix GMAC Rx Descriptor fields.
On Wed, Mar 14, 2018 at 10:51 AM, Christian Mauderer
wrote:
> ---
> bsps/arm/atsam/include/libchip/include/gmac.h | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/bsps/arm/atsam/include/libchip/include/gmac.h
> b/bsps/arm/atsam/include/libchip/include/gmac.h
> index 64e0079c25..a4227920bd 100644
> --- a/bsps/arm/atsam/include/libchip/include/gmac.h
> +++ b/bsps/arm/atsam/include/libchip/include/gmac.h
> @@ -186,13 +186,16 @@ typedef struct _GmacRxDescriptor {
> vlanPriority: 3, /** VLAN
> priority (if VLAN detected) */
> bPriorityDetected: 1, /** Priority
> tag detected */
> bVlanDetected: 1, /**< VLAN tag
> detected */
> -bTypeIDMatch: 1, /**< Type ID
> match */
> -bAddr4Match: 1,/**< Address
> register 4 match */
> -bAddr3Match: 1,/**< Address
> register 3 match */
> -bAddr2Match: 1,/**< Address
> register 2 match */
> -bAddr1Match: 1,/**< Address
> register 1 match */
> +typeIDMatchOrCksumResult: 2,
> +#define GMAC_RXDESC_ST_CKSUM_RESULT_NOT_CHECKED(0)
> +#define GMAC_RXDESC_ST_CKSUM_RESULT_IP_CHECKED (1)
> +#define GMAC_RXDESC_ST_CKSUM_RESULT_IP_AND_TCP_CHECKED (2)
> +#define GMAC_RXDESC_ST_CKSUM_RESULT_IP_AND_UDP_CHECKED (3)
> +
I find these #define in the middle of a struct definition quite
irregular. Is there a compelling reason they go here, or can they go
outside the struct?
> +bTypeIDMatchFoundOrCksumSNAPState: 1,
> +specAddrMatchRegister: 2,
> +bSpecAddrMatchFound: 1,
> reserved: 1,
> -bExtAddrMatch: 1, /**< External
> address match */
> bUniHashMatch: 1, /**< Unicast
> hash match */
> bMultiHashMatch: 1,/**<
> Multicast hash match */
> bBroadcastDetected: 1; /**< Global
> all ones broadcast
> --
> 2.13.6
>
> ___
> 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] openssl: Provide deprecated functions.
On Tue, Mar 13, 2018 at 10:02 AM, Christian Mauderer wrote: > Some applications (like the civetweb web server) still use functions > that are deprecated by openssl. If OPENSSL_NO_DEPRECATED is defined, > openssl will not provide these functions. This patch removes the define > so that the functions are available. > --- What are the negative consequences to this? I'm quite leery about enabling deprecated features in a security library. What is the cost to fix civetweb instead? -Gedare > libbsd.py | 3 +-- > libbsd_waf.py | 2 +- > 2 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/libbsd.py b/libbsd.py > index f70b4ead..233c06cd 100644 > --- a/libbsd.py > +++ b/libbsd.py > @@ -3614,8 +3614,7 @@ def crypto_openssl(mm): > 'crypto/openssl/crypto/cversion.c', > 'crypto/openssl/crypto/o_str.c', > ], > -mm.generator['source'](['-DOPENSSL_NO_DEPRECATED=1', > -'-DOPENSSL_NO_EC_NISTP_64_GCC_128=1', > +mm.generator['source'](['-DOPENSSL_NO_EC_NISTP_64_GCC_128=1', > '-DOPENSSL_NO_GMP=1', > '-DOPENSSL_NO_JPAKE=1', > '-DOPENSSL_NO_LIBUNBOUND=1', > diff --git a/libbsd_waf.py b/libbsd_waf.py > index 7782bccb..745512bf 100644 > --- a/libbsd_waf.py > +++ b/libbsd_waf.py > @@ -1317,7 +1317,7 @@ def build(bld): > features = "c", > cflags = cflags, > includes = ['freebsd/crypto', 'freebsd/crypto/openssl', > 'freebsd/crypto/openssl/crypto', 'freebsd/crypto/openssl/crypto/asn1', > 'freebsd/crypto/openssl/crypto/evp', 'freebsd/crypto/openssl/crypto/modes'] + > includes, > -defines = defines + ['NO_WINDOWS_BRAINDEATH=1', > 'OPENSSL_DISABLE_OLD_DES_SUPPORT=1', 'OPENSSL_NO_DEPRECATED=1', > 'OPENSSL_NO_EC_NISTP_64_GCC_128=1', 'OPENSSL_NO_GMP=1', 'OPENSSL_NO_JPAKE=1', > 'OPENSSL_NO_LIBUNBOUND=1', 'OPENSSL_NO_MD2=1', 'OPENSSL_NO_RC5=1', > 'OPENSSL_NO_RFC3779=1', 'OPENSSL_NO_SCTP=1', 'OPENSSL_NO_SSL2=1', > 'OPENSSL_NO_SSL_TRACE=1', 'OPENSSL_NO_STORE=1', 'OPENSSL_NO_UNIT_TEST=1', > 'OPENSSL_NO_WEAK_SSL_CIPHERS=1'], > +defines = defines + ['NO_WINDOWS_BRAINDEATH=1', > 'OPENSSL_DISABLE_OLD_DES_SUPPORT=1', 'OPENSSL_NO_EC_NISTP_64_GCC_128=1', > 'OPENSSL_NO_GMP=1', 'OPENSSL_NO_JPAKE=1', 'OPENSSL_NO_LIBUNBOUND=1', > 'OPENSSL_NO_MD2=1', 'OPENSSL_NO_RC5=1', 'OPENSSL_NO_RFC3779=1', > 'OPENSSL_NO_SCTP=1', 'OPENSSL_NO_SSL2=1', 'OPENSSL_NO_SSL_TRACE=1', > 'OPENSSL_NO_STORE=1', 'OPENSSL_NO_UNIT_TEST=1', > 'OPENSSL_NO_WEAK_SSL_CIPHERS=1'], > source = objs04_source) > libbsd_use += ["objs04"] > > -- > 2.13.6 > > ___ > 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 v2] arm/beagle: Added TRNG based getentropy implementation
From: Udit agarwal
---
bsps/arm/include/libcpu/am335x.h | 33 ++
c/src/lib/libbsp/arm/beagle/Makefile.am | 4 +-
c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c | 130 +++
3 files changed, 166 insertions(+), 1 deletion(-)
create mode 100644 c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
diff --git a/bsps/arm/include/libcpu/am335x.h b/bsps/arm/include/libcpu/am335x.h
index 367e97c..a6fb8b8 100644
--- a/bsps/arm/include/libcpu/am335x.h
+++ b/bsps/arm/include/libcpu/am335x.h
@@ -14,11 +14,17 @@
* Modified by Ben Gras to add lots
* of beagleboard/beaglebone definitions, delete lpc32xx specific
* ones, and merge with some other header files.
+ *
+ * Modified by Udit agarwal to add true random
+ * number generating module definitions and TRNG register structure.
*/
#if !defined(_AM335X_H_)
#define _AM335X_H_
+/* For TRNG register definition */
+#include
+
/* Interrupt controller memory map */
#define OMAP3_DM37XX_INTR_BASE 0x4820 /* INTCPS physical address */
@@ -701,4 +707,31 @@
#define AM335X_CM_PER_OCPWP_L3_CLKSTCTRL_CLKACTIVITY_OCPWP_L4_GCLK
(0x0020u)
#define AM335X_I2C_INT_STOP_CONDITION AM335X_I2C_IRQSTATUS_BF
+/* TRNG Registers */
+/* TRNG base address */
+#define TRNG_BASE 0x4831
+/* Mask bits for trng clock status */
+#define AM335X_CLK_TRNG_BIT_MASK (0x3)
+/* Mask bits for output ready flag */
+#define TRNG_STATUS_RDY (1u << 0)
+/* Mask bits for FRO related error */
+#define TRNG_STATUS_ERR (1u << 1)
+/* Mask bits for clock status */
+#define TRNG_STATUS_CLK (1u << 31)
+/* enable module */
+#define AM335X_TRNG_ENABLE (1 << 10)
+
+/* TRNG module clock register */
+#define CM_PER_TRNG_CLKCTRL (AM335X_CM_PER_ADDR | (9 << 4))
+
+/* TRNG register structure */
+typedef struct {
+ uint64_t output; /* 00 */
+ uint32_t status; /* 08 */
+ uint32_t irq_en; /* 0c */
+ uint32_t status_clr; /* 10 */
+ uint32_t control;/* 14 */
+ uint32_t config; /* 18 */
+} am335x_trng_register;
+
#endif
diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am
b/c/src/lib/libbsp/arm/beagle/Makefile.am
index 8251660..c483dc4 100644
--- a/c/src/lib/libbsp/arm/beagle/Makefile.am
+++ b/c/src/lib/libbsp/arm/beagle/Makefile.am
@@ -40,7 +40,6 @@ libbsp_a_LIBADD =
# Shared
libbsp_a_SOURCES += ../../shared/bootcard.c
-libbsp_a_SOURCES += ../../shared/getentropy-cpucounter.c
libbsp_a_SOURCES += ../../shared/src/bsp-fdt.c
libbsp_a_SOURCES += ../../shared/bspclean.c
libbsp_a_SOURCES += ../../shared/bspgetworkarea.c
@@ -88,6 +87,9 @@ libbsp_a_SOURCES += gpio/bbb-gpio.c
#pwm
libbsp_a_SOURCES += pwm/pwm.c
+#getentropy
+libbsp_a_SOURCES += dev/bbb_getentropy.c
+
#RTC
libbsp_a_SOURCES += rtc.c
libbsp_a_SOURCES += ../../shared/tod.c
diff --git a/c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
b/c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
new file mode 100644
index 000..b3ea681
--- /dev/null
+++ b/c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
@@ -0,0 +1,130 @@
+/**
+* @file
+*
+* @ingroup arm_beagle
+*
+* @brief Getentropy implementation on BeagleBone Black BSP
+*/
+
+/*
+* Copyright (c) 2018 Udit agarwal
+* 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
+#include
+#include
+
+/* max refill 34 * 256 cycles */
+#define AM335X_TRNG_MAX_REFILL (34 << 16)
+/* min refill 33 * 64 cycles */
+#define AM335X_TRNG_MIN_REFILL (33 << 0)
+/* startup 33 * 256 cycles */
+#define AM335X_TRNG_STARTUP_CYCLES (33 << 16)
+
+static rtems_mutex am335x_trng_mutex =
+RTEMS_MUTEX_INITIALIZER("am335x_trng");
+
+/* maximun and minimum refill cycle sets the number of samples to be taken
+ * from FRO to generate random number */
+stat
Re: Improve coverage analysis toolset
building couverture-qemu from rtems-source-builder ( https://github.com/cillianodonnell/rtems-source-builder/tree/couverture-build ) gives error building auromake-1.12.6-x86_64-linux-gnu-1 . I have attached the error report . -- vijay On 15 March 2018 at 19:17, Cillian O'Donnell wrote: > > > On 15 March 2018 at 12:26, Vijay Kumar Banerjee > wrote: > >> It runs with a bunch of errors . I have attached the log file >> > > Ok, I'm guessing you didn't set up Couverture-Qemu (special version of > qemu designed for generating extra trace data for coverage analysis). > That's what those errors are about. I have an RSB build for that. > > https://github.com/cillianodonnell/rtems-source- > builder/tree/couverture-build > > and the instructions for building it are > > https://devel.rtems.org/wiki/GSoC/2017/coveragetools#BuildingCouverture- > QemuwiththeRSB > > I know what the other problem is too. I have a specific environment > variable defined for the path, sorry I can't even remember putting it > there, I thought that was automatically generated (probably should be, > another thing to add to the list :)... ). So wherever you stuck the export > path for where the rsb built the tools, in .bashrc or whatever you're > using. Also put something like: > > export PATH=$HOME/development/rtems/5/bin:$PATH > > export PATH=$HOME/development/rtems/test/rtems-tools/build/tester/covoar:$PATH > > > or you could just copy covoar into the /bin directory with all the other > rsb tools gcc and all that, it'll find it either way. > > > >> >> -- vijay >> >> On 15 March 2018 at 16:58, Cillian O'Donnell >> wrote: >> >>> Looks good. If you run the samples without coverage is everything ok? >>> >>> So removing --coverage and tacking on /samples >>> >>> $HOME/development/rtems-tools/tester/rtems-test --rtems-bsp=leon3-qemu >>> --log=log-leon3.log --rtems-tools=$HOME/development/rtems/5 >>> --rtems-builddir=$HOME/development/rtems/kernel/leon3 >>> sparc-rtems5/c/leon3/testsuites/samples >>> >>> Do the tests run? >>> >>> On 15 March 2018 at 10:53, Vijay Kumar Banerjee < >>> vijaykumar9...@gmail.com> wrote: >>> I have attached the output of the ls of that directory -- vijay On 15 March 2018 at 15:52, Cillian O'Donnell wrote: > > > On 15 March 2018 at 03:58, Vijay Kumar Banerjee < > vijaykumar9...@gmail.com> wrote: > >> >> hello , >> >> as told by Joel , I started this thread to further discuss the >> coverage analysis toolset . >> >> Current status is , I'm trying to builld and run rtems-test from the >> coverage-merge branch of the previous GSoC student Cillian . >> https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge >> >> I'm getting an error that says . >> "Covoar not found !" >> > > It's supposed to find it in rtems-tools/build/tester/covoar/ If it's > in there it should be fine. Can you show me the contents of that > directory? > > cpod@cpod ~/development/rtems/test/rtems-tools/build/tester/covoar $ > ls > > > >> the Covoar appeared in rtems-tools/tester/covoar . >> >> -- >> >> Vijay >> >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel >> > > >>> >> > RTEMS Tools Project - Source Builder Error Report Build: error: building automake-1.12.6-x86_64-linux-gnu-1 Command Line: ../source-builder/sb-set-builder --log=couverture_qemu_log.txt --prefix=/home/lunatic/development/rtems/5 devel/couverture-qemu Python: 2.7.14 (default, Jan 17 2018, 14:28:32) [GCC 7.2.1 20170915 (Red Hat 7.2.1-2)] https://github.com/cillianodonnell/rtems-source-builder.git/origin/1d11496627fb0302d9f6425a01b297499a53ee2a Linux lunatic 4.14.14-300.fc27.x86_64 #1 SMP Fri Jan 19 13:19:54 UTC 2018 x86_64 Tail of the build log: -r-xr-xr-x 1000/1000 443 2012-12-15 15:04 automake-1.12.6/t/tap-more-w.sh -rwxr-xr-x 1000/1000 3150 2012-12-14 01:27 automake-1.12.6/t/testsuite-summary-count.sh -rwxr-xr-x 1000/1000 1509 2012-12-14 22:28 automake-1.12.6/t/aclocal-path.sh -rwxr-xr-x 1000/1000 1043 2012-12-14 22:28 automake-1.12.6/t/version6.sh -rwxr-xr-x 1000/1000 2050 2012-12-14 22:28 automake-1.12.6/t/distcheck-configure-flags-am.sh -rwxr-xr-x 1000/1000 1577 2012-12-14 22:28 automake-1.12.6/t/tests-environment-backcompat.sh -rwxr-xr-x 1000/1000 2966 2012-12-14 22:28 automake-1.12.6/t/backcompat5.sh -rwxr-xr-x 1000/1000 970 2012-12-14 22:28 automake-1.12.6/t/gcj2.sh -rwxr-xr-x 1000/1000 1561 2012-12-14 22:28 automake-1.12.6/t/ccnoco3.sh -r-xr-xr-x 1000/1000 218 2012-12-15 15:04 automake-1.12.6/t/depcomp-lt-makedepend.tap -rwxr-xr-x 1000/1000 1323 2012-12-14 22:28 automake-1.12.6/t/pr279.sh -r-xr-xr-x 1000/1000 201 2012-12-15 15:04 automake-1.12.6/t/depcomp-lt-cpp.tap -rwxr-xr-x 1000/1000
Re: Improve coverage analysis toolset
Just checked and the build was failing because one of the patches needed its hash to be updated to sha256. Just pushed that change. The build finishes successfully on my end. Pull that change into couverture-build branch and try it again. I'm not seeing any automake stuff here, so just check that and let me know. On 16 March 2018 at 14:59, Vijay Kumar Banerjee wrote: > building couverture-qemu from rtems-source-builder ( https://github.com/ > cillianodonnell/rtems-source-builder/tree/couverture-build ) > gives error building auromake-1.12.6-x86_64-linux-gnu-1 . > > I have attached the error report . > > -- vijay > > On 15 March 2018 at 19:17, Cillian O'Donnell > wrote: > >> >> >> On 15 March 2018 at 12:26, Vijay Kumar Banerjee > > wrote: >> >>> It runs with a bunch of errors . I have attached the log file >>> >> >> Ok, I'm guessing you didn't set up Couverture-Qemu (special version of >> qemu designed for generating extra trace data for coverage analysis). >> That's what those errors are about. I have an RSB build for that. >> >> https://github.com/cillianodonnell/rtems-source-builder/ >> tree/couverture-build >> >> and the instructions for building it are >> >> https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin >> gCouverture-QemuwiththeRSB >> >> I know what the other problem is too. I have a specific environment >> variable defined for the path, sorry I can't even remember putting it >> there, I thought that was automatically generated (probably should be, >> another thing to add to the list :)... ). So wherever you stuck the export >> path for where the rsb built the tools, in .bashrc or whatever you're >> using. Also put something like: >> >> export PATH=$HOME/development/rtems/5/bin:$PATH >> >> export >> PATH=$HOME/development/rtems/test/rtems-tools/build/tester/covoar:$PATH >> >> >> or you could just copy covoar into the /bin directory with all the other >> rsb tools gcc and all that, it'll find it either way. >> >> >> >>> >>> -- vijay >>> >>> On 15 March 2018 at 16:58, Cillian O'Donnell >>> wrote: >>> Looks good. If you run the samples without coverage is everything ok? So removing --coverage and tacking on /samples $HOME/development/rtems-tools/tester/rtems-test --rtems-bsp=leon3-qemu --log=log-leon3.log --rtems-tools=$HOME/development/rtems/5 --rtems-builddir=$HOME/development/rtems/kernel/leon3 sparc-rtems5/c/leon3/testsuites/samples Do the tests run? On 15 March 2018 at 10:53, Vijay Kumar Banerjee < vijaykumar9...@gmail.com> wrote: > I have attached the output of the ls of that directory > > -- vijay > > On 15 March 2018 at 15:52, Cillian O'Donnell > wrote: > >> >> >> On 15 March 2018 at 03:58, Vijay Kumar Banerjee < >> vijaykumar9...@gmail.com> wrote: >> >>> >>> hello , >>> >>> as told by Joel , I started this thread to further discuss the >>> coverage analysis toolset . >>> >>> Current status is , I'm trying to builld and run rtems-test from the >>> coverage-merge branch of the previous GSoC student Cillian . >>> https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge >>> >>> I'm getting an error that says . >>> "Covoar not found !" >>> >> >> It's supposed to find it in rtems-tools/build/tester/covoar/ If it's >> in there it should be fine. Can you show me the contents of that >> directory? >> >> cpod@cpod ~/development/rtems/test/rtems-tools/build/tester/covoar $ >> ls >> >> >> >>> the Covoar appeared in rtems-tools/tester/covoar . >>> >>> -- >>> >>> Vijay >>> >>> ___ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel >>> >> >> > >>> >> > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 3/3] i386/smp: Export _CPU_SMP_Prepare_start_multitasking as a function
Thanks.
I just pushed these.
I compiled all PC386 BSP family members with and without multiprocessing.
--joel
On Tue, Mar 13, 2018 at 11:14 AM, Amaan Cheval
wrote:
> When it's a macro, a function declaration causes a compiler error due to
> the
> macro being expanded.
>
> Partial log showing error:
> https://gist.github.com/AmaanC/ab3521141479aa6f61ea25f5d74ebb4d
>
> Closes #3331
> ---
> c/src/lib/libbsp/i386/shared/smp/smp-imps.c | 5 +
> cpukit/score/cpu/i386/include/rtems/score/cpu.h | 3 +--
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/c/src/lib/libbsp/i386/shared/smp/smp-imps.c
> b/c/src/lib/libbsp/i386/shared/smp/smp-imps.c
> index 1ed504ccf9..2ba36804cb 100644
> --- a/c/src/lib/libbsp/i386/shared/smp/smp-imps.c
> +++ b/c/src/lib/libbsp/i386/shared/smp/smp-imps.c
> @@ -804,6 +804,11 @@ uint32_t _CPU_SMP_Initialize( void )
>return (uint32_t) imps_probe();
> }
>
> +void _CPU_SMP_Prepare_start_multitasking( void )
> +{
> + /* Do nothing */
> +}
> +
> bool _CPU_SMP_Start_processor( uint32_t cpu_index )
> {
>(void) cpu_index;
> diff --git a/cpukit/score/cpu/i386/include/rtems/score/cpu.h
> b/cpukit/score/cpu/i386/include/rtems/score/cpu.h
> index 364bba765a..d8f89f6397 100644
> --- a/cpukit/score/cpu/i386/include/rtems/score/cpu.h
> +++ b/cpukit/score/cpu/i386/include/rtems/score/cpu.h
> @@ -470,8 +470,7 @@ void _CPU_Context_Initialize(
>
>void _CPU_SMP_Finalize_initialization( uint32_t cpu_count );
>
> - /* Nothing to do */
> - #define _CPU_SMP_Prepare_start_multitasking() do { } while ( 0 )
> + void _CPU_SMP_Prepare_start_multitasking( void );
>
>uint32_t _CPU_SMP_Get_current_processor( void );
>
> --
> 2.13.0
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Improve coverage analysis toolset
still the same error -- vijay On 16 March 2018 at 21:39, Cillian O'Donnell wrote: > Just checked and the build was failing because one of the patches needed > its hash to be updated to sha256. Just pushed that change. The build > finishes successfully on my end. Pull that change into couverture-build > branch and try it again. I'm not seeing any automake stuff here, so just > check that and let me know. > > On 16 March 2018 at 14:59, Vijay Kumar Banerjee > wrote: > >> building couverture-qemu from rtems-source-builder ( >> https://github.com/cillianodonnell/rtems-source-builder/ >> tree/couverture-build ) >> gives error building auromake-1.12.6-x86_64-linux-gnu-1 . >> >> I have attached the error report . >> >> -- vijay >> >> On 15 March 2018 at 19:17, Cillian O'Donnell >> wrote: >> >>> >>> >>> On 15 March 2018 at 12:26, Vijay Kumar Banerjee < >>> vijaykumar9...@gmail.com> wrote: >>> It runs with a bunch of errors . I have attached the log file >>> >>> Ok, I'm guessing you didn't set up Couverture-Qemu (special version of >>> qemu designed for generating extra trace data for coverage analysis). >>> That's what those errors are about. I have an RSB build for that. >>> >>> https://github.com/cillianodonnell/rtems-source-builder/tree >>> /couverture-build >>> >>> and the instructions for building it are >>> >>> https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin >>> gCouverture-QemuwiththeRSB >>> >>> I know what the other problem is too. I have a specific environment >>> variable defined for the path, sorry I can't even remember putting it >>> there, I thought that was automatically generated (probably should be, >>> another thing to add to the list :)... ). So wherever you stuck the export >>> path for where the rsb built the tools, in .bashrc or whatever you're >>> using. Also put something like: >>> >>> export PATH=$HOME/development/rtems/5/bin:$PATH >>> >>> export >>> PATH=$HOME/development/rtems/test/rtems-tools/build/tester/covoar:$PATH >>> >>> >>> or you could just copy covoar into the /bin directory with all the other >>> rsb tools gcc and all that, it'll find it either way. >>> >>> >>> -- vijay On 15 March 2018 at 16:58, Cillian O'Donnell wrote: > Looks good. If you run the samples without coverage is everything ok? > > So removing --coverage and tacking on /samples > > $HOME/development/rtems-tools/tester/rtems-test > --rtems-bsp=leon3-qemu --log=log-leon3.log > --rtems-tools=$HOME/development/rtems/5 > --rtems-builddir=$HOME/development/rtems/kernel/leon3 > sparc-rtems5/c/leon3/testsuites/samples > > Do the tests run? > > On 15 March 2018 at 10:53, Vijay Kumar Banerjee < > vijaykumar9...@gmail.com> wrote: > >> I have attached the output of the ls of that directory >> >> -- vijay >> >> On 15 March 2018 at 15:52, Cillian O'Donnell >> wrote: >> >>> >>> >>> On 15 March 2018 at 03:58, Vijay Kumar Banerjee < >>> vijaykumar9...@gmail.com> wrote: >>> hello , as told by Joel , I started this thread to further discuss the coverage analysis toolset . Current status is , I'm trying to builld and run rtems-test from the coverage-merge branch of the previous GSoC student Cillian . https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge I'm getting an error that says . "Covoar not found !" >>> >>> It's supposed to find it in rtems-tools/build/tester/covoar/ If >>> it's in there it should be fine. Can you show me the contents of that >>> directory? >>> >>> cpod@cpod ~/development/rtems/test/rtems-tools/build/tester/covoar >>> $ ls >>> >>> >>> the Covoar appeared in rtems-tools/tester/covoar . -- Vijay ___ 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] bsp/atsam: Fix GMAC Rx Descriptor fields.
- Ursprüngliche Mail -
> Von: "Gedare Bloom"
> An: "Christian Mauderer"
> CC: "RTEMS Devel"
> Gesendet: Freitag, 16. März 2018 15:08:39
> Betreff: Re: [PATCH] bsp/atsam: Fix GMAC Rx Descriptor fields.
> On Wed, Mar 14, 2018 at 10:51 AM, Christian Mauderer
> wrote:
>> ---
>> bsps/arm/atsam/include/libchip/include/gmac.h | 15 +--
>> 1 file changed, 9 insertions(+), 6 deletions(-)
>>
>> diff --git a/bsps/arm/atsam/include/libchip/include/gmac.h
>> b/bsps/arm/atsam/include/libchip/include/gmac.h
>> index 64e0079c25..a4227920bd 100644
>> --- a/bsps/arm/atsam/include/libchip/include/gmac.h
>> +++ b/bsps/arm/atsam/include/libchip/include/gmac.h
>> @@ -186,13 +186,16 @@ typedef struct _GmacRxDescriptor {
>> vlanPriority: 3, /** VLAN
>> priority (if VLAN detected) */
>> bPriorityDetected: 1, /** Priority
>> tag detected */
>> bVlanDetected: 1, /**< VLAN
>> tag detected */
>> -bTypeIDMatch: 1, /**< Type ID
>> match */
>> -bAddr4Match: 1,/**< Address
>> register 4 match */
>> -bAddr3Match: 1,/**< Address
>> register 3 match */
>> -bAddr2Match: 1,/**< Address
>> register 2 match */
>> -bAddr1Match: 1,/**< Address
>> register 1 match */
>> +typeIDMatchOrCksumResult: 2,
>> +#define GMAC_RXDESC_ST_CKSUM_RESULT_NOT_CHECKED(0)
>> +#define GMAC_RXDESC_ST_CKSUM_RESULT_IP_CHECKED (1)
>> +#define GMAC_RXDESC_ST_CKSUM_RESULT_IP_AND_TCP_CHECKED (2)
>> +#define GMAC_RXDESC_ST_CKSUM_RESULT_IP_AND_UDP_CHECKED (3)
>> +
>
> I find these #define in the middle of a struct definition quite
> irregular. Is there a compelling reason they go here, or can they go
> outside the struct?
I wanted to locate the defines near the field where they should be used. But I
don't have a strong opinion about that. I'll put them outside of the structure
and re-send a V2 patch on Monday.
>
>> +bTypeIDMatchFoundOrCksumSNAPState:
>> 1,
>> +specAddrMatchRegister: 2,
>> +bSpecAddrMatchFound: 1,
>> reserved: 1,
>> -bExtAddrMatch: 1, /**< External
>> address match */
>> bUniHashMatch: 1, /**< Unicast
>> hash match */
>> bMultiHashMatch: 1,/**<
>> Multicast hash match */
>> bBroadcastDetected: 1; /**< Global
>> all ones broadcast
>> --
>> 2.13.6
>>
>> ___
>> devel mailing list
>> devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
--
embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax: +49-89-18 94 741 - 08
PGP: Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Waiting for approval of three patches
Hello Gedare, thanks for taking a look at them. Best regards Christian - Ursprüngliche Mail - > Von: "Gedare Bloom" > An: "Christian Mauderer" > CC: "RTEMS Devel" > Gesendet: Freitag, 16. März 2018 15:07:05 > Betreff: Re: Waiting for approval of three patches > on it. > > On Fri, Mar 16, 2018 at 3:37 AM, Christian Mauderer > wrote: >> Hello, >> >> in the last three days I've sent a few patches to the mailing list. >> Would it be possible for one of our core maintainers to have a look at >> them and approve them (if they are OK) so that I can commit them? >> >> - 13.03.: [PATCH] openssl: Provide deprecated functions. >> This one enables some extra functions in the libbsd OpenSSL library. >> >> - 14.03.: [PATCH] bsp/atsam: Fix GMAC Rx Descriptor fields. >> A BSP specific patch that only fixes some register definitions. >> >> - 15.03.: [PATCH v2] if_atsam: Add checksum offload. >> Patch for the (BSP specific) if_atsam driver in libbsd. >> >> Best regards >> >> Christian >> -- >> >> embedded brains GmbH >> Herr Christian Mauderer >> Dornierstr. 4 >> D-82178 Puchheim >> Germany >> email: christian.maude...@embedded-brains.de >> Phone: +49-89-18 94 741 - 18 >> Fax: +49-89-18 94 741 - 08 >> PGP: Public key available on request. >> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >> ___ >> devel mailing list >> devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Gsoc 2018
Hello Developers, At this point of time, I have built the newlib for SPARC BSP and subscribed myself for newlib mailing list.Could you please suggest me any library or some of the functions that is needed to port to newlib? Any response from your side would be greatly appreciated. That would be great and easy start for me towards GSoC-2018. Thanks & regards, Salil Sirotia, Mtech,CSE-IS(Final Year), IIT(ISM),Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Gsoc 2018
Are you interested in the POSIX Compliance project? If so, you really need to get your proposal together and submitted. Then we can worry about doing the work proposed. With no proposal, you can't get accepted. https://devel.rtems.org/ticket/2966 is the POSIX Compliance ticket. It has sub-tickets for individual tasks that has been identified so far. --joel On Fri, Mar 16, 2018 at 1:25 PM, Salil Sirotia wrote: > Hello Developers, > > At this point of time, I have built the newlib for SPARC BSP and > subscribed myself for newlib mailing list.Could you please suggest me any > library or some of the functions that is needed to port to newlib? Any > response from your side would be > greatly appreciated. > > That would be great and easy start for me towards GSoC-2018. > > Thanks & regards, > Salil Sirotia, > Mtech,CSE-IS(Final Year), > IIT(ISM),Dhanbad > > ___ > 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: Improve coverage analysis toolset
If you build regular qemu with the RSB, does the same thing happen? Try ../source-builder/sb-set-builder --log=qemu_log.txt --prefix=$HOME/development/5 devel/qemu On 16 March 2018 at 16:48, Vijay Kumar Banerjee wrote: > still the same error > > -- vijay > > On 16 March 2018 at 21:39, Cillian O'Donnell > wrote: > >> Just checked and the build was failing because one of the patches needed >> its hash to be updated to sha256. Just pushed that change. The build >> finishes successfully on my end. Pull that change into couverture-build >> branch and try it again. I'm not seeing any automake stuff here, so just >> check that and let me know. >> >> On 16 March 2018 at 14:59, Vijay Kumar Banerjee > > wrote: >> >>> building couverture-qemu from rtems-source-builder ( >>> https://github.com/cillianodonnell/rtems-source-builder/tr >>> ee/couverture-build ) >>> gives error building auromake-1.12.6-x86_64-linux-gnu-1 . >>> >>> I have attached the error report . >>> >>> -- vijay >>> >>> On 15 March 2018 at 19:17, Cillian O'Donnell >>> wrote: >>> On 15 March 2018 at 12:26, Vijay Kumar Banerjee < vijaykumar9...@gmail.com> wrote: > It runs with a bunch of errors . I have attached the log file > Ok, I'm guessing you didn't set up Couverture-Qemu (special version of qemu designed for generating extra trace data for coverage analysis). That's what those errors are about. I have an RSB build for that. https://github.com/cillianodonnell/rtems-source-builder/tree /couverture-build and the instructions for building it are https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin gCouverture-QemuwiththeRSB I know what the other problem is too. I have a specific environment variable defined for the path, sorry I can't even remember putting it there, I thought that was automatically generated (probably should be, another thing to add to the list :)... ). So wherever you stuck the export path for where the rsb built the tools, in .bashrc or whatever you're using. Also put something like: export PATH=$HOME/development/rtems/5/bin:$PATH export PATH=$HOME/development/rtems/test/rtems-tools/build/tester/covoar:$PATH or you could just copy covoar into the /bin directory with all the other rsb tools gcc and all that, it'll find it either way. > > -- vijay > > On 15 March 2018 at 16:58, Cillian O'Donnell > wrote: > >> Looks good. If you run the samples without coverage is everything ok? >> >> So removing --coverage and tacking on /samples >> >> $HOME/development/rtems-tools/tester/rtems-test >> --rtems-bsp=leon3-qemu --log=log-leon3.log >> --rtems-tools=$HOME/development/rtems/5 >> --rtems-builddir=$HOME/development/rtems/kernel/leon3 >> sparc-rtems5/c/leon3/testsuites/samples >> >> Do the tests run? >> >> On 15 March 2018 at 10:53, Vijay Kumar Banerjee < >> vijaykumar9...@gmail.com> wrote: >> >>> I have attached the output of the ls of that directory >>> >>> -- vijay >>> >>> On 15 March 2018 at 15:52, Cillian O'Donnell >>> wrote: >>> On 15 March 2018 at 03:58, Vijay Kumar Banerjee < vijaykumar9...@gmail.com> wrote: > > hello , > > as told by Joel , I started this thread to further discuss the > coverage analysis toolset . > > Current status is , I'm trying to builld and run rtems-test from > the coverage-merge branch of the previous GSoC student Cillian . > https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge > > I'm getting an error that says . > "Covoar not found !" > It's supposed to find it in rtems-tools/build/tester/covoar/ If it's in there it should be fine. Can you show me the contents of that directory? cpod@cpod ~/development/rtems/test/rtems-tools/build/tester/covoar $ ls > the Covoar appeared in rtems-tools/tester/covoar . > > -- > > Vijay > > ___ > 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: MMU was Re: Contribute to a project under GSOC 2018
Sir, I have prepared a draft proposal for GSoC 2018 as suggested by you. I request you to please guide me whether I have made it correctly or not, whether I have written some big plans or more things can be included. The link for the Proposal is: https://docs.google.com/document/d/1boKGnnzQGCzxIVqBVMWvK7OFJTvWKzWDXj1EvuEuq5o/edit?usp=sharing Thanks and Regards Abhinav Jain On Wed, Mar 14, 2018 at 10:47 PM, Abhinav Jain wrote: > Sir, > > Thanks for the guidance. I am studying ARM architecture and trying to find > out the difference in it's architecture from other ones, I am trying to > understand what can be the minimum changes to the existing framework to get > it working on other architectures. > > Thanks and Regards > Abhinav Jain > > > On Wed, Mar 14, 2018, 10:41 PM Gedare Bloom wrote: > >> The framework exists in the rtems source code, underneath >> c/src/lib/libbsp/arm. >> >> Start with the GSoC template, adjust the dates, start adding details. >> When you have a draft you can invite comments for review. >> >> On Wed, Mar 14, 2018 at 12:18 PM, Abhinav Jain >> wrote: >> > Sir, >> > >> > The description of the RoadRunner OS is mentioned in the document >> provided >> > by you, >> > https://pdfs.semanticscholar.org/3c92/7ed6b426fccfb203dd96be9b7591b3 >> 744f1f.pdf >> > The link (http://ieeexplore.ieee.org/document/7509439/?part=1) which I >> > mentioned in the previous mail deals with memory management scheme for >> the >> > MMU-less embedded systems. >> > If there is already a framework for ARM MMU, I will try to extend it to >> > other architectures as much as possible, I read about various >> architectures >> > in past couple of days. >> > I request you to please provide the link to the available framework so >> that >> > I can study that and proceed with its enhancement if possible. Also, I >> > request you to please guide me for my GSoC proposal. >> > >> > Thanks and Regards >> > Abhinav Jain >> > >> > On Wed, Mar 14, 2018 at 9:37 PM, Gedare Bloom wrote: >> >> >> >> Abhinav, >> >> >> >> Send me the linked article. Does it describe the RoadRunner OS >> >> approach? I am not familiar with it. >> >> >> >> Note that there is a basic framework for ARM MMU in place already. >> >> Adoption/adaptation of it to other architectures is preferred versus >> >> replacing it, unless absolutely necessary. >> >> >> >> On Wed, Mar 14, 2018 at 12:03 PM, Abhinav Jain >> >> wrote: >> >> > Sir, >> >> > >> >> > I studied the documents provided by you in the previous mail, also I >> >> > read a >> >> > document from http://ieeexplore.ieee.org/document/7509439/?part=1. >> >> > As told by you in the previous mail that the first issue to be >> solved is >> >> > to >> >> > provide a BSP-level framework for MMU/MPU hardware, after reading the >> >> > memory >> >> > protection in roadrunner operating system, I think that with some >> >> > changes, >> >> > the same concept can be implemented in the RTEMS for memory >> protection. >> >> > I request you to please guide me whether I am right in the approach >> or I >> >> > have to think differently. >> >> > >> >> > >> >> > Thanks and Regards >> >> > Abhinav Jain >> >> > >> >> > >> >> > On Wed, Mar 7, 2018 at 10:49 AM, Abhinav Jain > > >> >> > wrote: >> >> >> >> >> >> Sir, >> >> >> >> >> >> Thanks a lot for the guidance. I will study the documents provided >> by >> >> >> you >> >> >> and will try to find more about this to increase my knowledge about >> >> >> Memory >> >> >> support. >> >> >> I will start preparing a draft proposal as per the template >> provided on >> >> >> the RTEMS GSoC page. >> >> >> >> >> >> Thanks and Regards >> >> >> Abhinav Jain >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Mar 6, 2018 10:25 PM, "Gedare Bloom" wrote: >> >> >> >> >> >> On Sun, Mar 4, 2018 at 1:50 AM, Abhinav Jain > > >> >> >> wrote: >> >> >> > Sir, >> >> >> > >> >> >> > Thanks for your time and consideration. I was discussing this >> project >> >> >> > with >> >> >> > Gedare Sir and he guided me, how to proceed. >> >> >> > I am studying various things before proceeding with the code part >> but >> >> >> > for >> >> >> > now, I request you to please guide me what should be my next >> steps to >> >> >> > work >> >> >> > on this project under GSOC'18. >> >> >> > >> >> >> > Thanks and Regards >> >> >> > Abhinav Jain >> >> >> > >> >> >> > On Sun, Mar 4, 2018 at 10:48 AM, Hesham Almatary >> >> >> > >> >> >> > wrote: >> >> >> >> >> >> >> >> On Sun, Mar 4, 2018 at 10:20 AM, Joel Sherrill >> >> >> >> wrote: >> >> >> >> > >> >> >> >> > >> >> >> >> > On Mar 3, 2018 12:16 PM, "Abhinav Jain" > > >> >> >> >> > wrote: >> >> >> >> > >> >> >> >> > Sir/Madam, >> >> >> >> > >> >> >> >> > I am Abhinav Jain, a second-year engineering student from >> Delhi, >> >> >> >> > India. >> >> >> >> > I >> >> >> >> > have been working in Linux Kernel Development, I have been >> writing >> >> >> >> > small >> >> >> >> > drivers and have a good knowledge of the operating system. >> >>
Students Submit GSoC Proposals
Hi I just wanted to remind everyone that the deadline for applying is March 27. I would encourage you all to go ahead and make sure you are registered in the Google system and have submitted at least the beginnings of your proposal. You can continue to edit and refine. But if you forget to submit, it is a hard "not accepted". https://summerofcode.withgoogle.com/ And if there are issues on the RTEMS side with the description in the tickets, please help us refine and fix our side. Good luck! --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Gsoc 2018
Check out the csv file in rtems-docs/posix-compliance. Chris and I put together a new POSIX Compliance Guide. It is on docs.rtems.org. Check out the guide and the new csv. Up to date and lots of POSIX profiles. :) Even has guidance on finding methods to implement. Between that and the ticket, should be a good start. On Mar 16, 2018 1:58 PM, "Aditya Upadhyay" wrote: > Hi Joel, > > I am sharing one spreadsheet to Salil what you had shared with me last > year. It will also help him to identify the works that need to be included > as a > part of GSoC-2018. > > > On Sat, Mar 17, 2018 at 12:08 AM, Joel Sherrill wrote: > > Are you interested in the POSIX Compliance project? > > > > If so, you really need to get your proposal together and submitted. Then > we > > can worry about doing the work proposed. With no proposal, you can't > > get accepted. > > > > https://devel.rtems.org/ticket/2966 is the POSIX Compliance ticket. It > > has sub-tickets for individual tasks that has been identified so far. > > > Can you please see the ticket: https://devel.rtems.org/ticket/2968 > It was a part of GSoC-2017. I have already ported Inttypes methods to > newlib. > Could you please close this sub-ticket? > > Thanks & Regards, > Aditya Upadhyay > > > --joel > > > > On Fri, Mar 16, 2018 at 1:25 PM, Salil Sirotia > > wrote: > >> > >> Hello Developers, > >> > >> At this point of time, I have built the newlib for SPARC BSP and > >> subscribed myself for newlib mailing list.Could you please suggest me > any > >> library or some of the functions that is needed to port to newlib? Any > >> response from your side would be > >> greatly appreciated. > >> > >> That would be great and easy start for me towards GSoC-2018. > >> > >> Thanks & regards, > >> Salil Sirotia, > >> Mtech,CSE-IS(Final Year), > >> IIT(ISM),Dhanbad > >> > >> ___ > >> devel mailing list > >> devel@rtems.org > >> http://lists.rtems.org/mailman/listinfo/devel > > > > > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Improve coverage analysis toolset
yes , the same thing happens On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" wrote: > If you build regular qemu with the RSB, does the same thing happen? > > Try > > ../source-builder/sb-set-builder --log=qemu_log.txt > --prefix=$HOME/development/5 devel/qemu > > > On 16 March 2018 at 16:48, Vijay Kumar Banerjee > wrote: > >> still the same error >> >> -- vijay >> >> On 16 March 2018 at 21:39, Cillian O'Donnell >> wrote: >> >>> Just checked and the build was failing because one of the patches needed >>> its hash to be updated to sha256. Just pushed that change. The build >>> finishes successfully on my end. Pull that change into couverture-build >>> branch and try it again. I'm not seeing any automake stuff here, so just >>> check that and let me know. >>> >>> On 16 March 2018 at 14:59, Vijay Kumar Banerjee < >>> vijaykumar9...@gmail.com> wrote: >>> building couverture-qemu from rtems-source-builder ( https://github.com/cillianodonnell/rtems-source-builder/tr ee/couverture-build ) gives error building auromake-1.12.6-x86_64-linux-gnu-1 . I have attached the error report . -- vijay On 15 March 2018 at 19:17, Cillian O'Donnell wrote: > > > On 15 March 2018 at 12:26, Vijay Kumar Banerjee < > vijaykumar9...@gmail.com> wrote: > >> It runs with a bunch of errors . I have attached the log file >> > > Ok, I'm guessing you didn't set up Couverture-Qemu (special version of > qemu designed for generating extra trace data for coverage analysis). > That's what those errors are about. I have an RSB build for that. > > https://github.com/cillianodonnell/rtems-source-builder/tree > /couverture-build > > and the instructions for building it are > > https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin > gCouverture-QemuwiththeRSB > > I know what the other problem is too. I have a specific environment > variable defined for the path, sorry I can't even remember putting it > there, I thought that was automatically generated (probably should be, > another thing to add to the list :)... ). So wherever you stuck the export > path for where the rsb built the tools, in .bashrc or whatever you're > using. Also put something like: > > export PATH=$HOME/development/rtems/5/bin:$PATH > > export > PATH=$HOME/development/rtems/test/rtems-tools/build/tester/covoar:$PATH > > > or you could just copy covoar into the /bin directory with all the > other rsb tools gcc and all that, it'll find it either way. > > > >> >> -- vijay >> >> On 15 March 2018 at 16:58, Cillian O'Donnell >> wrote: >> >>> Looks good. If you run the samples without coverage is everything ok? >>> >>> So removing --coverage and tacking on /samples >>> >>> $HOME/development/rtems-tools/tester/rtems-test >>> --rtems-bsp=leon3-qemu --log=log-leon3.log >>> --rtems-tools=$HOME/development/rtems/5 >>> --rtems-builddir=$HOME/development/rtems/kernel/leon3 >>> sparc-rtems5/c/leon3/testsuites/samples >>> >>> Do the tests run? >>> >>> On 15 March 2018 at 10:53, Vijay Kumar Banerjee < >>> vijaykumar9...@gmail.com> wrote: >>> I have attached the output of the ls of that directory -- vijay On 15 March 2018 at 15:52, Cillian O'Donnell >>> > wrote: > > > On 15 March 2018 at 03:58, Vijay Kumar Banerjee < > vijaykumar9...@gmail.com> wrote: > >> >> hello , >> >> as told by Joel , I started this thread to further discuss the >> coverage analysis toolset . >> >> Current status is , I'm trying to builld and run rtems-test from >> the coverage-merge branch of the previous GSoC student Cillian . >> https://github.com/cillianodonnell/rtems-tools/tree/coverage >> -merge >> >> I'm getting an error that says . >> "Covoar not found !" >> > > It's supposed to find it in rtems-tools/build/tester/covoar/ If > it's in there it should be fine. Can you show me the contents of that > directory? > > cpod@cpod ~/development/rtems/test/rtems-tools/build/tester/covoar > $ ls > > > >> the Covoar appeared in rtems-tools/tester/covoar . >> >> -- >> >> Vijay >> >> ___ >> 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: Improve coverage analysis toolset
the same error comes when I try to build qemu from the RTEMS/rtems-source-builder as well is the issue coming from my system ? I'm using fedora 27 64bit On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee" wrote: > yes , the same thing happens > > On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" > wrote: > >> If you build regular qemu with the RSB, does the same thing happen? >> >> Try >> >> ../source-builder/sb-set-builder --log=qemu_log.txt >> --prefix=$HOME/development/5 devel/qemu >> >> >> On 16 March 2018 at 16:48, Vijay Kumar Banerjee > > wrote: >> >>> still the same error >>> >>> -- vijay >>> >>> On 16 March 2018 at 21:39, Cillian O'Donnell >>> wrote: >>> Just checked and the build was failing because one of the patches needed its hash to be updated to sha256. Just pushed that change. The build finishes successfully on my end. Pull that change into couverture-build branch and try it again. I'm not seeing any automake stuff here, so just check that and let me know. On 16 March 2018 at 14:59, Vijay Kumar Banerjee < vijaykumar9...@gmail.com> wrote: > building couverture-qemu from rtems-source-builder ( > https://github.com/cillianodonnell/rtems-source-builder/tr > ee/couverture-build ) > gives error building auromake-1.12.6-x86_64-linux-gnu-1 . > > I have attached the error report . > > -- vijay > > On 15 March 2018 at 19:17, Cillian O'Donnell > wrote: > >> >> >> On 15 March 2018 at 12:26, Vijay Kumar Banerjee < >> vijaykumar9...@gmail.com> wrote: >> >>> It runs with a bunch of errors . I have attached the log file >>> >> >> Ok, I'm guessing you didn't set up Couverture-Qemu (special version >> of qemu designed for generating extra trace data for coverage analysis). >> That's what those errors are about. I have an RSB build for that. >> >> https://github.com/cillianodonnell/rtems-source-builder/tree >> /couverture-build >> >> and the instructions for building it are >> >> https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin >> gCouverture-QemuwiththeRSB >> >> I know what the other problem is too. I have a specific environment >> variable defined for the path, sorry I can't even remember putting it >> there, I thought that was automatically generated (probably should be, >> another thing to add to the list :)... ). So wherever you stuck the >> export >> path for where the rsb built the tools, in .bashrc or whatever you're >> using. Also put something like: >> >> export PATH=$HOME/development/rtems/5/bin:$PATH >> >> export >> PATH=$HOME/development/rtems/test/rtems-tools/build/tester/covoar:$PATH >> >> >> or you could just copy covoar into the /bin directory with all the >> other rsb tools gcc and all that, it'll find it either way. >> >> >> >>> >>> -- vijay >>> >>> On 15 March 2018 at 16:58, Cillian O'Donnell >>> wrote: >>> Looks good. If you run the samples without coverage is everything ok? So removing --coverage and tacking on /samples $HOME/development/rtems-tools/tester/rtems-test --rtems-bsp=leon3-qemu --log=log-leon3.log --rtems-tools=$HOME/development/rtems/5 --rtems-builddir=$HOME/development/rtems/kernel/leon3 sparc-rtems5/c/leon3/testsuites/samples Do the tests run? On 15 March 2018 at 10:53, Vijay Kumar Banerjee < vijaykumar9...@gmail.com> wrote: > I have attached the output of the ls of that directory > > -- vijay > > On 15 March 2018 at 15:52, Cillian O'Donnell < > cpodonne...@gmail.com> wrote: > >> >> >> On 15 March 2018 at 03:58, Vijay Kumar Banerjee < >> vijaykumar9...@gmail.com> wrote: >> >>> >>> hello , >>> >>> as told by Joel , I started this thread to further discuss the >>> coverage analysis toolset . >>> >>> Current status is , I'm trying to builld and run rtems-test from >>> the coverage-merge branch of the previous GSoC student Cillian . >>> https://github.com/cillianodonnell/rtems-tools/tree/coverage >>> -merge >>> >>> I'm getting an error that says . >>> "Covoar not found !" >>> >> >> It's supposed to find it in rtems-tools/build/tester/covoar/ If >> it's in there it should be fine. Can you show me the contents of that >> directory? >> >> cpod@cpod ~/development/rtems/test/rtems-tools/build/tester/covoar >> $ ls >> >> >> >>> the Covoar appeared in rtems-tools/tester/covoar . >>> >>> -- >>> >>> Vijay >>> >>>
Re: MMU was Re: Contribute to a project under GSOC 2018
high-level comments: * add citations to relevant literature that you used for inspiration. * start to write a design plan for the bsp-level framework you envision. * it would be a good idea to review the existing mmu support in RTEMS. * link to this google doc as your "Draft" from your GSoC application, and also upload an initial "Final" pdf, which you can continue to revise. Gedare On Fri, Mar 16, 2018 at 2:48 PM, Abhinav Jain wrote: > Sir, > > I have prepared a draft proposal for GSoC 2018 as suggested by you. > I request you to please guide me whether I have made it correctly or not, > whether I have written some big plans or more things can be included. > > The link for the Proposal is: > https://docs.google.com/document/d/1boKGnnzQGCzxIVqBVMWvK7OFJTvWKzWDXj1EvuEuq5o/edit?usp=sharing > > Thanks and Regards > Abhinav Jain > > On Wed, Mar 14, 2018 at 10:47 PM, Abhinav Jain > wrote: >> >> Sir, >> >> Thanks for the guidance. I am studying ARM architecture and trying to find >> out the difference in it's architecture from other ones, I am trying to >> understand what can be the minimum changes to the existing framework to get >> it working on other architectures. >> >> Thanks and Regards >> Abhinav Jain >> >> >> On Wed, Mar 14, 2018, 10:41 PM Gedare Bloom wrote: >>> >>> The framework exists in the rtems source code, underneath >>> c/src/lib/libbsp/arm. >>> >>> Start with the GSoC template, adjust the dates, start adding details. >>> When you have a draft you can invite comments for review. >>> >>> On Wed, Mar 14, 2018 at 12:18 PM, Abhinav Jain >>> wrote: >>> > Sir, >>> > >>> > The description of the RoadRunner OS is mentioned in the document >>> > provided >>> > by you, >>> > >>> > https://pdfs.semanticscholar.org/3c92/7ed6b426fccfb203dd96be9b7591b3744f1f.pdf >>> > The link (http://ieeexplore.ieee.org/document/7509439/?part=1) which I >>> > mentioned in the previous mail deals with memory management scheme for >>> > the >>> > MMU-less embedded systems. >>> > If there is already a framework for ARM MMU, I will try to extend it to >>> > other architectures as much as possible, I read about various >>> > architectures >>> > in past couple of days. >>> > I request you to please provide the link to the available framework so >>> > that >>> > I can study that and proceed with its enhancement if possible. Also, I >>> > request you to please guide me for my GSoC proposal. >>> > >>> > Thanks and Regards >>> > Abhinav Jain >>> > >>> > On Wed, Mar 14, 2018 at 9:37 PM, Gedare Bloom wrote: >>> >> >>> >> Abhinav, >>> >> >>> >> Send me the linked article. Does it describe the RoadRunner OS >>> >> approach? I am not familiar with it. >>> >> >>> >> Note that there is a basic framework for ARM MMU in place already. >>> >> Adoption/adaptation of it to other architectures is preferred versus >>> >> replacing it, unless absolutely necessary. >>> >> >>> >> On Wed, Mar 14, 2018 at 12:03 PM, Abhinav Jain >>> >> wrote: >>> >> > Sir, >>> >> > >>> >> > I studied the documents provided by you in the previous mail, also I >>> >> > read a >>> >> > document from http://ieeexplore.ieee.org/document/7509439/?part=1. >>> >> > As told by you in the previous mail that the first issue to be >>> >> > solved is >>> >> > to >>> >> > provide a BSP-level framework for MMU/MPU hardware, after reading >>> >> > the >>> >> > memory >>> >> > protection in roadrunner operating system, I think that with some >>> >> > changes, >>> >> > the same concept can be implemented in the RTEMS for memory >>> >> > protection. >>> >> > I request you to please guide me whether I am right in the approach >>> >> > or I >>> >> > have to think differently. >>> >> > >>> >> > >>> >> > Thanks and Regards >>> >> > Abhinav Jain >>> >> > >>> >> > >>> >> > On Wed, Mar 7, 2018 at 10:49 AM, Abhinav Jain >>> >> > >>> >> > wrote: >>> >> >> >>> >> >> Sir, >>> >> >> >>> >> >> Thanks a lot for the guidance. I will study the documents provided >>> >> >> by >>> >> >> you >>> >> >> and will try to find more about this to increase my knowledge about >>> >> >> Memory >>> >> >> support. >>> >> >> I will start preparing a draft proposal as per the template >>> >> >> provided on >>> >> >> the RTEMS GSoC page. >>> >> >> >>> >> >> Thanks and Regards >>> >> >> Abhinav Jain >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Mar 6, 2018 10:25 PM, "Gedare Bloom" wrote: >>> >> >> >>> >> >> On Sun, Mar 4, 2018 at 1:50 AM, Abhinav Jain >>> >> >> >>> >> >> wrote: >>> >> >> > Sir, >>> >> >> > >>> >> >> > Thanks for your time and consideration. I was discussing this >>> >> >> > project >>> >> >> > with >>> >> >> > Gedare Sir and he guided me, how to proceed. >>> >> >> > I am studying various things before proceeding with the code part >>> >> >> > but >>> >> >> > for >>> >> >> > now, I request you to please guide me what should be my next >>> >> >> > steps to >>> >> >> > work >>> >> >> > on this project under GSOC'18. >>> >> >> > >>> >> >> > Thanks and Regards >>>
Re: Improve coverage analysis toolset
Yes this is something more than my build, I'll need someone a bit more expert in the RSB to step in there. In the meantime, lets just build couverture-qemu manually so we can see is everything else working. git clone https://github.com/AdaCore/qemu cd qemu ./configure --target-list=sparc-softmmu --prefix=$HOME/qemu/install --disable-docs --disable-virtfs --disable-werror make make install then add the prefix to $PATH in .bashrc as well like before. export PATH=$HOME/qemu/install/bin:$PATH Then run rtem-test and see what happens On 16 March 2018 at 19:13, Vijay Kumar Banerjee wrote: > the same error comes when I try to build qemu from the > RTEMS/rtems-source-builder as well > > is the issue coming from my system ? I'm using fedora 27 64bit > > On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee" < > vijaykumar9...@gmail.com> wrote: > >> yes , the same thing happens >> >> On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" >> wrote: >> >>> If you build regular qemu with the RSB, does the same thing happen? >>> >>> Try >>> >>> ../source-builder/sb-set-builder --log=qemu_log.txt >>> --prefix=$HOME/development/5 devel/qemu >>> >>> >>> On 16 March 2018 at 16:48, Vijay Kumar Banerjee < >>> vijaykumar9...@gmail.com> wrote: >>> still the same error -- vijay On 16 March 2018 at 21:39, Cillian O'Donnell wrote: > Just checked and the build was failing because one of the patches > needed its hash to be updated to sha256. Just pushed that change. The > build > finishes successfully on my end. Pull that change into couverture-build > branch and try it again. I'm not seeing any automake stuff here, so just > check that and let me know. > > On 16 March 2018 at 14:59, Vijay Kumar Banerjee < > vijaykumar9...@gmail.com> wrote: > >> building couverture-qemu from rtems-source-builder ( >> https://github.com/cillianodonnell/rtems-source-builder/tr >> ee/couverture-build ) >> gives error building auromake-1.12.6-x86_64-linux-gnu-1 . >> >> I have attached the error report . >> >> -- vijay >> >> On 15 March 2018 at 19:17, Cillian O'Donnell >> wrote: >> >>> >>> >>> On 15 March 2018 at 12:26, Vijay Kumar Banerjee < >>> vijaykumar9...@gmail.com> wrote: >>> It runs with a bunch of errors . I have attached the log file >>> >>> Ok, I'm guessing you didn't set up Couverture-Qemu (special version >>> of qemu designed for generating extra trace data for coverage analysis). >>> That's what those errors are about. I have an RSB build for that. >>> >>> https://github.com/cillianodonnell/rtems-source-builder/tree >>> /couverture-build >>> >>> and the instructions for building it are >>> >>> https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin >>> gCouverture-QemuwiththeRSB >>> >>> I know what the other problem is too. I have a specific environment >>> variable defined for the path, sorry I can't even remember putting it >>> there, I thought that was automatically generated (probably should be, >>> another thing to add to the list :)... ). So wherever you stuck the >>> export >>> path for where the rsb built the tools, in .bashrc or whatever you're >>> using. Also put something like: >>> >>> export PATH=$HOME/development/rtems/5/bin:$PATH >>> >>> export >>> PATH=$HOME/development/rtems/test/rtems-tools/build/tester/covoar:$PATH >>> >>> >>> or you could just copy covoar into the /bin directory with all the >>> other rsb tools gcc and all that, it'll find it either way. >>> >>> >>> -- vijay On 15 March 2018 at 16:58, Cillian O'Donnell >>> > wrote: > Looks good. If you run the samples without coverage is everything > ok? > > So removing --coverage and tacking on /samples > > $HOME/development/rtems-tools/tester/rtems-test > --rtems-bsp=leon3-qemu --log=log-leon3.log > --rtems-tools=$HOME/development/rtems/5 > --rtems-builddir=$HOME/development/rtems/kernel/leon3 > sparc-rtems5/c/leon3/testsuites/samples > > Do the tests run? > > On 15 March 2018 at 10:53, Vijay Kumar Banerjee < > vijaykumar9...@gmail.com> wrote: > >> I have attached the output of the ls of that directory >> >> -- vijay >> >> On 15 March 2018 at 15:52, Cillian O'Donnell < >> cpodonne...@gmail.com> wrote: >> >>> >>> >>> On 15 March 2018 at 03:58, Vijay Kumar Banerjee < >>> vijaykumar9...@gmail.com> wrote: >>> hello , as told by Joel , I started this thread to further discuss the coverage analysis toolset . Current status is
Re: Improve coverage analysis toolset
Vijay, On Fri, Mar 16, 2018 at 10:59 AM, Vijay Kumar Banerjee wrote: > building couverture-qemu from rtems-source-builder ( > https://github.com/cillianodonnell/rtems-source-builder/tree/couverture-build > ) > gives error building auromake-1.12.6-x86_64-linux-gnu-1 . > > I have attached the error report . > Try to build just the autotools: source-builder/sb-set-builder devel/autotools Assuming that fails, report this as a problem in a separate email thread to focus effort on fixing the right "bug". > -- vijay > > On 15 March 2018 at 19:17, Cillian O'Donnell wrote: >> >> >> >> On 15 March 2018 at 12:26, Vijay Kumar Banerjee >> wrote: >>> >>> It runs with a bunch of errors . I have attached the log file >> >> >> Ok, I'm guessing you didn't set up Couverture-Qemu (special version of >> qemu designed for generating extra trace data for coverage analysis). That's >> what those errors are about. I have an RSB build for that. >> >> >> https://github.com/cillianodonnell/rtems-source-builder/tree/couverture-build >> >> and the instructions for building it are >> >> >> https://devel.rtems.org/wiki/GSoC/2017/coveragetools#BuildingCouverture-QemuwiththeRSB >> >> I know what the other problem is too. I have a specific environment >> variable defined for the path, sorry I can't even remember putting it there, >> I thought that was automatically generated (probably should be, another >> thing to add to the list :)... ). So wherever you stuck the export path for >> where the rsb built the tools, in .bashrc or whatever you're using. Also put >> something like: >> >> export PATH=$HOME/development/rtems/5/bin:$PATH >> export >> PATH=$HOME/development/rtems/test/rtems-tools/build/tester/covoar:$PATH >> >> or you could just copy covoar into the /bin directory with all the other >> rsb tools gcc and all that, it'll find it either way. >> >> >>> >>> >>> -- vijay >>> >>> On 15 March 2018 at 16:58, Cillian O'Donnell >>> wrote: Looks good. If you run the samples without coverage is everything ok? So removing --coverage and tacking on /samples $HOME/development/rtems-tools/tester/rtems-test --rtems-bsp=leon3-qemu --log=log-leon3.log --rtems-tools=$HOME/development/rtems/5 --rtems-builddir=$HOME/development/rtems/kernel/leon3 sparc-rtems5/c/leon3/testsuites/samples Do the tests run? On 15 March 2018 at 10:53, Vijay Kumar Banerjee wrote: > > I have attached the output of the ls of that directory > > -- vijay > > On 15 March 2018 at 15:52, Cillian O'Donnell > wrote: >> >> >> >> On 15 March 2018 at 03:58, Vijay Kumar Banerjee >> wrote: >>> >>> >>> hello , >>> >>> as told by Joel , I started this thread to further discuss the >>> coverage analysis toolset . >>> >>> Current status is , I'm trying to builld and run rtems-test from the >>> coverage-merge branch of the previous GSoC student Cillian . >>> https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge >>> >>> I'm getting an error that says . >>> "Covoar not found !" >> >> >> It's supposed to find it in rtems-tools/build/tester/covoar/ If it's >> in there it should be fine. Can you show me the contents of that >> directory? >> >> cpod@cpod ~/development/rtems/test/rtems-tools/build/tester/covoar $ >> ls >> >> >>> >>> the Covoar appeared in rtems-tools/tester/covoar . >>> >>> -- >>> >>> Vijay >>> >>> ___ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel >> >> > >>> >> > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2] arm/atsam: protect TRNG_GetRandData with mutex
From: Udit agarwal
---
c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
b/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
index 11e24dc..d3f1cf5 100644
--- a/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
+++ b/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c
@@ -16,6 +16,10 @@
#include
#include
#include
+#include
+
+static rtems_mutex atsam_trng_mutex =
+RTEMS_MUTEX_INITIALIZER("atsam_trng");
static void atsam_trng_enable(void)
{
@@ -25,6 +29,8 @@ static void atsam_trng_enable(void)
int getentropy(void *ptr, size_t n)
{
+ rtems_mutex_lock(&atsam_trng_mutex);
+
while (n > 0) {
uint32_t random;
size_t copy;
@@ -51,6 +57,7 @@ int getentropy(void *ptr, size_t n)
ptr += copy;
}
+ rtems_mutex_unlock(&atsam_trng_mutex);
return 0;
}
--
1.9.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: MMU was Re: Contribute to a project under GSOC 2018
On Mar 16, 2018 2:17 PM, "Gedare Bloom" wrote: high-level comments: * add citations to relevant literature that you used for inspiration. * start to write a design plan for the bsp-level framework you envision. * it would be a good idea to review the existing mmu support in RTEMS. * link to this google doc as your "Draft" from your GSoC application, and also upload an initial "Final" pdf, which you can continue to revise. Pok is a free ARINC 653 RTOS https://github.com/pok-kernel/pok ARINC 653 requires time and space separation. Pok has ports to three architectures on the main site above. It would likely be a good source reference for MMU handling. It will be static after initialization. --joel Gedare On Fri, Mar 16, 2018 at 2:48 PM, Abhinav Jain wrote: > Sir, > > I have prepared a draft proposal for GSoC 2018 as suggested by you. > I request you to please guide me whether I have made it correctly or not, > whether I have written some big plans or more things can be included. > > The link for the Proposal is: > https://docs.google.com/document/d/1boKGnnzQGCzxIVqBVMWvK7OFJTvWK zWDXj1EvuEuq5o/edit?usp=sharing > > Thanks and Regards > Abhinav Jain > > On Wed, Mar 14, 2018 at 10:47 PM, Abhinav Jain > wrote: >> >> Sir, >> >> Thanks for the guidance. I am studying ARM architecture and trying to find >> out the difference in it's architecture from other ones, I am trying to >> understand what can be the minimum changes to the existing framework to get >> it working on other architectures. >> >> Thanks and Regards >> Abhinav Jain >> >> >> On Wed, Mar 14, 2018, 10:41 PM Gedare Bloom wrote: >>> >>> The framework exists in the rtems source code, underneath >>> c/src/lib/libbsp/arm. >>> >>> Start with the GSoC template, adjust the dates, start adding details. >>> When you have a draft you can invite comments for review. >>> >>> On Wed, Mar 14, 2018 at 12:18 PM, Abhinav Jain >>> wrote: >>> > Sir, >>> > >>> > The description of the RoadRunner OS is mentioned in the document >>> > provided >>> > by you, >>> > >>> > https://pdfs.semanticscholar.org/3c92/7ed6b426fccfb203dd96be9b7591b3 744f1f.pdf >>> > The link (http://ieeexplore.ieee.org/document/7509439/?part=1) which I >>> > mentioned in the previous mail deals with memory management scheme for >>> > the >>> > MMU-less embedded systems. >>> > If there is already a framework for ARM MMU, I will try to extend it to >>> > other architectures as much as possible, I read about various >>> > architectures >>> > in past couple of days. >>> > I request you to please provide the link to the available framework so >>> > that >>> > I can study that and proceed with its enhancement if possible. Also, I >>> > request you to please guide me for my GSoC proposal. >>> > >>> > Thanks and Regards >>> > Abhinav Jain >>> > >>> > On Wed, Mar 14, 2018 at 9:37 PM, Gedare Bloom wrote: >>> >> >>> >> Abhinav, >>> >> >>> >> Send me the linked article. Does it describe the RoadRunner OS >>> >> approach? I am not familiar with it. >>> >> >>> >> Note that there is a basic framework for ARM MMU in place already. >>> >> Adoption/adaptation of it to other architectures is preferred versus >>> >> replacing it, unless absolutely necessary. >>> >> >>> >> On Wed, Mar 14, 2018 at 12:03 PM, Abhinav Jain >>> >> wrote: >>> >> > Sir, >>> >> > >>> >> > I studied the documents provided by you in the previous mail, also I >>> >> > read a >>> >> > document from http://ieeexplore.ieee.org/document/7509439/?part=1. >>> >> > As told by you in the previous mail that the first issue to be >>> >> > solved is >>> >> > to >>> >> > provide a BSP-level framework for MMU/MPU hardware, after reading >>> >> > the >>> >> > memory >>> >> > protection in roadrunner operating system, I think that with some >>> >> > changes, >>> >> > the same concept can be implemented in the RTEMS for memory >>> >> > protection. >>> >> > I request you to please guide me whether I am right in the approach >>> >> > or I >>> >> > have to think differently. >>> >> > >>> >> > >>> >> > Thanks and Regards >>> >> > Abhinav Jain >>> >> > >>> >> > >>> >> > On Wed, Mar 7, 2018 at 10:49 AM, Abhinav Jain >>> >> > >>> >> > wrote: >>> >> >> >>> >> >> Sir, >>> >> >> >>> >> >> Thanks a lot for the guidance. I will study the documents provided >>> >> >> by >>> >> >> you >>> >> >> and will try to find more about this to increase my knowledge about >>> >> >> Memory >>> >> >> support. >>> >> >> I will start preparing a draft proposal as per the template >>> >> >> provided on >>> >> >> the RTEMS GSoC page. >>> >> >> >>> >> >> Thanks and Regards >>> >> >> Abhinav Jain >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Mar 6, 2018 10:25 PM, "Gedare Bloom" wrote: >>> >> >> >>> >> >> On Sun, Mar 4, 2018 at 1:50 AM, Abhinav Jain >>> >> >> >>> >> >> wrote: >>> >> >> > Sir, >>> >> >> > >>> >> >> > Thanks for your time and consideration. I was discussing this >>> >> >> > project >>> >> >> > with >>> >> >> > Gedare Sir and he g
Re: [PATCH v2 3/3] i386/smp: Export _CPU_SMP_Prepare_start_multitasking as a function
Cheers! Thanks for taking the time to test them!
On Fri, Mar 16, 2018 at 10:06 PM Joel Sherrill wrote:
> Thanks.
>
> I just pushed these.
>
> I compiled all PC386 BSP family members with and without multiprocessing.
>
> --joel
>
> On Tue, Mar 13, 2018 at 11:14 AM, Amaan Cheval
> wrote:
>
>> When it's a macro, a function declaration causes a compiler error due to
>> the
>> macro being expanded.
>>
>> Partial log showing error:
>> https://gist.github.com/AmaanC/ab3521141479aa6f61ea25f5d74ebb4d
>>
>> Closes #3331
>> ---
>> c/src/lib/libbsp/i386/shared/smp/smp-imps.c | 5 +
>> cpukit/score/cpu/i386/include/rtems/score/cpu.h | 3 +--
>> 2 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/c/src/lib/libbsp/i386/shared/smp/smp-imps.c
>> b/c/src/lib/libbsp/i386/shared/smp/smp-imps.c
>> index 1ed504ccf9..2ba36804cb 100644
>> --- a/c/src/lib/libbsp/i386/shared/smp/smp-imps.c
>> +++ b/c/src/lib/libbsp/i386/shared/smp/smp-imps.c
>> @@ -804,6 +804,11 @@ uint32_t _CPU_SMP_Initialize( void )
>>return (uint32_t) imps_probe();
>> }
>>
>> +void _CPU_SMP_Prepare_start_multitasking( void )
>> +{
>> + /* Do nothing */
>> +}
>> +
>> bool _CPU_SMP_Start_processor( uint32_t cpu_index )
>> {
>>(void) cpu_index;
>> diff --git a/cpukit/score/cpu/i386/include/rtems/score/cpu.h
>> b/cpukit/score/cpu/i386/include/rtems/score/cpu.h
>> index 364bba765a..d8f89f6397 100644
>> --- a/cpukit/score/cpu/i386/include/rtems/score/cpu.h
>> +++ b/cpukit/score/cpu/i386/include/rtems/score/cpu.h
>> @@ -470,8 +470,7 @@ void _CPU_Context_Initialize(
>>
>>void _CPU_SMP_Finalize_initialization( uint32_t cpu_count );
>>
>> - /* Nothing to do */
>> - #define _CPU_SMP_Prepare_start_multitasking() do { } while ( 0 )
>> + void _CPU_SMP_Prepare_start_multitasking( void );
>>
>>uint32_t _CPU_SMP_Get_current_processor( void );
>>
>> --
>> 2.13.0
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
x86_64 port and BSP (GSoC 2018)
Hey everyone! Here's a link to a draft of my proposal (also shared through the GSoC website, and linked to on the wiki): https://docs.google.com/document/d/1X79Yj0DNqvaDFqpJMUX4gF3WC550GDvVDS5QufvAnFE/edit?usp=sharing I'd appreciate all comments - even if you're just skimming, let me know if you have something to say! I have a few questions too, which I'd appreciate help with: Regarding the proposal: - Does it seem like I'm committing too little / too much? - Are there any issues I've completely overlooked? Something I've oversimplified / that I may not realize the scope / difficulty of? - It seems like Chris (cc'd) owns the x86_64 ticket - would Chris be a potential mentor, or is ticket ownership not indicative of who the mentor might be? Misc: - I noticed that this project has been proposed in the past, at least twice. Is there any constructive criticism from the proposals back then that I could learn from? - In the proposals, I've left some tasks about the x86_64 rtems-tools highlighted in red because I'm hoping to test the tools before the proposal deadline to have a clearer idea for the timeline. The ticket[1] lists some tasks regarding the tools, but I'm not sure what the status of them is yet, or how to carry the tasks out quite yet. I aim to tackle this as soon as possible, but if you can provide any guidance, I'd appreciate that. Thanks! [1] https://devel.rtems.org/ticket/2898#Tools ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
