Re: [PATCH v2 1/5] libcsupport: Added futimens() and utimensat()

2021-05-10 Thread Gedare Bloom
On Mon, May 10, 2021 at 3:16 PM Ryan Long  wrote:
>
> Reply is below.
>
> -Original Message-
> From: Gedare Bloom 
> Sent: Monday, May 10, 2021 12:36 PM
> To: Ryan Long 
> Cc: devel@rtems.org
> Subject: Re: [PATCH v2 1/5] libcsupport: Added futimens() and utimensat()
>
> On Thu, May 6, 2021 at 1:51 PM Ryan Long  wrote:
> >
> > Created futimens.c and utimensat.c to add support for the POSIX
> > methods futimens() and utimensat().
> >
> > utime() and utimes() are considered obsolote by POSIX, but RTEMS will
> > continue to support them.
> >
> > Closes #4396
> > ---
> >  cpukit/Makefile.am |   2 +
> >  cpukit/include/rtems/libio_.h  |  60 +-
> >  cpukit/libcsupport/src/futimens.c  |  87 ++
> > cpukit/libcsupport/src/utimensat.c | 239 
> > +
> >  spec/build/cpukit/librtemscpu.yml  |   2 +
> >  5 files changed, 387 insertions(+), 3 deletions(-)  create mode
> > 100644 cpukit/libcsupport/src/futimens.c  create mode 100644
> > cpukit/libcsupport/src/utimensat.c
> >
> > diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am index
> > b0df610..29b4207 100644
> > --- a/cpukit/Makefile.am
> > +++ b/cpukit/Makefile.am
> > @@ -262,6 +262,8 @@ librtemscpu_a_SOURCES += libcsupport/src/unmount.c
> > librtemscpu_a_SOURCES += libcsupport/src/__usrenv.c
> > librtemscpu_a_SOURCES += libcsupport/src/utime.c
> > librtemscpu_a_SOURCES += libcsupport/src/utimes.c
> > +librtemscpu_a_SOURCES += libcsupport/src/futimens.c
> > +librtemscpu_a_SOURCES += libcsupport/src/utimensat.c
> >  librtemscpu_a_SOURCES += libcsupport/src/utsname.c
> > librtemscpu_a_SOURCES += libcsupport/src/vprintk.c
> > librtemscpu_a_SOURCES += libcsupport/src/write.c diff --git
> > a/cpukit/include/rtems/libio_.h b/cpukit/include/rtems/libio_.h index
> > e9eb462..7a0a169 100644
> > --- a/cpukit/include/rtems/libio_.h
> > +++ b/cpukit/include/rtems/libio_.h
> > @@ -2,13 +2,12 @@
> >   * @file
> >   *
> >   * @brief LibIO Internal Interface
> > - *
> > + *
> >   * This file is the libio internal interface.
> >   */
> >
> >  /*
> > - *  COPYRIGHT (c) 1989-2011.
> > - *  On-Line Applications Research Corporation (OAR).
> > + *  COPYRIGHT (C) 1989, 2021 On-Line Applications Research Corporation 
> > (OAR).
> >   *
> >   *  Modifications to support reference counting in the file system are
> >   *  Copyright (c) 2012 embedded brains GmbH.
> > @@ -357,6 +356,61 @@ static inline void rtems_filesystem_instance_unlock(
> >(*mt_entry->ops->unlock_h)( mt_entry );  }
> >
> > +/* Prototypes for functions used between utimensat() and futimens()
> > +*/
> > +
> We don't usually have this kind of separator comment.
>
> > +/**
> > + * @brief Checks the tv_sec member of a timespec struct
> > + *
> > + * @param[in] time The timespec struct to be validated
> > + *
> > + * Ensures that the value in the tv_sec member is non-negative.
> > + *
> > + * @retval Returns true if the tv_sec member is a valid value, otherwise 
> > false.
> > + */
> > +bool rtems_filesystem_utime_tv_sec_valid( struct timespec time );
> > +
> Should this be a timespec helper instead? It seems like a straightforward 
> helper.
> [Ryan Long] Do you mean just change the name of the function to 
> "timespec_helper_tv_sec_valid" or what?
>

I was thinking along the lines of the functions in
include/rtems/score/timespec.h
You  might consider whether _Timespec_Is_non_negative() should be added.

Speaking of which, you could probably use those helpers in a few
places to simplify your code, e.g.,
_Timespec_Set( times[0], 0, UTIME_NOW);


> > +/**
> > + * @brief Checks the tv_nsec member of a timespec struct
> > + *
> > + * Ensures that the value in the tv_nsec member is equal to either
> > + * UTIME_NOW, UTIME_OMIT, or a value greater-than or equal to zero
> > + * and less than a billion.
> > + *
> > + * @param[in] time The timespec struct to be validated
> > + *
> > + * @retval Returns true if tv_nsec member is a valid value, otherwise 
> > false.
> > + */
> > +bool rtems_filesystem_utime_tv_nsec_valid( struct timespec time );
> > +
> > +/**
> > + * @brief Determines if the process has write permissions to a file
> > + *
> > + * Checks that the process has the same userID as the file and
> > +whether the
> > + * file has write permissions.
> > + *
> > + * @param[in] currentloc The current location to a file
> > + * @param[in] fstat_h The file handler of @currentloc
> > + *
> > + * @retval Returns 0 if the process has write permissions, otherwise -1.
> > + */
> > +int rtems_filesystem_utime_check_permissions(
> > +  const rtems_filesystem_location_info_t *currentloc,
> > +  const struct timespec times[2]
> > +);
> > +
> The function name is overly broad. it seems like there should be a filesystem 
> helper that checks for write permission (or ownership).
> I don't know why times[] is passed? What is @param[in] fstat_h?
>
> Passing an array is a bit unusual.
> [Ryan Long] Forgot to update the Doxygen for that, but I got rid of the 
> 

RE: [PATCH v2 1/5] libcsupport: Added futimens() and utimensat()

2021-05-10 Thread Ryan Long
Reply is below.

-Original Message-
From: Gedare Bloom  
Sent: Monday, May 10, 2021 12:36 PM
To: Ryan Long 
Cc: devel@rtems.org
Subject: Re: [PATCH v2 1/5] libcsupport: Added futimens() and utimensat()

On Thu, May 6, 2021 at 1:51 PM Ryan Long  wrote:
>
> Created futimens.c and utimensat.c to add support for the POSIX 
> methods futimens() and utimensat().
>
> utime() and utimes() are considered obsolote by POSIX, but RTEMS will 
> continue to support them.
>
> Closes #4396
> ---
>  cpukit/Makefile.am |   2 +
>  cpukit/include/rtems/libio_.h  |  60 +-
>  cpukit/libcsupport/src/futimens.c  |  87 ++  
> cpukit/libcsupport/src/utimensat.c | 239 +
>  spec/build/cpukit/librtemscpu.yml  |   2 +
>  5 files changed, 387 insertions(+), 3 deletions(-)  create mode 
> 100644 cpukit/libcsupport/src/futimens.c  create mode 100644 
> cpukit/libcsupport/src/utimensat.c
>
> diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am index 
> b0df610..29b4207 100644
> --- a/cpukit/Makefile.am
> +++ b/cpukit/Makefile.am
> @@ -262,6 +262,8 @@ librtemscpu_a_SOURCES += libcsupport/src/unmount.c  
> librtemscpu_a_SOURCES += libcsupport/src/__usrenv.c  
> librtemscpu_a_SOURCES += libcsupport/src/utime.c  
> librtemscpu_a_SOURCES += libcsupport/src/utimes.c
> +librtemscpu_a_SOURCES += libcsupport/src/futimens.c 
> +librtemscpu_a_SOURCES += libcsupport/src/utimensat.c
>  librtemscpu_a_SOURCES += libcsupport/src/utsname.c  
> librtemscpu_a_SOURCES += libcsupport/src/vprintk.c  
> librtemscpu_a_SOURCES += libcsupport/src/write.c diff --git 
> a/cpukit/include/rtems/libio_.h b/cpukit/include/rtems/libio_.h index 
> e9eb462..7a0a169 100644
> --- a/cpukit/include/rtems/libio_.h
> +++ b/cpukit/include/rtems/libio_.h
> @@ -2,13 +2,12 @@
>   * @file
>   *
>   * @brief LibIO Internal Interface
> - *
> + *
>   * This file is the libio internal interface.
>   */
>
>  /*
> - *  COPYRIGHT (c) 1989-2011.
> - *  On-Line Applications Research Corporation (OAR).
> + *  COPYRIGHT (C) 1989, 2021 On-Line Applications Research Corporation (OAR).
>   *
>   *  Modifications to support reference counting in the file system are
>   *  Copyright (c) 2012 embedded brains GmbH.
> @@ -357,6 +356,61 @@ static inline void rtems_filesystem_instance_unlock(
>(*mt_entry->ops->unlock_h)( mt_entry );  }
>
> +/* Prototypes for functions used between utimensat() and futimens() 
> +*/
> +
We don't usually have this kind of separator comment.

> +/**
> + * @brief Checks the tv_sec member of a timespec struct
> + *
> + * @param[in] time The timespec struct to be validated
> + *
> + * Ensures that the value in the tv_sec member is non-negative.
> + *
> + * @retval Returns true if the tv_sec member is a valid value, otherwise 
> false.
> + */
> +bool rtems_filesystem_utime_tv_sec_valid( struct timespec time );
> +
Should this be a timespec helper instead? It seems like a straightforward 
helper.
[Ryan Long] Do you mean just change the name of the function to 
"timespec_helper_tv_sec_valid" or what?

> +/**
> + * @brief Checks the tv_nsec member of a timespec struct
> + *
> + * Ensures that the value in the tv_nsec member is equal to either
> + * UTIME_NOW, UTIME_OMIT, or a value greater-than or equal to zero
> + * and less than a billion.
> + *
> + * @param[in] time The timespec struct to be validated
> + *
> + * @retval Returns true if tv_nsec member is a valid value, otherwise false.
> + */
> +bool rtems_filesystem_utime_tv_nsec_valid( struct timespec time );
> +
> +/**
> + * @brief Determines if the process has write permissions to a file
> + *
> + * Checks that the process has the same userID as the file and 
> +whether the
> + * file has write permissions.
> + *
> + * @param[in] currentloc The current location to a file
> + * @param[in] fstat_h The file handler of @currentloc
> + *
> + * @retval Returns 0 if the process has write permissions, otherwise -1.
> + */
> +int rtems_filesystem_utime_check_permissions(
> +  const rtems_filesystem_location_info_t *currentloc,
> +  const struct timespec times[2]
> +);
> +
The function name is overly broad. it seems like there should be a filesystem 
helper that checks for write permission (or ownership).
I don't know why times[] is passed? What is @param[in] fstat_h?

Passing an array is a bit unusual.
[Ryan Long] Forgot to update the Doxygen for that, but I got rid of the ftat_h 
argument because I can just use currentloc to get what was being passed in. 
  The array of timespec structures is passed in to check 
for the conditions for the EACCES and EPERM errors.

