date:20180314

Re: [PATCH] Added Getentropy() support to beagle BSP

2018-03-14 Thread Sebastian Huber


On 14/03/18 00:38, Udit agarwal wrote:

Hi,
@Joel This seems to be SoC specific.


Yes, it is an on-chip peripheral.



So, here is the implementation with mutex, Do let me know if this is 
okay. I'll then do it for atsam also.


int getentropy(void *ptr, size_t n)
{
    volatile am335x_trng_register  *rng = (am335x_trng_register*) 
RNG_BASE;

    rtems_mutex lock_trng_reg = RTEMS_MUTEX_INITIALIZER("lock_trng_reg");


In order to ensure mutual exclusion for a particular piece of code via a 
mutex object all threads must use the same mutex object. Here, you 
create a mutex object on the fly on the stack of the executing thread. 
So, each thread has its own mutex. This doesn't work. You must use a 
global mutex used by all threads. For example:


static rtems_mutex am335x_trng_mutex = RTEMS_MUTEX_INITIALIZER("AM335X 
TRNG");




    while (n > 0)
    {
        uint64_t random;
        size_t copy;

        /* for mutual exclusion synchronization between multiple
           access to TRNG register in different contexts */
        rtems_mutex_lock(&lock_trng_reg);


I would do the lock/unlock around the while loop.



        /* wait untill RNG becomes ready with next set of random data */
        while( ( rng->status & RNG_STATUS_RDY ) == 0 )
        {
            /* wait */
        }

        random = trng_getranddata(rng);
        /* clear the status flag after reading to generate new random
           value */
        rng->status_clr = RNG_STATUS_RDY;
        rtems_mutex_unlock(&lock_trng_reg);

        /* checking for error by masking all bits other then error bit in
           status register */
        if( ((rng->status & RNG_STATUS_ERR)>>1) == 1)
        {
            copy = sizeof(random);
            if ( n < copy )
            {
                copy = n;
            }
            memcpy(ptr, &random, copy);
            n -= copy;
            ptr = (char*)ptr + copy;
        }
    }

    rtems_mutex_destroy(&lock_trng_reg);
    return 0;
}


On Wed, Mar 14, 2018 at 2:15 AM, Joel Sherrill > wrote:




On Mar 13, 2018 1:31 AM, "Sebastian Huber"
mailto:sebastian.hu...@embedded-brains.de>> wrote:



On 12/03/18 20:02, Udit agarwal wrote:

So, It looks like here's the final patch, do let me know
if its ready to be pushed. Also, it would be really
helpful if someone else also tests this patch before
pushing(Although i have done that once).

Thanks,
Udit agarwal


From 454a8ff3e0ea3393818859874705a54b098c6081 Mon Sep 17
00:00:00 2001
From: Udit agarwal mailto:dev.mada...@gmail.com>
>>

Date: Tue, 13 Mar 2018 00:20:28 +0530
Subject: [PATCH] Added Getentropy() support to beagle BSP

---
 bsps/arm/include/libcpu/am335x.h |  37 ++-
 c/src/lib/libbsp/arm/beagle/Makefile.am
 |   4 +-
 .../libbsp/arm/beagle/getentropy/bbb_getentropy.c | 116
+
 3 files changed, 155 insertions(+), 2 deletions(-)
 create mode 100644
c/src/lib/libbsp/arm/beagle/getentropy/bbb_getentropy.c

diff --git a/bsps/arm/include/libcpu/am335x.h
b/bsps/arm/include/libcpu/am335x.h
index 367e97c..cedd637 100644
--- a/bsps/arm/include/libcpu/am335x.h
+++ b/bsps/arm/include/libcpu/am335x.h
@@ -14,11 +14,17 @@
  * Modified by Ben Gras mailto:b...@shrike-systems.com>
>> to add lots

  * of beagleboard/beaglebone definitions, delete lpc32xx
specific
  * ones, and merge with some other header files.
+ *
+ * Modified by Udit agarwal mailto:dev.mada...@gmail.com>
>> to add 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,33 @@
 #define
AM335X_CM_PER_OCPWP_L3_CLKSTCTRL_CLKACTIVITY_OCPWP_L4_GCLK
(0x0020u)
 #define AM335X_I2C_INT_STOP_CONDITION AM335X_I2C_IRQSTATUS_BF

-#endif
+/* TRNG Register */
+
+/* RNG base address */
+#define RNG_BASE 0x4831
+/* RNG clock control */
+#define CM_PER_RNG_CLKCTRL (AM335X_CM_PER_AD

[PATCH 1/5] bsps/powerpc: Move legacy IRQ support

2018-03-14 Thread Sebastian Huber

This patch is a part of the BSP source reorganization.

Update #3285.
---
 .../bspsupport/irq.c => bsps/powerpc/shared/irq/ppc-irq-legacy.c| 0
 c/src/lib/libbsp/powerpc/beatnik/Makefile.am| 2 +-
 c/src/lib/libbsp/powerpc/haleakala/Makefile.am  | 2 +-
 c/src/lib/libbsp/powerpc/motorola_powerpc/Makefile.am   | 2 +-
 c/src/lib/libbsp/powerpc/mvme3100/Makefile.am   | 4 ++--
 c/src/lib/libbsp/powerpc/mvme5500/Makefile.am   | 2 +-
 c/src/lib/libbsp/powerpc/psim/Makefile.am   | 2 +-
 c/src/lib/libcpu/powerpc/Makefile.am| 6 --
 8 files changed, 7 insertions(+), 13 deletions(-)
 rename c/src/lib/libcpu/powerpc/new-exceptions/bspsupport/irq.c => 
bsps/powerpc/shared/irq/ppc-irq-legacy.c (100%)

diff --git a/c/src/lib/libcpu/powerpc/new-exceptions/bspsupport/irq.c 
b/bsps/powerpc/shared/irq/ppc-irq-legacy.c
similarity index 100%
rename from c/src/lib/libcpu/powerpc/new-exceptions/bspsupport/irq.c
rename to bsps/powerpc/shared/irq/ppc-irq-legacy.c
diff --git a/c/src/lib/libbsp/powerpc/beatnik/Makefile.am 
b/c/src/lib/libbsp/powerpc/beatnik/Makefile.am
index dcb82d9917..ae8971ded8 100644
--- a/c/src/lib/libbsp/powerpc/beatnik/Makefile.am
+++ b/c/src/lib/libbsp/powerpc/beatnik/Makefile.am
@@ -164,12 +164,12 @@ endif
 libbsp_a_SOURCES += ../../shared/tod.c tod/todcfg.c
 
 libbsp_a_SOURCES += ../../../../../../bsps/powerpc/shared/cache/cache.c
+libbsp_a_SOURCES += ../../../../../../bsps/powerpc/shared/irq/ppc-irq-legacy.c
 
 libbsp_a_LIBADD = ../../../libcpu/@RTEMS_CPU@/shared/cpuIdent.rel \
 ../../../libcpu/@RTEMS_CPU@/shared/stack.rel \
 ../../../libcpu/@RTEMS_CPU@/@exceptions@/rtems-cpu.rel \
 ../../../libcpu/@RTEMS_CPU@/@exceptions@/exc_bspsupport.rel \
-../../../libcpu/@RTEMS_CPU@/@exceptions@/irq_bspsupport.rel \
 ../../../libcpu/@RTEMS_CPU@/mpc6xx/clock.rel \
 ../../../libcpu/@RTEMS_CPU@/mpc6xx/mmu.rel \
 ../../../libcpu/@RTEMS_CPU@/mpc6xx/timer.rel \
diff --git a/c/src/lib/libbsp/powerpc/haleakala/Makefile.am 
b/c/src/lib/libbsp/powerpc/haleakala/Makefile.am
index dcb66d0f72..7a85b96caf 100644
--- a/c/src/lib/libbsp/powerpc/haleakala/Makefile.am
+++ b/c/src/lib/libbsp/powerpc/haleakala/Makefile.am
@@ -43,10 +43,10 @@ libbsp_a_SOURCES += network/network.c
 endif
 
 libbsp_a_SOURCES += ../../../../../../bsps/powerpc/shared/cache/cache.c
+libbsp_a_SOURCES += ../../../../../../bsps/powerpc/shared/irq/ppc-irq-legacy.c
 
 libbsp_a_LIBADD = ../../../libcpu/@RTEMS_CPU@/@exceptions@/rtems-cpu.rel \
 ../../../libcpu/@RTEMS_CPU@/@exceptions@/exc_bspsupport.rel \
-../../../libcpu/@RTEMS_CPU@/@exceptions@/irq_bspsupport.rel \
 ../../../libcpu/@RTEMS_CPU@/shared/cpuIdent.rel \
 ../../../libcpu/@RTEMS_CPU@/ppc403/clock.rel \
 ../../../libcpu/@RTEMS_CPU@/ppc403/timer.rel
diff --git a/c/src/lib/libbsp/powerpc/motorola_powerpc/Makefile.am 
b/c/src/lib/libbsp/powerpc/motorola_powerpc/Makefile.am
index 1cf3671233..ceb0f8844a 100644
--- a/c/src/lib/libbsp/powerpc/motorola_powerpc/Makefile.am
+++ b/c/src/lib/libbsp/powerpc/motorola_powerpc/Makefile.am
@@ -115,6 +115,7 @@ endif
 endif
 
 libbsp_a_SOURCES += ../../../../../../bsps/powerpc/shared/cache/cache.c
+libbsp_a_SOURCES += ../../../../../../bsps/powerpc/shared/irq/ppc-irq-legacy.c
 
 libbsp_a_LIBADD = \
 polledIO.rel \
@@ -123,7 +124,6 @@ libbsp_a_LIBADD = \
 ../../../libcpu/@RTEMS_CPU@/@exceptions@/rtems-cpu.rel \
 ../../../libcpu/@RTEMS_CPU@/mpc6xx/clock.rel \
 ../../../libcpu/@RTEMS_CPU@/@exceptions@/exc_bspsupport.rel \
-../../../libcpu/@RTEMS_CPU@/@exceptions@/irq_bspsupport.rel \
 ../../../libcpu/@RTEMS_CPU@/mpc6xx/mmu.rel \
 ../../../libcpu/@RTEMS_CPU@/mpc6xx/timer.rel \
 ../../../libcpu/@RTEMS_CPU@/mpc6xx/altivec.rel
diff --git a/c/src/lib/libbsp/powerpc/mvme3100/Makefile.am 
b/c/src/lib/libbsp/powerpc/mvme3100/Makefile.am
index a684c75a47..d7c2870e51 100644
--- a/c/src/lib/libbsp/powerpc/mvme3100/Makefile.am
+++ b/c/src/lib/libbsp/powerpc/mvme3100/Makefile.am
@@ -106,6 +106,7 @@ network_rel_LDFLAGS = $(RTEMS_RELLDFLAGS)
 endif
 
 libbsp_a_SOURCES += ../../../../../../bsps/powerpc/shared/cache/cache.c
+libbsp_a_SOURCES += ../../../../../../bsps/powerpc/shared/irq/ppc-irq-legacy.c
 
 libbsp_a_LIBADD = ../../../libcpu/@RTEMS_CPU@/shared/cpuIdent.rel \
 ../../../libcpu/@RTEMS_CPU@/shared/stack.rel \
@@ -113,8 +114,7 @@ libbsp_a_LIBADD = 
../../../libcpu/@RTEMS_CPU@/shared/cpuIdent.rel \
 ../../../libcpu/@RTEMS_CPU@/e500/timer.rel \
 ../../../libcpu/@RTEMS_CPU@/e500/mmu.rel \
 ../../../libcpu/@RTEMS_CPU@/@exceptions@/rtems-cpu.rel \
-../../../libcpu/@RTEMS_CPU@/@exceptions@/exc_bspsupport.rel \
-../../../libcpu/@RTEMS_CPU@/@exceptions@/irq_bspsupport.rel
+../../../libcpu/@RTEMS_CPU@/@exceptions@/exc_bspsupport.rel
 
 if HAS_NETWORKING
 libbsp_a_LIBADD += network.rel
diff --git a/c/src/lib/libbsp/powerpc/mvme5500/M

[PATCH 5/5] bsp/ss555: Move libcpu content to bsps

2018-03-14 Thread Sebastian Huber

This patch is a part of the BSP source reorganization.

Update #3285.
---
 .../clock => bsps/powerpc/ss555/dev}/clock.c   |  0
 .../powerpc/ss555/dev}/console-generic.c   |  0
 .../timer => bsps/powerpc/ss555/dev}/timer.c   |  0
 .../mpc5xx/irq => bsps/powerpc/ss555/start}/irq.c  |  0
 .../irq => bsps/powerpc/ss555/start}/irq_asm.S |  0
 .../irq => bsps/powerpc/ss555/start}/irq_init.c|  0
 .../powerpc/ss555/start}/raw_exception.c   |  0
 c/src/lib/libbsp/powerpc/ss555/Makefile.am | 14 ++--
 c/src/lib/libbsp/powerpc/ss555/README  | 24 +++
 c/src/lib/libcpu/powerpc/Makefile.am   | 35 --
 c/src/lib/libcpu/powerpc/mpc5xx/README | 23 ---
 c/src/lib/libcpu/powerpc/mpc5xx/ictrl/ictrl.c  | 68 
 c/src/lib/libcpu/powerpc/mpc5xx/ictrl/ictrl.h  | 75 --
 13 files changed, 31 insertions(+), 208 deletions(-)
 rename {c/src/lib/libcpu/powerpc/mpc5xx/clock => 
bsps/powerpc/ss555/dev}/clock.c (100%)
 rename {c/src/lib/libcpu/powerpc/mpc5xx/console-generic => 
bsps/powerpc/ss555/dev}/console-generic.c (100%)
 rename {c/src/lib/libcpu/powerpc/mpc5xx/timer => 
bsps/powerpc/ss555/dev}/timer.c (100%)
 rename {c/src/lib/libcpu/powerpc/mpc5xx/irq => bsps/powerpc/ss555/start}/irq.c 
(100%)
 rename {c/src/lib/libcpu/powerpc/mpc5xx/irq => 
bsps/powerpc/ss555/start}/irq_asm.S (100%)
 rename {c/src/lib/libcpu/powerpc/mpc5xx/irq => 
bsps/powerpc/ss555/start}/irq_init.c (100%)
 rename {c/src/lib/libcpu/powerpc/mpc5xx/exceptions => 
bsps/powerpc/ss555/start}/raw_exception.c (100%)
 delete mode 100644 c/src/lib/libcpu/powerpc/mpc5xx/README
 delete mode 100644 c/src/lib/libcpu/powerpc/mpc5xx/ictrl/ictrl.c
 delete mode 100644 c/src/lib/libcpu/powerpc/mpc5xx/ictrl/ictrl.h

