qemu version for source builder

[Richi Dubey]

Hi,

rdubey@hpc1:~/quick-start/src/rsb$
~/quick-start/rtems/6/bin/qemu-system-ppc64  -machine help
Supported machines are:
40p  IBM RS/6000 7020 (40p)
bamboo   bamboo
g3beige  Heathrow based PowerMAC
mac99Mac99 based PowerMAC
mpc8544dsmpc8544ds
none empty machine
powernv10IBM PowerNV (Non-Virtualized) POWER10
powernv8 IBM PowerNV (Non-Virtualized) POWER8
powernv  IBM PowerNV (Non-Virtualized) POWER9 (alias of
powernv9)
powernv9 IBM PowerNV (Non-Virtualized) POWER9
ppce500  generic paravirt e500 platform
pseries-2.1  pSeries Logical Partition (PAPR compliant)
pseries-2.10 pSeries Logical Partition (PAPR compliant)
pseries-2.11 pSeries Logical Partition (PAPR compliant)
pseries-2.12 pSeries Logical Partition (PAPR compliant)
pseries-2.12-sxxmpSeries Logical Partition (PAPR compliant)
pseries-2.2  pSeries Logical Partition (PAPR compliant)
pseries-2.3  pSeries Logical Partition (PAPR compliant)
pseries-2.4  pSeries Logical Partition (PAPR compliant)
pseries-2.5  pSeries Logical Partition (PAPR compliant)
pseries-2.6  pSeries Logical Partition (PAPR compliant)
pseries-2.7  pSeries Logical Partition (PAPR compliant)
pseries-2.8  pSeries Logical Partition (PAPR compliant)
pseries-2.9  pSeries Logical Partition (PAPR compliant)
pseries-3.0  pSeries Logical Partition (PAPR compliant)
pseries-3.1  pSeries Logical Partition (PAPR compliant)
pseries-4.0  pSeries Logical Partition (PAPR compliant)
pseries-4.1  pSeries Logical Partition (PAPR compliant)
pseries-4.2  pSeries Logical Partition (PAPR compliant)
pseries-5.0  pSeries Logical Partition (PAPR compliant)
pseries-5.1  pSeries Logical Partition (PAPR compliant)
pseries  pSeries Logical Partition (PAPR compliant) (alias of
pseries-5.2)
pseries-5.2  pSeries Logical Partition (PAPR compliant) (default)
ref405ep ref405ep
sam460ex aCube Sam460ex
taihutaihu
virtex-ml507 Xilinx Virtex ML507 reference design

I got this qemu by using the source builder with this command: "
./source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6
devel/qemu.bset"
 So, does this qemu not support e6500 cores (for the t2080rdb platform)?

I read in a recent discussion about choosing qemu version:
https://lists.rtems.org/pipermail/devel/2020-May/059645.html. I can't seem
to get any version of qemu except the no-version named one:

rdubey@hpc1:~/quick-start/src/rsb$ ./source-builder/sb-set-builder
--prefix=$HOME/quick-start/rtems/6 devel/qemu4.bset
RTEMS Source Builder - Set Builder, 6 (4e256fc4cb0d)
Build Set: devel/qemu4.bset
error: no build set file found: devel/qemu4.bset
Build Set: Time 0:00:00.000433
Build FAILED
rdubey@hpc1:~/quick-start/src/rsb$ ./source-builder/sb-set-builder
--prefix=$HOME/quick-start/rtems/6 devel/qemu6.bset
RTEMS Source Builder - Set Builder, 6 (4e256fc4cb0d)
Build Set: devel/qemu6.bset
error: no build set file found: devel/qemu6.bset
Build Set: Time 0:00:00.000442
Build FAILED
rdubey@hpc1:~/quick-start/src/rsb$ ./source-builder/sb-set-builder
--prefix=$HOME/quick-start/rtems/6 devel/qemu5.bset
RTEMS Source Builder - Set Builder, 6 (4e256fc4cb0d)
Build Set: devel/qemu5.bset
error: no build set file found: devel/qemu5.bset
Build Set: Time 0:00:00.000493
Build FAILED
rdubey@hpc1:~/quick-start/src/rsb$ ./source-builder/sb-set-builder
--prefix=$HOME/quick-start/rtems/6 devel/qemu.bset
RTEMS Source Builder - Set Builder, 6 (4e256fc4cb0d)
Build Set: devel/qemu.bset
Build Set: devel/autotools-internal.bset
config: devel/autoconf-2.69-1.cfg
///
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] bsps/shared/ofw: Fix coverity defects

[Niteesh G. S.]

On Fri, May 7, 2021 at 4:16 AM Vijay Kumar Banerjee  wrote:

> On Thu, May 6, 2021 at 10:57 AM Gedare Bloom  wrote:
> >
> > ok, Vijay please push
>
> Pushed. Thanks.
>
Thanks for pushing.