> +/**
> + * @brief Checks @times and updates @new_times
> + *
> + * @param[in] times The timespec struct to be checked
> + * @param[in,out] new_times The timespec struct to contain the 
> +updated time
> + *
> + * @retval Returns 0 if the time was update, otherwise -1.
> + */
> +int rtems_filesystem_utime_check_times(
> +  const struct timespec times[2],
> +  struct 

Re: [PATCH v1 0/2] [libbsd] Install correct machine include headers

2021-05-10 Thread Gedare Bloom
I can't review these currently, just want to put a note out there.
Hopefully someone else gets to it. Otherwise ping it in a week or two
and I might have more time to look myself..

On Mon, May 10, 2021 at 11:26 AM Jan Sommer  wrote:
>
> Hello,
>
> This is a follow-up on this discussion regarding the installed header files
> in libbsd: https://lists.rtems.org/pipermail/devel/2021-April/066211.html
>
> The current situation is, that for example for all machines the bus.h is 
> installed from
> within the rtemsbsd directory 
> (https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/machine/bus.h).
>
> According to the file docu it originates from the amd64 version of this file.
> It also has the following section in it which we ran into when compiling 
> Chris' ptpd2 archive:
>
> #ifdef __i386__
>   #error "your include paths are wrong"
> #endif
>
> This patchset does the following:
> - Add the target dependent machine include directory to 'header-paths' in 
> libbsd.py
> - Import (mostly) '_bus.h', 'bus.h' and 'cpufunc.h' for the targets from 
> freebsd-org
> - Remove those header files from rtemsbsd directory
>
> As a result the matching versions for machine dependent header files are now 
> installed
> for each BSP.
> Would this be an acceptable solution?
>
> So far I compiled some BSPs for i386, arm, aarch64, powerpc, riscv, sparc and 
> sparc64 to check that they still compile after the changes.
> Are there any other architectures which should be included?
>
> I ran into one problem regarding the compilation of 
> rtemsbsd/sys/dev/dw_mmc/dw_mmc.c:105
>
> > return (bus_space_read_4(0, sc->bushandle, off));
>
> The first parameter creates an error for riscv (I think because dereferencing 
> a NULL pointer).
> Are there any suggestion how to solve it (I am not familiar with the bus 
> space and there is a lot of macro magic going on)?
>
> Also, I am not sure if I always added the header files in the right
> module in libbsd.py. Any suggestions where to put them instead would be 
> welcome.
>
> Best regards,
>
> Jan
>
> Jan Sommer (2):
>   rtemsbd: Remove machine dependent files and use the ones from freebsd
>   machine: Add machine dependent header files to libbsd.py
>
>  freebsd/sys/arm/include/machine/_bus.h|  47 +
>  freebsd/sys/arm/include/machine/bus.h | 769 
>  freebsd/sys/arm64/include/machine/_bus.h  |  46 +
>  freebsd/sys/arm64/include/machine/bus.h   | 469 ++
>  freebsd/sys/powerpc/include/machine/_bus.h|  50 +
>  freebsd/sys/powerpc/include/machine/bus.h | 467 ++
>  freebsd/sys/riscv/include/machine/_bus.h  |  46 +
>  freebsd/sys/riscv/include/machine/bus.h   | 469 ++
>  freebsd/sys/riscv/include/machine/cpufunc.h   | 135 +++
>  freebsd/sys/riscv/include/machine/riscvreg.h  | 246 +
>  .../sys/sparc}/include/machine/_bus.h |   0
>  .../sys/sparc}/include/machine/bus.h  |   0
>  freebsd/sys/sparc/include/machine/cpufunc.h   |   0
>  freebsd/sys/sparc64/include/machine/_bus.h|  41 +
>  freebsd/sys/sparc64/include/machine/bus.h | 852 ++
>  libbsd.py |  26 +-
>  rtemsbsd/include/machine/cpufunc.h|   1 -
>  waf_libbsd.py |   2 -
>  18 files changed, 3660 insertions(+), 6 deletions(-)
>  create mode 100644 freebsd/sys/arm/include/machine/_bus.h
>  create mode 100644 freebsd/sys/arm/include/machine/bus.h
>  create mode 100644 freebsd/sys/arm64/include/machine/_bus.h
>  create mode 100644 freebsd/sys/arm64/include/machine/bus.h
>  create mode 100644 freebsd/sys/powerpc/include/machine/_bus.h
>  create mode 100644 freebsd/sys/powerpc/include/machine/bus.h
>  create mode 100644 freebsd/sys/riscv/include/machine/_bus.h
>  create mode 100644 freebsd/sys/riscv/include/machine/bus.h
>  create mode 100644 freebsd/sys/riscv/include/machine/cpufunc.h
>  create mode 100644 freebsd/sys/riscv/include/machine/riscvreg.h
>  rename {rtemsbsd => freebsd/sys/sparc}/include/machine/_bus.h (100%)
>  rename {rtemsbsd => freebsd/sys/sparc}/include/machine/bus.h (100%)
>  create mode 100644 freebsd/sys/sparc/include/machine/cpufunc.h
>  create mode 100644 freebsd/sys/sparc64/include/machine/_bus.h
>  create mode 100644 freebsd/sys/sparc64/include/machine/bus.h
>  delete mode 100644 rtemsbsd/include/machine/cpufunc.h
>
> --
> 2.17.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH 2/2] Fix the bibtex extension configure test

2021-05-10 Thread Gedare Bloom
ok to both of these. To honor Joel, I'll suggest you should include in
the commit msg a more descriptive notion of what you fixed (i.e.,
"fixed OS neutrality") ;)

On Mon, May 10, 2021 at 11:26 AM  wrote:
>
> From: Chris Johns 
>
> ---
>  common/waf.py | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/common/waf.py b/common/waf.py
> index 3806209..fa9aecb 100644
> --- a/common/waf.py
> +++ b/common/waf.py
> @@ -181,10 +181,12 @@ def check_sphinx_extension(ctx, extension):
>  def run_sphinx(bld):
>  rst_node = bld.srcnode.make_node('testbuild/contents.rst')
>  rst_node.parent.mkdir()
> -rst_node.write('.. COMMENT test sphinx\n')
> +rst_node.write('.. COMMENT test sphinx' + os.linesep)
>  bib_node = bld.srcnode.make_node('testbuild/refs.bib')
> +bib_node.write(os.linesep)
>  conf_node = bld.srcnode.make_node('testbuild/conf.py')
> -conf_node.write("bibtex_bibfiles = ['refs.bib']\n")
> +conf_node.write(os.linesep.join(["master_doc='contents'",
> + "bibtex_bibfiles = ['refs.bib']"]))
>  bld(rule = bld.kw['rule'], source = rst_node)
>
>  ctx.start_msg("Checking for '%s'" % (extension))
> --
> 2.24.3 (Apple Git-128)
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH rtems-libbsd v2] ipsec-tools/pfkey: Fix socket leak

2021-05-10 Thread Gedare Bloom
looks good, thanks. for the backport please open a separate ticket to 5.

On Mon, May 10, 2021 at 11:26 AM Christian MAUDERER
 wrote:
>
> Only change is a better description.
>
> Am 10.05.21 um 08:50 schrieb Christian Mauderer:
> > setkey uses pfkey_open to open a socket. But setkey doesn't close the
> > socket.
> >
> > The libipsec functions are used only by user space applications (setkey
> > and racoon). Adding the wrapper for socket makes sure that the opened
> > socket is registered and closes if the application exits.
> >
> > Fixes #4404
> > ---
> >   ipsec-tools/src/libipsec/pfkey.c | 7 +++
> >   1 file changed, 7 insertions(+)
> >
> > diff --git a/ipsec-tools/src/libipsec/pfkey.c 
> > b/ipsec-tools/src/libipsec/pfkey.c
> > index a621be12..385a21a9 100644
> > --- a/ipsec-tools/src/libipsec/pfkey.c
> > +++ b/ipsec-tools/src/libipsec/pfkey.c
> > @@ -1,5 +1,12 @@
> >   #include 
> >
> > +#ifdef __rtems__
> > +/* Only need socket from rtems-bsd-program wrappers! */
> > +int
> > +rtems_bsd_program_socket(int domain, int type, int protocol);
> > +#define socket(domain, type, protocol) \
> > +rtems_bsd_program_socket(domain, type, protocol)
> > +#endif /* __rtems__ */
> >   /*  $NetBSD: pfkey.c,v 1.21.2.1 2011/11/14 13:25:06 tteras Exp $*/
> >
> >   /*  $KAME: pfkey.c,v 1.47 2003/10/02 19:52:12 itojun Exp $  */
> >
>
> --
> 
> embedded brains GmbH
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> phone: +49-89-18 94 741 - 18
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] rtems: Use _Objects_Free_nothing() for msg queues

2021-05-10 Thread Gedare Bloom
ok

On Mon, May 10, 2021 at 11:41 AM Sebastian Huber
 wrote:
>
> Use _Objects_Free_nothing() for rtems_message_queue_construct() to avoid
> unreachable code in _CORE_message_queue_Close() in case only
> user-provided message buffers are used.
>
> Update #4007.
> ---
>  cpukit/rtems/src/msgqconstruct.c | 7 ++-
>  cpukit/score/src/coremsgclose.c  | 8 +++-
>  2 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/cpukit/rtems/src/msgqconstruct.c 
> b/cpukit/rtems/src/msgqconstruct.c
> index 6af57454cc..63ec75edff 100644
> --- a/cpukit/rtems/src/msgqconstruct.c
> +++ b/cpukit/rtems/src/msgqconstruct.c
> @@ -41,7 +41,12 @@ static void *_Message_queue_Get_buffers(
>  return NULL;
>}
>
> -  the_message_queue->free_message_buffers = config->storage_free;
> +  if ( config->storage_free != NULL ) {
> +the_message_queue->free_message_buffers = config->storage_free;
> +  } else {
> +the_message_queue->free_message_buffers = _Objects_Free_nothing;
> +  }
> +
>return config->storage_area;
>  }
>
> diff --git a/cpukit/score/src/coremsgclose.c b/cpukit/score/src/coremsgclose.c
> index 1610d8166b..aae3d5ae82 100644
> --- a/cpukit/score/src/coremsgclose.c
> +++ b/cpukit/score/src/coremsgclose.c
> @@ -51,11 +51,9 @@ void _CORE_message_queue_Close(
>  queue_context
>);
>
> -  if ( the_message_queue->free_message_buffers != NULL ) {
> -( *the_message_queue->free_message_buffers )(
> -  the_message_queue->message_buffers
> -);
> -  }
> +  ( *the_message_queue->free_message_buffers )(
> +the_message_queue->message_buffers
> +  );
>
>_Thread_queue_Destroy( _message_queue->Wait_queue );
>  }
> --
> 2.26.2
>
> ___
> 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 2/2] bsp: Use RTEMS_NOINIT for bsp_fdt_blob

2021-05-10 Thread Gedare Bloom
ok

On Mon, May 10, 2021 at 11:42 AM Sebastian Huber
 wrote:
>
> Sorry, I sent the wrong patch set. Please ignore this one.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/raspberrypi/console: Fix default console device

2021-05-10 Thread Niteesh G. S.
Hello Gedare,

On Mon, May 10, 2021 at 8:57 PM Gedare Bloom  wrote:

> On Thu, May 6, 2021 at 8:49 AM Niteesh G. S.  wrote:
> >
> > Hi Alan,
> >
> > On Thu, May 6, 2021 at 6:12 PM Alan Cudmore 
> wrote:
> >>
> >> Hi Niteesh,
> >>
> >> I was hoping to try this out as soon as I get some time. No later than
> weekend. So if nobody else is able to check it out, I will be able to
> provide some feedback soon.
> >>
> >> I should be able to bring up the console on a RPi Zero W and RPi3,
> correct?
> >
> > the consoles should work on Zero W and Pi3 by default. They only fail to
> work when  CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> > this option is used. This is because when that option is used it calls
> console_initialize which checks if any boot options were present if none
> were
> > given it defaults to pl011 which is the secondary UART in Zero w and Pi3
> so we get no output. This patch defaults to the primary UART instead of
> > pl011 depending on the board.
> > Also, this patch should be applied on RTEMS 5 since we started
> supporting Pi3 and Zero w from RTEMS 5.
> >
> You'll need to provide a separate patch with a ticket to close on 5
> for a backport. Wait until you get the approval for the master branch
> though.

OK. I'll create a ticket and request for a backport once this is pushed on
to the current master

Thanks,
Niteesh.

>
> > Thanks,
> > Niteesh.
> >
> >
> >>
> >> Thanks,
> >>
> >> Alan
> >>
> >>
> >>
> >> From: Niteesh G. S.
> >> Sent: Thursday, May 6, 2021 4:29 AM
> >> To: Joel Sherrill; Christian Mauderer
> >> Cc: rtems-de...@rtems.org
> >> Subject: Re: [PATCH] bsps/raspberrypi/console: Fix default console
> device
> >>
> >>
> >>
> >> ping.
> >>
> >>
> >>
> >> On Sat, May 1, 2021 at 9:47 PM Niteesh G. S. 
> wrote:
> >>
> >> On Sat, May 1, 2021 at 8:31 PM Joel Sherrill  wrote:
> >>
> >>
> >>
> >> On Sat, May 1, 2021, 8:53 AM Niteesh G. S. 
> wrote:
> >>
> >> Just to provide more context,
> >>
> >> When the CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER option is used
> >>
> >> and no --console option is provided, the console driver defaults to
> PL011.
> >>
> >> In raspberry pi 3 and other models whose primary UART is not PL011, we
> get no output.
> >>
> >> This patch fixes that by linking the primary UART to the console device.
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Niteesh
> >>
> >>
> >>
> >> On Sat, May 1, 2021 at 7:05 PM G S Niteesh Babu 
> wrote:
> >>
> >> When no console argument is given, the driver defaults to pl011
> >> this results in no output in case of Rpi3 whose primary uart is
> >> miniuart.
> >> This patch fixes that by defaulting to the primary uart when no
> >> console option is provided.
> >>
> >>
> >>
> >> Does the default need to vary by model?
> >>
> >> Yes, the primary UART is different across models.
> >>
> >>
> >>
> >> Rpi's have two UARTs PL011 and miniuart, on models which have Bluetooth
> >>
> >> the PL011 is used to talk to the Bluetooth and miniuart acts as the
> primary UART.
> >>
> >> Now we can change this by adding miniuart-bt to config.txt but the
> miniuart is
> >>
> >> based on the VPU core and requires to add another option which sets the
> core to
> >>
> >> a fixed freq.
> >>
> >>
> >>
> >> ---
> >>  bsps/arm/raspberrypi/console/console-config.c | 12 +---
> >>  1 file changed, 9 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> >> index 6b8eb80aa4..bd3a8d34c2 100644
> >> --- a/bsps/arm/raspberrypi/console/console-config.c
> >> +++ b/bsps/arm/raspberrypi/console/console-config.c
> >> @@ -165,10 +165,16 @@ static void console_select( void )
> >>  }
> >>}else {
> >>  /**
> >> - * If no command line option was given, default to PL011.
> >> + * If no console option was given we default to the primary uarts.
> >> + * The initialization of the uart's and BSP_output_char is already
> done
> >> + * in the uart_probe function called before this. So now we can
> safely
> >> + * compare BSP_output_char.
> >>   */
> >> -BSP_output_char = output_char_pl011;
> >> -link(PL011, CONSOLE_DEVICE_NAME);
> >> +if (BSP_output_char == output_char_pl011) {
> >> +  link(PL011, CONSOLE_DEVICE_NAME);
> >> +}else {
> >> +  link(MINIUART, CONSOLE_DEVICE_NAME);
> >> +}
> >>}
> >>  }
> >>
> >> --
> >> 2.17.1
> >>
> >> ___
> >> devel mailing list
> >> devel@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
> >>
> >>
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/raspberrypi/console: Fix default console device