diff --git a/c/src/lib/libcpu/powerpc/mpc5xx/clock/clock.c 
b/bsps/powerpc/ss555/dev/clock.c
similarity index 100%
rename from c/src/lib/libcpu/powerpc/mpc5xx/clock/clock.c
rename to bsps/powerpc/ss555/dev/clock.c
diff --git a/c/src/lib/libcpu/powerpc/mpc5xx/console-generic/console-generic.c 
b/bsps/powerpc/ss555/dev/console-generic.c
similarity index 100%
rename from c/src/lib/libcpu/powerpc/mpc5xx/console-generic/console-generic.c
rename to bsps/powerpc/ss555/dev/console-generic.c
diff --git a/c/src/lib/libcpu/powerpc/mpc5xx/timer/timer.c 
b/bsps/powerpc/ss555/dev/timer.c
similarity index 100%
rename from c/src/lib/libcpu/powerpc/mpc5xx/timer/timer.c
rename to bsps/powerpc/ss555/dev/timer.c
diff --git a/c/src/lib/libcpu/powerpc/mpc5xx/irq/irq.c 
b/bsps/powerpc/ss555/start/irq.c
similarity index 100%
rename from c/src/lib/libcpu/powerpc/mpc5xx/irq/irq.c
rename to bsps/powerpc/ss555/start/irq.c
diff --git a/c/src/lib/libcpu/powerpc/mpc5xx/irq/irq_asm.S 
b/bsps/powerpc/ss555/start/irq_asm.S
similarity index 100%
rename from c/src/lib/libcpu/powerpc/mpc5xx/irq/irq_asm.S
rename to bsps/powerpc/ss555/start/irq_asm.S
diff --git a/c/src/lib/libcpu/powerpc/mpc5xx/irq/irq_init.c 
b/bsps/powerpc/ss555/start/irq_init.c
similarity index 100%
rename from c/src/lib/libcpu/powerpc/mpc5xx/irq/irq_init.c
rename to bsps/powerpc/ss555/start/irq_init.c
diff --git a/c/src/lib/libcpu/powerpc/mpc5xx/exceptions/raw_exception.c 
b/bsps/powerpc/ss555/start/raw_exception.c
similarity index 100%
rename from c/src/lib/libcpu/powerpc/mpc5xx/exceptions/raw_exception.c
rename to bsps/powerpc/ss555/start/raw_exception.c
diff --git a/c/src/lib/libbsp/powerpc/ss555/Makefile.am 
b/c/src/lib/libbsp/powerpc/ss555/Makefile.am
index 6997ece985..0a85ecd539 100644
--- a/c/src/lib/libbsp/powerpc/ss555/Makefile.am
+++ b/c/src/lib/libbsp/powerpc/ss555/Makefile.am
@@ -37,16 +37,16 @@ libbsp_a_SOURCES += startup/tm27supp.c
 
 libbsp_a_SOURCES += ../../../../../../bsps/powerpc/shared/cache/cache.c
 libbsp_a_SOURCES += 
../../../../../../bsps/powerpc/shared/exceptions/ppc_exc_print.c
+libbsp_a_SOURCES += ../../../../../../bsps/powerpc/ss555/dev/clock.c
+libbsp_a_SOURCES += ../../../../../../bsps/powerpc/ss555/dev/console-generic.c
+libbsp_a_SOURCES += ../../../../../../bsps/powerpc/ss555/dev/timer.c
+libbsp_a_SOURCES += ../../../../../../bsps/powerpc/ss555/start/irq_asm.S
+libbsp_a_SOURCES += ../../../../../../bsps/powerpc/ss555/start/irq.c
+libbsp_a_SOURCES += ../../../../../../bsps/powerpc/ss555/start/irq_init.c
+libbsp_a_SOURCES += ../../../../../../bsps/powerpc/ss555/start/raw_exception.c
 libbsp_a_SOURCES += ../../../../../../bsps/powerpc/ss555/start/vectors_init.c
 libbsp_a_SOURCES += ../../../../../../bsps/powerpc/ss555/start/vectors.S
 
-libbsp_a_LIBADD = \
-../../../libcpu/@RTEMS_CPU@/mpc5xx/clock.rel \
-../../../libcpu/@RTEMS_CPU@/mpc5xx/console-generic.rel \
-../../../libcpu/@RTEMS_CPU@/mpc5xx/exceptions.rel \
-../../../libcpu/@RTEMS_CPU@/mpc5xx/irq.rel \
-../../../libcpu/@RTEMS_CPU@/mpc5xx/timer.rel
-
 include $(top_srcdir)/../../../../automake/local.am
 include $(srcdir)/../../../../../../bsps/powerpc/shared/shared.am
 include $(srcdir)/../../../../..

[PATCH 3/5] bsps/powerpc: Remove unused files

2018-03-14 Thread Sebastian Huber

This patch is a part of the BSP source reorganization.

Update #3285.
---
 .../libcpu/powerpc/mpc6xx/exceptions/asm_utils.S   |  62 --
 .../lib/libcpu/powerpc/new-exceptions/asm_utils.S  |  61 --
 .../new-exceptions/bspsupport/nested_irq_test.c| 105 -
 .../new-exceptions/bspsupport/ppc_exc_test.c   | 236 -
 4 files changed, 464 deletions(-)
 delete mode 100644 c/src/lib/libcpu/powerpc/mpc6xx/exceptions/asm_utils.S
 delete mode 100644 c/src/lib/libcpu/powerpc/new-exceptions/asm_utils.S
 delete mode 100644 
c/src/lib/libcpu/powerpc/new-exceptions/bspsupport/nested_irq_test.c
 delete mode 100644 
c/src/lib/libcpu/powerpc/new-exceptions/bspsupport/ppc_exc_test.c