>
> >
> > On Thu, May 6, 2021 at 2:06 AM G S Niteesh Babu 
> wrote:
> > >
> > > This patch adds asserts to fix coverity defects
> > > 1) CID 1474437 (Out-of-bounds access)
> > > 2) CID 1474436 (Out-of-bounds access)
> > >
> > > From manual inspection, out of bounds access cannot occur due to
> > > bounds checking but coverity fails to detect the checks.
> > > We are adding asserts as a secondary check.
> > > ---
> > >  bsps/shared/ofw/ofw.c | 12 +++-
> > >  1 file changed, 11 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
> > > index f4b8b63931..f7638b98ef 100644
> > > --- a/bsps/shared/ofw/ofw.c
> > > +++ b/bsps/shared/ofw/ofw.c
> > > @@ -42,6 +42,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >
> > >  static void *fdtp = NULL;
> > >
> > > @@ -186,6 +187,7 @@ ssize_t rtems_ofw_get_prop(
> > >const void *prop;
> > >int offset;
> > >int len;
> > > +  int copy_len;
> > >uint32_t cpuid;
> > >
> > >offset = rtems_fdt_phandle_to_offset(node);
> > > @@ -226,7 +228,9 @@ ssize_t rtems_ofw_get_prop(
> > >  return -1;
> > >}
> > >
> > > -  bcopy(prop, buf, MIN(len, bufsize));
> > > +  copy_len = MIN(len, bufsize);
> > > +  _Assert(copy_len <= bufsize);
> > > +  memmove(buf, prop, copy_len);
> > >
> > >return len;
> > >  }
> > > @@ -637,6 +641,12 @@ int rtems_ofw_get_reg(
> > >  range.child_bus = fdt32_to_cpu(ptr[j].child_bus);
> > >  range.size = fdt32_to_cpu(ptr[j].size);
> > >
> > > +/**
> > > + * (buf + size - (sizeof(buf[0]) - 1) is the last valid
> > > + * address for buf[i]. If buf[i] points to any address larger
> > > + * than this, it will be an out of bound access
> > > + */
> > > +_Assert(&buf[i] < (buf + size - (sizeof(buf[0]) - 1)));
> > >  if (buf[i].start >= range.child_bus &&
> > >  buf[i].start < range.child_bus + range.size) {
> > >offset = range.parent_bus - range.child_bus;
> > > --
> > > 2.17.1
> > >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project - Beagle BSP Projects

[Ahamed Husni]

Hi,

Sorry for not providing detailed explanations and for the late response.

On Sun, May 2, 2021 at 5:31 PM Christian Mauderer  wrote:

> Hello Husni,
>
> On 01/05/2021 23:38, Ahamed Husni wrote:
> > Hi all,
> >
> > My project proposal
> >
> https://docs.google.com/document/d/1CN3ri7g6NJeFPb5h8y4smr1aziGWyXbiiXUsFMhdUu4/edit?usp=sharing
> > <
> https://docs.google.com/document/d/1CN3ri7g6NJeFPb5h8y4smr1aziGWyXbiiXUsFMhdUu4/edit?usp=sharing
> >
> >
> > I tried to set up the JTAG Environment for the Beaglebone Black.
> > But I couldn't find the hardware anywhere in my country (Sri Lanka).
> >
> > I tried to,
> >
> >  1. Find TI XDS Debuggers
> >  2. Find a TI Launchpad so we can isolate and use the debugger in it.
>
> I assume you didn't find these?


Yes, that was the case until yesterday. Luckily I was able to find a TI
Launchpad CC1310 board.
Due to the Covid situation in the country, I'll only be able to get the
hardware on Monday.
So until then I won't be able to try anything related to JTAG.
Also I will need an ARM10-cTI20 JTAG adapter to use the XDS110 debugger in
the launchpad. I'll find it asap.


> >  3. Use RPi as a debugger using OpenOCD
>
> I would have expect that one to work (like nearly any OpenOCD debugger).
> What was the problem? Did OpenOCD detect the processor? What pins did
> you connect? Please provide some more details so we might can help with
> tips.
>


No. I didn't try it myself.
I found a discussion in TI. It looks like someone has tried it and wasn't
successful.
I didn't understand most of the technical stuff in the discussion.
It seems like he was able to program with JTAG but not debug.
https://e2e.ti.com/support/processors/f/processors-forum/777331/am3358-how-to-evaluate-if-a-jtag-chain-works-correctly

By the way: If you get it running it might would be a nice addition to
> the user manual:
>
>
> https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#debugging-beagle-bone-black-using-a-jtag-debugger-and-gdb
>
> That's currently mostly about the gdb part. You maybe could add two or
> three sentences and program calls how to start OpenOCD on a beagle and
> what pins can be used for it.
>
> >
> > I looked for the debuggers in major electronic shops, embedded systems
> > related companies,
> > university labs and etc. But couldn't find them.
> > Also these debuggers are expensive. When ordering online the shipping
> > charges are also high.
>
> I know from past GSoC that it can be difficult to get certain stuff in
> some countries. That's OK and I'm sure we find some solution.
>
> > So I can't guarantee that I can set up JTAG.
> >
> > Can we use RTEMS Libdebugger until we figure out the JTAG?
>
> I did too few stuff with libdebugger. So I don't know it really well. I
> _think_ that it needs a working network stack which would mean that you
> can only use it _after_ libbsd is initialized.
>
> Anyone: Please correct me if I'm wrong. If it would for example work
> with a serial interface, it should be OK.
>
> > Can we make a fallback plan for this project? If yes, what sorts of
> > changes should be made?
>
> I think the next best thing if you don't have a hardware debugger would
> be the RTEMS event recording. You have to instrument code and the
> processor has to be able to print an exception so you can get the data.
> You can't check anything on a instruction level but it's a great tool if
> you have to analyze the execution order of some problem cases. Most
> likely that will work for a lot of problems in your project too. So I
> would say that should be a fallback. Maybe you want to have a look at that:
>
> https://docs.rtems.org/branches/master/user/tracing/eventrecording.html
>
> Basically it's adding a few CONFIGURE_RECORD_... defines to your
> application, receive events with rtems-record-lttng via network or from
> a serial dump and then using Eclipse Trace Compass to analyze the trace.
> Please speak up if you need help setting that up.
>
>
For the last couple of days I've been learning about the rtems-libbsd.
I have built and installed the rtems-libbsd. I ran the Telnet testsuite on
the hardware.
Serial output is here .

Next I'll try out the libdebugger and event recording till I get the JTAG
hardwares.

Best regards,

Husni.

Best regards
>
> Christian
>
> >
> > Best regards,
> > Husni.
> >
> > On Fri, Apr 2, 2021 at 6:16 PM Christian Mauderer  > > wrote:
> >
> >
> >
> > On 02/04/2021 08:36, Ahamed Husni wrote:
> >  > > Yes, this seems like an area that can be chipped
> > away at, with a
> >  > > strong plan of activities. My concern would be
> > whether it is about
> >  > > writing code or not?
> >  > >
> >  > >
> >  > > After completing the above milestones, if we have more
> > time I can start
> >  > > to work on
> >  > > the Mass storage support.
> >  > >
> > 

Re: [PATCH v3] bsps/shared/ofw: Fix coverity defects

[Vijay Kumar Banerjee]

On Thu, May 6, 2021 at 10:57 AM Gedare Bloom  wrote:
>
> ok, Vijay please push

Pushed. Thanks.

>
> On Thu, May 6, 2021 at 2:06 AM G S Niteesh Babu  wrote:
> >
> > This patch adds asserts to fix coverity defects
> > 1) CID 1474437 (Out-of-bounds access)
> > 2) CID 1474436 (Out-of-bounds access)
> >
> > From manual inspection, out of bounds access cannot occur due to
> > bounds checking but coverity fails to detect the checks.
> > We are adding asserts as a secondary check.
> > ---
> >  bsps/shared/ofw/ofw.c | 12 +++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
> > index f4b8b63931..f7638b98ef 100644
> > --- a/bsps/shared/ofw/ofw.c
> > +++ b/bsps/shared/ofw/ofw.c
> > @@ -42,6 +42,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  static void *fdtp = NULL;
> >
> > @@ -186,6 +187,7 @@ ssize_t rtems_ofw_get_prop(
> >const void *prop;
> >int offset;
> >int len;
> > +  int copy_len;
> >uint32_t cpuid;
> >
> >offset = rtems_fdt_phandle_to_offset(node);
> > @@ -226,7 +228,9 @@ ssize_t rtems_ofw_get_prop(
> >  return -1;
> >}
> >
> > -  bcopy(prop, buf, MIN(len, bufsize));
> > +  copy_len = MIN(len, bufsize);
> > +  _Assert(copy_len <= bufsize);
> > +  memmove(buf, prop, copy_len);
> >
> >return len;
> >  }
> > @@ -637,6 +641,12 @@ int rtems_ofw_get_reg(
> >  range.child_bus = fdt32_to_cpu(ptr[j].child_bus);
> >  range.size = fdt32_to_cpu(ptr[j].size);
> >
> > +/**
> > + * (buf + size - (sizeof(buf[0]) - 1) is the last valid
> > + * address for buf[i]. If buf[i] points to any address larger
> > + * than this, it will be an out of bound access
> > + */
> > +_Assert(&buf[i] < (buf + size - (sizeof(buf[0]) - 1)));
> >  if (buf[i].start >= range.child_bus &&
> >  buf[i].start < range.child_bus + range.size) {
> >offset = range.parent_bus - range.child_bus;
> > --
> > 2.17.1
> >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Ryan Long]

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
@@ -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
--- a/cpukit/include/rtems/libio.h
+++ b/cpukit/include/rtems/libio.h
@@ -11,7 +11,7 @@
  */
 
 /*
- *  COPYRIGHT (c) 1989-2008.
+ *  COPYRIGHT (c) 1989-2008, 2021.
  *  On-Line Applications Research Corporation (OAR).
  *
  *  Modifications to support reference counting in the file system are
@@ -375,18 +37

[PATCH v2 4/5] psx13: Added tests for utimensat() and futimens()

[Ryan Long]

Improved tests for utime() and utimes() and update license.

Close #4399
---
 testsuites/psxtests/psx13/main.c |   5 +-
 testsuites/psxtests/psx13/test.c | 517 +--
 2 files changed, 498 insertions(+), 24 deletions(-)

diff --git a/testsuites/psxtests/psx13/main.c b/testsuites/psxtests/psx13/main.c
index f9e7907..7a560f9 100644
--- a/testsuites/psxtests/psx13/main.c
+++ b/testsuites/psxtests/psx13/main.c
@@ -1,5 +1,3 @@
-/*  SPDX-License-Identifier: BSD-2-Clause */
-
 /**
  *  @file
  *
@@ -8,8 +6,7 @@
  */
 
 /*
- *  COPYRIGHT (c) 1989-2009, 2021.
- *  On-Line Applications Research Corporation (OAR).
+ * COPYRIGHT (C) 1989, 2021 On-Line Applications Research Corporation (OAR).
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
diff --git a/testsuites/psxtests/psx13/test.c b/testsuites/psxtests/psx13/test.c
index e98b03a..cc929ef 100644
--- a/testsuites/psxtests/psx13/test.c
+++ b/testsuites/psxtests/psx13/test.c
@@ -1,5 +1,3 @@
-/*  SPDX-License-Identifier: BSD-2-Clause */
-
 /**
  *  @file
  *
@@ -17,12 +15,13 @@
  * - umask()
  * - utime()
  * - utimes()
+ * - utimensat()
+ * - futimens()
  * - sync()
  */
 
 /*
- *  COPYRIGHT (c) 1989-2009, 2021.
- *  On-Line Applications Research Corporation (OAR).
+ * COPYRIGHT (C) 1989, 2021 On-Line Applications Research Corporation (OAR).
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -210,8 +209,7 @@ static void Dup2Test( void )
 }
 
 /**
- * @brief Exercises fdatasync(). Does NOT test the functionality of the
- *underlying fdatasync entry in the IMFS op table.
+ * @brief Exercises fdatasync().
  */
 static void FDataSyncTest( void )
 {
@@ -259,60 +257,537 @@ static void UMaskTest( void )
 }
 
 /**
- * @brief Exercises utime(). Does not test the functionality of the
- *underlying utime entry in the IMFS op table.
+ * @brief Exercises utime().
  */
 static void UTimeTest( void )
 {
   int rv;
   struct utimbuf time;
+  struct timespec current_time;
   struct stat fstat;
 
-  /* First, an invalid filename. */
+  /* ENOENT test case */
+
+  /* Case: Pass an invalid filename. */
   rv = utime( "!This is an =invalid p@thname!!! :)", NULL );
   rtems_test_assert( rv == -1 );
   rtems_test_assert( errno == ENOENT );
 
-  /* Now, the success test. */
+  /* EACCES test case */
+
+  /* Case: Change user ID to someone besides root */
+  rv = seteuid( 1 );
+  rtems_test_assert( rv == 0 );
+
+  rv = utime( "testfile1.tst", NULL );
+  rtems_test_assert( rv == -1 );
+  rtems_test_assert( errno == EACCES );
+
+  rv = seteuid( 0 );
+  rtems_test_assert( rv == 0 );
+
+  /* EINVAL test cases */
+
+  /* Case: Invalid access time */
+  time.actime  = -1;
+  time.modtime = 54321;
+
+  rv = utime( "testfile1.tst", &time );
+  rtems_test_assert( rv == -1 );
+  rtems_test_assert( errno == EINVAL );
+
+  /* Case: Invalid modified time */
+  time.actime  = 12345;
+  time.modtime = -1;
+
+  rv = utime( "testfile1.tst", &time );
+  rtems_test_assert( rv == -1 );
+  rtems_test_assert( errno == EINVAL );
+
+  /* Successful test cases */
+
+  /* Case: Test without times argument */
+  clock_gettime( CLOCK_REALTIME, ¤t_time );
+
+  rv = utime( "testfile1.tst", NULL );
+  rtems_test_assert( rv == 0 );
+
+  rv = stat( "testfile1.tst", &fstat );
+  rtems_test_assert( rv == 0 );
+  rtems_test_assert( current_time.tv_sec <= fstat.st_atim.tv_sec );
+  rtems_test_assert( current_time.tv_sec <= fstat.st_mtim.tv_sec );
+
+  /* Case: time is filled with valid values */
   time.actime  = 12345;
   time.modtime = 54321;
 
   rv = utime( "testfile1.tst", &time );
   rtems_test_assert( rv == 0 );
 
-  /* But, did it set the time? */
+  /* Check that it actually changed the time */
   rv = stat( "testfile1.tst", &fstat );
   rtems_test_assert( rv == 0 );
   rtems_test_assert( fstat.st_atime == 12345 );
   rtems_test_assert( fstat.st_mtime == 54321 );
-
-  rv = utime( "testfile1.tst", NULL );
-  rtems_test_assert( rv == 0 );
 }
 
 /**
- * @brief Exercises utimes(). Does NOT test the functionality of the
- *underlying utime entry in the IMFS op table.
+ * @brief Exercises utimes().
  */
 static void UTimesTest( void )
 {
   int rv;
   struct timeval time[2];
+  struct timespec current_time;
   struct stat fstat;
 
-  /* First, an invalid filename. */
+  /* ENOENT test case */
+
+  /* Case: First, an invalid filename. */
   rv = utimes( "!This is an =invalid p@thname!!! : )", NULL);
   rtems_test_assert( rv == -1 );
   rtems_test_assert( errno == ENOENT );
 
-  /* Now, the success test. */
+  /* EACCES test case */
+
+  /* Change the user ID of the process to someone besides root */
+  rv = seteuid( 1 );
+  rtems_test_assert( rv == 0 );
+
+  rv = utimes( "testfile1.tst", NULL );
+  rtems_test_assert( rv == -1 );
+  rtems_test_assert( errno

[PATCH v2 3/5] libcsupport: Implement utimes() in terms of utimensat()

[Ryan Long]

utimes() now calls utimensat() to update file access
and modification timestamps.

Updated license.

Closes #4398
---
 cpukit/libcsupport/src/utimes.c | 51 ++---
 1 file changed, 38 insertions(+), 13 deletions(-)

diff --git a/cpukit/libcsupport/src/utimes.c b/cpukit/libcsupport/src/utimes.c
index 3dc47c0..eaed492 100644
--- a/cpukit/libcsupport/src/utimes.c
+++ b/cpukit/libcsupport/src/utimes.c
@@ -1,38 +1,63 @@
 /**
  *  @file
  *
- *  @brief Change File Last Access and Modification Times 
  *  @ingroup libcsupport
+ *
+ *  @brief Set file access and modification times in milliseconds.
  */
 
 /*
- *  Written by: Vinu Rajashekhar 
+ * COPYRIGHT (C) 1989, 2021 On-Line Applications Research Corporation (OAR).
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
  *
- *  The license and distribution terms for this file may be
- *  found in the file LICENSE in this distribution or at
- *  http://www.rtems.org/license/LICENSE.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
  */
 
 #ifdef HAVE_CONFIG_H
 #include "config.h"
 #endif
 
-#include 
-#include 
 #include 
 
+#include 
+
+/**
+ *  
https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/functions/futimens.html
+ *
+ *  Set file access and modification times
+ */
 int utimes(
   const char   *path,
   const struct timeval  times[2]
-) 
+)
 {
-  struct utimbuf timeinsecs;
+  struct timespec timeinsecs[2];
 
   if ( times == NULL )
-return utime( path, NULL );
+return utimensat( AT_FDCWD, path, NULL , 0 );
 
-  timeinsecs.actime  = times[0].tv_sec;
-  timeinsecs.modtime = times[1].tv_sec;
+  timeinsecs[0].tv_sec = times[0].tv_sec;
+  timeinsecs[0].tv_nsec = times[0].tv_usec * 1000;
+  timeinsecs[1].tv_sec = times[1].tv_sec;
+  timeinsecs[1].tv_nsec = times[1].tv_usec * 1000;
 
-  return utime( path, &timeinsecs );
+  return utimensat( AT_FDCWD, path, timeinsecs, 0 );
 }
-- 
1.8.3.1

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

[PATCH v2 2/5] libcsupport: Implement utime() in terms of utimensat()

[Ryan Long]

utime() now calls utimensat() to update file access
and modification timestamps.

Updated license.

Closes #4397
---
 cpukit/libcsupport/src/utime.c | 75 +++---
 1 file changed, 41 insertions(+), 34 deletions(-)

diff --git a/cpukit/libcsupport/src/utime.c b/cpukit/libcsupport/src/utime.c
index e2d8883..cca7eb5 100644
--- a/cpukit/libcsupport/src/utime.c
+++ b/cpukit/libcsupport/src/utime.c
@@ -1,58 +1,65 @@
 /**
  *  @file
  *
- *  @brief Set File Access and Modification Times
  *  @ingroup libcsupport
+ *
+ *  @brief Set file access and modification times in seconds.
  */
 
 /*
- *  COPYRIGHT (c) 1989-1999.
- *  On-Line Applications Research Corporation (OAR).
+ * COPYRIGHT (C) 1989, 2021 On-Line Applications Research Corporation (OAR).
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
  *
- *  The license and distribution terms for this file may be
- *  found in the file LICENSE in this distribution or at
- *  http://www.rtems.org/license/LICENSE.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
  */
 
 #ifdef HAVE_CONFIG_H
 #include "config.h"
 #endif
 
-/* FIXME: This include is a workaround for a broken  in Newlib */
-#include 
+#include 
+#include 
 
+#include 
 #include 
 
-#include 
-
 /**
- *  POSIX 1003.1b 5.5.6 - Set File Access and Modification Times
+ *  https://pubs.opengroup.org/onlinepubs/009604599/functions/utime.html
+ *
+ *  Set file access and modification times
  */
-int utime( const char *path, const struct utimbuf *times )
+int utime(
+  const char *path,
+  const struct utimbuf *times
+)
 {
-  int rv = 0;
-  rtems_filesystem_eval_path_context_t ctx;
-  int eval_flags = RTEMS_FS_FOLLOW_LINK;
-  const rtems_filesystem_location_info_t *currentloc =
-rtems_filesystem_eval_path_start( &ctx, path, eval_flags );
-  struct utimbuf now_times;
-
-  if ( times == NULL ) {
-time_t now = time( NULL );
-
-now_times.actime = now;
-now_times.modtime = now;
-
-times = &now_times;
-  }
+  struct timespec new_times[2];
 
-  rv = (*currentloc->mt_entry->ops->utime_h)(
-currentloc,
-times->actime,
-times->modtime
-  );
+  if ( times == NULL )
+return utimensat(AT_FDCWD, path, NULL, 0);
 
-  rtems_filesystem_eval_path_cleanup( &ctx );
+  new_times[0].tv_sec = times->actime;
+  new_times[0].tv_nsec = 0;
+  new_times[1].tv_sec = times->modtime;
+  new_times[1].tv_nsec = 0;
 
-  return rv;
+  return utimensat(AT_FDCWD, path, new_times, 0);
 }
-- 
1.8.3.1

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

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

[Ryan Long]

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() */
+
+/**
+ * @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 );
+
+/**
+ * @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]
+);
+
+/**
+ * @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]
+);
+
 /*
  *  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 in
+ *  nanoseconds.
+ */
+
+/*
+ * COPYRIGHT (C) 1989, 2021 On-Line Applications Research Corporation (OAR).
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANT

[PATCH v2 0/5] Add nanosecond support patch

[Ryan Long]

Hi,

Here's the patch set with the recommended changes. Joel, Kinsey, and I
changed the check for the EACCES and added the EPERM case. We believe
that it is correct now.

Thanks,
Ryan

Ryan Long (5):
  libcsupport: Added futimens() and utimensat()
  libcsupport: Implement utime() in terms of utimensat()
  libcsupport: Implement utimes() in terms of utimensat()
  psx13: Added tests for utimensat() and futimens()
  Change filesystem utime_h handler to utimens_h

 bsps/arm/csb337/umon/tfsDriver.c|   2 +-
 cpukit/Makefile.am  |   6 +-
 cpukit/include/rtems/confdefs/libio.h   |   4 +-
 cpukit/include/rtems/imfs.h |   7 +-
 cpukit/include/rtems/libio.h|  21 +-
 cpukit/include/rtems/libio_.h   |  60 +++-
 cpukit/libcsupport/src/__usrenv.c   |   9 +-
 cpukit/libcsupport/src/futimens.c   |  87 +
 cpukit/libcsupport/src/utime.c  |  75 ++--
 cpukit/libcsupport/src/utimensat.c  | 239 +
 cpukit/libcsupport/src/utimes.c |  51 ++-
 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   |   6 +-
 testsuites/psxtests/psx13/main.c|   5 +-
 testsuites/psxtests/psx13/test.c| 517 ++--
 25 files changed, 1084 insertions(+), 201 deletions(-)
 create mode 100644 cpukit/libcsupport/src/futimens.c
 create mode 100644 cpukit/libcsupport/src/utimensat.c
 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

-- 
1.8.3.1

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

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

[Joel Sherrill]

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

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

[Christian Mauderer]

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




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

Re: [PATCH v4] rtems-debugger: Fixed 32bit pointers

[Gedare Bloom]

On Thu, May 6, 2021 at 10:13 AM Joel Sherrill  wrote:
>
>
>
> On Wed, May 5, 2021 at 12:35 AM Gedare Bloom  wrote:
>>
>> On Tue, May 4, 2021 at 1:34 PM Stephen Clark  
>> wrote:
>> >
>> > Using 32bit types like uint32_t for pointers creates issues on 64 bit
>> > architectures like AArch64. Replaced occurrences of these with uintptr_t,
>> > which will work for both 32 and 64 bit architectures. Added hex_decode_addr
>> > function to rtems-debugger.
>> > ---
>> >  .../rtems/debugger/rtems-debugger-server.h|  5 
>> >  cpukit/libdebugger/rtems-debugger-server.c| 30 +++
>> >  cpukit/libdebugger/rtems-debugger-target.c|  2 +-
>> >  cpukit/libdebugger/rtems-debugger-target.h|  2 +-
>> >  4 files changed, 32 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/cpukit/include/rtems/debugger/rtems-debugger-server.h 
>> > b/cpukit/include/rtems/debugger/rtems-debugger-server.h
>> > index 2189aac873..beff302641 100644
>> > --- a/cpukit/include/rtems/debugger/rtems-debugger-server.h
>> > +++ b/cpukit/include/rtems/debugger/rtems-debugger-server.h
>> > @@ -50,6 +50,11 @@ extern "C" {
>> >   */
>> >  #define DB_UINT uint32_t
>> >
>> > +/**
>> > + * Data type for addresses. Here for 64bit support.
>> > + */
>> > +#define DB_ADDR uintptr_t
>> > +
>> >  /*
>> >   * Debugger signals.
>> >   */
>> > diff --git a/cpukit/libdebugger/rtems-debugger-server.c 
>> > b/cpukit/libdebugger/rtems-debugger-server.c
>> > index 975ec23a30..2ada418a79 100644
>> > --- a/cpukit/libdebugger/rtems-debugger-server.c
>> > +++ b/cpukit/libdebugger/rtems-debugger-server.c
>> > @@ -154,6 +154,26 @@ hex_encode(int val)
>> >return "0123456789abcdef"[val & 0xf];
>> >  }
>> >
>> > +static inline DB_ADDR
>> > +hex_decode_addr(const uint8_t* data)
>> > +{
>> > +  DB_ADDR ui = 0;
>> > +  size_t  i;
>> > +  if (data[0] == '-') {
>> > +if (data[1] == '1')
>> > +  ui = (DB_ADDR) -1;
>> > +  }
>> > +  else {
>> > +for (i = 0; i < (sizeof(ui) * 2); ++i) {
>> > +  int v = hex_decode(data[i]);
>> > +  if (v < 0)
>> > +break;
>> > +  ui = (ui << 4) | v;
>> > +}
>> > +  }
>> > +  return ui;
>> > +}
>> > +
>> This function body is identical to the following hex_decode_uint()
>> except for the type of DB_ADDR. They could probably be merged. Is
>> there a reason not to combine them and avoid the copy-paste?
>
>
> DB_ADDR aka uintptr_t is just stated as being large enough to hold
> an address. It is not listed in the set of types the C Standard makes
> size guarantees about. See
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf in
> section 5.2.4.2.1 for the relationship between types that are guaranteed.
> Notice that uintptr_t is just described in English when it shows up
> in the standard and not in this list.
>
> I don't think we can assume any specific integer type is equivalent to
> uintptr_t.
>
> It is a good example for function templates but they are not in C.
>
OK. probably this can be done with macros, but I won't push for that :)

>
>>
>> >  static inline DB_UINT
>> >  hex_decode_uint(const uint8_t* data)
>> >  {
>> > @@ -1438,10 +1458,10 @@ remote_read_memory(uint8_t* buffer, int size)
>> >if (comma == NULL)
>> >  remote_packet_out_str(r_E01);
>> >else {
>> > -DB_UINT addr;
>> > +uintptr_t addr;
>> >  DB_UINT length;
>> >  int r;
>> > -addr = hex_decode_uint(&buffer[1]);
>> > +addr = hex_decode_addr(&buffer[1]);
>> >  length = hex_decode_uint((const uint8_t*) comma + 1);
>> >  remote_packet_out_reset();
>> >  r = rtems_debugger_target_start_memory_access();
>> > @@ -1468,10 +1488,10 @@ remote_write_memory(uint8_t* buffer, int size)
>> >comma = strchr((const char*) buffer, ',');
>> >colon = strchr((const char*) buffer, ':');
>> >if (comma != NULL && colon != NULL) {
>> > -DB_UINT addr;
>> > +uintptr_t addr;
>> >  DB_UINT length;
>> >  int r;
>> > -addr = hex_decode_uint(&buffer[1]);
>> > +addr = hex_decode_addr(&buffer[1]);
>> >  length = hex_decode_uint((const uint8_t*) comma + 1);
>> >  r = rtems_debugger_target_start_memory_access();
>> >  if (r == 0) {
>> > @@ -1521,7 +1541,7 @@ remote_breakpoints(bool insert, uint8_t* buffer, int 
>> > size)
>> >uint32_t capabilities;
>> >DB_UINT  addr;
>> >DB_UINT  kind;
>> > -  addr = hex_decode_uint((const uint8_t*) comma1 + 1);
>> > +  addr = hex_decode_addr((const uint8_t*) comma1 + 1);
>> >kind = hex_decode_uint((const uint8_t*)comma2 + 1);
>> >capabilities = rtems_debugger_target_capabilities();
>> >switch (buffer[1]) {
>> > diff --git a/cpukit/libdebugger/rtems-debugger-target.c 
>> > b/cpukit/libdebugger/rtems-debugger-target.c
>> > index bf7579700d..34e4e84d2f 100644
>> > --- a/cpukit/libdebugger/rtems-debugger-target.c
>> > +++ b/cpukit/libdebugger/rtems-debugger-target.c
>> > @@ -168,7 +168,7 @@ rtems_debugger_target_reg_table_size(void)
>> >  }
>> >
>> >  int
>> > 

Re: [PATCH v3] bsps/shared/ofw: Fix coverity defects

[Gedare Bloom]

ok, Vijay please push

On Thu, May 6, 2021 at 2:06 AM G S Niteesh Babu  wrote:
>
> This patch adds asserts to fix coverity defects
> 1) CID 1474437 (Out-of-bounds access)
> 2) CID 1474436 (Out-of-bounds access)
>
> From manual inspection, out of bounds access cannot occur due to
> bounds checking but coverity fails to detect the checks.
> We are adding asserts as a secondary check.
> ---
>  bsps/shared/ofw/ofw.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
> index f4b8b63931..f7638b98ef 100644
> --- a/bsps/shared/ofw/ofw.c
> +++ b/bsps/shared/ofw/ofw.c
> @@ -42,6 +42,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  static void *fdtp = NULL;
>
> @@ -186,6 +187,7 @@ ssize_t rtems_ofw_get_prop(
>const void *prop;
>int offset;
>int len;
> +  int copy_len;
>uint32_t cpuid;
>
>offset = rtems_fdt_phandle_to_offset(node);
> @@ -226,7 +228,9 @@ ssize_t rtems_ofw_get_prop(
>  return -1;
>}
>
> -  bcopy(prop, buf, MIN(len, bufsize));
> +  copy_len = MIN(len, bufsize);
> +  _Assert(copy_len <= bufsize);
> +  memmove(buf, prop, copy_len);
>
>return len;
>  }
> @@ -637,6 +641,12 @@ int rtems_ofw_get_reg(
>  range.child_bus = fdt32_to_cpu(ptr[j].child_bus);
>  range.size = fdt32_to_cpu(ptr[j].size);
>
> +/**
> + * (buf + size - (sizeof(buf[0]) - 1) is the last valid
> + * address for buf[i]. If buf[i] points to any address larger
> + * than this, it will be an out of bound access
> + */
> +_Assert(&buf[i] < (buf + size - (sizeof(buf[0]) - 1)));
>  if (buf[i].start >= range.child_bus &&
>  buf[i].start < range.child_bus + range.size) {
>offset = range.parent_bus - range.child_bus;
> --
> 2.17.1
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v4] rtems-debugger: Fixed 32bit pointers

[Joel Sherrill]

On Wed, May 5, 2021 at 12:35 AM Gedare Bloom  wrote:

> On Tue, May 4, 2021 at 1:34 PM Stephen Clark 
> wrote:
> >
> > Using 32bit types like uint32_t for pointers creates issues on 64 bit
> > architectures like AArch64. Replaced occurrences of these with uintptr_t,
> > which will work for both 32 and 64 bit architectures. Added
> hex_decode_addr
> > function to rtems-debugger.
> > ---
> >  .../rtems/debugger/rtems-debugger-server.h|  5 
> >  cpukit/libdebugger/rtems-debugger-server.c| 30 +++
> >  cpukit/libdebugger/rtems-debugger-target.c|  2 +-
> >  cpukit/libdebugger/rtems-debugger-target.h|  2 +-
> >  4 files changed, 32 insertions(+), 7 deletions(-)
> >
> > diff --git a/cpukit/include/rtems/debugger/rtems-debugger-server.h
> b/cpukit/include/rtems/debugger/rtems-debugger-server.h
> > index 2189aac873..beff302641 100644
> > --- a/cpukit/include/rtems/debugger/rtems-debugger-server.h
> > +++ b/cpukit/include/rtems/debugger/rtems-debugger-server.h
> > @@ -50,6 +50,11 @@ extern "C" {
> >   */
> >  #define DB_UINT uint32_t
> >
> > +/**
> > + * Data type for addresses. Here for 64bit support.
> > + */
> > +#define DB_ADDR uintptr_t
> > +
> >  /*
> >   * Debugger signals.
> >   */
> > diff --git a/cpukit/libdebugger/rtems-debugger-server.c
> b/cpukit/libdebugger/rtems-debugger-server.c
> > index 975ec23a30..2ada418a79 100644
> > --- a/cpukit/libdebugger/rtems-debugger-server.c
> > +++ b/cpukit/libdebugger/rtems-debugger-server.c
> > @@ -154,6 +154,26 @@ hex_encode(int val)
> >return "0123456789abcdef"[val & 0xf];
> >  }
> >
> > +static inline DB_ADDR
> > +hex_decode_addr(const uint8_t* data)
> > +{
> > +  DB_ADDR ui = 0;
> > +  size_t  i;
> > +  if (data[0] == '-') {
> > +if (data[1] == '1')
> > +  ui = (DB_ADDR) -1;
> > +  }
> > +  else {
> > +for (i = 0; i < (sizeof(ui) * 2); ++i) {
> > +  int v = hex_decode(data[i]);
> > +  if (v < 0)
> > +break;
> > +  ui = (ui << 4) | v;
> > +}
> > +  }
> > +  return ui;
> > +}
> > +
> This function body is identical to the following hex_decode_uint()
> except for the type of DB_ADDR. They could probably be merged. Is
> there a reason not to combine them and avoid the copy-paste?
>

DB_ADDR aka uintptr_t is just stated as being large enough to hold
an address. It is not listed in the set of types the C Standard makes
size guarantees about. See
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf in
section 5.2.4.2.1 for the relationship between types that are guaranteed.
Notice that uintptr_t is just described in English when it shows up
in the standard and not in this list.

I don't think we can assume any specific integer type is equivalent to
uintptr_t.

It is a good example for function templates but they are not in C.



> >  static inline DB_UINT
> >  hex_decode_uint(const uint8_t* data)
> >  {
> > @@ -1438,10 +1458,10 @@ remote_read_memory(uint8_t* buffer, int size)
> >if (comma == NULL)
> >  remote_packet_out_str(r_E01);
> >else {
> > -DB_UINT addr;
> > +uintptr_t addr;
> >  DB_UINT length;
> >  int r;
> > -addr = hex_decode_uint(&buffer[1]);
> > +addr = hex_decode_addr(&buffer[1]);
> >  length = hex_decode_uint((const uint8_t*) comma + 1);
> >  remote_packet_out_reset();
> >  r = rtems_debugger_target_start_memory_access();
> > @@ -1468,10 +1488,10 @@ remote_write_memory(uint8_t* buffer, int size)
> >comma = strchr((const char*) buffer, ',');
> >colon = strchr((const char*) buffer, ':');
> >if (comma != NULL && colon != NULL) {
> > -DB_UINT addr;
> > +uintptr_t addr;
> >  DB_UINT length;
> >  int r;
> > -addr = hex_decode_uint(&buffer[1]);
> > +addr = hex_decode_addr(&buffer[1]);
> >  length = hex_decode_uint((const uint8_t*) comma + 1);
> >  r = rtems_debugger_target_start_memory_access();
> >  if (r == 0) {
> > @@ -1521,7 +1541,7 @@ remote_breakpoints(bool insert, uint8_t* buffer,
> int size)
> >uint32_t capabilities;
> >DB_UINT  addr;
> >DB_UINT  kind;
> > -  addr = hex_decode_uint((const uint8_t*) comma1 + 1);
> > +  addr = hex_decode_addr((const uint8_t*) comma1 + 1);
> >kind = hex_decode_uint((const uint8_t*)comma2 + 1);
> >capabilities = rtems_debugger_target_capabilities();
> >switch (buffer[1]) {
> > diff --git a/cpukit/libdebugger/rtems-debugger-target.c
> b/cpukit/libdebugger/rtems-debugger-target.c
> > index bf7579700d..34e4e84d2f 100644
> > --- a/cpukit/libdebugger/rtems-debugger-target.c
> > +++ b/cpukit/libdebugger/rtems-debugger-target.c
> > @@ -168,7 +168,7 @@ rtems_debugger_target_reg_table_size(void)
> >  }
> >
> >  int
> > -rtems_debugger_target_swbreak_control(bool insert, DB_UINT addr,
> DB_UINT kind)
> > +rtems_debugger_target_swbreak_control(bool insert, uintptr_t addr,
> DB_UINT kind)
> why not use DB_ADDR?
>

That should be DB_ADDR unless there is another sweep to eliminate DB_ADDR.
But I wouldn't d

Fwd: PowerPC Disassembler Fails to Compile on CentOS 7

[Joel Sherrill]

PowerPC failed to build on rtems7 and the next bump should fix it.

-- Forwarded message -
From: Joel Sherrill 
Date: Thu, May 6, 2021, 10:24 AM
Subject: Re: PowerPC Disassembler Fails to Compile on CentOS 7
To: H.J. Lu 
Cc: binutils 


Thanks. I guess the next bump in our bleeding edge tools will catch this
fix.

On Thu, May 6, 2021, 10:19 AM H.J. Lu  wrote:

> On Thu, May 6, 2021 at 8:14 AM Joel Sherrill  wrote:
> >
> > Hi
> >
> > binutils hash ed29efb which should be near the head appears to be
> assuming
> > that a newer GCC is being used which defaults to something else. The host
> > GCC reports:
> >
> > gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
> >
> > And the compilation fails with this:
> >
> > libtool: compile:  gcc -O2 -g -pipe
> >
> -I/home/joel/rtems-cron-7/rtems-source-builder/rtems/build/tmp/sb-1001/7/rtems-powerpc/home/joel/rtems-cron-7/tools/7/include
> > -DHAVE_CONFIG_H -I.
> -I../../sourceware-mirror-binutils-gdb-ed29efb/opcodes
> > -I. -I../../sourceware-mirror-binutils-gdb-ed29efb/opcodes -I../bfd
> > -I../../sourceware-mirror-binutils-gdb-ed29efb/opcodes/../include
> > -I../../sourceware-mirror-binutils-gdb-ed29efb/opcodes/../bfd -W -Wall
> > -Wstrict-prototypes -Wmissing-prototypes -Wshadow -g -O2 -MT ppc-opc.lo
> -MD
> > -MP -MF .deps/ppc-opc.Tpo -c
> > ../../sourceware-mirror-binutils-gdb-ed29efb/opcodes/ppc-opc.c -o
> ppc-opc.o
> > mv -f .deps/disassemble.Tpo .deps/disassemble.Plo
> > ../../sourceware-mirror-binutils-gdb-ed29efb/opcodes/ppc-dis.c: In
> function
> > 'print_insn_powerpc':
> > mv -f .deps/dis-buf.Tpo .deps/dis-buf.Plo
> > ../../sourceware-mirror-binutils-gdb-ed29efb/opcodes/ppc-dis.c:1071:8:
> > error: 'for' loop initial declarations are only allowed in C99 mode
> > for (int i = 0; i < 2; i++)
> > ^
> > ../../sourceware-mirror-binutils-gdb-ed29efb/opcodes/ppc-dis.c:1071:8:
> > note: use option -std=c99 or -std=gnu99 to compile your code
> >
> > Should the code not declare i in the for loop of the compiler arguments
> add
> > C99?
> >
> > --joel
>
> Should be fixed by:
>
> commit a8d6316b67d52eaa1b7b311084ddff71a66f7cc0
> Author: Nick Clifton 
> Date:   Tue May 4 13:40:34 2021 +0100
>
> Replace AC_PROG_CC with AC_PROG_CC_C99 in top level configure file.
>
> 2021-05-04  Nick Clifton  
>
> * configure.ac (AC_PROG_CC): Replace with AC_PROG_CC_C99.
> * configure: Regenerate.
>
> --
> H.J.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Niteesh G. S.]

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
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rtemstoolkit/mailer.py: Fix option ordering for add_arguments

[Alex White]

On Wed, May 5, 2021 at 10:15 PM Chris Johns  wrote:
>
> On 6/5/21 4:49 am, Gedare Bloom wrote:
> > On Wed, May 5, 2021 at 9:16 AM Alex White  wrote:
> >>
> >> On Wed, May 5, 2021 at 9:47 AM Gedare Bloom  wrote:
> >>>
> >>> Why?
> >>
> >> To prevent the '--mail' and '--use-gitconfig' options from being added 
> >> more than once to the ArgumentParser in add_arguments.
> >>
> > How does that happen?
> >
> > I'm not trying to be frustrating (just annoying). I want to be sure
> > we're using the right solution for the right problem, and not just
> > putting a bandaid over something so it works while we hide some
> > underlying concerns.

It happened because I did not know about the lack of a dictionary key ordering 
guarantee in Python (at least before 3.6 I believe) and because I forgot to 
update the start index for iterating the keys. I will take Chris's approach 
below.

>
> Gedare, I am agree. I think there maybe another simpler solution.
>
> Why not make the list() be something like ...
>
>   no_add = ['--mail', '--use-gitconfig']
>   for o in [opt for opt in list(_options) if not in no_add]:
> ..
>
> ... or something like that?

This seems more reliable as it avoids the magic number in the loop and should 
avoid introducing problems like this in the future. I'll get a v2 out with this 
added.

Thanks,

Alex

>
> Chris
> ___
> 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: Large compressed patch: posix-compliance: Update to include POSIX 1003.1-2017 (Issue 7).

[Joel Sherrill]

On Wed, May 5, 2021, 11:36 PM Gedare Bloom  wrote:

> Thanks Joel. Is this patch 2/2?  Go ahead.
>

Yeah.

I will commit it. Thanks.


> On Wed, May 5, 2021 at 3:36 PM Joel Sherrill  wrote:
> >
> > Hi
> >
> > This was too large to send through uncompressed so I am attaching it.
> Gedare's idea of not renaming the CSV to bump the version was good. But
> this change adds a new column for POSIX 1003.1-2017 (Issue 7). That's the
> worst case for patch size.
> >
> > bzip dropped it from 300+k to 16k so that's acceptable.
> >
> > --joel
> > ___
> > 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

[Alan Cudmore]

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? Thanks,Alan From: Niteesh G. S.Sent: Thursday, May 6, 2021 4:29 AMTo: Joel Sherrill; Christian MaudererCc: rtems-de...@rtems.orgSubject: 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 usedand 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 pl011this results in no output in case of Rpi3 whose primary uart isminiuart.This patch fixes that by defaulting to the primary uart when noconsole 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 Bluetooththe 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 isbased on the VPU core and requires to add another option which sets the core toa 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.cindex 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 listdevel@rtems.orghttp://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

[Niteesh G. S.]

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

Re: [PATCH v2] bsps/shared/ofw: Fix coverity defects

[Niteesh G. S.]

Hi,

I am really sorry for sending the wrong patch, the crash happened because of
wrong arguments to memove, bcopy has src first and dest second whereas it
is vice versa in memmove. I had fixed this but had sent the old one.
I am really sorry for the trouble. I'll make sure this doesn't happen again.

I have sent a v3 please take a look at that. I tested the patch by creating
a new
branch, applying the patch, and then building and testing. So I am sure it
will work.

Thanks,
Niteesh

On Thu, May 6, 2021 at 7:17 AM Vijay Kumar Banerjee  wrote:

> Hi all,
>
> On Wed, May 5, 2021 at 8:42 AM Gedare Bloom  wrote:
> >
> > alright looks good. Vijay or Christian please confirm and push if
> > you're good with it too.
> >
> ofw01.exe breaks after this patch. This probably needs some more debugging.
>
> If it helps, I'm pasting the error:
> ```
> *** FATAL ***
> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
>
> R0   = 0x8001e68c R8  = 0x8001e68c
> R1   = 0x80104641 R9  = 0x8005b90c
> R2   = 0x0030 R10 = 0x80104640
> R3   = 0x80104648 R11 = 0x0002
> R4   = 0x0008 R12 = 0x8001e68b
> R5   = 0x2ebc SP  = 0x801045b8
> R6   = 0x80104640 LR  = 0x8000d720
> R7   = 0x80101e28 PC  = 0x80011ba8
> CPSR = 0x8193 VEC = 0x0004
> RTEMS version: 6.0.0.cfabe5d6e9d8b428110732fffb7ff6ee8211de04
> RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB
> 4e256fc4cb0d91a098d2f3d88c3d302fc0426d56, Newlib 436e475)
> executing thread ID: 0x089010001
> executing thread name: IDLE
> U-Boot SPL 2018.09-2-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500)
> Trying to boot from MMC2
> Loading Environment from EXT4...
> ** Unable to use mmc 0:1 for loading the env **
>
> ```
>
> Best regards,
> Vijay
>
> > On Wed, May 5, 2021 at 12:52 AM Niteesh G. S. 
> wrote:
> > >
> > >
> > >
> > > On Mon, May 3, 2021 at 11:23 PM Gedare Bloom  wrote:
> > >>
> > >> Hi Niteesh,
> > >>
> > >> This looks good to me. What/how did you test it?
> > >
> > > I tested it using the ofw01 test
> > > https://git.rtems.org/rtems/tree/testsuites/libtests/ofw01/init.c
> > > and read EEPROM using i2c.
> > >
> > >>
> > >> Gedare
> > >>
> > >> On Sat, May 1, 2021 at 6:31 AM G S Niteesh Babu 
> wrote:
> > >> >
> > >> > This patch adds asserts to fix coverity defects
> > >> > 1) CID 1474437 (Out-of-bounds access)
> > >> > 2) CID 1474436 (Out-of-bounds access)
> > >> >
> > >> > From manual inspection, out of bounds access cannot occur due to
> > >> > bounds checking but coverity fails to detect the checks.
> > >> > We are adding asserts as a secondary check.
> > >> > ---
> > >> >  bsps/shared/ofw/ofw.c | 12 +++-
> > >> >  1 file changed, 11 insertions(+), 1 deletion(-)
> > >> >
> > >> > diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
> > >> > index f4b8b63931..0e0a7033ab 100644
> > >> > --- a/bsps/shared/ofw/ofw.c
> > >> > +++ b/bsps/shared/ofw/ofw.c
> > >> > @@ -42,6 +42,7 @@
> > >> >  #include 
> > >> >  #include 
> > >> >  #include 
> > >> > +#include 
> > >> >
> > >> >  static void *fdtp = NULL;
> > >> >
> > >> > @@ -186,6 +187,7 @@ ssize_t rtems_ofw_get_prop(
> > >> >const void *prop;
> > >> >int offset;
> > >> >int len;
> > >> > +  int copy_len;
> > >> >uint32_t cpuid;
> > >> >
> > >> >offset = rtems_fdt_phandle_to_offset(node);
> > >> > @@ -226,7 +228,9 @@ ssize_t rtems_ofw_get_prop(
> > >> >  return -1;
> > >> >}
> > >> >
> > >> > -  bcopy(prop, buf, MIN(len, bufsize));
> > >> > +  copy_len = MIN(len, bufsize);
> > >> > +  _Assert(copy_len <= bufsize);
> > >> > +  memmove(prop, buf, copy_len);
> > >> >
> > >> >return len;
> > >> >  }
> > >> > @@ -637,6 +641,12 @@ int rtems_ofw_get_reg(
> > >> >  range.child_bus = fdt32_to_cpu(ptr[j].child_bus);
> > >> >  range.size = fdt32_to_cpu(ptr[j].size);
> > >> >
> > >> > +/**
> > >> > + * (buf + size - (sizeof(buf[0]) - 1) is the last valid
> > >> > + * address for buf[i]. If buf[i] points to any address
> larger
> > >> > + * than this, it will be an out of bound access
> > >> > + */
> > >> > +_Assert(&buf[i] < (buf + size - (sizeof(buf[0]) - 1)));
> > >> >  if (buf[i].start >= range.child_bus &&
> > >> >  buf[i].start < range.child_bus + range.size) {
> > >> >offset = range.parent_bus - range.child_bus;
> > >> > --
> > >> > 2.17.1
> > >> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v3] bsps/shared/ofw: Fix coverity defects

[G S Niteesh Babu]

This patch adds asserts to fix coverity defects
1) CID 1474437 (Out-of-bounds access)
2) CID 1474436 (Out-of-bounds access)

>From manual inspection, out of bounds access cannot occur due to
bounds checking but coverity fails to detect the checks.
We are adding asserts as a secondary check.
---
 bsps/shared/ofw/ofw.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
index f4b8b63931..f7638b98ef 100644
--- a/bsps/shared/ofw/ofw.c
+++ b/bsps/shared/ofw/ofw.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static void *fdtp = NULL;
 
@@ -186,6 +187,7 @@ ssize_t rtems_ofw_get_prop(
   const void *prop;
   int offset;
   int len;
+  int copy_len;
   uint32_t cpuid;
 
   offset = rtems_fdt_phandle_to_offset(node);
@@ -226,7 +228,9 @@ ssize_t rtems_ofw_get_prop(
 return -1;
   }
 
-  bcopy(prop, buf, MIN(len, bufsize));
+  copy_len = MIN(len, bufsize);
+  _Assert(copy_len <= bufsize);
+  memmove(buf, prop, copy_len);
 
   return len;
 }
@@ -637,6 +641,12 @@ int rtems_ofw_get_reg(
 range.child_bus = fdt32_to_cpu(ptr[j].child_bus);
 range.size = fdt32_to_cpu(ptr[j].size);
 
+/**
+ * (buf + size - (sizeof(buf[0]) - 1) is the last valid
+ * address for buf[i]. If buf[i] points to any address larger
+ * than this, it will be an out of bound access
+ */
+_Assert(&buf[i] < (buf + size - (sizeof(buf[0]) - 1)));
 if (buf[i].start >= range.child_bus &&
 buf[i].start < range.child_bus + range.size) {
   offset = range.parent_bus - range.child_bus;
-- 
2.17.1

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