2021-05-10 Thread Niteesh G. S.
Hello Alan,

On Mon, May 10, 2021 at 8:04 PM Alan Cudmore  wrote:

> Hi Niteesh,
> I was able to build the current RTEMS master (raspberrypi BSP) and I
> was also able to successfully apply your patch and rebuild.
> However, I am having trouble getting RTEMS running on the Raspberry Pis I
> have.
> I tried it with and without the patch and I cannot get it to work. I
> tried a Raspberry Pi Zero, B+, and Zero W ( with the patch).
> I used these instructions for the firmware on SD card:
> https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#raspberrypi
>
> I tried:
> - RTEMS master "arm/raspberrypi" BSP with and without the patch
> - RTEMS 5 branch "arm/raspberrypi" BSP
> - latest version of the RPI firmware files
> - an older version of the RPI firmware (from June 2016)
> I used the config.txt file that is recommended, but I did not have any
> command line options. I did not have my raspberry Pis connected to
> HDMI, only serial.
>
> Can you describe your setup?
> I know I have been through this before.
>

https://github.com/gs-niteesh/rpi3_RTEMS
These are the files I have in my boot partition. Usually, I use u-boot so
that
I can have a tftp server setup. But I am also able to load the images with
RPi loader using the same files.
I have some doco on how I create the images for the respective bootloader
type in the INFO.txt in the repo.
Also please make sure that you are up to date with the master branch. One
commit broke Rpi BSP but it was later fixed.
I was able to get the Hello example running using both Rpi bootloader and
uboot with the latest master branch.

For loading using u-boot I use the following commands
fatload mmc 0 0x1000 bcm2710-rpi-3-b.dtb
fatload mmc 0 0x20 rtems.img
bootm 0x20 - 0x1000

Thanks,
Niteesh


> Thanks,
> Alan
>
> On Thu, May 6, 2021 at 10:48 AM Niteesh G. S. 
> wrote:
> >
> > Hi Alan,
> >
> > On Thu, May 6, 2021 at 6:12 PM Alan Cudmore 
> wrote:
> >>
> >> Hi Niteesh,
> >>
> >> I was hoping to try this out as soon as I get some time. No later than
> weekend. So if nobody else is able to check it out, I will be able to
> provide some feedback soon.
> >>
> >> I should be able to bring up the console on a RPi Zero W and RPi3,
> correct?
> >
> > the consoles should work on Zero W and Pi3 by default. They only fail to
> work when  CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> > this option is used. This is because when that option is used it calls
> console_initialize which checks if any boot options were present if none
> were
> > given it defaults to pl011 which is the secondary UART in Zero w and Pi3
> so we get no output. This patch defaults to the primary UART instead of
> > pl011 depending on the board.
> > Also, this patch should be applied on RTEMS 5 since we started
> supporting Pi3 and Zero w from RTEMS 5.
> >
> > Thanks,
> > Niteesh.
> >
> >
> >>
> >> Thanks,
> >>
> >> Alan
> >>
> >>
> >>
> >> From: Niteesh G. S.
> >> Sent: Thursday, May 6, 2021 4:29 AM
> >> To: Joel Sherrill; Christian Mauderer
> >> Cc: rtems-de...@rtems.org
> >> Subject: Re: [PATCH] bsps/raspberrypi/console: Fix default console
> device
> >>
> >>
> >>
> >> ping.
> >>
> >>
> >>
> >> On Sat, May 1, 2021 at 9:47 PM Niteesh G. S. 
> wrote:
> >>
> >> On Sat, May 1, 2021 at 8:31 PM Joel Sherrill  wrote:
> >>
> >>
> >>
> >> On Sat, May 1, 2021, 8:53 AM Niteesh G. S. 
> wrote:
> >>
> >> Just to provide more context,
> >>
> >> When the CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER option is used
> >>
> >> and no --console option is provided, the console driver defaults to
> PL011.
> >>
> >> In raspberry pi 3 and other models whose primary UART is not PL011, we
> get no output.
> >>
> >> This patch fixes that by linking the primary UART to the console device.
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Niteesh
> >>
> >>
> >>
> >> On Sat, May 1, 2021 at 7:05 PM G S Niteesh Babu 
> wrote:
> >>
> >> When no console argument is given, the driver defaults to pl011
> >> this results in no output in case of Rpi3 whose primary uart is
> >> miniuart.
> >> This patch fixes that by defaulting to the primary uart when no
> >> console option is provided.
> >>
> >>
> >>
> >> Does the default need to vary by model?
> >>
> >> Yes, the primary UART is different across models.
> >>
> >>
> >>
> >> Rpi's have two UARTs PL011 and miniuart, on models which have Bluetooth
> >>
> >> the PL011 is used to talk to the Bluetooth and miniuart acts as the
> primary UART.
> >>
> >> Now we can change this by adding miniuart-bt to config.txt but the
> miniuart is
> >>
> >> based on the VPU core and requires to add another option which sets the
> core to
> >>
> >> a fixed freq.
> >>
> >>
> >>
> >> ---
> >>  bsps/arm/raspberrypi/console/console-config.c | 12 +---
> >>  1 file changed, 9 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> >> index 6b8eb80aa4..bd3a8d34c2 100644
> >> --- a/bsps/arm/raspberrypi/console/console-config.c
> 

Re: qemu-system-ppc64 does not work on powerpc/qoriq_e6500_64

2021-05-10 Thread Richi Dubey
Great, thanks.

On Mon, 10 May 2021, 23:04 Karel Gardas,  wrote:

> On 5/10/21 2:26 PM, Richi Dubey wrote:
> > Thanks, I'll check it out.
>
> -bios `where you do have`/u-boot.e500.
>
> Karel
>
> >
> > On Mon, May 10, 2021 at 10:19 AM Sebastian Huber
> >  > > wrote:
> >
> > On 09/05/2021 06:02, Richi Dubey wrote:
> > > 0x42c8 199 SET_SELF_CPU_CONTROL CPU_SELF, r5
> > > (gdb)
> > > 0x in ?? ()
> > > (gdb)
> > > 0x in ?? ()
> > > (gdb)
> > > 0x in ?? ()
> > > (gdb)
> > > 0x in ?? ()
> > > (gdb)
> > > 0x in ?? ()
> > > (gdb)
> > >
> > >
> >
>  - - -
> >
> > >
> > > Is there a way to solve this?
> >
> > This BSP assumes that it is booted via U-Boot. Maybe there is an
> option
> > in Qemu to simulate this. Otherwise you probably have to change the
> > startup sequence.
> >
> > --
> > embedded brains GmbH
> > Herr Sebastian HUBER
> > Dornierstr. 4
> > 82178 Puchheim
> > Germany
> > email: sebastian.hu...@embedded-brains.de
> > 
> > phone: +49-89-18 94 741 - 16
> > fax:   +49-89-18 94 741 - 08
> >
> > Registergericht: Amtsgericht München
> > Registernummer: HRB 157899
> > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas
> Dörfler
> > Unsere Datenschutzerklärung finden Sie hier:
> > https://embedded-brains.de/datenschutzerklaerung/
> > 
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 5/5] Change filesystem utime_h handler to utimens_h

2021-05-10 Thread Joel Sherrill
On Mon, May 10, 2021 at 12:48 PM Gedare Bloom  wrote:

