BSD APIs supported by RTEMS?

2018-03-13 Thread Joel Sherrill 
Hi

I have been working on updating the POSIX Compliance Guide for RTEMS. The
current guide has evaluations of RTEMS versus two versions of POSIX, COO,
C11, and an assortment of POSIX profiles.

What BSD specific APIs beyond POSIX does RTEMS support? I would like to
make the API list as complete as possible.

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

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

2018-03-13 Thread 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.

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");

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(_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(_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, , copy);
n -= copy;
ptr = (char*)ptr + copy;
}
}

rtems_mutex_destroy(_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"  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 >
>>
>> 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/ge
>> tentropy/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  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  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_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 (Beagle Bone Black) is a particular board and the AM335X is a SoC
> family. This should be something like this
>
> typedef struct {
>  ...
> } am335x_trng;
>
>
> +
>> +#endif
>> \ No newline at end of file
>>
>
> Git thinks that files should have a newline at the end of the file.
>
>
> diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am
>> b/c/src/lib/libbsp/arm/beagle/Makefile.am
>> index 8251660..5d5ade3 100644
>> ---

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

2018-03-13 Thread Chris Johns 
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?

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-13 Thread Chris Johns 
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(>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.

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

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.

>>
> 
> We have also this comment:
> 
> struct _inode {
>     cyg_uint32        i_ino;
> 
>     int            i_count;
>     mode_t            i_mode;
>     nlink_t            i_nlink; // Could we dispense with this?
>     uid_t            i_uid;
>     gid_t            i_gid;
>     time_t            i_atime;
>     time_t            i_mtime;
>     time_t            i_ctime;
> //    union {
>         unsigned short    i_rdev; // For devices only
>         struct _inode *    i_parent; // For directories only
>         off_t        i_size; // For files only

Is that a requirement or an observation?

It could be related to the implementation and there not being a need to set this
field for a directory so it never was, ie non-data nodes ...

https://git.rtems.org/rtems/tree/cpukit/libfs/src/jffs2/src/readinode.c#n1207

> //    };
>     struct super_block *    i_sb;
>     struct jffs2_full_dirent * i_fd;
> 
>     struct jffs2_inode_info  

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

2018-03-13 Thread Joel Sherrill 
On Mar 13, 2018 1:31 AM, "Sebastian Huber" <
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 >
>
> 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/ge
> tentropy/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 (Beagle Bone Black) is a particular board and the AM335X is a SoC
family. This should be something like this

typedef struct {
 ...
} am335x_trng;


+
> +#endif
> \ No newline at end of file
>

Git thinks that files should have a newline at the end of the file.


diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am
> b/c/src/lib/libbsp/arm/beagle/Makefile.am
> index 8251660..5d5ade3 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 += getentropy/bbb_getentropy.c
> +
>

With the new BSP source structure

https://devel.rtems.org/ticket/3285

this new file could be also placed at

bsps/arm/beagle/dev/getentropy.c


Is this specific to the Beagle or the SoC? Or a combination? Earlier you
said the structure was SoC specific?


[...]
>
> +int getentropy(void *ptr, size_t n)
> +{
> +volatile bbb_trng_register  *rng = (bbb_trng_register*) RNG_BASE;
> +am335x_rng_enable(rng);
> +while (n > 0)
> +{
> +uint64_t random;
> +size_t copy;
> +
> +/* wait untill RNG becomes ready with next set of random data */
> +while( ( rng->status & RNG_STATUS_RDY ) == 0 )
> +{
> +/* wait */
> +}
>

What happens if you call this function in parallel on different processors?

+
> +random = trng_getranddata(rng);
> +
> +/* Checking for error by masking all bits other then error bit in
> +   status register */
> +if( ((rng->status & RNG_STATUS_ERR)>>1) == 1)
> +{
> +/* clear the status flag after reading to generate new random
>

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

2018-03-13 Thread Christian Mauderer 
Am 13.03.2018 um 15:59 schrieb Udit agarwal:
> Hi,
> I have updated the patch, following were the changes:
> *Removed trialling white spaces and added new line at the end of each file
> *am335x_rng_enable() is now being called only once during initialization.
> *changed  directory to /arm/beagle/dev/bbb_getentropy.c
> *Renamed TRNG register structure as: am335x_trng_register 
> I have tested the patch after making above changes and it worked as before.
> 
> I need some suggestion regarding the solution to the problem raised
> during parallel execution of getentropy(),
> In that case, Two processes can actually fetch same random number. I was
> thinking to implement some sort of
> flag set/reset variable in shared memory, which can be used to implement
> a lock for TRNG register access something
> like a binary semaphore.

Hello Udit,

seems to be a small trick question from Sebastian: The processor family
only has single cores. But the problem can occur there too: If a high
prio task interrupts a lower prio task while it is waiting for the flag,
the two tasks might get the same value.

If you protect the critical section with a mutex, that should fix it.
One of the self contained mutexes should be usable here:
https://docs.rtems.org/branches/master/c-user/self_contained_objects.html#mutual-exclusion

By the way: That bug exists on the ATSAM too.

Best regards

Christian Mauderer

> 
> From b10e55c7f5cc8ca95b0d9b6a8cc7b8e37330544b Mon Sep 17 00:00:00 2001
> From: Udit agarwal >
> Date: Tue, 13 Mar 2018 15:50:43 +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 | 117
> +++
>  3 files changed, 153 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.c
> b/c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
> new file mode 100644
> index 000..b2aea71
> --- /dev/null
> +++ b/c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
> @@ -0,0 +1,117 @@
> +/**
> +* @file
> +*
> +*

Re: GSoC 2018 (x86_64, pc386, SMP improvements, rump kernels)

2018-03-13 Thread Amaan Cheval 
I like the sound of that! One quick question.

> ...to get it running on qemu. Real HW would be a sanity check.

What kind of real hardware would I need? I do have an x86 64-bit processor
as my primary computer, and likely one on spare / abandoned devices too
(though I'll need to confirm). Is there anything specific that you foresee
me needing to check to confirm they'll be good enough for the purposes of
this project (besides UEFI)?

I also vaguely remember OAR hosting a lab with a bunch of development
boards; does the lab have x86_64 hardware?

On Tue, Mar 13, 2018 at 2:04 AM Joel Sherrill  wrote:



> On Mon, Mar 12, 2018 at 3:20 PM, Gedare Bloom  wrote:

>> On Mon, Mar 12, 2018 at 12:41 PM, Amaan Cheval 
wrote:
>> > On Mon, Mar 12, 2018 at 9:53 PM Gedare Bloom  wrote:
>> >
>> >> On Mon, Mar 12, 2018 at 3:01 AM, Sebastian Huber
>> >>  wrote:
>> >> > On 10/03/18 18:02, Amaan Cheval wrote:
>> >> >>
>> >> >> - Improve RTEMS SMP[3]
>> >> >>
>> >> >> What kinds of improvements to SMP are we considering?
>> >> >
>> >> >
>> >> > The SMP support is quite complete now. In general, an independent
>> > review is
>> >> > required, but this is probably not a GSoC project. Some areas in the
>> >> > implementation are a bit too complex (e.g. thread lock) and should
be
>> >> > simplified, however, I guess this is a very difficult task.
>> >> >
>> >> > A formal specification using TLA+ for the OMIP and MrsP locking
>> > protocols
>> >> > would be nice.
>> >> >
>> >> > https://en.wikipedia.org/wiki/TLA%2B
>> >> >
>> >> > A proper strong APA scheduler:
>> >> >
>> >> > https://devel.rtems.org/ticket/2510
>> >> >
>> >> > I am not sure if there is a real application demand for this.
>> >> >
>> >
>> >> I would be supportive of formal specification or strong APA projects
>> >> despite user demand.
>> >
>> > That's good to know! I'll look into it! :)
>> >
>> >
>> >> >> As noted earlier, SMP
>> >> >> support on i386 is lagging. Is there any interest in bringing that
up
>> > to
>> >> >> par with the other architectures?
>> >> >
>> >> >
>> >> > I think this makes only sense for a x86_64 BSP.
>> >> >
>> >
>> >> There is a need for a modernized framework for x86 and x86_64. Both
>> >> projects are relevant and important.
>> >
>> > That's good to know. I haven't been able to quite tease the 2 projects
>> > apart; for eg. it seems the x86_64 BSP would also be based on
non-legacy
>> > hardware (UEFI vs. BIOS?), so it would be tied to improving the
existing
>> > PC386 code as well.
>> >
>> > I think my main proposal will be along these lines; figuring out the
>> > essentials for the x86_64 BSP, and modernizing the existing x86 as I
can at
>> > the same time.
>> >
>> > How does that sound?
>> >

>> I think that should be appropriate. You should be able to demonstrate
>> progress on the new BSP then, while you contribute code to the old
>> one.


> When Chris and I have discussed this in the past, we have tossed around
> the idea of a new port -- x86_64,. a true 64-bit port. It would have a new
> BSP that would not depend on legacy hardware and would boot using UEFI.

> To pace this out so it is achievable in a summer, the first steps would
> focus on the port proper and do the minimum required of a BSP to get
> it running on qemu. Real HW would be a sanity check. Focus on a port
> and minimum BSP (initialization, console, clock tick).

> Chris has suggested that the BSP could use whatever it needed from
> FreeBSD, such as UEFI support.

> Key.. new port.. new BSP.. without the legacy baggage of 32-bit and old
HW.
> More work but a much better result in the long run.



>> > Since I'm pretty keen on RTEMS, I think I'll have a 2nd proposal too,
which
>> > I'll decide and discuss with you guys soon, hopefully! (Perhaps the
tracing
>> > or the APA scheduling projects).
>> >

>> That's fine.  I don't think APA by itself is enough for the summer.

>> >
>> >> > From an application developer point of view a ready to use tracing
of
>> > thread
>> >> > context switches and interrupts would be nice. Some kind of data
>> > provider
>> >> > for the lttng-relayd (LTTng 2 relay daemon)
>> >> >
>> >> > https://lttng.org/docs/v2.10/#doc-lttng-relayd
>> >> >
>> >> > Which can be used by
>> >> >
>> >> > https://projects.eclipse.org/projects/tools.tracecompass
>> >> >
>> >
>> >> Joel has been looking at the trace compass. We also have other tracing
>> >> projects (barectf integration) that would be relevant to investigate
>> >> along those same lines.
>> >
>> >> > --
>> >> > 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.
>> >> >

[PATCH v2 3/3] i386/smp: Export _CPU_SMP_Prepare_start_multitasking as a function

2018-03-13 Thread Amaan Cheval 
When it's a macro, a function declaration causes a compiler error due to the
macro being expanded.

Partial log showing error:
https://gist.github.com/AmaanC/ab3521141479aa6f61ea25f5d74ebb4d

Closes #3331
---
 c/src/lib/libbsp/i386/shared/smp/smp-imps.c | 5 +
 cpukit/score/cpu/i386/include/rtems/score/cpu.h | 3 +--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/c/src/lib/libbsp/i386/shared/smp/smp-imps.c 
b/c/src/lib/libbsp/i386/shared/smp/smp-imps.c
index 1ed504ccf9..2ba36804cb 100644
--- a/c/src/lib/libbsp/i386/shared/smp/smp-imps.c
+++ b/c/src/lib/libbsp/i386/shared/smp/smp-imps.c
@@ -804,6 +804,11 @@ uint32_t _CPU_SMP_Initialize( void )
   return (uint32_t) imps_probe();
 }
 
+void _CPU_SMP_Prepare_start_multitasking( void )
+{
+  /* Do nothing */
+}
+
 bool _CPU_SMP_Start_processor( uint32_t cpu_index )
 {
   (void) cpu_index;
diff --git a/cpukit/score/cpu/i386/include/rtems/score/cpu.h 
b/cpukit/score/cpu/i386/include/rtems/score/cpu.h
index 364bba765a..d8f89f6397 100644
--- a/cpukit/score/cpu/i386/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/i386/include/rtems/score/cpu.h
@@ -470,8 +470,7 @@ void _CPU_Context_Initialize(
 
   void _CPU_SMP_Finalize_initialization( uint32_t cpu_count );
 
-  /* Nothing to do */
-  #define _CPU_SMP_Prepare_start_multitasking() do { } while ( 0 )
+  void _CPU_SMP_Prepare_start_multitasking( void );
 
   uint32_t _CPU_SMP_Get_current_processor( void );
 
-- 
2.13.0

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

[PATCH v2 2/3] i386/smp: Have ld use incremental build for appstart.o

2018-03-13 Thread Amaan Cheval 
With HAS_SMP set, we have:

  libbsp_a_LIBADD += appstart.$(OBJEXT)

When trying to build appstart.o, however, we link start.o with appcpustart.o
through the linkcmds script, which leaves several symbols unresolved, and
without the "-r" (or -i) flag, this throws undefined reference errors.

This change requires us to re-run the ./bootstrap script to regenerate
Makefile.in, and therefore the Makefile for the particular BSP as well.

Complete log of errors available here:
https://gist.github.com/AmaanC/d40bd7393dca1f82965938275845b7f9

Updates #3331
---
 c/src/lib/libbsp/i386/pc386/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/c/src/lib/libbsp/i386/pc386/Makefile.am 
b/c/src/lib/libbsp/i386/pc386/Makefile.am
index 0acce55c44..a8b469120b 100644
--- a/c/src/lib/libbsp/i386/pc386/Makefile.am
+++ b/c/src/lib/libbsp/i386/pc386/Makefile.am
@@ -154,7 +154,7 @@ appcpustart.$(OBJEXT): start/start16.S
$(CPPASCOMPILE) $(AM_CPPFLAGS) -DSMP_SECONDARY_CORE -o $@ -c $<
 
 appstart.$(OBJEXT): appcpustart.$(OBJEXT)
-   $(LD) -N -T $(top_srcdir)/startup/linkcmds \
+   $(LD) -r -N -T $(top_srcdir)/startup/linkcmds \
-Ttext 0x7 -e app_processor_start -nostdlib \
-o appstart_tmp.exe $<
$(OBJCOPY) -O binary appstart_tmp.exe appstart.bin
-- 
2.13.0

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

[PATCH v2 1/3] i386/smp: Define CPU_Interrupt_frame as non-void struct

2018-03-13 Thread Amaan Cheval 
This change, excluding the #error directive, lets us make progress towards
compiling i386 targets with --enable-smp.

The #error directive needs to be there since the CPU_Interrupt_frame is used by
the SMP context switching code, and this placeholder struct, if used, would only
lead to more subtle bugs and errors. With the directive, the SMP context
switching code can be improved separately.

Updates #3331
---
 cpukit/score/cpu/i386/include/rtems/score/cpu.h | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/cpukit/score/cpu/i386/include/rtems/score/cpu.h 
b/cpukit/score/cpu/i386/include/rtems/score/cpu.h
index f78149c24b..364bba765a 100644
--- a/cpukit/score/cpu/i386/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/i386/include/rtems/score/cpu.h
@@ -271,12 +271,26 @@ typedef void (*cpuExcHandlerType) (CPU_Exception_frame*);
 extern cpuExcHandlerType _currentExcHandler;
 extern void rtems_exception_init_mngt(void);
 
+#ifdef RTEMS_SMP
+  /* Throw compile-time error to indicate incomplete support */
+  #error "i386 targets do not support SMP.\
+ See: https://devel.rtems.org/ticket/3335;
+
+  /*
+   * This size must match the size of the CPU_Interrupt_frame, which must be
+   * used in the SMP context switch code, which is incomplete at the moment.
+   */
+  #define CPU_INTERRUPT_FRAME_SIZE 4
+#endif
+
 /*
  * This port does not pass any frame info to the
  * interrupt handler.
  */
 
-typedef void CPU_Interrupt_frame;
+typedef struct {
+  uint32_t todo_replace_with_apt_registers;
+} CPU_Interrupt_frame;
 
 typedef enum {
   I386_EXCEPTION_DIVIDE_BY_ZERO  = 0,
-- 
2.13.0

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

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

2018-03-13 Thread Amaan Cheval 
See this thread[1] for v1 of the patch. The changes in this version
are similar, except they *still throw a compile-time error* to
indicate the missing i386 support for SMP, while still fixing up the
rest of the problems that prevented compilation, as suggested by Joel
here[2].

[1] https://lists.rtems.org/pipermail/devel/2018-March/020409.html
[2] https://lists.rtems.org/pipermail/devel/2018-March/020438.html

Amaan Cheval (3):
  i386/smp: Define CPU_Interrupt_frame as non-void struct
  i386/smp: Have ld use incremental build for appstart.o
  i386/smp: Export _CPU_SMP_Prepare_start_multitasking as a function

 c/src/lib/libbsp/i386/pc386/Makefile.am |  2 +-
 c/src/lib/libbsp/i386/shared/smp/smp-imps.c |  5 +
 cpukit/score/cpu/i386/include/rtems/score/cpu.h | 19 ---
 3 files changed, 22 insertions(+), 4 deletions(-)

-- 
2.13.0

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

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

2018-03-13 Thread Udit agarwal 
Hi,
I have updated the patch, following were the changes:
*Removed trialling white spaces and added new line at the end of each file
*am335x_rng_enable() is now being called only once during initialization.
*changed  directory to /arm/beagle/dev/bbb_getentropy.c
*Renamed TRNG register structure as: am335x_trng_register
I have tested the patch after making above changes and it worked as before.

I need some suggestion regarding the solution to the problem raised during
parallel execution of getentropy(),
In that case, Two processes can actually fetch same random number. I was
thinking to implement some sort of
flag set/reset variable in shared memory, which can be used to implement a
lock for TRNG register access something
like a binary semaphore.

>From b10e55c7f5cc8ca95b0d9b6a8cc7b8e37330544b Mon Sep 17 00:00:00 2001
From: Udit agarwal 
Date: Tue, 13 Mar 2018 15:50:43 +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 | 117
+++
 3 files changed, 153 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.c
b/c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
new file mode 100644
index 000..b2aea71
--- /dev/null
+++ b/c/src/lib/libbsp/arm/beagle/dev/bbb_getentropy.c
@@ -0,0 +1,117 @@
+/**
+* @file
+*
+* @ingroup arm_beagle
+*
+* @brief Getentropy implementation on BeagleBone Black BSP
+*/
+
+/*
+* Copyright (c) 2018 Udit agarwal 
+* All rights reserved.
+*
+* Redistribution and use in source and binary forms, with or without
+* modification, are permitted provided that the following conditions
+* are met:
+* 1. Redistributions of source code must retain the above copyright
+*notice, this list of conditions and the following disclaimer.
+* 2. Redistributions in binary form must reproduce the above copyright
+*notice, this list of conditions and the following disclaimer in the
+*documentation and/or other materials provided with the distribution.
+*
+* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE
+* ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE

Re: GSOC'18 contribution plan

2018-03-13 Thread Joel Sherrill 
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?


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

[PATCH] openssl: Provide deprecated functions.

2018-03-13 Thread Christian Mauderer 
Some applications (like the civetweb web server) still use functions
that are deprecated by openssl. If OPENSSL_NO_DEPRECATED is defined,
openssl will not provide these functions. This patch removes the define
so that the functions are available.
---
 libbsd.py | 3 +--
 libbsd_waf.py | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/libbsd.py b/libbsd.py
index f70b4ead..233c06cd 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -3614,8 +3614,7 @@ def crypto_openssl(mm):
 'crypto/openssl/crypto/cversion.c',
 'crypto/openssl/crypto/o_str.c',
 ],
-mm.generator['source'](['-DOPENSSL_NO_DEPRECATED=1',
-'-DOPENSSL_NO_EC_NISTP_64_GCC_128=1',
+mm.generator['source'](['-DOPENSSL_NO_EC_NISTP_64_GCC_128=1',
 '-DOPENSSL_NO_GMP=1',
 '-DOPENSSL_NO_JPAKE=1',
 '-DOPENSSL_NO_LIBUNBOUND=1',
diff --git a/libbsd_waf.py b/libbsd_waf.py
index 7782bccb..745512bf 100644
--- a/libbsd_waf.py
+++ b/libbsd_waf.py
@@ -1317,7 +1317,7 @@ def build(bld):
 features = "c",
 cflags = cflags,
 includes = ['freebsd/crypto', 'freebsd/crypto/openssl', 
'freebsd/crypto/openssl/crypto', 'freebsd/crypto/openssl/crypto/asn1', 
'freebsd/crypto/openssl/crypto/evp', 'freebsd/crypto/openssl/crypto/modes'] + 
includes,
-defines = defines + ['NO_WINDOWS_BRAINDEATH=1', 
'OPENSSL_DISABLE_OLD_DES_SUPPORT=1', 'OPENSSL_NO_DEPRECATED=1', 
'OPENSSL_NO_EC_NISTP_64_GCC_128=1', 'OPENSSL_NO_GMP=1', 'OPENSSL_NO_JPAKE=1', 
'OPENSSL_NO_LIBUNBOUND=1', 'OPENSSL_NO_MD2=1', 'OPENSSL_NO_RC5=1', 
'OPENSSL_NO_RFC3779=1', 'OPENSSL_NO_SCTP=1', 'OPENSSL_NO_SSL2=1', 
'OPENSSL_NO_SSL_TRACE=1', 'OPENSSL_NO_STORE=1', 'OPENSSL_NO_UNIT_TEST=1', 
'OPENSSL_NO_WEAK_SSL_CIPHERS=1'],
+defines = defines + ['NO_WINDOWS_BRAINDEATH=1', 
'OPENSSL_DISABLE_OLD_DES_SUPPORT=1', 'OPENSSL_NO_EC_NISTP_64_GCC_128=1', 
'OPENSSL_NO_GMP=1', 'OPENSSL_NO_JPAKE=1', 'OPENSSL_NO_LIBUNBOUND=1', 
'OPENSSL_NO_MD2=1', 'OPENSSL_NO_RC5=1', 'OPENSSL_NO_RFC3779=1', 
'OPENSSL_NO_SCTP=1', 'OPENSSL_NO_SSL2=1', 'OPENSSL_NO_SSL_TRACE=1', 
'OPENSSL_NO_STORE=1', 'OPENSSL_NO_UNIT_TEST=1', 
'OPENSSL_NO_WEAK_SSL_CIPHERS=1'],
 source = objs04_source)
 libbsd_use += ["objs04"]
 
-- 
2.13.6

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

Re: [PATCH] bsp/atsam: Allow setting the drive strength.

2018-03-13 Thread Sebastian Huber 

On 12/03/18 16:43, Christian Mauderer wrote:

This adds a simple function for setting the PIO drive strength.


Thanks, looks good.

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

GSOC'18 contribution plan

2018-03-13 Thread Vidushi Vashishth 
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:

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.

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.

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

Re: GSoC 2018 (x86_64, pc386, SMP improvements, rump kernels)

2018-03-13 Thread Joel Sherrill 
On Mar 13, 2018 1:36 AM, "Sebastian Huber" <
sebastian.hu...@embedded-brains.de> wrote:

On 12/03/18 21:20, Gedare Bloom wrote:

> Since I'm pretty keen on RTEMS, I think I'll have a 2nd proposal too, which
>> I'll decide and discuss with you guys soon, hopefully! (Perhaps the
>> tracing
>> or the APA scheduling projects).
>>
>> That's fine.  I don't think APA by itself is enough for the summer.
>
>
The strong APA scheduler was a GSoC project last year. Unfortunately the
student got ill and could not really work on it.

I think a ready to use tracing framework with good support from standard
tools would be quite nice for RTEMS application development. I have some
network stack performance issues which are probably more easy to track down
with such a tool ;-)


The  Common Trace Format (CTF) project is the one I steering students to
for this use case. It is what integrates into Eclipse and lets you use the
Linux Trace Toolkit (LTTNG). That tool visualizes trace logs, can do it
live or from logs, and has built-in capability to detect some behavioral
errors based on logged event patterns.

The cousin of this is the TCF project for remote debugging and target
interaction. Also used by Eclipse.

As far as I can tell, those are the two pieces required to give us a really
nice and complete Eclipse environment.


-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchhe
im,
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] libfs/jffs2: Force the inode size to a non-zero value if a directory.

2018-03-13 Thread Sebastian Huber 

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(>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? I thought this is a hack to make the 
Newlib scandir() happy? This i_size is used in several places. How do 
you know that you didn't accidentally broke something?




We have also this comment:

struct _inode {
    cyg_uint32        i_ino;

    int            i_count;
    mode_t            i_mode;
    nlink_t            i_nlink; // Could we dispense with this?
    uid_t            i_uid;
    gid_t            i_gid;
    time_t            i_atime;
    time_t            i_mtime;
    time_t            i_ctime;
//    union {
        unsigned short    i_rdev; // For devices only
        struct _inode *    i_parent; // For directories only
        off_t        i_size; // For files only
//    };
    struct super_block *    i_sb;
    struct jffs2_full_dirent * i_fd;

    struct jffs2_inode_info    jffs2_i;

    struct _inode *        i_cache_prev; // We need doubly-linked?
    struct _inode *        i_cache_next;
};

Which is no longer valid with this change.

--
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] libfs/jffs2: Force the inode size to a non-zero value if a directory.

2018-03-13 Thread Sebastian Huber 

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(>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? I thought this is a hack to make the 
Newlib scandir() happy? This i_size is used in several places. How do 
you know that you didn't accidentally broke something?


--
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 2/3] Add ARM Paravirtualization support

2018-03-13 Thread Sebastian Huber 

On 12/03/18 21:41, Joel Sherrill wrote:

diff --git a/cpukit/score/cpu/arm/cpu_asm.S b/cpukit/score/cpu/arm/cpu_asm.S
index f58b99d..39a756c 100644
--- a/cpukit/score/cpu/arm/cpu_asm.S
+++ b/cpukit/score/cpu/arm/cpu_asm.S
@@ -111,9 +111,10 @@ DEFINE_FUNCTION_ARM(_CPU_Context_switch)
  #endif
  
  #ifdef ARM_MULTILIB_HAS_THREAD_ID_REGISTER


Why don't you suppress the ARM_MULTILIB_HAS_THREAD_ID_REGISTER 
definition in case RTEMS_PARAVIRT is defined?



+  #ifndef ARM_DISABLE_THREAD_ID_REGISTER_USE
mcr p15, 0, r3, c13, c0, 3
+  #endif
  #endif
-


Please don't delete this blank line. The next statement has nothing to 
do with the thread ID.



str r4, [r2, #PER_CPU_ISR_DISPATCH_DISABLE]
  
  	/* In ARMv5T and above the load of PC is an interworking branch */


--
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] libfs/jffs2: Force the inode size to a non-zero value if a directory.

2018-03-13 Thread Sebastian Huber 

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


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