diff --git a/c/src/lib/libcpu/powerpc/mpc6xx/exceptions/asm_utils.S 
b/c/src/lib/libcpu/powerpc/mpc6xx/exceptions/asm_utils.S
deleted file mode 100644
index 538bbaf8ca..00
--- a/c/src/lib/libcpu/powerpc/mpc6xx/exceptions/asm_utils.S
+++ /dev/null
@@ -1,62 +0,0 @@
-/*
- *  asm_utils.s
- *
- *  Copyright (C) 1999 Eric Valette (vale...@crf.canon.fr)
- *
- *  This file contains the low-level support for moving exception
- *  exception code to appropriate location.
- *
- */
-
-#include 
-#include 
-#include 
-
-   .globl  codemove
-codemove:
-   .type   codemove,@function
-/* r3 dest, r4 src, r5 length in bytes, r6 cachelinesize */
-   cmplw   cr1,r3,r4
-   addir0,r5,3
-   srwi.   r0,r0,2
-   beq cr1,4f  /* In place copy is not necessary */
-   beq 7f  /* Protect against 0 count */
-   mtctr   r0
-   bge cr1,2f
-
-   la  r8,-4(r4)
-   la  r7,-4(r3)
-1: lwzur0,4(r8)
-   stwur0,4(r7)
-   bdnz1b
-   b   4f
-
-2: slwir0,r0,2
-   add r8,r4,r0
-   add r7,r3,r0
-3: lwzur0,-4(r8)
-   stwur0,-4(r7)
-   bdnz3b
-
-/* Now flush the cache:note that we must start from a cache aligned
- * address. Otherwise we might miss one cache line.
- */
-4: cmpwi   r6,0
-   add r5,r3,r5
-   beq 7f  /* Always flush prefetch queue in any case */
-   subir0,r6,1
-   andcr3,r3,r0
-   mr  r4,r3
-5: cmplw   r4,r5
-   dcbst   0,r4
-   add r4,r4,r6
-   blt 5b
-   sync/* Wait for all dcbst to complete on bus */
-   mr  r4,r3
-6: cmplw   r4,r5
-   icbi0,r4
-   add r4,r4,r6
-   blt 6b
-7: sync/* Wait for all icbi to complete on bus */
-   isync
-   blr
diff --git a/c/src/lib/libcpu/powerpc/new-exceptions/asm_utils.S 
b/c/src/lib/libcpu/powerpc/new-exceptions/asm_utils.S
deleted file mode 100644
index d50eb8ee99..00
--- a/c/src/lib/libcpu/powerpc/new-exceptions/asm_utils.S
+++ /dev/null
@@ -1,61 +0,0 @@
-/*
- *  asm_utils.s
- *
- *  Copyright (C) 1999 Eric Valette (vale...@crf.canon.fr)
- *
- *  This file contains the low-level support for moving exception
- *  exception code to appropriate location.
- *
- */
-
-#include 
-#include 
-
-   .globl  codemove
-codemove:
-   .type   codemove,@function
-/* r3 dest, r4 src, r5 length in bytes, r6 cachelinesize */
-   cmplw   cr1,r3,r4
-   addir0,r5,3
-   srwi.   r0,r0,2
-   beq cr1,4f  /* In place copy is not necessary */
-   beq 7f  /* Protect against 0 count */
-   mtctr   r0
-   bge cr1,2f
-
-   la  r8,-4(r4)
-   la  r7,-4(r3)
-1: lwzur0,4(r8)
-   stwur0,4(r7)
-   bdnz1b
-   b   4f
-
-2: slwir0,r0,2
-   add r8,r4,r0
-   add r7,r3,r0
-3: lwzur0,-4(r8)
-   stwur0,-4(r7)
-   bdnz3b
-
-/* Now flush the cache:note that we must start from a cache aligned
- * address. Otherwise we might miss one cache line.
- */
-4: cmpwi   r6,0
-   add r5,r3,r5
-   beq 7f  /* Always flush prefetch queue in any case */
-   subir0,r6,1
-   andcr3,r3,r0
-   mr  r4,r3
-5: cmplw   r4,r5
-   dcbst   0,r4
-   add r4,r4,r6
-   blt 5b
-   sync/* Wait for all dcbst to complete on bus */
-   mr  r4,r3
-6: cmplw   r4,r5
-   icbi0,r4
-   add r4,r4,r6
-   blt 6b
-7: sync/* Wait for all icbi to complete on bus */
-   isync
-   blr
diff --git 
a/c/src/lib/libcpu/powerpc/new-exceptions/bspsupport/nested_irq_test.c 
b/c/src/lib/libcpu/powerpc/new-exceptions/bspsupport/nested_irq_test.c
deleted file mode 100644
index 716fc68463..00
--- a/c/src/lib/libcpu/powerpc/new-exceptions/bspsupport/nested_irq_test.c
+++ /dev/null
@@ -1,105 +0,0 @@
-/*
- * Test nested interrupts.
- *
- * Author: Till Straumann , 2007
- *
- *  The license and distribution terms for this file may be
- *  found in the file LICENSE in this distribution or at
- *  http://www.rtems.org/license/LICENSE.
- */
-
-
-/*
- * Needs board with 2 available openp

[PATCH 4/5] bsps/powerpc: Move exceptions support to bsps

2018-03-14 Thread Sebastian Huber

This patch is a part of the BSP source reorganization.

Update #3285.
---
 bsps/powerpc/shared/exceptions.am  | 14 +
 .../powerpc/shared/exceptions}/README  |  0
 .../powerpc/shared/exceptions}/ppc-code-copy.c |  0
 .../powerpc/shared/exceptions}/ppc_exc.S   |  8 +
 .../powerpc/shared/exceptions}/ppc_exc_address.c   |  0
 .../powerpc/shared/exceptions}/ppc_exc_alignment.c |  0
 .../shared/exceptions}/ppc_exc_asm_macros.h|  0
 .../shared/exceptions}/ppc_exc_async_normal.S  |  0
 .../shared/exceptions}/ppc_exc_categories.c|  0
 .../powerpc/shared/exceptions}/ppc_exc_fatal.S |  0
 .../shared/exceptions}/ppc_exc_global_handler.c|  0
 .../powerpc/shared/exceptions}/ppc_exc_hdl.c   |  0
 .../shared/exceptions}/ppc_exc_initialize.c|  0
 .../powerpc/shared/exceptions}/ppc_exc_naked.S |  0
 .../powerpc/shared/exceptions}/ppc_exc_print.c |  0
 .../powerpc/shared/exceptions}/ppc_exc_prologue.c  |  0
 .../vectors => bsps/powerpc/ss555/start}/vectors.S |  0
 .../powerpc/ss555/start}/vectors_init.c|  0
 c/src/lib/libbsp/powerpc/beatnik/Makefile.am   |  4 +--
 c/src/lib/libbsp/powerpc/gen5200/Makefile.am   |  4 +--
 c/src/lib/libbsp/powerpc/gen83xx/Makefile.am   |  4 +--
 c/src/lib/libbsp/powerpc/haleakala/Makefile.am |  4 +--
 .../libbsp/powerpc/motorola_powerpc/Makefile.am|  2 +-
 c/src/lib/libbsp/powerpc/mpc55xxevb/Makefile.am|  2 +-
 c/src/lib/libbsp/powerpc/mpc8260ads/Makefile.am|  4 +--
 c/src/lib/libbsp/powerpc/mvme3100/Makefile.am  |  4 +--
 c/src/lib/libbsp/powerpc/mvme5500/Makefile.am  |  2 +-
 c/src/lib/libbsp/powerpc/psim/Makefile.am  |  2 +-
 c/src/lib/libbsp/powerpc/qemuppc/Makefile.am   |  4 +--
 c/src/lib/libbsp/powerpc/qoriq/Makefile.am |  4 +--
 c/src/lib/libbsp/powerpc/ss555/Makefile.am |  6 ++--
 c/src/lib/libbsp/powerpc/t32mppc/Makefile.am   |  3 +-
 c/src/lib/libbsp/powerpc/tqm8xx/Makefile.am|  2 +-
 c/src/lib/libbsp/powerpc/virtex/Makefile.am|  3 +-
 c/src/lib/libbsp/powerpc/virtex4/Makefile.am   |  4 +--
 c/src/lib/libbsp/powerpc/virtex5/Makefile.am   |  4 +--
 c/src/lib/libcpu/powerpc/Makefile.am   | 34 --
 37 files changed, 53 insertions(+), 65 deletions(-)
 create mode 100644 bsps/powerpc/shared/exceptions.am
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/README (100%)
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/ppc-code-copy.c (100%)
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/ppc_exc.S (97%)
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/ppc_exc_address.c (100%)
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/ppc_exc_alignment.c (100%)
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/ppc_exc_asm_macros.h (100%)
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/ppc_exc_async_normal.S (100%)
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/ppc_exc_categories.c (100%)
 mode change 100755 => 100644
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/ppc_exc_fatal.S (100%)
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/ppc_exc_global_handler.c (100%)
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/ppc_exc_hdl.c (100%)
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/ppc_exc_initialize.c (100%)
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/ppc_exc_naked.S (100%)
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/ppc_exc_print.c (100%)
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/ppc_exc_prologue.c (100%)
 rename {c/src/lib/libcpu/powerpc/mpc5xx/vectors => 
bsps/powerpc/ss555/start}/vectors.S (100%)
 rename {c/src/lib/libcpu/powerpc/mpc5xx/vectors => 
bsps/powerpc/ss555/start}/vectors_init.c (100%)

diff --git a/bsps/powerpc/shared/exceptions.am 
b/bsps/powerpc/shared/exceptions.am
new file mode 100644
index 00..e85b4bb326
--- /dev/null
+++ b/bsps/powerpc/shared/exceptions.am
@@ -0,0 +1,14 @@
+libbsp_a_SOURCES += 
../../../../../../bsps/powerpc/shared/exceptions/ppc-code-copy.c
+libbsp_a_SOURCES += 
../../../../../../bsps/powerpc/shared/exceptions/ppc_exc_address.c
+libbsp_a_SOURCES += 
../../../../../../bsps/powerpc/shared/exceptions/ppc_exc_alignment.c
+libbsp_a_SOURCES += 
../../../../../../bsps/powerpc/shared/exceptions/ppc_exc_asm_macros.h
+libb

[PATCH 2/5] bsps/powerpc: Move basic support to bsps

2018-03-14 Thread Sebastian Huber

This patch is a part of the BSP source reorganization.

Update #3285.
---
 .../new-exceptions => bsps/powerpc/shared}/cpu.c   |  0
 .../include => bsps/powerpc/shared}/cpuIdent.c |  0
 .../powerpc/shared}/cpu_asm.S  |  0
 .../powerpc/shared/ppc-print-stack.c   |  0
 bsps/powerpc/shared/shared.am  |  4 
 c/src/lib/libbsp/powerpc/beatnik/Makefile.am   |  6 ++---
 c/src/lib/libbsp/powerpc/gen5200/Makefile.am   |  6 ++---
 c/src/lib/libbsp/powerpc/gen83xx/Makefile.am   |  5 ++---
 c/src/lib/libbsp/powerpc/haleakala/Makefile.am |  5 ++---
 .../libbsp/powerpc/motorola_powerpc/Makefile.am|  4 +---
 c/src/lib/libbsp/powerpc/mpc55xxevb/Makefile.am|  6 ++---
 c/src/lib/libbsp/powerpc/mpc8260ads/Makefile.am|  5 ++---
 c/src/lib/libbsp/powerpc/mvme3100/Makefile.am  |  6 ++---
 c/src/lib/libbsp/powerpc/mvme5500/Makefile.am  |  4 +---
 c/src/lib/libbsp/powerpc/psim/Makefile.am  |  6 ++---
 c/src/lib/libbsp/powerpc/qemuppc/Makefile.am   |  6 ++---
 c/src/lib/libbsp/powerpc/qoriq/Makefile.am |  5 ++---
 c/src/lib/libbsp/powerpc/ss555/Makefile.am |  3 +--
 c/src/lib/libbsp/powerpc/t32mppc/Makefile.am   |  5 ++---
 c/src/lib/libbsp/powerpc/tqm8xx/Makefile.am|  3 +--
 c/src/lib/libbsp/powerpc/virtex/Makefile.am|  6 ++---
 c/src/lib/libbsp/powerpc/virtex4/Makefile.am   |  5 ++---
 c/src/lib/libbsp/powerpc/virtex5/Makefile.am   |  5 ++---
 c/src/lib/libcpu/powerpc/Makefile.am   | 26 +-
 24 files changed, 37 insertions(+), 84 deletions(-)
 rename {c/src/lib/libcpu/powerpc/new-exceptions => bsps/powerpc/shared}/cpu.c 
(100%)
 rename {c/src/lib/libcpu/powerpc/shared/include => 
bsps/powerpc/shared}/cpuIdent.c (100%)
 mode change 100755 => 100644
 rename {c/src/lib/libcpu/powerpc/new-exceptions => 
bsps/powerpc/shared}/cpu_asm.S (100%)
 rename c/src/lib/libcpu/powerpc/shared/src/stack.c => 
bsps/powerpc/shared/ppc-print-stack.c (100%)
 create mode 100644 bsps/powerpc/shared/shared.am

diff --git a/c/src/lib/libcpu/powerpc/new-exceptions/cpu.c 
b/bsps/powerpc/shared/cpu.c
similarity index 100%
rename from c/src/lib/libcpu/powerpc/new-exceptions/cpu.c
rename to bsps/powerpc/shared/cpu.c
diff --git a/c/src/lib/libcpu/powerpc/shared/include/cpuIdent.c 
b/bsps/powerpc/shared/cpuIdent.c
old mode 100755
new mode 100644
similarity index 100%
rename from c/src/lib/libcpu/powerpc/shared/include/cpuIdent.c
rename to bsps/powerpc/shared/cpuIdent.c
diff --git a/c/src/lib/libcpu/powerpc/new-exceptions/cpu_asm.S 
b/bsps/powerpc/shared/cpu_asm.S
similarity index 100%
rename from c/src/lib/libcpu/powerpc/new-exceptions/cpu_asm.S
rename to bsps/powerpc/shared/cpu_asm.S
diff --git a/c/src/lib/libcpu/powerpc/shared/src/stack.c 
b/bsps/powerpc/shared/ppc-print-stack.c
similarity index 100%
rename from c/src/lib/libcpu/powerpc/shared/src/stack.c
rename to bsps/powerpc/shared/ppc-print-stack.c
diff --git a/bsps/powerpc/shared/shared.am b/bsps/powerpc/shared/shared.am
new file mode 100644
index 00..7b779361f4
--- /dev/null
+++ b/bsps/powerpc/shared/shared.am
@@ -0,0 +1,4 @@
+libbsp_a_SOURCES += ../../../../../../bsps/powerpc/shared/cpu_asm.S
+libbsp_a_SOURCES += ../../../../../../bsps/powerpc/shared/cpu.c
+libbsp_a_SOURCES += ../../../../../../bsps/powerpc/shared/cpuIdent.c
+libbsp_a_SOURCES += ../../../../../../bsps/powerpc/shared/ppc-print-stack.c
diff --git a/c/src/lib/libbsp/powerpc/beatnik/Makefile.am 
b/c/src/lib/libbsp/powerpc/beatnik/Makefile.am
index ae8971ded8..9926e383f4 100644
--- a/c/src/lib/libbsp/powerpc/beatnik/Makefile.am
+++ b/c/src/lib/libbsp/powerpc/beatnik/Makefile.am
@@ -166,10 +166,7 @@ libbsp_a_SOURCES += ../../shared/tod.c tod/todcfg.c
 libbsp_a_SOURCES += ../../../../../../bsps/powerpc/shared/cache/cache.c
 libbsp_a_SOURCES += ../../../../../../bsps/powerpc/shared/irq/ppc-irq-legacy.c
 
-libbsp_a_LIBADD = ../../../libcpu/@RTEMS_CPU@/shared/cpuIdent.rel \
-../../../libcpu/@RTEMS_CPU@/shared/stack.rel \
-../../../libcpu/@RTEMS_CPU@/@exceptions@/rtems-cpu.rel \
-../../../libcpu/@RTEMS_CPU@/@exceptions@/exc_bspsupport.rel \
+libbsp_a_LIBADD = ../../../libcpu/@RTEMS_CPU@/@exceptions@/exc_bspsupport.rel \
 ../../../libcpu/@RTEMS_CPU@/mpc6xx/clock.rel \
 ../../../libcpu/@RTEMS_CPU@/mpc6xx/mmu.rel \
 ../../../libcpu/@RTEMS_CPU@/mpc6xx/timer.rel \
@@ -183,4 +180,5 @@ endif
 EXTRA_DIST += README LICENSE
 
 include $(top_srcdir)/../../../../automake/local.am
+include $(srcdir)/../../../../../../bsps/powerpc/shared/shared.am
 include $(srcdir)/../../../../../../bsps/powerpc/beatnik/headers.am
diff --git a/c/src/lib/libbsp/powerpc/gen5200/Makefile.am 
b/c/src/lib/libbsp/powerpc/gen5200/Makefile.am
index 4a6b536e65..b35576ed2e 100644
--- a/c/src/lib/libbsp/powerpc/gen5200/Makefile.am
+++ b/c/src/lib/libbsp/powerpc/gen5200/Makefile.am
@@ -112,12 +112,10 @@ endif
 
 libbsp_a_SOURCES += ../../../../../../bsps/powerpc/shared/cache/cac

[PATCH 0/5] BSP source reorganization (powerpc)

2018-03-14 Thread Sebastian Huber

Sebastian Huber (5):
  bsps/powerpc: Move legacy IRQ support
  bsps/powerpc: Move basic support to bsps
  bsps/powerpc: Remove unused files
  bsps/powerpc: Move exceptions support to bsps
  bsp/ss555: Move libcpu content to bsps

 .../new-exceptions => bsps/powerpc/shared}/cpu.c   |   0
 .../include => bsps/powerpc/shared}/cpuIdent.c |   0
 .../powerpc/shared}/cpu_asm.S  |   0
 bsps/powerpc/shared/exceptions.am  |  14 ++
 .../powerpc/shared/exceptions}/README  |   0
 .../powerpc/shared/exceptions}/ppc-code-copy.c |   0
 .../powerpc/shared/exceptions}/ppc_exc.S   |   8 +
 .../powerpc/shared/exceptions}/ppc_exc_address.c   |   0
 .../powerpc/shared/exceptions}/ppc_exc_alignment.c |   0
 .../shared/exceptions}/ppc_exc_asm_macros.h|   0
 .../shared/exceptions}/ppc_exc_async_normal.S  |   0
 .../shared/exceptions}/ppc_exc_categories.c|   0
 .../powerpc/shared/exceptions}/ppc_exc_fatal.S |   0
 .../shared/exceptions}/ppc_exc_global_handler.c|   0
 .../powerpc/shared/exceptions}/ppc_exc_hdl.c   |   0
 .../shared/exceptions}/ppc_exc_initialize.c|   0
 .../powerpc/shared/exceptions}/ppc_exc_naked.S |   0
 .../powerpc/shared/exceptions}/ppc_exc_print.c |   0
 .../powerpc/shared/exceptions}/ppc_exc_prologue.c  |   0
 .../powerpc/shared/irq/ppc-irq-legacy.c|   0
 .../powerpc/shared/ppc-print-stack.c   |   0
 bsps/powerpc/shared/shared.am  |   4 +
 .../clock => bsps/powerpc/ss555/dev}/clock.c   |   0
 .../powerpc/ss555/dev}/console-generic.c   |   0
 .../timer => bsps/powerpc/ss555/dev}/timer.c   |   0
 .../mpc5xx/irq => bsps/powerpc/ss555/start}/irq.c  |   0
 .../irq => bsps/powerpc/ss555/start}/irq_asm.S |   0
 .../irq => bsps/powerpc/ss555/start}/irq_init.c|   0
 .../powerpc/ss555/start}/raw_exception.c   |   0
 .../vectors => bsps/powerpc/ss555/start}/vectors.S |   0
 .../powerpc/ss555/start}/vectors_init.c|   0
 c/src/lib/libbsp/powerpc/beatnik/Makefile.am   |  10 +-
 c/src/lib/libbsp/powerpc/gen5200/Makefile.am   |   8 +-
 c/src/lib/libbsp/powerpc/gen83xx/Makefile.am   |   7 +-
 c/src/lib/libbsp/powerpc/haleakala/Makefile.am |   9 +-
 .../libbsp/powerpc/motorola_powerpc/Makefile.am|   8 +-
 c/src/lib/libbsp/powerpc/mpc55xxevb/Makefile.am|   8 +-
 c/src/lib/libbsp/powerpc/mpc8260ads/Makefile.am|   7 +-
 c/src/lib/libbsp/powerpc/mvme3100/Makefile.am  |  12 +-
 c/src/lib/libbsp/powerpc/mvme5500/Makefile.am  |   8 +-
 c/src/lib/libbsp/powerpc/psim/Makefile.am  |  10 +-
 c/src/lib/libbsp/powerpc/qemuppc/Makefile.am   |   8 +-
 c/src/lib/libbsp/powerpc/qoriq/Makefile.am |   7 +-
 c/src/lib/libbsp/powerpc/ss555/Makefile.am |  21 +-
 c/src/lib/libbsp/powerpc/ss555/README  |  24 +++
 c/src/lib/libbsp/powerpc/t32mppc/Makefile.am   |   6 +-
 c/src/lib/libbsp/powerpc/tqm8xx/Makefile.am|   5 +-
 c/src/lib/libbsp/powerpc/virtex/Makefile.am|   7 +-
 c/src/lib/libbsp/powerpc/virtex4/Makefile.am   |   7 +-
 c/src/lib/libbsp/powerpc/virtex5/Makefile.am   |   7 +-
 c/src/lib/libcpu/powerpc/Makefile.am   | 101 +
 c/src/lib/libcpu/powerpc/mpc5xx/README |  23 --
 c/src/lib/libcpu/powerpc/mpc5xx/ictrl/ictrl.c  |  68 --
 c/src/lib/libcpu/powerpc/mpc5xx/ictrl/ictrl.h  |  75 ---
 .../libcpu/powerpc/mpc6xx/exceptions/asm_utils.S   |  62 --
 .../lib/libcpu/powerpc/new-exceptions/asm_utils.S  |  61 --
 .../new-exceptions/bspsupport/nested_irq_test.c| 105 -
 .../new-exceptions/bspsupport/ppc_exc_test.c   | 236 -
 58 files changed, 115 insertions(+), 821 deletions(-)
 rename {c/src/lib/libcpu/powerpc/new-exceptions => bsps/powerpc/shared}/cpu.c 
(100%)
 rename {c/src/lib/libcpu/powerpc/shared/include => 
bsps/powerpc/shared}/cpuIdent.c (100%)
 mode change 100755 => 100644
 rename {c/src/lib/libcpu/powerpc/new-exceptions => 
bsps/powerpc/shared}/cpu_asm.S (100%)
 create mode 100644 bsps/powerpc/shared/exceptions.am
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/README (100%)
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/ppc-code-copy.c (100%)
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/ppc_exc.S (97%)
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/ppc_exc_address.c (100%)
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/ppc_exc_alignment.c (100%)
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/ppc_exc_asm_macros.h (100%)
 rename {c/src/lib/libcpu/powerpc/new-exceptions/bspsupport => 
bsps/powerpc/shared/exceptions}/ppc_exc_async_normal.S (100%)
 rename {c/src/lib/lib

Fwd: Re: [PATCH] Added Getentropy() support to beagle BSP

2018-03-14 Thread Christian Mauderer

Ups. Hit reply instead of reply all. This should go to the mailing list.

--- Ursprüngliche Nachricht ---
> 
> Am Mittwoch, 14. März 2018 schrieb Udit agarwal:
> > Hi,
> > @Joel This seems to be SoC specific.
> > 
> > 
> > So, here is the implementation with mutex, Do let me know if this is okay. 
> > I'll then do it for atsam also.
> 
> Atsam should be an extra patch.
> 
> > 
> > int getentropy(void *ptr, size_t n)
> > {
> > volatile am335x_trng_register *rng = (am335x_trng_register*) RNG_BASE;
> > rtems_mutex lock_trng_reg = RTEMS_MUTEX_INITIALIZER("lock_trng_reg");
> 
> If you create a local variable every thread will have it's own mutex. So they 
> still can access the critical section in parallel. Use a global one in this 
> case.
> 
> > 
> > while (n > 0)
> > {
> > uint64_t random;
> > size_t copy;
> > 
> > /* for mutual exclusion synchronization between multiple
> > access to TRNG register in different contexts */
> > rtems_mutex_lock(&lock_trng_reg);
> > 
> > /* wait untill RNG becomes ready with next set of random data */
> > while( ( rng->status & RNG_STATUS_RDY ) == 0 )
> > {
> > /* wait */
> > }
> > 
> > random = trng_getranddata(rng);
> > /* clear the status flag after reading to generate new random
> > value */
> > rng->status_clr = RNG_STATUS_RDY;
> > rtems_mutex_unlock(&lock_trng_reg);
> > 
> > /* checking for error by masking all bits other then error bit in
> > status register */
> > if( ((rng->status & RNG_STATUS_ERR)>>1) == 1)
> > {
> > copy = sizeof(random);
> > if ( n < copy )
> > {
> > copy = n;
> > }
> > memcpy(ptr, &random, copy);
> > n -= copy;
> > ptr = (char*)ptr + copy;
> > }
> 
> Just noted that one: What Value is returned in the error case? Can the error 
> even happen? I think that there is a special function that should be called 
> in that case.
> 
> > }
> > 
> > rtems_mutex_destroy(&lock_trng_reg);
> > return 0;
> > }
> > 
> > 
> > 
> > 
> > On Wed, Mar 14, 2018 at 2:15 AM, Joel Sherrill  wrote:
> > 
> > 
> > 
> > 
> > 
> > On Mar 13, 2018 1:31 AM, "Sebastian Huber" 
> >  wrote:
> > 
> > 
> > 
> > On 12/03/18 20:02, Udit agarwal wrote:
> > 
> > So, It looks like here's the final patch, do let me know if its ready to be 
> > pushed. Also, it would be really helpful if someone else also tests this 
> > patch before pushing(Although i have done that once).
> > 
> > Thanks,
> > Udit agarwal
> > 
> > 
> > From 454a8ff3e0ea3393818859874705a54b098c6081 Mon Sep 17 00:00:00 2001
> > 
> > From: Udit agarwal mailto:dev.mada...@gmail.com>>
> > 
> > Date: Tue, 13 Mar 2018 00:20:28 +0530
> > Subject: [PATCH] Added Getentropy() support to beagle BSP
> > 
> > ---
> > bsps/arm/include/libcpu/am335x.h | 37 ++-
> > c/src/lib/libbsp/arm/beagle/Makefile.am | 4 +-
> > .../libbsp/arm/beagle/getentropy/bbb_getentropy.c | 116 
> > +
> > 3 files changed, 155 insertions(+), 2 deletions(-)
> > create mode 100644 c/src/lib/libbsp/arm/beagle/getentropy/bbb_getentropy.c
> > 
> > diff --git a/bsps/arm/include/libcpu/am335x.h 
> > b/bsps/arm/include/libcpu/am335x.h
> > index 367e97c..cedd637 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 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,33 @@
> > #define AM335X_CM_PER_OCPWP_L3_CLKSTCTRL_CLKACTIVITY_OCPWP_L4_GCLK 
> > (0x0020u)
> > #define AM335X_I2C_INT_STOP_CONDITION AM335X_I2C_IRQSTATUS_BF
> > 
> > -#endif
> > +/* TRNG Register */
> > +
> > +/* RNG base address */
> > +#define RNG_BASE 0x4831
> > +/* RNG clock control */
> > +#define CM_PER_RNG_CLKCTRL (AM335X_CM_PER_ADDR | (9 << 4))
> > +/* rng module clock status bits */
> > +#define AM335X_CLK_RNG_BIT_MASK (0x3)
> > +/* Offset from RNG base for output ready flag */
> > +#define RNG_STATUS_RDY (1u << 0)
> > +/* Offset from RNG base for FRO related error */
> > +#define RNG_STATUS_ERR (1u << 1)
> > +/* Offset from RNG base for clock status */
> > +#define RNG_STATUS_CLK (1u << 31)
> > +/* enable module */
> > +#define AM335X_RNG_ENABLE (1 << 10)
> > +
> > +/* TRNG register structure */
> > +struct bbb_trng_register
> > +{
> > + 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 */
> > +};
> > +typedef struct bbb_trng_register bbb_trng_register;
> > 
> > 
> > The bbb (Beag

Re: [PATCH] libfs/jffs2: Force the inode size to a non-zero value if a directory.

2018-03-14 Thread Sebastian Huber


On 13/03/18 22:45, Chris Johns wrote:

On 13/03/2018 17:52, Sebastian Huber wrote:

On 13/03/18 07:50, Sebastian Huber wrote:

On 13/03/18 07:47, Chris Johns wrote:

On 13/03/2018 17:18, Sebastian Huber wrote:

On 13/03/18 00:49, Chris Johns wrote:

Set the inode size to 256 to work around a newlib scandir check where a
directory has to have a non-zero size to work. Set the size to greater than
24 bytes, a small dirent size so the allocator in scandir works.

The newlib scandir code should be updated to a more recent scandir from
FreeBSD where these checks have been removed. This change is a work
around to avoid new tools on the release branch.

With this change scandir works on IMFS, RFS and JFFS2.

I cannot find a scandir() test in the fstests for all file systems.


Closes #3332
---
    cpukit/libfs/src/jffs2/src/fs-rtems.c | 3 +++
    1 file changed, 3 insertions(+)

diff --git a/cpukit/libfs/src/jffs2/src/fs-rtems.c
b/cpukit/libfs/src/jffs2/src/fs-rtems.c
index ce84d44470..790929d856 100644
--- a/cpukit/libfs/src/jffs2/src/fs-rtems.c
+++ b/cpukit/libfs/src/jffs2/src/fs-rtems.c
@@ -1512,6 +1512,9 @@ static int jffs2_read_inode (struct _inode *inode)
    inode->i_mtime = je32_to_cpu(latest_node.mtime);
    inode->i_ctime = je32_to_cpu(latest_node.ctime);
    +    if (S_ISDIR(inode->i_mode))
+    inode->i_size = 256;
+
    inode->i_nlink = f->inocache->pino_nlink;
    mutex_unlock(&f->sem);

This code is from the original JFFS2 support for eCos. Which side-effects has
this i_size change for directories? Why can't you place this hack in
rtems_jffs2_fstat()? This would reduce the impact area of this change.


I did not know the history of the RTEMS wrapper. I just assumed all code in that
file is specific to RTEMS. The change I have makes things consistent. I still
think it is OK?

What do you mean with consistent?

The function being patched is internal to `fs-rtems.c` which is a wrapper for
JFFS2. The consistent comment I made referred to any reference to the inode had
the same value exported to RTEMS, ie consistent.

The code may have come from ecos and if ecos is using newlib with scandir they
have the same problem. I do not consider ecos as being upstream, rather this
code has been taken 'as was' (?).


I thought this is a hack to make the Newlib scandir() happy?

The issue is clearly in scandir. FreeBSD these days and glibc do not stat the
directory for it's size, OpenSolaris still does. The proper fix is to scandir.

Fixing scandir requires a newlib patch and that means an update to the RSB. If
this is preferred please say, it however is a lot more work so I am reluctant to
do this, I do not have the time.

I have coded around the scandir issue with opendir and readdir and I suspect
there are a number of cases of this happening. I have seen at least one other
case and wondered at the time why opendir etc was being used instead of scandir.


Then we should open a new ticket for the scandir() problem in Newlib and 
reference this ticket in the workaround. Once Newlib is fixed we can 
remove the workaround.





This i_size is used in several places. How do you know that

you didn't accidentally broke something?

The only thing I can think of is reading a directory as a file and a 0 means do
not read. That does not seem to be a problem with the patch, I can cat a
directory and get the same sort of rubbish I get when doing this on any other
host which implies the directory as a file does have a size. If I remove the
patch the cat of the same directory gives the same result and that would imply
something else is wrong or inconsistent so who knows if what we have there is
correct.


If you read() from a directory, then you get a stream of struct dirent 
items, see rtems_jffs2_dir_read().




The size of a directory is file system specific so I would say any code that
assumes anything is file system specific and fragile and the scandir issue would
seem to support this. I have built a large application which uses the JFFS2
heavily for application installing and management with many files and I see no
issue. I have no other test results to say otherwise.


Ok, I have difficulties to understand from the source code, why the 
i_size change has no impact on the internal file system operation:


grep -r '\' cpukit/libfs/
cpukit/libfs/src/jffs2/include/linux/kernel.h:#define 
truncate_setsize(x, y) do { (x)->i_size = (y); } while (0)

cpukit/libfs/src/jffs2/src/nodelist.c:/* Doesn't set inode->i_size */
cpukit/libfs/src/jffs2/src/dir-rtems.c: inode->i_size = datalen;
cpukit/libfs/src/jffs2/src/dir-rtems.c: ri->isize = ri->dsize = 
ri->csize = cpu_to_je32(inode->i_size);
cpukit/libfs/src/jffs2/src/dir-rtems.c: ri->totlen = 
cpu_to_je32(sizeof(*ri) + inode->i_size);
cpukit/libfs/src/jffs2/src/fs-rtems.c:    (unsigned 
int)inode->i_size, offset));
cpukit/libfs/src/jffs2/src/fs-rtems.c:  ri->isize = 
cpu_to_je32(max((uint32_t)inode->i_size, offset));
cpukit/libfs/src/jffs2/src/fs-rtems.c:

Re: [PATCH] cpu-supplement: Add ARM BSPs chapter

2018-03-14 Thread Sebastian Huber


On 13/03/18 22:58, Chris Johns wrote:

On 09/03/2018 19:55, Sebastian Huber wrote:

On 06/11/17 10:03, Sebastian Huber wrote:

On 26/10/17 08:22, Sebastian Huber wrote:

Please review this patch carefully. It adds a new chapter "ARM Board Support
Packages" following the "ARM Specific Information" chapter. It adds a
template structure for other BSPs.

Where should we place common BSP configuration options like
BSP_PRESS_KEY_FOR_RESET? We probably don't want to add a copy and paste
version to every BSP section.


Any comments with respect to the BSP documentation? It makes little sense to
start with this work if the general direction is unclear.


The insufficient and user unfriendly BSP documentation is still a big issue from
my point of view. I think it is one of be biggest obstacles to get started with
RTEMS. The BSP documentation should be part of a sphinx based rtems-docs manual.


How do we get the large number of BSP_OPTS parameters out of the BSPs and into
suitable documentation? I am reluctant to support fragmented or partial
approaches to solving this problem, I feel the "project" or effect needs to
accept _all_ BSPs need to be covered. This is a community effort that needs some
leadership and ownership.

It is a difficult area because:

1. The overlap to device TRMs and yet wanting to provide some self contained
information for a device knowledgeable user.

2. How is it maintained and checked? Reviews of patches require related doc 
patches?

3. Changing the build system, the waf build Amar created changes the way
BSP_OPTS are handled requiring clear definition with ranges and other factors
and that could be annotated with suitable documentation allowing automatic
generation. Do we push for funding for this effort and deal with it then?


For BSP documentation you need to know the hardware and the BSP in 
detail. I think we can only do this step by step and should focus on the 
BSPs that are still in use and maintained. We need a clear concept of 
the desired BSP documentation, so that it is easy for new contributors 
to fix the documentation of their BSP of interest. A build configuration 
command line help for BSP options would be nice, but I think this is 
optional. I would remove the BSP options documentation in configure.ac 
for BSPs which document the options in a manual. If we want to provide 
build configuration command line help, then we should generate it from 
some documentation master and use it for the command line help and the 
manual. This is some extra effort. It is probably in the range of 
several man weeks to update the documentation of all BSPs.


The manual should have one level for the architectures, one level for 
the BSPs and one for the BSP details. I would not use more than three 
levels in a PDF document. Do we want to create a dedicated BSP manual or 
merge it into an existing manual (which one and how)?


--
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 v2 0/3] Fix compiler errors for SMP on i386

2018-03-14 Thread Sebastian Huber


Who will review and check in i386-specific patches?

--
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: GSOC'18 contribution plan

2018-03-14 Thread Gedare Bloom

On Tue, Mar 13, 2018 at 10:07 AM, Joel Sherrill  wrote:
>
>
> On Tue, Mar 13, 2018 at 8:46 AM, Vidushi Vashishth 
> wrote:
>>
>> Hello!
>>
>> I am Vidushi Vashishth from Netaji Subhas Institute of Technology, Delhi
>> and I intend to participate in the selection procedure for GSOC'18. I have
>> already submitted the Hello world patch. The past couple of days I have been
>> going through the open projects and I am interested in the ones below:
>
>
> Awesome! Make sure you are on the list here.
>>
>>
>> 1) Run time tracing
>> For this project I have been reading about the Common Trace Format
>> Integration, Trace Buffering, RTEMS trace linker's working which utilises
>> INI configuration files. I have been following the ticket #3028. I am
>> currently working on the tasks present on the ticket's description. It would
>> be helpful if the community could point out to any other relevant issues
>> which I could work on to get a better idea about this project. I would get
>> back when I find one myself. As suggested on the mailing list, I would also
>> like to investigate the TCF project to see if a combination of both of these
>> can be undertaken in one summer. Let me know if this is too optimistic.
>
>
> As I mentioned on another thread this morning, CTF and TCF are IMO very
> important things
> for RTEMS to support. Sebastian was commenting how the tracing would help
> him.
> If I had to assign a priority to the two, I guess I would put CTF first
> because it fills a gap.
> TCF is also important but we do have debugging now but TCF might offer some
> unique
> capability we don't have.
>
>>
>>
>> 2) Rump Kernels
>> The project's description was a little open ended but garnered my
>> interest. It would require a little more research from my end to come up
>> with ideas myself. I would do that if time permits.
>
>
> Given the current status of libbsd, I am not sure what the goal of it would
> be. I think
> originally it was proposed as an alternative way to get many BSD
> capabilities onto
> RTEMS.
>
> Can someone comment?
>

Rump kernels may still have utility for adopting portable subsystems
from NetBSD code base without a major import hassle. It also could be
complementary to libbsd perhaps. Hesham did some initial research in
this direction before being distracted by other pursuits, so he might
have some more insight. He wrote a blog post about it before...

Gedare

>>
>>
>> I intend to write my proposal in a week's time.
>>
>> References:
>> https://devel.rtems.org/ticket/3028
>> https://devel.rtems.org/wiki/Developer/Projects/Open/RumpKernels
>>
>> Best,
>> Vidushi
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

POSIX Headers Not in Newlib

2018-03-14 Thread Joel Sherrill

Hi

We have the POSIX headers dlfcn.h and mqueue.h in RTEMS. I think they are
the only POSIX .h files not in newlib..

Should we migrate them to newlib?

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] bsp/atsam: Fix GMAC Rx Descriptor fields.

2018-03-14 Thread Christian Mauderer

---
 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)
+
+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

[PATCH] if_atsam: Add checksum offload. - Explanation

2018-03-14 Thread Christian Mauderer

Note that although the if_atsam does althoug exist in the old network
stack, this patch is for the libbsd. In the old stack there is no
support for hardware checksum offload.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] if_atsam: Add checksum offload.

2018-03-14 Thread Christian Mauderer

---
 rtemsbsd/sys/dev/atsam/if_atsam.c | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/rtemsbsd/sys/dev/atsam/if_atsam.c 
b/rtemsbsd/sys/dev/atsam/if_atsam.c
index 794937be..d47a17e7 100644
--- a/rtemsbsd/sys/dev/atsam/if_atsam.c
+++ b/rtemsbsd/sys/dev/atsam/if_atsam.c
@@ -554,6 +554,23 @@ static void if_atsam_rx_daemon(void *arg)
m->m_data = mtod(m, char*)+ETHER_ALIGN;
m->m_len = frame_len;
m->m_pkthdr.len = frame_len;
+   /* check checksum offload result */
+   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;
+   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_DATA_VALID |
+   CSUM_PSEUDO_HDR;
+   m->m_pkthdr.csum_data = 0x;
+   }
+
IF_ATSAM_UNLOCK(sc);
sc->ifp->if_input(ifp, m);
IF_ATSAM_LOCK(sc);
@@ -658,6 +675,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 +724,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 +1003,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 +1489,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_capabilities |= IFCAP_HWCSUM | IFCAP_HWCSUM_IPV6 |
+   IFCAP_VLAN_HWCSUM;
+   ifp->if_hwassist = CSUM_IP | CSUM_IP_UDP | CSUM_IP_TCP |
+   CSUM_IP6_UDP | CSUM_IP6_TCP;
IFQ_SET_MAXLEN(&ifp->if_snd, TXBUF_COUNT - 1);
ifp->if_snd.ifq_drv_maxlen = TXBUF_COUNT - 1;
IFQ_SET_READY(&ifp->if_snd);
-- 
2.13.6

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSOC'18 contribution plan

2018-03-14 Thread Hesham Almatary

Rump kernels have the advantage of running "unmodified" NetBSD device
drivers and benchmarks (e.g. Redis, iPerf, etc) on top of the
underlying OS. AFAIK, it's well-designed to port on other OSes and the
requirements/syscalls for it are well documented/defined.

That said, I'm not sure how this would overlap with the existing
RTEMS' libbsd project when it comes to the goals; others might
comment.

heshamelmatary.blogspot.com/2015/02/thoughts-on-supporting-rump-kernels-on.html

On Thu, Mar 15, 2018 at 1:00 AM, Gedare Bloom  wrote:
> On Tue, Mar 13, 2018 at 10:07 AM, Joel Sherrill  wrote:
>>
>>
>> On Tue, Mar 13, 2018 at 8:46 AM, Vidushi Vashishth 
>> wrote:
>>>
>>> Hello!
>>>
>>> I am Vidushi Vashishth from Netaji Subhas Institute of Technology, Delhi
>>> and I intend to participate in the selection procedure for GSOC'18. I have
>>> already submitted the Hello world patch. The past couple of days I have been
>>> going through the open projects and I am interested in the ones below:
>>
>>
>> Awesome! Make sure you are on the list here.
>>>
>>>
>>> 1) Run time tracing
>>> For this project I have been reading about the Common Trace Format
>>> Integration, Trace Buffering, RTEMS trace linker's working which utilises
>>> INI configuration files. I have been following the ticket #3028. I am
>>> currently working on the tasks present on the ticket's description. It would
>>> be helpful if the community could point out to any other relevant issues
>>> which I could work on to get a better idea about this project. I would get
>>> back when I find one myself. As suggested on the mailing list, I would also
>>> like to investigate the TCF project to see if a combination of both of these
>>> can be undertaken in one summer. Let me know if this is too optimistic.
>>
>>
>> As I mentioned on another thread this morning, CTF and TCF are IMO very
>> important things
>> for RTEMS to support. Sebastian was commenting how the tracing would help
>> him.
>> If I had to assign a priority to the two, I guess I would put CTF first
>> because it fills a gap.
>> TCF is also important but we do have debugging now but TCF might offer some
>> unique
>> capability we don't have.
>>
>>>
>>>
>>> 2) Rump Kernels
>>> The project's description was a little open ended but garnered my
>>> interest. It would require a little more research from my end to come up
>>> with ideas myself. I would do that if time permits.
>>
>>
>> Given the current status of libbsd, I am not sure what the goal of it would
>> be. I think
>> originally it was proposed as an alternative way to get many BSD
>> capabilities onto
>> RTEMS.
>>
>> Can someone comment?
>>
>
> Rump kernels may still have utility for adopting portable subsystems
> from NetBSD code base without a major import hassle. It also could be
> complementary to libbsd perhaps. Hesham did some initial research in
> this direction before being distracted by other pursuits, so he might
> have some more insight. He wrote a blog post about it before...
>
> Gedare
>
>>>
>>>
>>> I intend to write my proposal in a week's time.
>>>
>>> References:
>>> https://devel.rtems.org/ticket/3028
>>> https://devel.rtems.org/wiki/Developer/Projects/Open/RumpKernels
>>>
>>> Best,
>>> Vidushi
>>>
>>



-- 
Hesham
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSOC'18 contribution plan

2018-03-14 Thread Joel Sherrill

On Wed, Mar 14, 2018 at 10:59 AM, Hesham Almatary 
wrote:

> Rump kernels have the advantage of running "unmodified" NetBSD device
> drivers and benchmarks (e.g. Redis, iPerf, etc) on top of the
> underlying OS. AFAIK, it's well-designed to port on other OSes and the
> requirements/syscalls for it are well documented/defined.
>
> That said, I'm not sure how this would overlap with the existing
> RTEMS' libbsd project when it comes to the goals; others might
> comment.
>
> heshamelmatary.blogspot.com/2015/02/thoughts-on-
> supporting-rump-kernels-on.html


I'm fine with it as a project. I just wanted to hear someone say something
that gave it value. Just running the NetBSD filesystems and SATA driver
would be a big win.

It would be interesting to see this and compare the end result to
rtems-libbsd.

--joel


>
>
> On Thu, Mar 15, 2018 at 1:00 AM, Gedare Bloom  wrote:
> > On Tue, Mar 13, 2018 at 10:07 AM, Joel Sherrill  wrote:
> >>
> >>
> >> On Tue, Mar 13, 2018 at 8:46 AM, Vidushi Vashishth  >
> >> wrote:
> >>>
> >>> Hello!
> >>>
> >>> I am Vidushi Vashishth from Netaji Subhas Institute of Technology,
> Delhi
> >>> and I intend to participate in the selection procedure for GSOC'18. I
> have
> >>> already submitted the Hello world patch. The past couple of days I
> have been
> >>> going through the open projects and I am interested in the ones below:
> >>
> >>
> >> Awesome! Make sure you are on the list here.
> >>>
> >>>
> >>> 1) Run time tracing
> >>> For this project I have been reading about the Common Trace Format
> >>> Integration, Trace Buffering, RTEMS trace linker's working which
> utilises
> >>> INI configuration files. I have been following the ticket #3028. I am
> >>> currently working on the tasks present on the ticket's description. It
> would
> >>> be helpful if the community could point out to any other relevant
> issues
> >>> which I could work on to get a better idea about this project. I would
> get
> >>> back when I find one myself. As suggested on the mailing list, I would
> also
> >>> like to investigate the TCF project to see if a combination of both of
> these
> >>> can be undertaken in one summer. Let me know if this is too optimistic.
> >>
> >>
> >> As I mentioned on another thread this morning, CTF and TCF are IMO very
> >> important things
> >> for RTEMS to support. Sebastian was commenting how the tracing would
> help
> >> him.
> >> If I had to assign a priority to the two, I guess I would put CTF first
> >> because it fills a gap.
> >> TCF is also important but we do have debugging now but TCF might offer
> some
> >> unique
> >> capability we don't have.
> >>
> >>>
> >>>
> >>> 2) Rump Kernels
> >>> The project's description was a little open ended but garnered my
> >>> interest. It would require a little more research from my end to come
> up
> >>> with ideas myself. I would do that if time permits.
> >>
> >>
> >> Given the current status of libbsd, I am not sure what the goal of it
> would
> >> be. I think
> >> originally it was proposed as an alternative way to get many BSD
> >> capabilities onto
> >> RTEMS.
> >>
> >> Can someone comment?
> >>
> >
> > Rump kernels may still have utility for adopting portable subsystems
> > from NetBSD code base without a major import hassle. It also could be
> > complementary to libbsd perhaps. Hesham did some initial research in
> > this direction before being distracted by other pursuits, so he might
> > have some more insight. He wrote a blog post about it before...
> >
> > Gedare
> >
> >>>
> >>>
> >>> I intend to write my proposal in a week's time.
> >>>
> >>> References:
> >>> https://devel.rtems.org/ticket/3028
> >>> https://devel.rtems.org/wiki/Developer/Projects/Open/RumpKernels
> >>>
> >>> Best,
> >>> Vidushi
> >>>
> >>
>
>
>
> --
> Hesham
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: want to contribute to project

2018-03-14 Thread Joel Sherrill

On Wed, Mar 14, 2018 at 1:26 PM, Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

> I'm still getting the Covoar not found error
> I'm not able to understand what am I missing, if it needs a fix, please
> help me understand the code.
>

covoar is now part of the rtems-tools package so you need to build and
install that.

FYI I still have your draft proposal up and it is in my queue to review.

--joel


>
> Thanks
>
> On 9 March 2018 at 22:20, Vijay Kumar Banerjee 
> wrote:
>
>>
>>
>> On 9 Mar 2018 10:15 p.m., "Vijay Kumar Banerjee" <
>> vijaykumar9...@gmail.com> wrote:
>>
>>
>>
>> On 9 Mar 2018 3:34 a.m., "Joel Sherrill"  wrote:
>>
>>
>>
>> On Sun, Mar 4, 2018 at 4:52 AM, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On 3 March 2018 at 22:18, Vijay Kumar Banerjee >> > wrote:
>>>
 Hello sir,

 I need some guidance to proceed to apply for #2920 as my GSoC project.

 I wanted to know the following points :

  1. What are the prerequisites (do I have to produce something ? like
 the hello world )

>>>
>>> Other than the hello world, there's no official prerequisites. Usually
>>> the next thing is to fix a small bug, have a look at the tickets here:
>>>
>>> https://devel.rtems.org/query
>>>
>>>
  2. reference materials (like specific doc), to familiarise with the
 rtems-tester and rsb .

>>>
>>> Relevant to you would be RTEMS Tester section of the main user manual.
>>> The rest of the manual should be useful for setting up rtems in general.
>>>
>>> https://docs.rtems.org/branches/master/user/tools/tester.html
>>>
>>
>> Running this and submitting some results for a BSP on a simulator would
>> be a good step.
>> This project requires doing that a lot.  You can do one BSP that runs on
>> a gdb based simulator
>> and another on a qemu based simulator.
>>
>> I'll surely do that . currently I'm trying to run cillian's project ,
>> facing some issues with the test.py , which I'll try to fix , probably it's
>> related to the path . I'll be at the other part of the country for a  few
>> days (4 days ), after that I'll try to submit results for a BSP on a
>> simulator
>>
>> There is a project based on qemu that includes coverage trace ability.
>>
>>
>>>
>>> The links to the previous projects which you already found and the other
>>> links I've mentioned.
>>>
>>>
  3. how to properly plan the project into phase wise tasks and weekly
 sub-tasks.

>>>
>>> Essentially it would be:
>>> 1. Get coverage analysis running again (converting the config files to
>>> .ini and a couple of fixes to some of the parsing in the sections that
>>> haven't been integrated, might be all that it takes).
>>> 2. Then get the coverage tools integrated with RTEMS Tester. Which is
>>> fix the outstanding issues that are mentioned in:
>>> https://devel.rtems.org/ticket/2920
>>> Chris Johns might have things to add to this, ultimately the integration
>>> to RTEMS Tester will be up to him.
>>>
>>
>> I would add finishing getting the Couverture qemu into the RSB.
>>
>> Okay sir.
>>
>>
>> Once the setup is running, there are a couple of meaty projects.
>>
>> Chris and I have talked about reworking the report generation in covoar.
>> Currently, the C++ code writes HTML and txt files.  It would be nice to
>> have covoar generate something which is subsequently processed
>> with a report generator. We don't have a complete solution in mind but
>> writing Sphinx like the RTEMS documentation is an option. One challenge
>> is that the current HTML output has filtering capability and that wouldn't
>> be possible (I think) using Sphinx.
>>
>> The other desirable capability is to ensure the gcov output is correct and
>> can be processed by the GNU gcov tool to produce reports with the same
>> results as covoar. I think Cillian got a start on this but only as far as
>> noting
>> it wasn't always the same. We have a mentor from the GCC community
>> to help with this.
>>
>> Once the gcov output is trustworthy, we can try other tools like lcov to
>> see what other reports we can get.
>>
>>
>> Thank you for describing the object in detail , I'll read more about
>> covoar and try to understand how it generates the output and how it can be
>> modified .
>>
>>
>>> The order in which the problems are listed in that ticket are probably
>>> the order in which you would complete them, the stuff about generating the
>>> xml reports and gcov and all of that is probably a 2nd or 3rd phase task
>>> for you depending on how it goes. The plan can change as you go along, its
>>> just important that you make a plan to begin with.
>>>
>>> Good luck,
>>>
>>> Cillian.
>>>
>>>

 Thank you,
 Vijay k.





 On 1 March 2018 at 15:38, Cillian O'Donnell 
 wrote:

>
>
> On 1 March 2018 at 09:10, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> hello,
>>
>> while trying to figure out the starting point, I came across this
>> project f

Re: [PATCH] if_atsam: Add checksum offload.

2018-03-14 Thread Christian Mauderer

While on my way home I already noted two bugs. I'll send a V2 tomorrow.
Sorry for the spam.

Am 14.03.2018 um 15:54 schrieb Christian Mauderer:
> ---
>  rtemsbsd/sys/dev/atsam/if_atsam.c | 34 +-
>  1 file changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/rtemsbsd/sys/dev/atsam/if_atsam.c 
> b/rtemsbsd/sys/dev/atsam/if_atsam.c
> index 794937be..d47a17e7 100644
> --- a/rtemsbsd/sys/dev/atsam/if_atsam.c
> +++ b/rtemsbsd/sys/dev/atsam/if_atsam.c
> @@ -554,6 +554,23 @@ static void if_atsam_rx_daemon(void *arg)
>   m->m_data = mtod(m, char*)+ETHER_ALIGN;
>   m->m_len = frame_len;
>   m->m_pkthdr.len = frame_len;
> + /* check checksum offload result */
> + 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;
> + 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_DATA_VALID |
> + CSUM_PSEUDO_HDR;
> + m->m_pkthdr.csum_data = 0x;
> + }
> +
>   IF_ATSAM_UNLOCK(sc);
>   sc->ifp->if_input(ifp, m);
>   IF_ATSAM_LOCK(sc);
> @@ -658,6 +675,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 +724,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 +1003,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 +1489,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_capabilities |= IFCAP_HWCSUM | IFCAP_HWCSUM_IPV6 |
> + IFCAP_VLAN_HWCSUM;
> + ifp->if_hwassist = CSUM_IP | CSUM_IP_UDP | CSUM_IP_TCP |
> + CSUM_IP6_UDP | CSUM_IP6_TCP;
>   IFQ_SET_MAXLEN(&ifp->if_snd, TXBUF_COUNT - 1);
>   ifp->if_snd.ifq_drv_maxlen = TXBUF_COUNT - 1;
>   IFQ_SET_READY(&ifp->if_snd);
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 0/3] Fix compiler errors for SMP on i386

2018-03-14 Thread Joel Sherrill

Obviously not you Sebastian. :)

Amaan.. what's your expectation of the overall status of SMP on pc386
after these patches are added?

If something is "compile only" now, are there comments in the tickets
indicating that? Is this clear from the git log messages? Is there anywhere
you got something compiling, but not working, in the code that might
need a comment?

Just wanting to know what I should expect when I test these and
ensure the next person who looks at these areas understands
the status.

--joel

On Wed, Mar 14, 2018 at 1:55 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Who will review and check in i386-specific patches?
>
> --
> 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 v2 0/3] Fix compiler errors for SMP on i386

2018-03-14 Thread Amaan Cheval

On Thu, Mar 15, 2018 at 12:27 AM Joel Sherrill  wrote:

> Obviously not you Sebastian. :)

> Amaan.. what's your expectation of the overall status of SMP on pc386
> after these patches are added?

A compile-time error will still be thrown, but for anyone who wants to
tackle SMP issues on i386, they'll be able to pick up at what the
implementation currently lacks, instead of the "bitrot" that's occured as
the expectations of the RTEMS SMP system fell out of sync with the existing
i386-specific code.

> If something is "compile only" now, are there comments in the tickets
> indicating that? Is this clear from the git log messages? Is there
anywhere
> you got something compiling, but not working, in the code that might
> need a comment?

Patch 1 (CPU_Interrupt_frame's definition) is this way, and there's a
comment and it's mentioned in the commit message as well.
Patch 3 _may_ be thought of as that way - it only changes a macro to a
function, which does effectively the same thing (void body) - I'm not sure
that needs a comment left besides what was already there (and has been
preserved in the function as well).

The relevant tickets may benefit from some elaboration; the ticket this
patch series handles does mention that it's only to fix compile-time
issues, not logical implementation details[1]. The implementation details
that haven't been accounted for in patch 1 have the ticket in the error
message linked to [2], which I think has enough information to get one
started in the right direction, but I'll let you be the judge of that. (It
could benefit from direct links to the code, but given refactoring may
occur, pointing to a stale commit didn't seem any smarter than letting a
future undertaker just grep the codebase for the CPU_Interrupt_frame - I
might be wrong about that!)

[1] https://devel.rtems.org/ticket/3331#ticket
[2] https://devel.rtems.org/ticket/3335#ticket

> Just wanting to know what I should expect when I test these and
> ensure the next person who looks at these areas understands
> the status.

If you were to test this as-is, you'd still see a compile-time error with
the --enable-smp option, which we want. If you took the #error directive
out, though, you'd be free to tackle the implementation specific aspects
without having to first figure out seemingly unrelated errors. (Note that
if you have --enable-smp in first, then you "make clean", and try with
--disable-smp, that isn't enough. You need to start fresh.)

> --joel

> On Wed, Mar 14, 2018 at 1:55 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>> Who will review and check in i386-specific patches?

>> --
>> 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: want to contribute to project

2018-03-14 Thread Cillian O'Donnell

On 14 March 2018 at 18:26, Vijay Kumar Banerjee 
wrote:

> I'm still getting the Covoar not found error
> I'm not able to understand what am I missing, if it needs a fix, please
> help me understand the code.
>

Have a look where all the rsb tools were built. Does covoar appear in there?

The directory is something like:

cd  ~/development/rtems/4.12/bin

>
> Thanks
>
> On 9 March 2018 at 22:20, Vijay Kumar Banerjee 
> wrote:
>
>>
>>
>> On 9 Mar 2018 10:15 p.m., "Vijay Kumar Banerjee" <
>> vijaykumar9...@gmail.com> wrote:
>>
>>
>>
>> On 9 Mar 2018 3:34 a.m., "Joel Sherrill"  wrote:
>>
>>
>>
>> On Sun, Mar 4, 2018 at 4:52 AM, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On 3 March 2018 at 22:18, Vijay Kumar Banerjee >> > wrote:
>>>
 Hello sir,

 I need some guidance to proceed to apply for #2920 as my GSoC project.

 I wanted to know the following points :

  1. What are the prerequisites (do I have to produce something ? like
 the hello world )

>>>
>>> Other than the hello world, there's no official prerequisites. Usually
>>> the next thing is to fix a small bug, have a look at the tickets here:
>>>
>>> https://devel.rtems.org/query
>>>
>>>
  2. reference materials (like specific doc), to familiarise with the
 rtems-tester and rsb .

>>>
>>> Relevant to you would be RTEMS Tester section of the main user manual.
>>> The rest of the manual should be useful for setting up rtems in general.
>>>
>>> https://docs.rtems.org/branches/master/user/tools/tester.html
>>>
>>
>> Running this and submitting some results for a BSP on a simulator would
>> be a good step.
>> This project requires doing that a lot.  You can do one BSP that runs on
>> a gdb based simulator
>> and another on a qemu based simulator.
>>
>> I'll surely do that . currently I'm trying to run cillian's project ,
>> facing some issues with the test.py , which I'll try to fix , probably it's
>> related to the path . I'll be at the other part of the country for a  few
>> days (4 days ), after that I'll try to submit results for a BSP on a
>> simulator
>>
>> There is a project based on qemu that includes coverage trace ability.
>>
>>
>>>
>>> The links to the previous projects which you already found and the other
>>> links I've mentioned.
>>>
>>>
  3. how to properly plan the project into phase wise tasks and weekly
 sub-tasks.

>>>
>>> Essentially it would be:
>>> 1. Get coverage analysis running again (converting the config files to
>>> .ini and a couple of fixes to some of the parsing in the sections that
>>> haven't been integrated, might be all that it takes).
>>> 2. Then get the coverage tools integrated with RTEMS Tester. Which is
>>> fix the outstanding issues that are mentioned in:
>>> https://devel.rtems.org/ticket/2920
>>> Chris Johns might have things to add to this, ultimately the integration
>>> to RTEMS Tester will be up to him.
>>>
>>
>> I would add finishing getting the Couverture qemu into the RSB.
>>
>> Okay sir.
>>
>>
>> Once the setup is running, there are a couple of meaty projects.
>>
>> Chris and I have talked about reworking the report generation in covoar.
>> Currently, the C++ code writes HTML and txt files.  It would be nice to
>> have covoar generate something which is subsequently processed
>> with a report generator. We don't have a complete solution in mind but
>> writing Sphinx like the RTEMS documentation is an option. One challenge
>> is that the current HTML output has filtering capability and that wouldn't
>> be possible (I think) using Sphinx.
>>
>> The other desirable capability is to ensure the gcov output is correct and
>> can be processed by the GNU gcov tool to produce reports with the same
>> results as covoar. I think Cillian got a start on this but only as far as
>> noting
>> it wasn't always the same. We have a mentor from the GCC community
>> to help with this.
>>
>> Once the gcov output is trustworthy, we can try other tools like lcov to
>> see what other reports we can get.
>>
>>
>> Thank you for describing the object in detail , I'll read more about
>> covoar and try to understand how it generates the output and how it can be
>> modified .
>>
>>
>>> The order in which the problems are listed in that ticket are probably
>>> the order in which you would complete them, the stuff about generating the
>>> xml reports and gcov and all of that is probably a 2nd or 3rd phase task
>>> for you depending on how it goes. The plan can change as you go along, its
>>> just important that you make a plan to begin with.
>>>
>>> Good luck,
>>>
>>> Cillian.
>>>
>>>

 Thank you,
 Vijay k.





 On 1 March 2018 at 15:38, Cillian O'Donnell 
 wrote:

>
>
> On 1 March 2018 at 09:10, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> hello,
>>
>> while trying to figure out the starting point, I came across this
>> project form GSoC 2017 by C.P. O'Donell
>>
>> https://sum

Re: want to contribute to project

2018-03-14 Thread Cillian O'Donnell

On 14 March 2018 at 19:51, Cillian O'Donnell  wrote:

>
>
> On 14 March 2018 at 18:26, Vijay Kumar Banerjee 
> wrote:
>
>> I'm still getting the Covoar not found error
>> I'm not able to understand what am I missing, if it needs a fix, please
>> help me understand the code.
>>
>
> Have a look where all the rsb tools were built. Does covoar appear in
> there?
>
> The directory is something like:
>
> cd  ~/development/rtems/4.12/bin
>

Sorry, nevermind that, just remenbered I had  put covoar there for
something else.

You mentioned before that waf built covoar properly and it appeared in:

"covoar is in /rtems-tools/build/covoar"

is it this or is it rtems-tools/build/tester/covoar

and you're definitely using the coverage-merge branch of my github

https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge

>
>> Thanks
>>
>> On 9 March 2018 at 22:20, Vijay Kumar Banerjee 
>> wrote:
>>
>>>
>>>
>>> On 9 Mar 2018 10:15 p.m., "Vijay Kumar Banerjee" <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>
>>>
>>> On 9 Mar 2018 3:34 a.m., "Joel Sherrill" 
>>> wrote:
>>>
>>>
>>>
>>> On Sun, Mar 4, 2018 at 4:52 AM, Cillian O'Donnell >> > wrote:
>>>


 On 3 March 2018 at 22:18, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> Hello sir,
>
> I need some guidance to proceed to apply for #2920 as my GSoC project.
>
> I wanted to know the following points :
>
>  1. What are the prerequisites (do I have to produce something ? like
> the hello world )
>

 Other than the hello world, there's no official prerequisites. Usually
 the next thing is to fix a small bug, have a look at the tickets here:

 https://devel.rtems.org/query


>  2. reference materials (like specific doc), to familiarise with the
> rtems-tester and rsb .
>

 Relevant to you would be RTEMS Tester section of the main user manual.
 The rest of the manual should be useful for setting up rtems in general.

 https://docs.rtems.org/branches/master/user/tools/tester.html

>>>
>>> Running this and submitting some results for a BSP on a simulator would
>>> be a good step.
>>> This project requires doing that a lot.  You can do one BSP that runs on
>>> a gdb based simulator
>>> and another on a qemu based simulator.
>>>
>>> I'll surely do that . currently I'm trying to run cillian's project ,
>>> facing some issues with the test.py , which I'll try to fix , probably it's
>>> related to the path . I'll be at the other part of the country for a  few
>>> days (4 days ), after that I'll try to submit results for a BSP on a
>>> simulator
>>>
>>> There is a project based on qemu that includes coverage trace ability.
>>>
>>>

 The links to the previous projects which you already found and the
 other links I've mentioned.


>  3. how to properly plan the project into phase wise tasks and weekly
> sub-tasks.
>

 Essentially it would be:
 1. Get coverage analysis running again (converting the config files to
 .ini and a couple of fixes to some of the parsing in the sections that
 haven't been integrated, might be all that it takes).
 2. Then get the coverage tools integrated with RTEMS Tester. Which is
 fix the outstanding issues that are mentioned in:
 https://devel.rtems.org/ticket/2920
 Chris Johns might have things to add to this, ultimately the
 integration to RTEMS Tester will be up to him.

>>>
>>> I would add finishing getting the Couverture qemu into the RSB.
>>>
>>> Okay sir.
>>>
>>>
>>> Once the setup is running, there are a couple of meaty projects.
>>>
>>> Chris and I have talked about reworking the report generation in covoar.
>>> Currently, the C++ code writes HTML and txt files.  It would be nice to
>>> have covoar generate something which is subsequently processed
>>> with a report generator. We don't have a complete solution in mind but
>>> writing Sphinx like the RTEMS documentation is an option. One challenge
>>> is that the current HTML output has filtering capability and that
>>> wouldn't
>>> be possible (I think) using Sphinx.
>>>
>>> The other desirable capability is to ensure the gcov output is correct
>>> and
>>> can be processed by the GNU gcov tool to produce reports with the same
>>> results as covoar. I think Cillian got a start on this but only as far
>>> as noting
>>> it wasn't always the same. We have a mentor from the GCC community
>>> to help with this.
>>>
>>> Once the gcov output is trustworthy, we can try other tools like lcov to
>>> see what other reports we can get.
>>>
>>>
>>> Thank you for describing the object in detail , I'll read more about
>>> covoar and try to understand how it generates the output and how it can be
>>> modified .
>>>
>>>
 The order in which the problems are listed in that ticket are probably
 the order in which you would complete them, the stuff about generating the
 xml reports and gcov and all o

Re: want to contribute to project

2018-03-14 Thread Joel Sherrill

On Wed, Mar 14, 2018 at 4:13 PM, Cillian O'Donnell 
wrote:

>
>
> On 14 March 2018 at 19:51, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On 14 March 2018 at 18:26, Vijay Kumar Banerjee > > wrote:
>>
>>> I'm still getting the Covoar not found error
>>> I'm not able to understand what am I missing, if it needs a fix, please
>>> help me understand the code.
>>>
>>
>> Have a look where all the rsb tools were built. Does covoar appear in
>> there?
>>
>> The directory is something like:
>>
>> cd  ~/development/rtems/4.12/bin
>>
>
> Sorry, nevermind that, just remenbered I had  put covoar there for
> something else.
>
> You mentioned before that waf built covoar properly and it appeared in:
>
> "covoar is in /rtems-tools/build/covoar"
>
> is it this or is it rtems-tools/build/tester/covoar
>
> and you're definitely using the coverage-merge branch of my github
>
> https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge
>

It shouldn't matter much but I think we merged all your changes. If not, we
want to
fix that. Hopefully he can use the main rtems-tools.

--joel

>
>>> Thanks
>>>
>>> On 9 March 2018 at 22:20, Vijay Kumar Banerjee >> > wrote:
>>>

 On 9 Mar 2018 10:15 p.m., "Vijay Kumar Banerjee" <
 vijaykumar9...@gmail.com> wrote:

 On 9 Mar 2018 3:34 a.m., "Joel Sherrill" 
 wrote:

 On Sun, Mar 4, 2018 at 4:52 AM, Cillian O'Donnell <
 cpodonne...@gmail.com> wrote:

>
>
> On 3 March 2018 at 22:18, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Hello sir,
>>
>> I need some guidance to proceed to apply for #2920 as my GSoC project.
>>
>> I wanted to know the following points :
>>
>>  1. What are the prerequisites (do I have to produce something ? like
>> the hello world )
>>
>
> Other than the hello world, there's no official prerequisites. Usually
> the next thing is to fix a small bug, have a look at the tickets here:
>
> https://devel.rtems.org/query
>
>
>>  2. reference materials (like specific doc), to familiarise with the
>> rtems-tester and rsb .
>>
>
> Relevant to you would be RTEMS Tester section of the main user manual.
> The rest of the manual should be useful for setting up rtems in general.
>
> https://docs.rtems.org/branches/master/user/tools/tester.html
>

 Running this and submitting some results for a BSP on a simulator would
 be a good step.
 This project requires doing that a lot.  You can do one BSP that runs
 on a gdb based simulator
 and another on a qemu based simulator.

 I'll surely do that . currently I'm trying to run cillian's project ,
 facing some issues with the test.py , which I'll try to fix , probably it's
 related to the path . I'll be at the other part of the country for a  few
 days (4 days ), after that I'll try to submit results for a BSP on a
 simulator

 There is a project based on qemu that includes coverage trace ability.

>
> The links to the previous projects which you already found and the
> other links I've mentioned.
>
>
>>  3. how to properly plan the project into phase wise tasks and weekly
>> sub-tasks.
>>
>
> Essentially it would be:
> 1. Get coverage analysis running again (converting the config files to
> .ini and a couple of fixes to some of the parsing in the sections that
> haven't been integrated, might be all that it takes).
> 2. Then get the coverage tools integrated with RTEMS Tester. Which is
> fix the outstanding issues that are mentioned in:
> https://devel.rtems.org/ticket/2920
> Chris Johns might have things to add to this, ultimately the
> integration to RTEMS Tester will be up to him.
>

 I would add finishing getting the Couverture qemu into the RSB.

 Okay sir.

 Once the setup is running, there are a couple of meaty projects.

 Chris and I have talked about reworking the report generation in
 covoar.
 Currently, the C++ code writes HTML and txt files.  It would be nice to
 have covoar generate something which is subsequently processed
 with a report generator. We don't have a complete solution in mind but
 writing Sphinx like the RTEMS documentation is an option. One challenge
 is that the current HTML output has filtering capability and that
 wouldn't
 be possible (I think) using Sphinx.

 The other desirable capability is to ensure the gcov output is correct
 and
 can be processed by the GNU gcov tool to produce reports with the same
 results as covoar. I think Cillian got a start on this but only as far
 as noting
 it wasn't always the same. We have a mentor from the GCC community
 to help with this.

 Once the gcov output is trustworthy, we can try other tools like lcov to
 see what othe

Re: want to contribute to project

2018-03-14 Thread Cillian O'Donnell

The covoar fixes made it in but all the python stuff never made it in
because of outstanding issues in the open project page, so to see it
working, it'll have to be from the old github until the terms tester stuff
gets merged.

On Wed, 14 Mar 2018, 21:33 Joel Sherrill,  wrote:

>
>
> On Wed, Mar 14, 2018 at 4:13 PM, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On 14 March 2018 at 19:51, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On 14 March 2018 at 18:26, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 I'm still getting the Covoar not found error
 I'm not able to understand what am I missing, if it needs a fix, please
 help me understand the code.

>>>
>>> Have a look where all the rsb tools were built. Does covoar appear in
>>> there?
>>>
>>> The directory is something like:
>>>
>>> cd  ~/development/rtems/4.12/bin
>>>
>>
>> Sorry, nevermind that, just remenbered I had  put covoar there for
>> something else.
>>
>> You mentioned before that waf built covoar properly and it appeared in:
>>
>> "covoar is in /rtems-tools/build/covoar"
>>
>> is it this or is it rtems-tools/build/tester/covoar
>>
>> and you're definitely using the coverage-merge branch of my github
>>
>> https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge
>>
>
> It shouldn't matter much but I think we merged all your changes. If not,
> we want to
> fix that. Hopefully he can use the main rtems-tools.
>
> --joel
>
>
>>
 Thanks

 On 9 March 2018 at 22:20, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

>
>
> On 9 Mar 2018 10:15 p.m., "Vijay Kumar Banerjee" <
> vijaykumar9...@gmail.com> wrote:
>
>
>
> On 9 Mar 2018 3:34 a.m., "Joel Sherrill" 
> wrote:
>
>
>
> On Sun, Mar 4, 2018 at 4:52 AM, Cillian O'Donnell <
> cpodonne...@gmail.com> wrote:
>
>>
>>
>> On 3 March 2018 at 22:18, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> Hello sir,
>>>
>>> I need some guidance to proceed to apply for #2920 as my GSoC
>>> project.
>>>
>>> I wanted to know the following points :
>>>
>>>  1. What are the prerequisites (do I have to produce something
>>> ? like the hello world )
>>>
>>
>> Other than the hello world, there's no official prerequisites.
>> Usually the next thing is to fix a small bug, have a look at the tickets
>> here:
>>
>> https://devel.rtems.org/query
>>
>>
>>>  2. reference materials (like specific doc), to familiarise with the
>>> rtems-tester and rsb .
>>>
>>
>> Relevant to you would be RTEMS Tester section of the main user
>> manual. The rest of the manual should be useful for setting up rtems in
>> general.
>>
>> https://docs.rtems.org/branches/master/user/tools/tester.html
>>
>
> Running this and submitting some results for a BSP on a simulator
> would be a good step.
> This project requires doing that a lot.  You can do one BSP that runs
> on a gdb based simulator
> and another on a qemu based simulator.
>
> I'll surely do that . currently I'm trying to run cillian's project ,
> facing some issues with the test.py , which I'll try to fix , probably 
> it's
> related to the path . I'll be at the other part of the country for a  few
> days (4 days ), after that I'll try to submit results for a BSP on a
> simulator
>
> There is a project based on qemu that includes coverage trace ability.
>
>
>>
>> The links to the previous projects which you already found and the
>> other links I've mentioned.
>>
>>
>>>  3. how to properly plan the project into phase wise tasks and
>>> weekly sub-tasks.
>>>
>>
>> Essentially it would be:
>> 1. Get coverage analysis running again (converting the config files
>> to .ini and a couple of fixes to some of the parsing in the sections that
>> haven't been integrated, might be all that it takes).
>> 2. Then get the coverage tools integrated with RTEMS Tester. Which is
>> fix the outstanding issues that are mentioned in:
>> https://devel.rtems.org/ticket/2920
>> Chris Johns might have things to add to this, ultimately the
>> integration to RTEMS Tester will be up to him.
>>
>
> I would add finishing getting the Couverture qemu into the RSB.
>
> Okay sir.
>
>
> Once the setup is running, there are a couple of meaty projects.
>
> Chris and I have talked about reworking the report generation in
> covoar.
> Currently, the C++ code writes HTML and txt files.  It would be nice to
> have covoar generate something which is subsequently processed
> with a report generator. We don't have a complete solution in mind but
> writing Sphinx like the RTEMS documentation is an option. One challenge
> is that the current HTML output has filtering capabilit

Re: want to contribute to project

2018-03-14 Thread Joel Sherrill

On Wed, Mar 14, 2018 at 4:49 PM, Cillian O'Donnell 
wrote:

> The covoar fixes made it in but all the python stuff never made it in
> because of outstanding issues in the open project page, so to see it
> working, it'll have to be from the old github until the terms tester stuff
> gets merged.
>

OK. Start a new thread to ping Chris and I on. We will need to figure out
where
things stand and what barriers remain to merging it.

At the least, your work needs to be rebaselined against the current master.
Probably not too bad.

--joel


>
> On Wed, 14 Mar 2018, 21:33 Joel Sherrill,  wrote:
>
>>
>>
>> On Wed, Mar 14, 2018 at 4:13 PM, Cillian O'Donnell > > wrote:
>>
>>>
>>>
>>> On 14 March 2018 at 19:51, Cillian O'Donnell 
>>> wrote:
>>>


 On 14 March 2018 at 18:26, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> I'm still getting the Covoar not found error
> I'm not able to understand what am I missing, if it needs a
> fix, please help me understand the code.
>

 Have a look where all the rsb tools were built. Does covoar appear in
 there?

 The directory is something like:

 cd  ~/development/rtems/4.12/bin

>>>
>>> Sorry, nevermind that, just remenbered I had  put covoar there for
>>> something else.
>>>
>>> You mentioned before that waf built covoar properly and it appeared in:
>>>
>>> "covoar is in /rtems-tools/build/covoar"
>>>
>>> is it this or is it rtems-tools/build/tester/covoar
>>>
>>> and you're definitely using the coverage-merge branch of my github
>>>
>>> https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge
>>>
>>
>> It shouldn't matter much but I think we merged all your changes. If not,
>> we want to
>> fix that. Hopefully he can use the main rtems-tools.
>>
>> --joel
>>
>>
>>>
> Thanks
>
> On 9 March 2018 at 22:20, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>>
>>
>> On 9 Mar 2018 10:15 p.m., "Vijay Kumar Banerjee" <
>> vijaykumar9...@gmail.com> wrote:
>>
>>
>>
>> On 9 Mar 2018 3:34 a.m., "Joel Sherrill" 
>> wrote:
>>
>>
>>
>> On Sun, Mar 4, 2018 at 4:52 AM, Cillian O'Donnell <
>> cpodonne...@gmail.com> wrote:
>>
>>>
>>>
>>> On 3 March 2018 at 22:18, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 Hello sir,

 I need some guidance to proceed to apply for #2920 as my GSoC
 project.

 I wanted to know the following points :

  1. What are the prerequisites (do I have to produce something
 ? like the hello world )

>>>
>>> Other than the hello world, there's no official prerequisites.
>>> Usually the next thing is to fix a small bug, have a look at the tickets
>>> here:
>>>
>>> https://devel.rtems.org/query
>>>
>>>
  2. reference materials (like specific doc), to familiarise with
 the rtems-tester and rsb .

>>>
>>> Relevant to you would be RTEMS Tester section of the main user
>>> manual. The rest of the manual should be useful for setting up rtems in
>>> general.
>>>
>>> https://docs.rtems.org/branches/master/user/tools/tester.html
>>>
>>
>> Running this and submitting some results for a BSP on a simulator
>> would be a good step.
>> This project requires doing that a lot.  You can do one BSP that runs
>> on a gdb based simulator
>> and another on a qemu based simulator.
>>
>> I'll surely do that . currently I'm trying to run cillian's project ,
>> facing some issues with the test.py , which I'll try to fix , probably 
>> it's
>> related to the path . I'll be at the other part of the country for a  few
>> days (4 days ), after that I'll try to submit results for a BSP on a
>> simulator
>>
>> There is a project based on qemu that includes coverage trace ability.
>>
>>
>>>
>>> The links to the previous projects which you already found and the
>>> other links I've mentioned.
>>>
>>>
  3. how to properly plan the project into phase wise tasks and
 weekly sub-tasks.

>>>
>>> Essentially it would be:
>>> 1. Get coverage analysis running again (converting the config files
>>> to .ini and a couple of fixes to some of the parsing in the sections 
>>> that
>>> haven't been integrated, might be all that it takes).
>>> 2. Then get the coverage tools integrated with RTEMS Tester. Which
>>> is fix the outstanding issues that are mentioned in:
>>> https://devel.rtems.org/ticket/2920
>>> Chris Johns might have things to add to this, ultimately the
>>> integration to RTEMS Tester will be up to him.
>>>
>>
>> I would add finishing getting the Couverture qemu into the RSB.
>>
>> Okay sir.
>>
>>
>> Once the setup is running, there are a couple o

Re: want to contribute to project

2018-03-14 Thread Chris Johns

On 15/03/2018 08:56, Joel Sherrill wrote:
> On Wed, Mar 14, 2018 at 4:49 PM, Cillian O'Donnell  > wrote:
> The covoar fixes made it in but all the python stuff never made it in
> because of outstanding issues in the open project page, so to see it
> working, it'll have to be from the old github until the terms tester stuff
> gets merged.

Is there a link to the page with the details?

> OK. Start a new thread to ping Chris and I on. We will need to figure out 
> where
> things stand and what barriers remain to merging it.

Watching :)

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] libfs/jffs2: Force the inode size to a non-zero value if a directory.

2018-03-14 Thread Chris Johns

On 14/03/2018 17:53, Sebastian Huber wrote:
> On 13/03/18 22:45, Chris Johns wrote:
>> On 13/03/2018 17:52, Sebastian Huber wrote:
>>> On 13/03/18 07:50, Sebastian Huber wrote:
 On 13/03/18 07:47, Chris Johns wrote:
> On 13/03/2018 17:18, Sebastian Huber wrote:
>> On 13/03/18 00:49, Chris Johns wrote:
>>> Set the inode size to 256 to work around a newlib scandir check where a
>>> directory has to have a non-zero size to work. Set the size to greater 
>>> than
>>> 24 bytes, a small dirent size so the allocator in scandir works.
>>>
>>> The newlib scandir code should be updated to a more recent scandir from
>>> FreeBSD where these checks have been removed. This change is a work
>>> around to avoid new tools on the release branch.
>>>
>>> With this change scandir works on IMFS, RFS and JFFS2.
>> I cannot find a scandir() test in the fstests for all file systems.
>>
>>> Closes #3332
>>> ---
>>>     cpukit/libfs/src/jffs2/src/fs-rtems.c | 3 +++
>>>     1 file changed, 3 insertions(+)
>>>
>>> diff --git a/cpukit/libfs/src/jffs2/src/fs-rtems.c
>>> b/cpukit/libfs/src/jffs2/src/fs-rtems.c
>>> index ce84d44470..790929d856 100644
>>> --- a/cpukit/libfs/src/jffs2/src/fs-rtems.c
>>> +++ b/cpukit/libfs/src/jffs2/src/fs-rtems.c
>>> @@ -1512,6 +1512,9 @@ static int jffs2_read_inode (struct _inode *inode)
>>>     inode->i_mtime = je32_to_cpu(latest_node.mtime);
>>>     inode->i_ctime = je32_to_cpu(latest_node.ctime);
>>>     +    if (S_ISDIR(inode->i_mode))
>>> +    inode->i_size = 256;
>>> +
>>>     inode->i_nlink = f->inocache->pino_nlink;
>>>     mutex_unlock(&f->sem);
>> This code is from the original JFFS2 support for eCos. Which 
>> side-effects has
>> this i_size change for directories? Why can't you place this hack in
>> rtems_jffs2_fstat()? This would reduce the impact area of this change.
>>
> I did not know the history of the RTEMS wrapper. I just assumed all code 
> in
> that
> file is specific to RTEMS. The change I have makes things consistent. I 
> still
> think it is OK?
 What do you mean with consistent?
>> The function being patched is internal to `fs-rtems.c` which is a wrapper for
>> JFFS2. The consistent comment I made referred to any reference to the inode 
>> had
>> the same value exported to RTEMS, ie consistent.
>>
>> The code may have come from ecos and if ecos is using newlib with scandir 
>> they
>> have the same problem. I do not consider ecos as being upstream, rather this
>> code has been taken 'as was' (?).
>>
>>> I thought this is a hack to make the Newlib scandir() happy?
>> The issue is clearly in scandir. FreeBSD these days and glibc do not stat the
>> directory for it's size, OpenSolaris still does. The proper fix is to 
>> scandir.
>>
>> Fixing scandir requires a newlib patch and that means an update to the RSB. 
>> If
>> this is preferred please say, it however is a lot more work so I am 
>> reluctant to
>> do this, I do not have the time.
>>
>> I have coded around the scandir issue with opendir and readdir and I suspect
>> there are a number of cases of this happening. I have seen at least one other
>> case and wondered at the time why opendir etc was being used instead of 
>> scandir.
> 
> Then we should open a new ticket for the scandir() problem in Newlib and
> reference this ticket in the workaround. Once Newlib is fixed we can remove 
> the
> workaround.
> 

I was not planning on this fix for 5 just 4.11 and I do not think we will be
changing newlib on that release branch.

>>
>>> This i_size is used in several places. How do you know that
 you didn't accidentally broke something?
>> The only thing I can think of is reading a directory as a file and a 0 means 
>> do
>> not read. That does not seem to be a problem with the patch, I can cat a
>> directory and get the same sort of rubbish I get when doing this on any other
>> host which implies the directory as a file does have a size. If I remove the
>> patch the cat of the same directory gives the same result and that would 
>> imply
>> something else is wrong or inconsistent so who knows if what we have there is
>> correct.
> 
> If you read() from a directory, then you get a stream of struct dirent items,
> see rtems_jffs2_dir_read().
> 

Thank, that makes sense, I have not looked into it.

>>
>> The size of a directory is file system specific so I would say any code that
>> assumes anything is file system specific and fragile and the scandir issue 
>> would
>> seem to support this. I have built a large application which uses the JFFS2
>> heavily for application installing and management with many files and I see 
>> no
>> issue. I have no other test results to say otherwise.
> 
> Ok, I have difficulties to understand from the source code, why the i_size
> change has no impact on the internal file system operation:

Because for

Re: POSIX Headers Not in Newlib

2018-03-14 Thread Chris Johns

On 15/03/2018 01:22, Joel Sherrill wrote:
> We have the POSIX headers dlfcn.h and mqueue.h in RTEMS. I think they are the
> only POSIX .h files not in newlib..
> 
> Should we migrate them to newlib?

I think it makes sense too.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: POSIX Headers Not in Newlib

2018-03-14 Thread Joel Sherrill

On Wed, Mar 14, 2018 at 6:08 PM, Chris Johns  wrote:

> On 15/03/2018 01:22, Joel Sherrill wrote:
> > We have the POSIX headers dlfcn.h and mqueue.h in RTEMS. I think they
> are the
> > only POSIX .h files not in newlib..
> >
> > Should we migrate them to newlib?
>
> I think it makes sense too.
>

Unfortunately, I found two pthread methods which had incorrect
prototypes per POSIX.  If we want to add these headers to newlib
and fix these prototypes, we should do it on one tool bump.

Assuming the .h files are only dependent on other POSIX h files. :)

What's the consensus?

--joel

>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: want to contribute to project

2018-03-14 Thread Vijay Kumar Banerjee

On 15 March 2018 at 02:43, Cillian O'Donnell  wrote:

>
>
> On 14 March 2018 at 19:51, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On 14 March 2018 at 18:26, Vijay Kumar Banerjee > > wrote:
>>
>>> I'm still getting the Covoar not found error
>>> I'm not able to understand what am I missing, if it needs a fix, please
>>> help me understand the code.
>>>
>>
>> Have a look where all the rsb tools were built. Does covoar appear in
>> there?
>>
>> The directory is something like:
>>
>> cd  ~/development/rtems/4.12/bin
>>
>
> Sorry, nevermind that, just remenbered I had  put covoar there for
> something else.
>
> You mentioned before that waf built covoar properly and it appeared in:
>
> "covoar is in /rtems-tools/build/covoar"
>
> is it this or is it rtems-tools/build/tester/covoar
>
it is rtems-tools/build/tester/covoar

>
> and you're definitely using the coverage-merge branch of my github
>
yes.

> https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge
>
>>
>>> Thanks
>>>
>>> On 9 March 2018 at 22:20, Vijay Kumar Banerjee >> > wrote:
>>>

 On 9 Mar 2018 10:15 p.m., "Vijay Kumar Banerjee" <
 vijaykumar9...@gmail.com> wrote:

 On 9 Mar 2018 3:34 a.m., "Joel Sherrill" 
 wrote:

 On Sun, Mar 4, 2018 at 4:52 AM, Cillian O'Donnell <
 cpodonne...@gmail.com> wrote:

>
>
> On 3 March 2018 at 22:18, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Hello sir,
>>
>> I need some guidance to proceed to apply for #2920 as my GSoC project.
>>
>> I wanted to know the following points :
>>
>>  1. What are the prerequisites (do I have to produce something ? like
>> the hello world )
>>
>
> Other than the hello world, there's no official prerequisites. Usually
> the next thing is to fix a small bug, have a look at the tickets here:
>
> https://devel.rtems.org/query
>
>
>>  2. reference materials (like specific doc), to familiarise with the
>> rtems-tester and rsb .
>>
>
> Relevant to you would be RTEMS Tester section of the main user manual.
> The rest of the manual should be useful for setting up rtems in general.
>
> https://docs.rtems.org/branches/master/user/tools/tester.html
>

 Running this and submitting some results for a BSP on a simulator would
 be a good step.
 This project requires doing that a lot.  You can do one BSP that runs
 on a gdb based simulator
 and another on a qemu based simulator.

 I'll surely do that . currently I'm trying to run cillian's project ,
 facing some issues with the test.py , which I'll try to fix , probably it's
 related to the path . I'll be at the other part of the country for a  few
 days (4 days ), after that I'll try to submit results for a BSP on a
 simulator

 There is a project based on qemu that includes coverage trace ability.

>
> The links to the previous projects which you already found and the
> other links I've mentioned.
>
>
>>  3. how to properly plan the project into phase wise tasks and weekly
>> sub-tasks.
>>
>
> Essentially it would be:
> 1. Get coverage analysis running again (converting the config files to
> .ini and a couple of fixes to some of the parsing in the sections that
> haven't been integrated, might be all that it takes).
> 2. Then get the coverage tools integrated with RTEMS Tester. Which is
> fix the outstanding issues that are mentioned in:
> https://devel.rtems.org/ticket/2920
> Chris Johns might have things to add to this, ultimately the
> integration to RTEMS Tester will be up to him.
>

 I would add finishing getting the Couverture qemu into the RSB.

 Okay sir.

 Once the setup is running, there are a couple of meaty projects.

 Chris and I have talked about reworking the report generation in
 covoar.
 Currently, the C++ code writes HTML and txt files.  It would be nice to
 have covoar generate something which is subsequently processed
 with a report generator. We don't have a complete solution in mind but
 writing Sphinx like the RTEMS documentation is an option. One challenge
 is that the current HTML output has filtering capability and that
 wouldn't
 be possible (I think) using Sphinx.

 The other desirable capability is to ensure the gcov output is correct
 and
 can be processed by the GNU gcov tool to produce reports with the same
 results as covoar. I think Cillian got a start on this but only as far
 as noting
 it wasn't always the same. We have a mentor from the GCC community
 to help with this.

 Once the gcov output is trustworthy, we can try other tools like lcov to
 see what other reports we can get.

 Thank you for describing the object in detail , I'll read more about

Re: want to contribute to project

2018-03-14 Thread Vijay Kumar Banerjee

Okay , I'll start a new thread as told by Joel .

On 15 March 2018 at 03:26, Joel Sherrill  wrote:

>
>
> On Wed, Mar 14, 2018 at 4:49 PM, Cillian O'Donnell 
> wrote:
>
>> The covoar fixes made it in but all the python stuff never made it in
>> because of outstanding issues in the open project page, so to see it
>> working, it'll have to be from the old github until the terms tester stuff
>> gets merged.
>>
>
> OK. Start a new thread to ping Chris and I on. We will need to figure out
> where
> things stand and what barriers remain to merging it.
>
> At the least, your work needs to be rebaselined against the current master.
> Probably not too bad.
>
> --joel
>
>
>>
>> On Wed, 14 Mar 2018, 21:33 Joel Sherrill,  wrote:
>>
>>>
>>>
>>> On Wed, Mar 14, 2018 at 4:13 PM, Cillian O'Donnell <
>>> cpodonne...@gmail.com> wrote:
>>>


 On 14 March 2018 at 19:51, Cillian O'Donnell 
 wrote:

>
>
> On 14 March 2018 at 18:26, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> I'm still getting the Covoar not found error
>> I'm not able to understand what am I missing, if it needs a
>> fix, please help me understand the code.
>>
>
> Have a look where all the rsb tools were built. Does covoar appear in
> there?
>
> The directory is something like:
>
> cd  ~/development/rtems/4.12/bin
>

 Sorry, nevermind that, just remenbered I had  put covoar there for
 something else.

 You mentioned before that waf built covoar properly and it appeared in:

 "covoar is in /rtems-tools/build/covoar"

 is it this or is it rtems-tools/build/tester/covoar

 and you're definitely using the coverage-merge branch of my github

 https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge

>>>
>>> It shouldn't matter much but I think we merged all your changes. If not,
>>> we want to
>>> fix that. Hopefully he can use the main rtems-tools.
>>>
>>> --joel
>>>
>>>

>> Thanks
>>
>> On 9 March 2018 at 22:20, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>>
>>> On 9 Mar 2018 10:15 p.m., "Vijay Kumar Banerjee" <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>
>>>
>>> On 9 Mar 2018 3:34 a.m., "Joel Sherrill" 
>>> wrote:
>>>
>>>
>>>
>>> On Sun, Mar 4, 2018 at 4:52 AM, Cillian O'Donnell <
>>> cpodonne...@gmail.com> wrote:
>>>


 On 3 March 2018 at 22:18, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> Hello sir,
>
> I need some guidance to proceed to apply for #2920 as my GSoC
> project.
>
> I wanted to know the following points :
>
>  1. What are the prerequisites (do I have to produce something
> ? like the hello world )
>

 Other than the hello world, there's no official prerequisites.
 Usually the next thing is to fix a small bug, have a look at the 
 tickets
 here:

 https://devel.rtems.org/query


>  2. reference materials (like specific doc), to familiarise with
> the rtems-tester and rsb .
>

 Relevant to you would be RTEMS Tester section of the main user
 manual. The rest of the manual should be useful for setting up rtems in
 general.

 https://docs.rtems.org/branches/master/user/tools/tester.html

>>>
>>> Running this and submitting some results for a BSP on a simulator
>>> would be a good step.
>>> This project requires doing that a lot.  You can do one BSP that
>>> runs on a gdb based simulator
>>> and another on a qemu based simulator.
>>>
>>> I'll surely do that . currently I'm trying to run cillian's project
>>> , facing some issues with the test.py , which I'll try to fix , probably
>>> it's related to the path . I'll be at the other part of the country for 
>>> a
>>>  few days (4 days ), after that I'll try to submit results for a BSP on 
>>> a
>>> simulator
>>>
>>> There is a project based on qemu that includes coverage trace
>>> ability.
>>>
>>>

 The links to the previous projects which you already found and the
 other links I've mentioned.


>  3. how to properly plan the project into phase wise tasks and
> weekly sub-tasks.
>

 Essentially it would be:
 1. Get coverage analysis running again (converting the config files
 to .ini and a couple of fixes to some of the parsing in the sections 
 that
 haven't been integrated, might be all that it takes).
 2. Then get the coverage tools integrated with RTEMS Tester. Which
 is fix the outstanding issues that are mentioned in:
 https://devel.rt

Improve coverage analysis toolset

2018-03-14 Thread Vijay Kumar Banerjee

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 !"

the Covoar appeared in rtems-tools/tester/covoar .

-- 

Vijay
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Added Getentropy() support to beagle BSP

2018-03-14 Thread Udit agarwal

Hi,
Below is the updated patch along with the one for atsam. Please have a look.
Moreover, in error case(FRO unwanted shutdown), Error bit of status
register turns zero, indicating that FRO is no longer running.Untill now, i
haven't came across any situation where this bit turns 0. In the NETBSD

and in linux kernel

(line 241 ) implementation of am335x_trng, it seems they aren't checking
for this bit. Instead they are only using RNG_STATUS_RDY as an indication
of successful random data generation.

*Patch: atsam*

>From ae0c79ae4850503259c64387dea69346e7d7b1d4 Mon Sep 17 00:00:00 2001
From: Udit agarwal 
Date: Thu, 15 Mar 2018 09:43:13 +0530
Subject: [PATCH] Fixed mutual exclusion of critical section

---
 c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c | 6 ++
 1 file changed, 6 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..b26b6a8 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,8 @@
 #include 
 #include 

+static rtems_mutex atsam_trng_reg =
RTEMS_MUTEX_INITIALIZER("atsam_trng_reg");
+
 static void atsam_trng_enable(void)
 {
 PMC_EnablePeripheral(ID_TRNG);
@@ -29,9 +31,12 @@ int getentropy(void *ptr, size_t n)
 uint32_t random;
 size_t copy;

+rtems_mutex_lock(&atsam_trng_reg);
 while ((TRNG_GetStatus() & TRNG_ISR_DATRDY) == 0) {
 /* wait */
 }
+
+rtems_mutex_unlock(&atsam_trng_reg);
 random = TRNG_GetRandData();

 /*
@@ -51,6 +56,7 @@ int getentropy(void *ptr, size_t n)
 ptr += copy;
 }

+rtems_mutex_destroy(&atsam_trng_reg);
 return 0;
 }

-- 
1.9.1

*Patch BBB*

>From ea885f9681c14f324917469b295e7489f56c10e7 Mon Sep 17 00:00:00 2001
From: Udit agarwal 
Date: Thu, 15 Mar 2018 09:24:35 +0530
Subject: [PATCH] Added getentropy support to beagle BSP

---
 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 | 126
+++
 3 files changed, 162 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..6170ef3 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 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 Register */
+
+/* RNG base address */
+#define RNG_BASE 0x4831
+/* RNG clock control */
+#define CM_PER_RNG_CLKCTRL (AM335X_CM_PER_ADDR | (9 << 4))
+/* rng module clock status bits */
+#define AM335X_CLK_RNG_BIT_MASK (0x3)
+/* Offset from RNG base for output ready flag */
+#define RNG_STATUS_RDY (1u <<  0)
+/* Offset from RNG base for FRO related error */
+#define RNG_STATUS_ERR (1u <<  1)
+/* Offset from RNG base for clock status */
+#define RNG_STATUS_CLK (1u << 31)
+/* enable module */
+#define AM335X_RNG_ENABLE (1 << 10)
+
+/* 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.

Re: [PATCH] Added Getentropy() support to beagle BSP

2018-03-14 Thread Sebastian Huber




On 15/03/18 05:56, Udit agarwal wrote:

 c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c | 6 ++
 1 file changed, 6 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..b26b6a8 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,8 @@
 #include 
 #include 

+static rtems_mutex atsam_trng_reg = 
RTEMS_MUTEX_INITIALIZER("atsam_trng_reg");


Is this a register or a mutex?


+
 static void atsam_trng_enable(void)
 {
 PMC_EnablePeripheral(ID_TRNG);
@@ -29,9 +31,12 @@ int getentropy(void *ptr, size_t n)
     uint32_t random;
     size_t copy;

+        rtems_mutex_lock(&atsam_trng_reg);
     while ((TRNG_GetStatus() & TRNG_ISR_DATRDY) == 0) {
         /* wait */
     }
+
+        rtems_mutex_unlock(&atsam_trng_reg);


Now the status register read is protected by a mutex.


    random = TRNG_GetRandData();


Can you ensure that this read is correct in a multi-threaded application 
(the status register has the right value during the read)?




     /*
@@ -51,6 +56,7 @@ int getentropy(void *ptr, size_t n)
     ptr += copy;
 }

+    rtems_mutex_destroy(&atsam_trng_reg);


Here  you destroy the mutex. What happens if you call getentropy() a 
second time?



return 0;
 }


--
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

2018-03-14 Thread Sebastian Huber




On 15/03/18 05:56, Udit agarwal wrote:

+/* TRNG Register */
+
+/* RNG base address */


Is the module name TRNG or RNG?


+#define RNG_BASE 0x4831
+/* RNG clock control */
+#define CM_PER_RNG_CLKCTRL (AM335X_CM_PER_ADDR | (9 << 4))


This define is probably not for the TRNG register block. Should it move 
the corresponding register block?



+/* rng module clock status bits */
+#define AM335X_CLK_RNG_BIT_MASK (0x3)
+/* Offset from RNG base for output ready flag */
+#define RNG_STATUS_RDY (1u <<  0)
+/* Offset from RNG base for FRO related error */
+#define RNG_STATUS_ERR (1u <<  1)
+/* Offset from RNG base for clock status */
+#define RNG_STATUS_CLK (1u << 31)


Are these offsets or bits?


+/* enable module */
+#define AM335X_RNG_ENABLE (1 << 10)
+


--
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

37 matches

Mail list logo