> On Thu, May 6, 2021 at 1:51 PM Ryan Long  wrote:
> >
> > Also updated licenses.
> >
> > Closes #4400
> > ---
> >  bsps/arm/csb337/umon/tfsDriver.c|  2 +-
> >  cpukit/Makefile.am  |  4 +--
> >  cpukit/include/rtems/confdefs/libio.h   |  4 +--
> >  cpukit/include/rtems/imfs.h |  7 +++--
> >  cpukit/include/rtems/libio.h| 21 +++
> >  cpukit/libcsupport/src/__usrenv.c   |  9 +++
> >  cpukit/libfs/src/defaults/default_ops.c |  2 +-
> >  cpukit/libfs/src/defaults/default_utime.c   | 32 --
> >  cpukit/libfs/src/defaults/default_utimens.c | 33 +++
> >  cpukit/libfs/src/dosfs/msdos_init.c | 11 
> >  cpukit/libfs/src/ftpfs/ftpfs.c  |  2 +-
> >  cpukit/libfs/src/ftpfs/tftpDriver.c |  2 +-
> >  cpukit/libfs/src/imfs/imfs_init.c   |  4 +--
> >  cpukit/libfs/src/imfs/imfs_utime.c  | 41
> 
> >  cpukit/libfs/src/imfs/imfs_utimens.c| 42
> +
> >  cpukit/libfs/src/jffs2/src/fs-rtems.c   | 11 
> >  cpukit/libfs/src/rfs/rtems-rfs-rtems.c  | 16 +--
> >  spec/build/cpukit/librtemscpu.yml   |  4 +--
> >  18 files changed, 120 insertions(+), 127 deletions(-)
> >  delete mode 100644 cpukit/libfs/src/defaults/default_utime.c
> >  create mode 100644 cpukit/libfs/src/defaults/default_utimens.c
> >  delete mode 100644 cpukit/libfs/src/imfs/imfs_utime.c
> >  create mode 100644 cpukit/libfs/src/imfs/imfs_utimens.c
> >
> > diff --git a/bsps/arm/csb337/umon/tfsDriver.c
> b/bsps/arm/csb337/umon/tfsDriver.c
> > index 0195346..caf3a4b 100644
> > --- a/bsps/arm/csb337/umon/tfsDriver.c
> > +++ b/bsps/arm/csb337/umon/tfsDriver.c
> > @@ -657,7 +657,7 @@ static const rtems_filesystem_operations_table
> rtems_tfs_ops = {
> >.mount_h = rtems_filesystem_default_mount,
> >.unmount_h = rtems_filesystem_default_unmount,
> >.fsunmount_me_h = rtems_filesystem_default_fsunmount,
> > -  .utime_h = rtems_filesystem_default_utime,
> > +  .utimens_h = rtems_filesystem_default_utimens,
> >.symlink_h = rtems_filesystem_default_symlink,
> >.readlink_h = rtems_filesystem_default_readlink,
> >.rename_h = rtems_filesystem_default_rename,
> > diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
> > index 29b4207..c144773 100644
> > --- a/cpukit/Makefile.am
> > +++ b/cpukit/Makefile.am
> > @@ -377,7 +377,7 @@ librtemscpu_a_SOURCES +=
> libfs/src/defaults/default_rmnod.c
> >  librtemscpu_a_SOURCES += libfs/src/defaults/default_statvfs.c
> >  librtemscpu_a_SOURCES += libfs/src/defaults/default_symlink.c
> >  librtemscpu_a_SOURCES += libfs/src/defaults/default_unmount.c
> > -librtemscpu_a_SOURCES += libfs/src/defaults/default_utime.c
> > +librtemscpu_a_SOURCES += libfs/src/defaults/default_utimens.c
> >  librtemscpu_a_SOURCES += libfs/src/defaults/default_write.c
> >  librtemscpu_a_SOURCES += libfs/src/defaults/default_writev.c
> >  librtemscpu_a_SOURCES += libfs/src/dosfs/fat.c
> > @@ -434,7 +434,7 @@ librtemscpu_a_SOURCES += libfs/src/imfs/imfs_stat.c
> >  librtemscpu_a_SOURCES += libfs/src/imfs/imfs_stat_file.c
> >  librtemscpu_a_SOURCES += libfs/src/imfs/imfs_symlink.c
> >  librtemscpu_a_SOURCES += libfs/src/imfs/imfs_unmount.c
> > -librtemscpu_a_SOURCES += libfs/src/imfs/imfs_utime.c
> > +librtemscpu_a_SOURCES += libfs/src/imfs/imfs_utimens.c
> >  librtemscpu_a_SOURCES += libfs/src/imfs/ioman.c
> >  librtemscpu_a_SOURCES += libfs/src/pipe/fifo.c
> >  librtemscpu_a_SOURCES += libfs/src/pipe/pipe.c
> > diff --git a/cpukit/include/rtems/confdefs/libio.h
> b/cpukit/include/rtems/confdefs/libio.h
> > index 16a4fb69..1b84f8c 100644
> > --- a/cpukit/include/rtems/confdefs/libio.h
> > +++ b/cpukit/include/rtems/confdefs/libio.h
> > @@ -231,9 +231,9 @@ static const rtems_filesystem_operations_table
> IMFS_root_ops = {
> >#endif
> >rtems_filesystem_default_fsunmount,
> >#ifdef CONFIGURE_IMFS_DISABLE_UTIME
> > -rtems_filesystem_default_utime,
> > +rtems_filesystem_default_utimens,
> >#else
> > -IMFS_utime,
> > +IMFS_utimens,
> >#endif
> >#ifdef CONFIGURE_IMFS_DISABLE_SYMLINK
> >  rtems_filesystem_default_symlink,
> > diff --git a/cpukit/include/rtems/imfs.h b/cpukit/include/rtems/imfs.h
> > index b2a9868..6e0d5d5 100644
> > --- a/cpukit/include/rtems/imfs.h
> > +++ b/cpukit/include/rtems/imfs.h
> > @@ -5,7 +5,7 @@
> >   */
> >
> >  /*
> > - *  COPYRIGHT (c) 1989-2011.
> > + *  COPYRIGHT (c) 1989-2011, 2021.
> >   *  On-Line Applications Research Corporation (OAR).
> >   *
> >   *  The license and distribution terms for this file may be
> fix license?
>

That is OK. And add SPDX.

I've generally encouraged only changing the license and adding SPDX
on files with substantial change.

But a part of me just wants to rip through areas which are clearly
written by the core 

Re: [PATCH v2 5/5] Change filesystem utime_h handler to utimens_h

2021-05-10 Thread Gedare Bloom
On Thu, May 6, 2021 at 1:51 PM Ryan Long  wrote:
>
> Also updated licenses.
>
> Closes #4400
> ---
>  bsps/arm/csb337/umon/tfsDriver.c|  2 +-
>  cpukit/Makefile.am  |  4 +--
>  cpukit/include/rtems/confdefs/libio.h   |  4 +--
>  cpukit/include/rtems/imfs.h |  7 +++--
>  cpukit/include/rtems/libio.h| 21 +++
>  cpukit/libcsupport/src/__usrenv.c   |  9 +++
>  cpukit/libfs/src/defaults/default_ops.c |  2 +-
>  cpukit/libfs/src/defaults/default_utime.c   | 32 --
>  cpukit/libfs/src/defaults/default_utimens.c | 33 +++
>  cpukit/libfs/src/dosfs/msdos_init.c | 11 
>  cpukit/libfs/src/ftpfs/ftpfs.c  |  2 +-
>  cpukit/libfs/src/ftpfs/tftpDriver.c |  2 +-
>  cpukit/libfs/src/imfs/imfs_init.c   |  4 +--
>  cpukit/libfs/src/imfs/imfs_utime.c  | 41 
>  cpukit/libfs/src/imfs/imfs_utimens.c| 42 
> +
>  cpukit/libfs/src/jffs2/src/fs-rtems.c   | 11 
>  cpukit/libfs/src/rfs/rtems-rfs-rtems.c  | 16 +--
>  spec/build/cpukit/librtemscpu.yml   |  4 +--
>  18 files changed, 120 insertions(+), 127 deletions(-)
>  delete mode 100644 cpukit/libfs/src/defaults/default_utime.c
>  create mode 100644 cpukit/libfs/src/defaults/default_utimens.c
>  delete mode 100644 cpukit/libfs/src/imfs/imfs_utime.c
>  create mode 100644 cpukit/libfs/src/imfs/imfs_utimens.c
>
> diff --git a/bsps/arm/csb337/umon/tfsDriver.c 
> b/bsps/arm/csb337/umon/tfsDriver.c
> index 0195346..caf3a4b 100644
> --- a/bsps/arm/csb337/umon/tfsDriver.c
> +++ b/bsps/arm/csb337/umon/tfsDriver.c
> @@ -657,7 +657,7 @@ static const rtems_filesystem_operations_table  
> rtems_tfs_ops = {
>.mount_h = rtems_filesystem_default_mount,
>.unmount_h = rtems_filesystem_default_unmount,
>.fsunmount_me_h = rtems_filesystem_default_fsunmount,
> -  .utime_h = rtems_filesystem_default_utime,
> +  .utimens_h = rtems_filesystem_default_utimens,
>.symlink_h = rtems_filesystem_default_symlink,
>.readlink_h = rtems_filesystem_default_readlink,
>.rename_h = rtems_filesystem_default_rename,
> diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
> index 29b4207..c144773 100644
> --- a/cpukit/Makefile.am
> +++ b/cpukit/Makefile.am
> @@ -377,7 +377,7 @@ librtemscpu_a_SOURCES += 
> libfs/src/defaults/default_rmnod.c
>  librtemscpu_a_SOURCES += libfs/src/defaults/default_statvfs.c
>  librtemscpu_a_SOURCES += libfs/src/defaults/default_symlink.c
>  librtemscpu_a_SOURCES += libfs/src/defaults/default_unmount.c
> -librtemscpu_a_SOURCES += libfs/src/defaults/default_utime.c
> +librtemscpu_a_SOURCES += libfs/src/defaults/default_utimens.c
>  librtemscpu_a_SOURCES += libfs/src/defaults/default_write.c
>  librtemscpu_a_SOURCES += libfs/src/defaults/default_writev.c
>  librtemscpu_a_SOURCES += libfs/src/dosfs/fat.c
> @@ -434,7 +434,7 @@ librtemscpu_a_SOURCES += libfs/src/imfs/imfs_stat.c
>  librtemscpu_a_SOURCES += libfs/src/imfs/imfs_stat_file.c
>  librtemscpu_a_SOURCES += libfs/src/imfs/imfs_symlink.c
>  librtemscpu_a_SOURCES += libfs/src/imfs/imfs_unmount.c
> -librtemscpu_a_SOURCES += libfs/src/imfs/imfs_utime.c
> +librtemscpu_a_SOURCES += libfs/src/imfs/imfs_utimens.c
>  librtemscpu_a_SOURCES += libfs/src/imfs/ioman.c
>  librtemscpu_a_SOURCES += libfs/src/pipe/fifo.c
>  librtemscpu_a_SOURCES += libfs/src/pipe/pipe.c
> diff --git a/cpukit/include/rtems/confdefs/libio.h 
> b/cpukit/include/rtems/confdefs/libio.h
> index 16a4fb69..1b84f8c 100644
> --- a/cpukit/include/rtems/confdefs/libio.h
> +++ b/cpukit/include/rtems/confdefs/libio.h
> @@ -231,9 +231,9 @@ static const rtems_filesystem_operations_table 
> IMFS_root_ops = {
>#endif
>rtems_filesystem_default_fsunmount,
>#ifdef CONFIGURE_IMFS_DISABLE_UTIME
> -rtems_filesystem_default_utime,
> +rtems_filesystem_default_utimens,
>#else
> -IMFS_utime,
> +IMFS_utimens,
>#endif
>#ifdef CONFIGURE_IMFS_DISABLE_SYMLINK
>  rtems_filesystem_default_symlink,
> diff --git a/cpukit/include/rtems/imfs.h b/cpukit/include/rtems/imfs.h
> index b2a9868..6e0d5d5 100644
> --- a/cpukit/include/rtems/imfs.h
> +++ b/cpukit/include/rtems/imfs.h
> @@ -5,7 +5,7 @@
>   */
>
>  /*
> - *  COPYRIGHT (c) 1989-2011.
> + *  COPYRIGHT (c) 1989-2011, 2021.
>   *  On-Line Applications Research Corporation (OAR).
>   *
>   *  The license and distribution terms for this file may be
fix license?

> @@ -954,10 +954,9 @@ extern int device_ftruncate(
>   * This routine is the implementation of the utime() system
>   * call for the IMFS.
>   */
> -extern int IMFS_utime(
> +extern int IMFS_utimens(
>const rtems_filesystem_location_info_t *loc,
> -  time_t actime,
> -  time_t modtime
> +  struct timespec times[2]
>  );
>
>  /**
> diff --git a/cpukit/include/rtems/libio.h b/cpukit/include/rtems/libio.h
> index 519e797..99543ba 100644
> --- 

Re: [PATCH 2/2] bsp: Use RTEMS_NOINIT for bsp_fdt_blob

2021-05-10 Thread Sebastian Huber

Sorry, I sent the wrong patch set. Please ignore this one.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 1/2] score: Rename _Stack_Free_nothing()

2021-05-10 Thread Sebastian Huber
Rename _Stack_Free_nothing() in _Objects_Free_nothing() to make it
reusable for the message queue buffers.

Update #4007.
---
 cpukit/Makefile.am |  2 +-
 cpukit/include/rtems/score/objectimpl.h|  7 +++
 cpukit/include/rtems/score/stackimpl.h |  7 ---
 cpukit/include/rtems/score/threadimpl.h|  2 +-
 cpukit/posix/src/pthreadcreate.c   |  2 +-
 cpukit/rtems/src/taskconstruct.c   |  2 +-
 ...stackallocatorfreenothing.c => objectfreenothing.c} | 10 +-
 spec/build/cpukit/librtemscpu.yml  |  2 +-
 8 files changed, 17 insertions(+), 17 deletions(-)
 rename cpukit/score/src/{stackallocatorfreenothing.c => objectfreenothing.c} 
(90%)

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index c9600f7242..0178d5d82a 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -867,6 +867,7 @@ librtemscpu_a_SOURCES += score/src/objectallocateunlimited.c
 librtemscpu_a_SOURCES += score/src/objectclose.c
 librtemscpu_a_SOURCES += score/src/objectextendinformation.c
 librtemscpu_a_SOURCES += score/src/objectfree.c
+librtemscpu_a_SOURCES += score/src/objectfreenothing.c
 librtemscpu_a_SOURCES += score/src/objectfreestatic.c
 librtemscpu_a_SOURCES += score/src/objectgetnext.c
 librtemscpu_a_SOURCES += score/src/objectinitializeinformation.c
@@ -931,7 +932,6 @@ librtemscpu_a_SOURCES += score/src/schedulercbsreleasejob.c
 librtemscpu_a_SOURCES += score/src/schedulercbsunblock.c
 librtemscpu_a_SOURCES += score/src/stackallocator.c
 librtemscpu_a_SOURCES += score/src/stackallocatorfree.c
-librtemscpu_a_SOURCES += score/src/stackallocatorfreenothing.c
 librtemscpu_a_SOURCES += score/src/stackallocatorinit.c
 librtemscpu_a_SOURCES += score/src/pheapallocate.c
 librtemscpu_a_SOURCES += score/src/pheapextend.c
diff --git a/cpukit/include/rtems/score/objectimpl.h 
b/cpukit/include/rtems/score/objectimpl.h
index 54d6f0841b..0c9c85e062 100644
--- a/cpukit/include/rtems/score/objectimpl.h
+++ b/cpukit/include/rtems/score/objectimpl.h
@@ -954,6 +954,13 @@ RTEMS_INLINE_ROUTINE Objects_Control 
*_Objects_Allocate_with_extend(
   return the_object;
 }
 
+/**
+ * @brief This function does nothing.
+ *
+ * @param ptr is not used.
+ */
+void _Objects_Free_nothing( void *ptr );
+
 /** @} */
 
 #ifdef __cplusplus
diff --git a/cpukit/include/rtems/score/stackimpl.h 
b/cpukit/include/rtems/score/stackimpl.h
index c261f8bd4f..330fd32be7 100644
--- a/cpukit/include/rtems/score/stackimpl.h
+++ b/cpukit/include/rtems/score/stackimpl.h
@@ -194,13 +194,6 @@ void *_Stack_Allocate( size_t stack_size );
  */
 void _Stack_Free( void *stack_area );
 
-/**
- * @brief This function does nothing.
- *
- * @param stack_area is not used.
- */
-void _Stack_Free_nothing( void *stack_area );
-
 /** @} */
 
 #ifdef __cplusplus
diff --git a/cpukit/include/rtems/score/threadimpl.h 
b/cpukit/include/rtems/score/threadimpl.h
index c861e8b119..ba7c159962 100644
--- a/cpukit/include/rtems/score/threadimpl.h
+++ b/cpukit/include/rtems/score/threadimpl.h
@@ -144,7 +144,7 @@ typedef struct {
   /**
* @brief This member contains the handler to free the stack.
*
-   * It shall not be NULL.  Use _Stack_Free_nothing() if nothing is to free.
+   * It shall not be NULL.  Use _Objects_Free_nothing() if nothing is to free.
*/
   void ( *stack_free )( void * );
 
diff --git a/cpukit/posix/src/pthreadcreate.c b/cpukit/posix/src/pthreadcreate.c
index 055d304699..9474d07032 100644
--- a/cpukit/posix/src/pthreadcreate.c
+++ b/cpukit/posix/src/pthreadcreate.c
@@ -221,7 +221,7 @@ int pthread_create(
 config.stack_free = _Stack_Free;
 config.stack_area = _Stack_Allocate( config.stack_size );
   } else {
-config.stack_free = _Stack_Free_nothing;
+config.stack_free = _Objects_Free_nothing;
   }
 
   if ( config.stack_area == NULL ) {
diff --git a/cpukit/rtems/src/taskconstruct.c b/cpukit/rtems/src/taskconstruct.c
index e267db2fc5..6e03440aed 100644
--- a/cpukit/rtems/src/taskconstruct.c
+++ b/cpukit/rtems/src/taskconstruct.c
@@ -92,7 +92,7 @@ static rtems_status_code _RTEMS_tasks_Prepare_user_stack(
   if ( config->storage_free != NULL ) {
 thread_config->stack_free = config->storage_free;
   } else {
-thread_config->stack_free = _Stack_Free_nothing;
+thread_config->stack_free = _Objects_Free_nothing;
   }
 
   return RTEMS_SUCCESSFUL;
diff --git a/cpukit/score/src/stackallocatorfreenothing.c 
b/cpukit/score/src/objectfreenothing.c
similarity index 90%
rename from cpukit/score/src/stackallocatorfreenothing.c
rename to cpukit/score/src/objectfreenothing.c
index e341814b0c..0845d4c140 100644
--- a/cpukit/score/src/stackallocatorfreenothing.c
+++ b/cpukit/score/src/objectfreenothing.c
@@ -3,10 +3,10 @@
 /**
  * @file
  *
- * @ingroup RTEMSScoreStack
+ * @ingroup RTEMSScoreObject
  *
  * @brief This source file contains the implementation of
- *   _Stack_Free_nothing().
+ *   

[PATCH 2/2] rtems: Use _Objects_Free_nothing() for msg queues

2021-05-10 Thread Sebastian Huber
Use _Objects_Free_nothing() for rtems_message_queue_construct() to avoid
unreachable code in _CORE_message_queue_Close() in case only
user-provided message buffers are used.

Update #4007.
---
 cpukit/rtems/src/msgqconstruct.c | 7 ++-
 cpukit/score/src/coremsgclose.c  | 8 +++-
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/cpukit/rtems/src/msgqconstruct.c b/cpukit/rtems/src/msgqconstruct.c
index 6af57454cc..63ec75edff 100644
--- a/cpukit/rtems/src/msgqconstruct.c
+++ b/cpukit/rtems/src/msgqconstruct.c
@@ -41,7 +41,12 @@ static void *_Message_queue_Get_buffers(
 return NULL;
   }
 
-  the_message_queue->free_message_buffers = config->storage_free;
+  if ( config->storage_free != NULL ) {
+the_message_queue->free_message_buffers = config->storage_free;
+  } else {
+the_message_queue->free_message_buffers = _Objects_Free_nothing;
+  }
+
   return config->storage_area;
 }
 
diff --git a/cpukit/score/src/coremsgclose.c b/cpukit/score/src/coremsgclose.c
index 1610d8166b..aae3d5ae82 100644
--- a/cpukit/score/src/coremsgclose.c
+++ b/cpukit/score/src/coremsgclose.c
@@ -51,11 +51,9 @@ void _CORE_message_queue_Close(
 queue_context
   );
 
-  if ( the_message_queue->free_message_buffers != NULL ) {
-( *the_message_queue->free_message_buffers )(
-  the_message_queue->message_buffers
-);
-  }
+  ( *the_message_queue->free_message_buffers )(
+the_message_queue->message_buffers
+  );
 
   _Thread_queue_Destroy( _message_queue->Wait_queue );
 }
-- 
2.26.2

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


[PATCH 1/2] rtems: rtems_scheduler_get_processor_set() docs

2021-05-10 Thread Sebastian Huber
Document changed error status.

Update #4401.
---
 cpukit/include/rtems/rtems/tasks.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/include/rtems/rtems/tasks.h 
b/cpukit/include/rtems/rtems/tasks.h
index df4d7f3d03..e6f7696923 100644
--- a/cpukit/include/rtems/rtems/tasks.h
+++ b/cpukit/include/rtems/rtems/tasks.h
@@ -780,7 +780,7 @@ uint32_t rtems_scheduler_get_processor_maximum( void );
  * @retval ::RTEMS_INVALID_ID There was no scheduler associated with the
  *   identifier specified by ``scheduler_id``.
  *
- * @retval ::RTEMS_INVALID_NUMBER The provided processor set was too small for
+ * @retval ::RTEMS_INVALID_SIZE The provided processor set was too small for
  *   the set of processors owned by the scheduler.
  *
  * @par Constraints
-- 
2.26.2

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


[PATCH 2/2] bsp: Use RTEMS_NOINIT for bsp_fdt_blob

2021-05-10 Thread Sebastian Huber
This makes it possible to copy a boot loader provided device tree to
bsp_fdt_blob before the BSS section is cleared to zero.  The
disadvantage is that bsp_fdt_blob contains now uninitialized data.
---
 bsps/shared/start/bsp-fdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsps/shared/start/bsp-fdt.c b/bsps/shared/start/bsp-fdt.c
index 50a485eb16..9cd46e5927 100644
--- a/bsps/shared/start/bsp-fdt.c
+++ b/bsps/shared/start/bsp-fdt.c
@@ -32,7 +32,7 @@ static const uint32_t
 bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)] CPU_STRUCTURE_ALIGNMENT 
=
   { 0xdeadbeef };
 #else
-static uint32_t
+RTEMS_NOINIT static uint32_t
 bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)] CPU_STRUCTURE_ALIGNMENT;
 #endif
 
-- 
2.26.2

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


Re: [PATCH v2 1/5] libcsupport: Added futimens() and utimensat()

2021-05-10 Thread Gedare Bloom
On Thu, May 6, 2021 at 1:51 PM Ryan Long  wrote:
>
> Created futimens.c and utimensat.c to add support for the POSIX
> methods futimens() and utimensat().
>
> utime() and utimes() are considered obsolote by POSIX, but RTEMS
> will continue to support them.
>
> Closes #4396
> ---
>  cpukit/Makefile.am |   2 +
>  cpukit/include/rtems/libio_.h  |  60 +-
>  cpukit/libcsupport/src/futimens.c  |  87 ++
>  cpukit/libcsupport/src/utimensat.c | 239 
> +
>  spec/build/cpukit/librtemscpu.yml  |   2 +
>  5 files changed, 387 insertions(+), 3 deletions(-)
>  create mode 100644 cpukit/libcsupport/src/futimens.c
>  create mode 100644 cpukit/libcsupport/src/utimensat.c
>
> diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
> index b0df610..29b4207 100644
> --- a/cpukit/Makefile.am
> +++ b/cpukit/Makefile.am
> @@ -262,6 +262,8 @@ librtemscpu_a_SOURCES += libcsupport/src/unmount.c
>  librtemscpu_a_SOURCES += libcsupport/src/__usrenv.c
>  librtemscpu_a_SOURCES += libcsupport/src/utime.c
>  librtemscpu_a_SOURCES += libcsupport/src/utimes.c
> +librtemscpu_a_SOURCES += libcsupport/src/futimens.c
> +librtemscpu_a_SOURCES += libcsupport/src/utimensat.c
>  librtemscpu_a_SOURCES += libcsupport/src/utsname.c
>  librtemscpu_a_SOURCES += libcsupport/src/vprintk.c
>  librtemscpu_a_SOURCES += libcsupport/src/write.c
> diff --git a/cpukit/include/rtems/libio_.h b/cpukit/include/rtems/libio_.h
> index e9eb462..7a0a169 100644
> --- a/cpukit/include/rtems/libio_.h
> +++ b/cpukit/include/rtems/libio_.h
> @@ -2,13 +2,12 @@
>   * @file
>   *
>   * @brief LibIO Internal Interface
> - *
> + *
>   * This file is the libio internal interface.
>   */
>
>  /*
> - *  COPYRIGHT (c) 1989-2011.
> - *  On-Line Applications Research Corporation (OAR).
> + *  COPYRIGHT (C) 1989, 2021 On-Line Applications Research Corporation (OAR).
>   *
>   *  Modifications to support reference counting in the file system are
>   *  Copyright (c) 2012 embedded brains GmbH.
> @@ -357,6 +356,61 @@ static inline void rtems_filesystem_instance_unlock(
>(*mt_entry->ops->unlock_h)( mt_entry );
>  }
>
> +/* Prototypes for functions used between utimensat() and futimens() */
> +
We don't usually have this kind of separator comment.

> +/**
> + * @brief Checks the tv_sec member of a timespec struct
> + *
> + * @param[in] time The timespec struct to be validated
> + *
> + * Ensures that the value in the tv_sec member is non-negative.
> + *
> + * @retval Returns true if the tv_sec member is a valid value, otherwise 
> false.
> + */
> +bool rtems_filesystem_utime_tv_sec_valid( struct timespec time );
> +
Should this be a timespec helper instead? It seems like a
straightforward helper.

> +/**
> + * @brief Checks the tv_nsec member of a timespec struct
> + *
> + * Ensures that the value in the tv_nsec member is equal to either
> + * UTIME_NOW, UTIME_OMIT, or a value greater-than or equal to zero
> + * and less than a billion.
> + *
> + * @param[in] time The timespec struct to be validated
> + *
> + * @retval Returns true if tv_nsec member is a valid value, otherwise false.
> + */
> +bool rtems_filesystem_utime_tv_nsec_valid( struct timespec time );
> +
> +/**
> + * @brief Determines if the process has write permissions to a file
> + *
> + * Checks that the process has the same userID as the file and whether the
> + * file has write permissions.
> + *
> + * @param[in] currentloc The current location to a file
> + * @param[in] fstat_h The file handler of @currentloc
> + *
> + * @retval Returns 0 if the process has write permissions, otherwise -1.
> + */
> +int rtems_filesystem_utime_check_permissions(
> +  const rtems_filesystem_location_info_t *currentloc,
> +  const struct timespec times[2]
> +);
> +
The function name is overly broad. it seems like there should be a
filesystem helper that checks for write permission (or ownership).
I don't know why times[] is passed? What is @param[in] fstat_h?

Passing an array is a bit unusual.

> +/**
> + * @brief Checks @times and updates @new_times
> + *
> + * @param[in] times The timespec struct to be checked
> + * @param[in,out] new_times The timespec struct to contain the updated time
> + *
> + * @retval Returns 0 if the time was update, otherwise -1.
> + */
> +int rtems_filesystem_utime_check_times(
> +  const struct timespec times[2],
> +  struct timespec new_times[2]
> +);
Updates to what?

It may be simpler internally to explicitly refer to "access" and
"modified" times instead of times[0] and times[1]?

> +
>  /*
>   *  File Descriptor Routine Prototypes
>   */
> diff --git a/cpukit/libcsupport/src/futimens.c 
> b/cpukit/libcsupport/src/futimens.c
> new file mode 100644
> index 000..c2ef9da
> --- /dev/null
> +++ b/cpukit/libcsupport/src/futimens.c
> @@ -0,0 +1,87 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + *  @file
> + *
> + *  @ingroup libcsupport
> + *
> + *  @brief Set file access and modification times based on file descriptor 

Re: qemu-system-ppc64 does not work on powerpc/qoriq_e6500_64

2021-05-10 Thread Karel Gardas
On 5/10/21 2:26 PM, Richi Dubey wrote:
> Thanks, I'll check it out.

-bios `where you do have`/u-boot.e500.

Karel

> 
> On Mon, May 10, 2021 at 10:19 AM Sebastian Huber
>  > wrote:
> 
> On 09/05/2021 06:02, Richi Dubey wrote:
> > 0x42c8 199 SET_SELF_CPU_CONTROL CPU_SELF, r5
> > (gdb)
> > 0x in ?? ()
> > (gdb)
> > 0x in ?? ()
> > (gdb)
> > 0x in ?? ()
> > (gdb)
> > 0x in ?? ()
> > (gdb)
> > 0x in ?? ()
> > (gdb)
> >
> >
> - - 
> -
> 
> >
> > Is there a way to solve this?
> 
> This BSP assumes that it is booted via U-Boot. Maybe there is an option
> in Qemu to simulate this. Otherwise you probably have to change the
> startup sequence.
> 
> -- 
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> 
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
> 
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> 
> 
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 

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

Re: qemu-system-ppc64 does not work on powerpc/qoriq_e6500_64

2021-05-10 Thread Richi Dubey
Thanks, I'll check it out.

On Mon, May 10, 2021 at 10:19 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 09/05/2021 06:02, Richi Dubey wrote:
> > 0x42c8 199 SET_SELF_CPU_CONTROL CPU_SELF, r5
> > (gdb)
> > 0x in ?? ()
> > (gdb)
> > 0x in ?? ()
> > (gdb)
> > 0x in ?? ()
> > (gdb)
> > 0x in ?? ()
> > (gdb)
> > 0x in ?? ()
> > (gdb)
> >
> >
> - - -
>
> >
> > Is there a way to solve this?
>
> This BSP assumes that it is booted via U-Boot. Maybe there is an option
> in Qemu to simulate this. Otherwise you probably have to change the
> startup sequence.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v1 1/2] rtemsbd: Remove machine dependent files and use the ones from freebsd

2021-05-10 Thread Jan Sommer
- Remove cpufunc.h, bus.h and _bus.h from rtemsbd. Otherwise the same
files will be installed for all target architectures which can lead to
incompatibilities
- Instead use the machine dependent header files from freebsd
---
 freebsd/sys/arm/include/machine/_bus.h|  47 +
 freebsd/sys/arm/include/machine/bus.h | 769 
 freebsd/sys/arm64/include/machine/_bus.h  |  46 +
 freebsd/sys/arm64/include/machine/bus.h   | 469 ++
 freebsd/sys/powerpc/include/machine/_bus.h|  50 +
 freebsd/sys/powerpc/include/machine/bus.h | 467 ++
 freebsd/sys/riscv/include/machine/_bus.h  |  46 +
 freebsd/sys/riscv/include/machine/bus.h   | 469 ++
 freebsd/sys/riscv/include/machine/cpufunc.h   | 135 +++
 freebsd/sys/riscv/include/machine/riscvreg.h  | 246 +
 .../sys/sparc}/include/machine/_bus.h |   0
 .../sys/sparc}/include/machine/bus.h  |   0
 freebsd/sys/sparc/include/machine/cpufunc.h   |   0
 freebsd/sys/sparc64/include/machine/_bus.h|  41 +
 freebsd/sys/sparc64/include/machine/bus.h | 852 ++
 rtemsbsd/include/machine/cpufunc.h|   1 -
 16 files changed, 3637 insertions(+), 1 deletion(-)
 create mode 100644 freebsd/sys/arm/include/machine/_bus.h
 create mode 100644 freebsd/sys/arm/include/machine/bus.h
 create mode 100644 freebsd/sys/arm64/include/machine/_bus.h
 create mode 100644 freebsd/sys/arm64/include/machine/bus.h
 create mode 100644 freebsd/sys/powerpc/include/machine/_bus.h
 create mode 100644 freebsd/sys/powerpc/include/machine/bus.h
 create mode 100644 freebsd/sys/riscv/include/machine/_bus.h
 create mode 100644 freebsd/sys/riscv/include/machine/bus.h
 create mode 100644 freebsd/sys/riscv/include/machine/cpufunc.h
 create mode 100644 freebsd/sys/riscv/include/machine/riscvreg.h
 rename {rtemsbsd => freebsd/sys/sparc}/include/machine/_bus.h (100%)
 rename {rtemsbsd => freebsd/sys/sparc}/include/machine/bus.h (100%)
 create mode 100644 freebsd/sys/sparc/include/machine/cpufunc.h
 create mode 100644 freebsd/sys/sparc64/include/machine/_bus.h
 create mode 100644 freebsd/sys/sparc64/include/machine/bus.h
 delete mode 100644 rtemsbsd/include/machine/cpufunc.h

diff --git a/freebsd/sys/arm/include/machine/_bus.h 
b/freebsd/sys/arm/include/machine/_bus.h
new file mode 100644
index ..9bb51e98
--- /dev/null
+++ b/freebsd/sys/arm/include/machine/_bus.h
@@ -0,0 +1,47 @@
+/*-
+ * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
+ *
+ * Copyright (c) 2005 M. Warner Losh.
+ *
+ * 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,
+ *without modification, immediately at the beginning of the file.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in
+ *the documentation and/or other materials provided with the
+ *distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR
+ * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * $FreeBSD$
+ */
+
+#ifndef ARM_INCLUDE__BUS_H
+#define ARM_INCLUDE__BUS_H
+
+/*
+ * Addresses (in bus space).
+ */
+typedef u_long bus_addr_t;
+typedef u_long bus_size_t;
+
+/*
+ * Access methods for bus space.
+ */
+typedef struct bus_space *bus_space_tag_t;
+typedef u_long bus_space_handle_t;
+
+#endif /* ARM_INCLUDE__BUS_H */
diff --git a/freebsd/sys/arm/include/machine/bus.h 
b/freebsd/sys/arm/include/machine/bus.h
new file mode 100644
index ..37994f68
--- /dev/null
+++ b/freebsd/sys/arm/include/machine/bus.h
@@ -0,0 +1,769 @@
+/* $NetBSD: bus.h,v 1.11 2003/07/28 17:35:54 thorpej Exp $ */
+
+/*-
+ * Copyright (c) 1996, 1997, 1998, 2001 The NetBSD Foundation, Inc.
+ * All rights reserved.
+ *
+ * This code is derived from software contributed to The NetBSD Foundation
+ * by Jason R. Thorpe of the Numerical Aerospace Simulation Facility,
+ * NASA Ames Research Center.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions 

[PATCH 2/2] Fix the bibtex extension configure test

2021-05-10 Thread chrisj
From: Chris Johns 

---
 common/waf.py | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/common/waf.py b/common/waf.py
index 3806209..fa9aecb 100644
--- a/common/waf.py
+++ b/common/waf.py
@@ -181,10 +181,12 @@ def check_sphinx_extension(ctx, extension):
 def run_sphinx(bld):
 rst_node = bld.srcnode.make_node('testbuild/contents.rst')
 rst_node.parent.mkdir()
-rst_node.write('.. COMMENT test sphinx\n')
+rst_node.write('.. COMMENT test sphinx' + os.linesep)
 bib_node = bld.srcnode.make_node('testbuild/refs.bib')
+bib_node.write(os.linesep)
 conf_node = bld.srcnode.make_node('testbuild/conf.py')
-conf_node.write("bibtex_bibfiles = ['refs.bib']\n")
+conf_node.write(os.linesep.join(["master_doc='contents'",
+ "bibtex_bibfiles = ['refs.bib']"]))
 bld(rule = bld.kw['rule'], source = rst_node)
 
 ctx.start_msg("Checking for '%s'" % (extension))
-- 
2.24.3 (Apple Git-128)

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


Re: [PATCH rtems-libbsd v2] ipsec-tools/pfkey: Fix socket leak

2021-05-10 Thread Christian MAUDERER

Only change is a better description.

Am 10.05.21 um 08:50 schrieb Christian Mauderer:

setkey uses pfkey_open to open a socket. But setkey doesn't close the
socket.

The libipsec functions are used only by user space applications (setkey
and racoon). Adding the wrapper for socket makes sure that the opened
socket is registered and closes if the application exits.

Fixes #4404
---
  ipsec-tools/src/libipsec/pfkey.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/ipsec-tools/src/libipsec/pfkey.c b/ipsec-tools/src/libipsec/pfkey.c
index a621be12..385a21a9 100644
--- a/ipsec-tools/src/libipsec/pfkey.c
+++ b/ipsec-tools/src/libipsec/pfkey.c
@@ -1,5 +1,12 @@
  #include 
  
+#ifdef __rtems__

+/* Only need socket from rtems-bsd-program wrappers! */
+int
+rtems_bsd_program_socket(int domain, int type, int protocol);
+#define socket(domain, type, protocol) \
+rtems_bsd_program_socket(domain, type, protocol)
+#endif /* __rtems__ */
  /*$NetBSD: pfkey.c,v 1.21.2.1 2011/11/14 13:25:06 tteras Exp $*/
  
  /*	$KAME: pfkey.c,v 1.47 2003/10/02 19:52:12 itojun Exp $	*/




--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: qemu-system-ppc64 does not work on powerpc/qoriq_e6500_64

2021-05-10 Thread Sebastian Huber

On 09/05/2021 06:02, Richi Dubey wrote:

0x42c8 199 SET_SELF_CPU_CONTROL CPU_SELF, r5
(gdb)
0x in ?? ()
(gdb)
0x in ?? ()
(gdb)
0x in ?? ()
(gdb)
0x in ?? ()
(gdb)
0x in ?? ()
(gdb)

- - - 


Is there a way to solve this?


This BSP assumes that it is booted via U-Boot. Maybe there is an option 
in Qemu to simulate this. Otherwise you probably have to change the 
startup sequence.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC - Code Formatting and Style Checking for RTEMS score

2021-05-10 Thread Ida Delphine
Hello everyone,
Went through some previous emails and it turns out Sebastian already came
up with a configuration for clang format which works well for RTEMS except
for the fact that some configurations haven't been implemented into
clang-format yet. Using

AlignConsecutiveDeclarations: false
PointerAlignment: Right

Doesn't seem to work.
For example in the cpukit/score/src/threadq.c file, something like

RTEMS_STATIC_ASSERT(
offsetof( Thread_queue_Syslock_queue, Queue.name )
== offsetof( struct _Thread_queue_Queue, _name ),
THREAD_QUEUE_SYSLOCK_QUEUE_NAME
);

RTEMS_STATIC_ASSERT(
sizeof( Thread_queue_Syslock_queue )
== sizeof( struct _Thread_queue_Queue ),
THREAD_QUEUE_SYSLOCK_QUEUE_SIZE
);

#if defined(RTEMS_SMP)
void _Thread_queue_Do_acquire_critical(
Thread_queue_Control *the_thread_queue,
ISR_lock_Context *lock_context
)
{
_Thread_queue_Queue_acquire_critical(
_thread_queue->Queue,
_thread_queue->Lock_stats,
lock_context
);

becomes this after using the given configuration

RTEMS_STATIC_ASSERT(sizeof(Thread_queue_Syslock_queue) ==
sizeof(struct _Thread_queue_Queue),
THREAD_QUEUE_SYSLOCK_QUEUE_SIZE);

#if defined(RTEMS_SMP)
void _Thread_queue_Do_acquire_critical(Thread_queue_Control *
the_thread_queue,
ISR_lock_Context *lock_context) {
_Thread_queue_Queue_acquire_critical(
_thread_queue->Queue, _thread_queue->Lock_stats, lock_context);

Everything seems manageable except for this alignment issue...
This also throws more light on the changes using clang-format (
https://lists.rtems.org/pipermail/devel/2018-December/024145.html)

On Thu, May 6, 2021 at 8:05 PM Joel Sherrill  wrote:

>
>
> On Thu, May 6, 2021 at 12:47 PM Christian Mauderer 
> wrote:
>
>> Hello Ida and Gedare,
>>
>> On 06/05/2021 06:26, Gedare Bloom wrote:
>> > hi Ida,
>> >
>> > On Wed, May 5, 2021 at 3:21 PM Ida Delphine  wrote:
>> >>
>> >> Hello everyone,
>> >>
>> >> Regarding this project (https://devel.rtems.org/ticket/3860) I went
>> with clang-format as we all agreed. I have tested it on some "score" files
>> and it made some changes which I don't think are very much in line with the
>> RTEMS coding style. However, it wasn't really clear if we will chage the
>> RTEMS coding style or try to make changes to clang-format to fit the style.
>> >> Please will love to know the best option.
>> >>
>> > We will likely need to consider our choices carefully. If we can find
>> > a suitably close style that is already well-supported by clang, and
>> > get consensus from the maintainers on a change, then that might be the
>> > best route forward.
>>
>> +1
>>
>> > I think the first thing to do is take the examples
>> > that have been shown by Sebastian that are "close" but not quite
>> > perfect, and identify the cases where they differ with RTEMS style in
>> > order to present for discussion here. If consensus can't be reached to
>> > change the style, then we would need to have a plan for how to improve
>> > the existing tools for what we have.
>>
>> I also found the following tool quite useful to play with the clang
>> style config:
>>
>> https://zed0.co.uk/clang-format-configurator/
>>
>> Maybe it can help a bit to find out what certain options mean.
>>
>> >
>> > However, I think there is interest in doing less work on the tool
>> > side, and more work on how to integrate it into our workflows better.
>>
>> +1
>>
>
> I agree with all of this from the student perspective. But we will have
> to come to some agreement on a machine producible format to
> be able to use the integration. A report on what doesn't match would
> give us something to chew on while Ida works the integration.
>
> --joel
>
>>
>> >
>> >> Cheers,
>> >> Ida.
>> >> ___
>> >> devel mailing list
>> >> devel@rtems.org
>> >> http://lists.rtems.org/mailman/listinfo/devel
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>> >
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v1 0/2] [libbsd] Install correct machine include headers

2021-05-10 Thread Jan Sommer
Hello,

This is a follow-up on this discussion regarding the installed header files
in libbsd: https://lists.rtems.org/pipermail/devel/2021-April/066211.html

The current situation is, that for example for all machines the bus.h is 
installed from
within the rtemsbsd directory 
(https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/machine/bus.h).

According to the file docu it originates from the amd64 version of this file.
It also has the following section in it which we ran into when compiling Chris' 
ptpd2 archive:

#ifdef __i386__
  #error "your include paths are wrong"
#endif

This patchset does the following:
- Add the target dependent machine include directory to 'header-paths' in 
libbsd.py
- Import (mostly) '_bus.h', 'bus.h' and 'cpufunc.h' for the targets from 
freebsd-org
- Remove those header files from rtemsbsd directory

As a result the matching versions for machine dependent header files are now 
installed
for each BSP.
Would this be an acceptable solution?

So far I compiled some BSPs for i386, arm, aarch64, powerpc, riscv, sparc and 
sparc64 to check that they still compile after the changes.
Are there any other architectures which should be included?

I ran into one problem regarding the compilation of 
rtemsbsd/sys/dev/dw_mmc/dw_mmc.c:105

> return (bus_space_read_4(0, sc->bushandle, off));

The first parameter creates an error for riscv (I think because dereferencing a 
NULL pointer).
Are there any suggestion how to solve it (I am not familiar with the bus space 
and there is a lot of macro magic going on)?

Also, I am not sure if I always added the header files in the right
module in libbsd.py. Any suggestions where to put them instead would be welcome.

Best regards,

Jan

Jan Sommer (2):
  rtemsbd: Remove machine dependent files and use the ones from freebsd
  machine: Add machine dependent header files to libbsd.py

 freebsd/sys/arm/include/machine/_bus.h|  47 +
 freebsd/sys/arm/include/machine/bus.h | 769 
 freebsd/sys/arm64/include/machine/_bus.h  |  46 +
 freebsd/sys/arm64/include/machine/bus.h   | 469 ++
 freebsd/sys/powerpc/include/machine/_bus.h|  50 +
 freebsd/sys/powerpc/include/machine/bus.h | 467 ++
 freebsd/sys/riscv/include/machine/_bus.h  |  46 +
 freebsd/sys/riscv/include/machine/bus.h   | 469 ++
 freebsd/sys/riscv/include/machine/cpufunc.h   | 135 +++
 freebsd/sys/riscv/include/machine/riscvreg.h  | 246 +
 .../sys/sparc}/include/machine/_bus.h |   0
 .../sys/sparc}/include/machine/bus.h  |   0
 freebsd/sys/sparc/include/machine/cpufunc.h   |   0
 freebsd/sys/sparc64/include/machine/_bus.h|  41 +
 freebsd/sys/sparc64/include/machine/bus.h | 852 ++
 libbsd.py |  26 +-
 rtemsbsd/include/machine/cpufunc.h|   1 -
 waf_libbsd.py |   2 -
 18 files changed, 3660 insertions(+), 6 deletions(-)
 create mode 100644 freebsd/sys/arm/include/machine/_bus.h
 create mode 100644 freebsd/sys/arm/include/machine/bus.h
 create mode 100644 freebsd/sys/arm64/include/machine/_bus.h
 create mode 100644 freebsd/sys/arm64/include/machine/bus.h
 create mode 100644 freebsd/sys/powerpc/include/machine/_bus.h
 create mode 100644 freebsd/sys/powerpc/include/machine/bus.h
 create mode 100644 freebsd/sys/riscv/include/machine/_bus.h
 create mode 100644 freebsd/sys/riscv/include/machine/bus.h
 create mode 100644 freebsd/sys/riscv/include/machine/cpufunc.h
 create mode 100644 freebsd/sys/riscv/include/machine/riscvreg.h
 rename {rtemsbsd => freebsd/sys/sparc}/include/machine/_bus.h (100%)
 rename {rtemsbsd => freebsd/sys/sparc}/include/machine/bus.h (100%)
 create mode 100644 freebsd/sys/sparc/include/machine/cpufunc.h
 create mode 100644 freebsd/sys/sparc64/include/machine/_bus.h
 create mode 100644 freebsd/sys/sparc64/include/machine/bus.h
 delete mode 100644 rtemsbsd/include/machine/cpufunc.h

-- 
2.17.1

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


[PATCH rtems-libbsd v2] ipsec-tools/pfkey: Fix socket leak

2021-05-10 Thread Christian Mauderer
setkey uses pfkey_open to open a socket. But setkey doesn't close the
socket.

The libipsec functions are used only by user space applications (setkey
and racoon). Adding the wrapper for socket makes sure that the opened
socket is registered and closes if the application exits.

Fixes #4404
---
 ipsec-tools/src/libipsec/pfkey.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/ipsec-tools/src/libipsec/pfkey.c b/ipsec-tools/src/libipsec/pfkey.c
index a621be12..385a21a9 100644
--- a/ipsec-tools/src/libipsec/pfkey.c
+++ b/ipsec-tools/src/libipsec/pfkey.c
@@ -1,5 +1,12 @@
 #include 
 
+#ifdef __rtems__
+/* Only need socket from rtems-bsd-program wrappers! */
+int
+rtems_bsd_program_socket(int domain, int type, int protocol);
+#define socket(domain, type, protocol) \
+rtems_bsd_program_socket(domain, type, protocol)
+#endif /* __rtems__ */
 /* $NetBSD: pfkey.c,v 1.21.2.1 2011/11/14 13:25:06 tteras Exp $*/
 
 /* $KAME: pfkey.c,v 1.47 2003/10/02 19:52:12 itojun Exp $  */
-- 
2.26.2

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


[GSoC 2021] Beagle BSP USB OTG Support

2021-05-10 Thread Ahamed Husni
Hi all,

I need to debug the Beaglebone Black using JTAG. I got a TI LaunchPad
CC1310. Launchpad has a XDS110 debugger with a (ARM - not sure) 10 pin JTAG
out which can be used to debug external targets. The Beaglebone has a cTI
20 pin JTAG interface. Pin layouts for the ARM10 and cTI20 is given here.

http://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_jtag_connectors.html#connector-information

Can we map the pins, point to point without adapters to debug the BBB using
Launchpads's XDS110?

Following is what I came up with just refering the above given pin layouts.

*ARM10 to cTI20*

1==5 (VTRef/VCC)
2==1 (SWDIO/TMS)
3==8(GND)
4==9  (SWCLK/TCLK) SWDCLK(9) and TCK(11) are separate in cTI
5==10  (GND)
6==7(SWO/TDO)
7 KEYED
8==3 (NC/TDI)
9==12   (GNDDetect)
10==15  (nRESET)

Will this work? (EMU pins are not used here)

Also I found a discussion in TI' forum which says,

"Controlling the EMU0 and EMU1 signals, which are mandatory to place the
AM335x in debug mode."

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/777331/am3358-how-to-evaluate-if-a-jtag-chain-works-correctly

Also the hardware Mod for libdebugger in RTEMS connects the SWO/TDO(7) to
the EMU0(13).

https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#debugging-using-libdebugger

My Project Proposal:
https://docs.google.com/document/d/1CN3ri7g6NJeFPb5h8y4smr1aziGWyXbiiXUsFMhdUu4/edit?usp=sharing

Best regards,
Husni Faiz.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 1/2] Fix the linux specific include

2021-05-10 Thread chrisj
From: Chris Johns 

---
 common/latex.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/common/latex.py b/common/latex.py
index a1b3917..17d3015 100644
--- a/common/latex.py
+++ b/common/latex.py
@@ -4,10 +4,6 @@
 
 import os
 import re
-try:
-from distro import linux_distribution
-except:
-from platform import linux_distribution
 
 package_test_preamble = ['\\newif\\ifsphinxKeepOldNames 
\\sphinxKeepOldNamestrue',
  '\documentclass[a4paper,11pt,english]{report}']
@@ -85,6 +81,10 @@ def tex_test(test):
 def host_name():
 uname = os.uname()
 if uname[0] == 'Linux':
+try:
+from distro import linux_distribution
+except:
+from platform import linux_distribution
 distro = linux_distribution()
 name = '%s/%s' % (uname[0], distro[0])
 version = distro[1]
-- 
2.24.3 (Apple Git-128)

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


[PATCH v1 2/2] machine: Add machine dependent header files to libbsd.py

2021-05-10 Thread Jan Sommer
---
 libbsd.py | 26 +++---
 waf_libbsd.py |  2 --
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/libbsd.py b/libbsd.py
index add91e5a..248af993 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -104,6 +104,7 @@ _defaults = {
 # (source, [targets..])
 # i386
 ('freebsd/sys/i386/include', ['freebsd/sys/x86/include', 
'freebsd/sys/i386/include']),
+('freebsd/sys/i386/include/machine', 
['freebsd/sys/x86/include/machine', 'freebsd/sys/i386/include/machine']),
 # arm64
 ('freebsd/sys/aarch64/include', ['freebsd/sys/aarch64/include', 
'freebsd/sys/arm64/include']),
 ],
@@ -124,6 +125,7 @@ _defaults = {
 #  local path   wildcard   
dest path
 [('rtemsbsd/include',   '**/*.h',  
''),
  ('rtemsbsd/@CPU@/include', '**/*.h',  
''),
+ ('freebsd/sys/@CPU@/include',  '**/*.h',  
 ''),
  ('freebsd/include','**/*.h',  
''),
  ('freebsd/sys/bsm','**/*.h',  
'bsm'),
  ('freebsd/sys/cam','**/*.h',  
'cam'),
@@ -224,7 +226,7 @@ class rtems(builder.Module):
 'sys/arm/lpc/lpc_pwr.c',
 'sys/dev/atsam/if_atsam.c',
 'sys/dev/atsam/if_atsam_media.c',
-'sys/dev/dw_mmc/dw_mmc.c',
+#'sys/dev/dw_mmc/dw_mmc.c',
 'sys/dev/ffec/if_ffec_mcf548x.c',
 'sys/dev/ffec/if_ffec_mpc8xx.c',
 'sys/dev/input/touchscreen/tsc_lpc32xx.c',
@@ -595,6 +597,16 @@ class fdt(builder.Module):
 ],
 mm.generator['source']()
 )
+self.addCPUDependentFreeBSDHeaderFiles(
+[
+'sys/arm/include/_bus.h',
+'sys/arm/include/bus.h',
+'sys/arm64/include/_bus.h',
+'sys/arm64/include/bus.h',
+'sys/riscv/include/_bus.h',
+'sys/riscv/include/bus.h',
+]
+)
 self.addRTEMSKernelSourceFiles(
 [
 'rtems/ofw_machdep.c',
@@ -1600,6 +1612,8 @@ class dev_nic(builder.Module):
 'sys/sparc64/include/cpufunc.h',
 'sys/sparc64/include/asi.h',
 'sys/sparc64/include/pstate.h',
+'sys/riscv/include/cpufunc.h',
+'sys/riscv/include/riscvreg.h',
 ]
 )
 self.addKernelSpaceSourceFiles(
@@ -2937,6 +2951,10 @@ class pci(builder.Module):
 'sys/x86/include/legacyvar.h',
 'sys/x86/include/bus.h',
 'sys/x86/include/pci_cfgreg.h',
+'sys/powerpc/include/bus.h',
+'sys/powerpc/include/_bus.h',
+'sys/sparc64/include/bus.h',
+'sys/sparc64/include/_bus.h',
 ]
 )
 self.addCPUDependentFreeBSDSourceFiles(
@@ -5299,7 +5317,8 @@ class imx(builder.Module):
 
 def generate(self):
 mm = self.manager
-self.addKernelSpaceHeaderFiles(
+
+self.addCPUDependentFreeBSDHeaderFiles(
 [
 'sys/arm/freescale/imx/imx6_anatopreg.h',
 'sys/arm/freescale/imx/imx6_anatopvar.h',
@@ -5308,7 +5327,8 @@ class imx(builder.Module):
 'sys/arm/freescale/imx/imx_machdep.h',
 ]
 )
-self.addKernelSpaceSourceFiles(
+self.addCPUDependentFreeBSDSourceFiles(
+[ 'arm' ],
 [
 'sys/arm/freescale/imx/imx6_ccm.c',
 'sys/arm/freescale/imx/imx6_usbphy.c',
diff --git a/waf_libbsd.py b/waf_libbsd.py
index 070d3eac..bbbae929 100644
--- a/waf_libbsd.py
+++ b/waf_libbsd.py
@@ -538,8 +538,6 @@ class Builder(builder.ModuleManager):
 if 'header-paths' in config:
 headerPaths = config['header-paths']
 cpu = bld.get_env()['RTEMS_ARCH']
-if cpu == "i386":
-cpu = 'x86'
 for headers in headerPaths:
 # Get the dest path
 ipath = os.path.join(arch_inc_path, headers[2])
-- 
2.17.1

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


Re: [PATCH] bsps/raspberrypi/console: Fix default console device

2021-05-10 Thread Alan Cudmore
Hi Niteesh,
I was able to build the current RTEMS master (raspberrypi BSP) and I
was also able to successfully apply your patch and rebuild.
However, I am having trouble getting RTEMS running on the Raspberry Pis I have.
I tried it with and without the patch and I cannot get it to work. I
tried a Raspberry Pi Zero, B+, and Zero W ( with the patch).
I used these instructions for the firmware on SD card:
https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#raspberrypi

I tried:
- RTEMS master "arm/raspberrypi" BSP with and without the patch
- RTEMS 5 branch "arm/raspberrypi" BSP
- latest version of the RPI firmware files
- an older version of the RPI firmware (from June 2016)
I used the config.txt file that is recommended, but I did not have any
command line options. I did not have my raspberry Pis connected to
HDMI, only serial.

Can you describe your setup?
I know I have been through this before.

Thanks,
Alan

On Thu, May 6, 2021 at 10:48 AM Niteesh G. S.  wrote:
>
> Hi Alan,
>
> On Thu, May 6, 2021 at 6:12 PM Alan Cudmore  wrote:
>>
>> Hi Niteesh,
>>
>> I was hoping to try this out as soon as I get some time. No later than 
>> weekend. So if nobody else is able to check it out, I will be able to 
>> provide some feedback soon.
>>
>> I should be able to bring up the console on a RPi Zero W and RPi3, correct?
>
> the consoles should work on Zero W and Pi3 by default. They only fail to work 
> when  CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> this option is used. This is because when that option is used it calls 
> console_initialize which checks if any boot options were present if none were
> given it defaults to pl011 which is the secondary UART in Zero w and Pi3 so 
> we get no output. This patch defaults to the primary UART instead of
> pl011 depending on the board.
> Also, this patch should be applied on RTEMS 5 since we started supporting Pi3 
> and Zero w from RTEMS 5.
>
> Thanks,
> Niteesh.
>
>
>>
>> Thanks,
>>
>> Alan
>>
>>
>>
>> From: Niteesh G. S.
>> Sent: Thursday, May 6, 2021 4:29 AM
>> To: Joel Sherrill; Christian Mauderer
>> Cc: rtems-de...@rtems.org
>> Subject: Re: [PATCH] bsps/raspberrypi/console: Fix default console device
>>
>>
>>
>> ping.
>>
>>
>>
>> On Sat, May 1, 2021 at 9:47 PM Niteesh G. S.  wrote:
>>
>> On Sat, May 1, 2021 at 8:31 PM Joel Sherrill  wrote:
>>
>>
>>
>> On Sat, May 1, 2021, 8:53 AM Niteesh G. S.  wrote:
>>
>> Just to provide more context,
>>
>> When the CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER option is used
>>
>> and no --console option is provided, the console driver defaults to PL011.
>>
>> In raspberry pi 3 and other models whose primary UART is not PL011, we get 
>> no output.
>>
>> This patch fixes that by linking the primary UART to the console device.
>>
>>
>>
>> Thanks,
>>
>> Niteesh
>>
>>
>>
>> On Sat, May 1, 2021 at 7:05 PM G S Niteesh Babu  wrote:
>>
>> When no console argument is given, the driver defaults to pl011
>> this results in no output in case of Rpi3 whose primary uart is
>> miniuart.
>> This patch fixes that by defaulting to the primary uart when no
>> console option is provided.
>>
>>
>>
>> Does the default need to vary by model?
>>
>> Yes, the primary UART is different across models.
>>
>>
>>
>> Rpi's have two UARTs PL011 and miniuart, on models which have Bluetooth
>>
>> the PL011 is used to talk to the Bluetooth and miniuart acts as the primary 
>> UART.
>>
>> Now we can change this by adding miniuart-bt to config.txt but the miniuart 
>> is
>>
>> based on the VPU core and requires to add another option which sets the core 
>> to
>>
>> a fixed freq.
>>
>>
>>
>> ---
>>  bsps/arm/raspberrypi/console/console-config.c | 12 +---
>>  1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/bsps/arm/raspberrypi/console/console-config.c 
>> b/bsps/arm/raspberrypi/console/console-config.c
>> index 6b8eb80aa4..bd3a8d34c2 100644
>> --- a/bsps/arm/raspberrypi/console/console-config.c
>> +++ b/bsps/arm/raspberrypi/console/console-config.c
>> @@ -165,10 +165,16 @@ static void console_select( void )
>>  }
>>}else {
>>  /**
>> - * If no command line option was given, default to PL011.
>> + * If no console option was given we default to the primary uarts.
>> + * The initialization of the uart's and BSP_output_char is already done
>> + * in the uart_probe function called before this. So now we can safely
>> + * compare BSP_output_char.
>>   */
>> -BSP_output_char = output_char_pl011;
>> -link(PL011, CONSOLE_DEVICE_NAME);
>> +if (BSP_output_char == output_char_pl011) {
>> +  link(PL011, CONSOLE_DEVICE_NAME);
>> +}else {
>> +  link(MINIUART, CONSOLE_DEVICE_NAME);
>> +}
>>}
>>  }
>>
>> --
>> 2.17.1
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
___
devel mailing list
devel@rtems.org

Re: [GSoC 2021] Beagle BSP USB OTG Support

2021-05-10 Thread Christian MAUDERER

Hello Ahamed,

I'm using a J-Link to debug Beagle. I think that it doesn't have a EMU 
pin either. Only difference: It has an additional TRST. I would suggest 
to just try it.


I think on OpenOCD there are a few options regarding RST. You can have 
SRST only, TRST only, both connected together and both as separate pins.


Best regards

Christian

Am 10.05.21 um 06:09 schrieb Ahamed Husni:

Hi all,

I need to debug the Beaglebone Black using JTAG. I got a TI LaunchPad 
CC1310. Launchpad has a XDS110 debugger with a (ARM - not sure) 10 pin 
JTAG out which can be used to debug external targets. The Beaglebone has 
a cTI 20 pin JTAG interface. Pin layouts for the ARM10 and cTI20 is 
given here.


http://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_jtag_connectors.html#connector-information 



Can we map the pins, point to point without adapters to debug the BBB 
using Launchpads's XDS110?


Following is what I came up with just refering the above given pin layouts.

*ARM10 to cTI20*

1==5     (VTRef/VCC)
2==1     (SWDIO/TMS)
3==8    (GND)
4==9      (SWCLK/TCLK) SWDCLK(9) and TCK(11) are separate in cTI
5==10  (GND)
6==7    (SWO/TDO)
7 KEYED
8==3     (NC/TDI)
9==12   (GNDDetect)
10==15  (nRESET)

Will this work? (EMU pins are not used here)

Also I found a discussion in TI' forum which says,

"Controlling the EMU0 and EMU1 signals, which are mandatory to place the 
AM335x in debug mode."


https://e2e.ti.com/support/processors-group/processors/f/processors-forum/777331/am3358-how-to-evaluate-if-a-jtag-chain-works-correctly 



Also the hardware Mod for libdebugger in RTEMS connects the SWO/TDO(7) 
to the EMU0(13).


https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#debugging-using-libdebugger 



My Project Proposal:
https://docs.google.com/document/d/1CN3ri7g6NJeFPb5h8y4smr1aziGWyXbiiXUsFMhdUu4/edit?usp=sharing 



Best regards,
Husni Faiz.



--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/raspberrypi/console: Fix default console device

2021-05-10 Thread Gedare Bloom
On Thu, May 6, 2021 at 8:49 AM Niteesh G. S.  wrote:
>
> Hi Alan,
>
> On Thu, May 6, 2021 at 6:12 PM Alan Cudmore  wrote:
>>
>> Hi Niteesh,
>>
>> I was hoping to try this out as soon as I get some time. No later than 
>> weekend. So if nobody else is able to check it out, I will be able to 
>> provide some feedback soon.
>>
>> I should be able to bring up the console on a RPi Zero W and RPi3, correct?
>
> the consoles should work on Zero W and Pi3 by default. They only fail to work 
> when  CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> this option is used. This is because when that option is used it calls 
> console_initialize which checks if any boot options were present if none were
> given it defaults to pl011 which is the secondary UART in Zero w and Pi3 so 
> we get no output. This patch defaults to the primary UART instead of
> pl011 depending on the board.
> Also, this patch should be applied on RTEMS 5 since we started supporting Pi3 
> and Zero w from RTEMS 5.
>
You'll need to provide a separate patch with a ticket to close on 5
for a backport. Wait until you get the approval for the master branch
though.

> Thanks,
> Niteesh.
>
>
>>
>> Thanks,
>>
>> Alan
>>
>>
>>
>> From: Niteesh G. S.
>> Sent: Thursday, May 6, 2021 4:29 AM
>> To: Joel Sherrill; Christian Mauderer
>> Cc: rtems-de...@rtems.org
>> Subject: Re: [PATCH] bsps/raspberrypi/console: Fix default console device
>>
>>
>>
>> ping.
>>
>>
>>
>> On Sat, May 1, 2021 at 9:47 PM Niteesh G. S.  wrote:
>>
>> On Sat, May 1, 2021 at 8:31 PM Joel Sherrill  wrote:
>>
>>
>>
>> On Sat, May 1, 2021, 8:53 AM Niteesh G. S.  wrote:
>>
>> Just to provide more context,
>>
>> When the CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER option is used
>>
>> and no --console option is provided, the console driver defaults to PL011.
>>
>> In raspberry pi 3 and other models whose primary UART is not PL011, we get 
>> no output.
>>
>> This patch fixes that by linking the primary UART to the console device.
>>
>>
>>
>> Thanks,
>>
>> Niteesh
>>
>>
>>
>> On Sat, May 1, 2021 at 7:05 PM G S Niteesh Babu  wrote:
>>
>> When no console argument is given, the driver defaults to pl011
>> this results in no output in case of Rpi3 whose primary uart is
>> miniuart.
>> This patch fixes that by defaulting to the primary uart when no
>> console option is provided.
>>
>>
>>
>> Does the default need to vary by model?
>>
>> Yes, the primary UART is different across models.
>>
>>
>>
>> Rpi's have two UARTs PL011 and miniuart, on models which have Bluetooth
>>
>> the PL011 is used to talk to the Bluetooth and miniuart acts as the primary 
>> UART.
>>
>> Now we can change this by adding miniuart-bt to config.txt but the miniuart 
>> is
>>
>> based on the VPU core and requires to add another option which sets the core 
>> to
>>
>> a fixed freq.
>>
>>
>>
>> ---
>>  bsps/arm/raspberrypi/console/console-config.c | 12 +---
>>  1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/bsps/arm/raspberrypi/console/console-config.c 
>> b/bsps/arm/raspberrypi/console/console-config.c
>> index 6b8eb80aa4..bd3a8d34c2 100644
>> --- a/bsps/arm/raspberrypi/console/console-config.c
>> +++ b/bsps/arm/raspberrypi/console/console-config.c
>> @@ -165,10 +165,16 @@ static void console_select( void )
>>  }
>>}else {
>>  /**
>> - * If no command line option was given, default to PL011.
>> + * If no console option was given we default to the primary uarts.
>> + * The initialization of the uart's and BSP_output_char is already done
>> + * in the uart_probe function called before this. So now we can safely
>> + * compare BSP_output_char.
>>   */
>> -BSP_output_char = output_char_pl011;
>> -link(PL011, CONSOLE_DEVICE_NAME);
>> +if (BSP_output_char == output_char_pl011) {
>> +  link(PL011, CONSOLE_DEVICE_NAME);
>> +}else {
>> +  link(MINIUART, CONSOLE_DEVICE_NAME);
>> +}
>>}
>>  }
>>
>> --
>> 2.17.1
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel