[PATCH 24/27] libfdt: Add support for disabling version checks

[Sebastian Huber]

From: Simon Glass 

Allow enabling FDT_ASSUME_LATEST to disable version checks.

Signed-off-by: Simon Glass 
Reviewed-by: David Gibson 
Message-Id: <20200220214557.176528-7-...@chromium.org>
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt.c| 34 +-
 cpukit/dtc/libfdt/fdt_ro.c | 16 
 cpukit/dtc/libfdt/fdt_rw.c |  6 +++---
 3 files changed, 32 insertions(+), 24 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt.c b/cpukit/dtc/libfdt/fdt.c
index 0dabb920ad..4419204a86 100644
--- a/cpukit/dtc/libfdt/fdt.c
+++ b/cpukit/dtc/libfdt/fdt.c
@@ -24,10 +24,13 @@ int32_t fdt_ro_probe_(const void *fdt)
 
if (fdt_magic(fdt) == FDT_MAGIC) {
/* Complete tree */
-   if (fdt_version(fdt) < FDT_FIRST_SUPPORTED_VERSION)
-   return -FDT_ERR_BADVERSION;
-   if (fdt_last_comp_version(fdt) > FDT_LAST_SUPPORTED_VERSION)
-   return -FDT_ERR_BADVERSION;
+   if (!can_assume(LATEST)) {
+   if (fdt_version(fdt) < FDT_FIRST_SUPPORTED_VERSION)
+   return -FDT_ERR_BADVERSION;
+   if (fdt_last_comp_version(fdt) >
+   FDT_LAST_SUPPORTED_VERSION)
+   return -FDT_ERR_BADVERSION;
+   }
} else if (fdt_magic(fdt) == FDT_SW_MAGIC) {
/* Unfinished sequential-write blob */
if (fdt_size_dt_struct(fdt) == 0)
@@ -75,7 +78,8 @@ size_t fdt_header_size_(uint32_t version)
 
 size_t fdt_header_size(const void *fdt)
 {
-   return fdt_header_size_(fdt_version(fdt));
+   return can_assume(LATEST) ? FDT_V17_SIZE :
+   fdt_header_size_(fdt_version(fdt));
 }
 
 int fdt_check_header(const void *fdt)
@@ -84,11 +88,14 @@ int fdt_check_header(const void *fdt)
 
if (fdt_magic(fdt) != FDT_MAGIC)
return -FDT_ERR_BADMAGIC;
-   if ((fdt_version(fdt) < FDT_FIRST_SUPPORTED_VERSION)
-   || (fdt_last_comp_version(fdt) > FDT_LAST_SUPPORTED_VERSION))
-   return -FDT_ERR_BADVERSION;
-   if (fdt_version(fdt) < fdt_last_comp_version(fdt))
-   return -FDT_ERR_BADVERSION;
+   if (!can_assume(LATEST)) {
+   if ((fdt_version(fdt) < FDT_FIRST_SUPPORTED_VERSION)
+   || (fdt_last_comp_version(fdt) >
+   FDT_LAST_SUPPORTED_VERSION))
+   return -FDT_ERR_BADVERSION;
+   if (fdt_version(fdt) < fdt_last_comp_version(fdt))
+   return -FDT_ERR_BADVERSION;
+   }
hdrsize = fdt_header_size(fdt);
if (!can_assume(VALID_DTB)) {
 
@@ -104,7 +111,7 @@ int fdt_check_header(const void *fdt)
 
if (!can_assume(VALID_DTB)) {
/* Bounds check structure block */
-   if (fdt_version(fdt) < 17) {
+   if (!can_assume(LATEST) && fdt_version(fdt) < 17) {
if (!check_off_(hdrsize, fdt_totalsize(fdt),
fdt_off_dt_struct(fdt)))
return -FDT_ERR_TRUNCATED;
@@ -135,7 +142,7 @@ const void *fdt_offset_ptr(const void *fdt, int offset, 
unsigned int len)
|| (absoffset + len) > fdt_totalsize(fdt))
return NULL;
 
-   if (fdt_version(fdt) >= 0x11)
+   if (can_assume(LATEST) || fdt_version(fdt) >= 0x11)
if (((offset + len) < offset)
|| ((offset + len) > fdt_size_dt_struct(fdt)))
return NULL;
@@ -175,7 +182,8 @@ uint32_t fdt_next_tag(const void *fdt, int startoffset, int 
*nextoffset)
/* skip-name offset, length and value */
offset += sizeof(struct fdt_property) - FDT_TAGSIZE
+ fdt32_to_cpu(*lenp);
-   if (fdt_version(fdt) < 0x10 && fdt32_to_cpu(*lenp) >= 8 &&
+   if (!can_assume(LATEST) &&
+   fdt_version(fdt) < 0x10 && fdt32_to_cpu(*lenp) >= 8 &&
((offset - fdt32_to_cpu(*lenp)) % 8) != 0)
offset += 4;
break;
diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index 9c325591ae..2fa768e56c 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -60,7 +60,7 @@ const char *fdt_get_string(const void *fdt, int stroffset, 
int *lenp)
if (fdt_magic(fdt) == FDT_MAGIC) {
if (stroffset < 0)
goto fail;
-   if (fdt_version(fdt) >= 17) {
+   if (can_assume(LATEST) || fdt_version(fdt) >= 17) {
if (stroffset >= fdt_size_dt_strings(fdt))
goto fail;
if ((fdt_size_dt_strings(fdt) - stroffset) < len)
@@ -307,7 +307,7 @@ const char *fdt_get_name(const void *fdt, int nodeoffset, 
int *len)
 
nameptr = nh->name;
 
- 

[PATCH 16/27] libfdt: Allow #size-cells of 0

[Sebastian Huber]

From: David Gibson 

c12b2b0c20eb "libfdt: fdt_address_cells() and fdt_size_cells()" introduced
a bug as it consolidated code between the helpers for getting
#address-cells and #size-cells.  Specifically #size-cells is allowed to
be 0, and is frequently found so in practice for /cpus.  IEEE1275 only
requires implementations to handle 1..4 for #address-cells, although one
could make a case for #address-cells == #size-cells == 0 being used to
represent a bridge with a single port.

While we're there, it's not totally obvious that the existing implicit
cast of a u32 to int will give the correct results according to strict C,
although it does work in practice.  Straighten that up to cast only after
we've made our range checks.

Reported-by: yonghuhaige via https://github.com/dgibson/dtc/issues/28
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_addresses.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt_addresses.c 
b/cpukit/dtc/libfdt/fdt_addresses.c
index d8ba8ec60c..9a82cd0ba2 100644
--- a/cpukit/dtc/libfdt/fdt_addresses.c
+++ b/cpukit/dtc/libfdt/fdt_addresses.c
@@ -14,7 +14,7 @@
 static int fdt_cells(const void *fdt, int nodeoffset, const char *name)
 {
const fdt32_t *c;
-   int val;
+   uint32_t val;
int len;
 
c = fdt_getprop(fdt, nodeoffset, name, );
@@ -25,10 +25,10 @@ static int fdt_cells(const void *fdt, int nodeoffset, const 
char *name)
return -FDT_ERR_BADNCELLS;
 
val = fdt32_to_cpu(*c);
-   if ((val <= 0) || (val > FDT_MAX_NCELLS))
+   if (val > FDT_MAX_NCELLS)
return -FDT_ERR_BADNCELLS;
 
-   return val;
+   return (int)val;
 }
 
 int fdt_address_cells(const void *fdt, int nodeoffset)
@@ -36,6 +36,8 @@ int fdt_address_cells(const void *fdt, int nodeoffset)
int val;
 
val = fdt_cells(fdt, nodeoffset, "#address-cells");
+   if (val == 0)
+   return -FDT_ERR_BADNCELLS;
if (val == -FDT_ERR_NOTFOUND)
return 2;
return val;
-- 
2.16.4

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

[PATCH 15/27] libfdt: Tweak data handling to satisfy Coverity

[Sebastian Huber]

From: David Gibson 

In libfdt we often sanity test fdt_totalsize(fdt) fairly early, then
trust it (but *only* that header field) for the remainder of our work.
However, Coverity gets confused by this - it sees the byteswap in
fdt32_ld() and assumes that means it is coming from an untrusted source
everytime, resulting in many tainted data warnings.

Most of these end up with logic in fdt_get_string() as the unsafe
destination for this tainted data, so let's tweak the logic there to make
it clearer to Coverity that this is ok.

We add a sanity test on fdt_totalsize() to fdt_probe_ro_().  Because the
interface allows bare ints to be used for offsets, we already have the
assumption that totalsize must be 31-bits or less (2GiB would be a
ludicrously large fdt).  This makes this more explicit.

We also make fdt_probe_ro() return the size for convenience, and change the
logic in fdt_get_string() to keep it in a local so that Coverity can see
that it has already been bounds-checked.

Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt.c |  9 +++--
 cpukit/dtc/libfdt/fdt_ro.c  | 11 ++-
 cpukit/dtc/libfdt/libfdt_internal.h | 10 +-
 3 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt.c b/cpukit/dtc/libfdt/fdt.c
index 179168ec63..d6ce7c052d 100644
--- a/cpukit/dtc/libfdt/fdt.c
+++ b/cpukit/dtc/libfdt/fdt.c
@@ -15,8 +15,10 @@
  * that the given buffer contains what appears to be a flattened
  * device tree with sane information in its header.
  */
-int fdt_ro_probe_(const void *fdt)
+int32_t fdt_ro_probe_(const void *fdt)
 {
+   uint32_t totalsize = fdt_totalsize(fdt);
+
if (fdt_magic(fdt) == FDT_MAGIC) {
/* Complete tree */
if (fdt_version(fdt) < FDT_FIRST_SUPPORTED_VERSION)
@@ -31,7 +33,10 @@ int fdt_ro_probe_(const void *fdt)
return -FDT_ERR_BADMAGIC;
}
 
-   return 0;
+   if (totalsize < INT32_MAX)
+   return totalsize;
+   else
+   return -FDT_ERR_TRUNCATED;
 }
 
 static int check_off_(uint32_t hdrsize, uint32_t totalsize, uint32_t off)
diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index 6fd9ec170d..a5c2797cde 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -33,19 +33,20 @@ static int fdt_nodename_eq_(const void *fdt, int offset,
 
 const char *fdt_get_string(const void *fdt, int stroffset, int *lenp)
 {
+   int32_t totalsize = fdt_ro_probe_(fdt);
uint32_t absoffset = stroffset + fdt_off_dt_strings(fdt);
size_t len;
int err;
const char *s, *n;
 
-   err = fdt_ro_probe_(fdt);
-   if (err != 0)
+   err = totalsize;
+   if (totalsize < 0)
goto fail;
 
err = -FDT_ERR_BADOFFSET;
-   if (absoffset >= fdt_totalsize(fdt))
+   if (absoffset >= totalsize)
goto fail;
-   len = fdt_totalsize(fdt) - absoffset;
+   len = totalsize - absoffset;
 
if (fdt_magic(fdt) == FDT_MAGIC) {
if (stroffset < 0)
@@ -288,7 +289,7 @@ const char *fdt_get_name(const void *fdt, int nodeoffset, 
int *len)
const char *nameptr;
int err;
 
-   if (((err = fdt_ro_probe_(fdt)) != 0)
+   if (((err = fdt_ro_probe_(fdt)) < 0)
|| ((err = fdt_check_node_offset_(fdt, nodeoffset)) < 0))
goto fail;
 
diff --git a/cpukit/dtc/libfdt/libfdt_internal.h 
b/cpukit/dtc/libfdt/libfdt_internal.h
index 7830e550c3..741eeb3150 100644
--- a/cpukit/dtc/libfdt/libfdt_internal.h
+++ b/cpukit/dtc/libfdt/libfdt_internal.h
@@ -11,11 +11,11 @@
 #define FDT_TAGALIGN(x)(FDT_ALIGN((x), FDT_TAGSIZE))
 
 int fdt_ro_probe_(const void *fdt);
-#define FDT_RO_PROBE(fdt)  \
-   { \
-   int err_; \
-   if ((err_ = fdt_ro_probe_(fdt)) != 0)   \
-   return err_; \
+#define FDT_RO_PROBE(fdt)  \
+   {   \
+   int totalsize_; \
+   if ((totalsize_ = fdt_ro_probe_(fdt)) < 0)  \
+   return totalsize_;  \
}
 
 int fdt_check_node_offset_(const void *fdt, int offset);
-- 
2.16.4

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

[PATCH 18/27] libfdt: Correct prototype for fdt_ro_probe_()

[Sebastian Huber]

From: David Gibson 

This function returns an int32_t, however the prototype in
libfdt_internal.h shows it returning an int.  We haven't caught this before
because they're the same type on nearly all platforms this gets built on.
Apparently it's not the case on FreeRTOS, so someone hit this mismatch
building for that platform.

Reported-by: dharani kumar 
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/libfdt_internal.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cpukit/dtc/libfdt/libfdt_internal.h 
b/cpukit/dtc/libfdt/libfdt_internal.h
index 741eeb3150..058c7358d4 100644
--- a/cpukit/dtc/libfdt/libfdt_internal.h
+++ b/cpukit/dtc/libfdt/libfdt_internal.h
@@ -10,10 +10,10 @@
 #define FDT_ALIGN(x, a)(((x) + (a) - 1) & ~((a) - 1))
 #define FDT_TAGALIGN(x)(FDT_ALIGN((x), FDT_TAGSIZE))
 
-int fdt_ro_probe_(const void *fdt);
+int32_t fdt_ro_probe_(const void *fdt);
 #define FDT_RO_PROBE(fdt)  \
{   \
-   int totalsize_; \
+   int32_t totalsize_; \
if ((totalsize_ = fdt_ro_probe_(fdt)) < 0)  \
return totalsize_;  \
}
-- 
2.16.4

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

[PATCH 22/27] libfdt: Add support for disabling sanity checks

[Sebastian Huber]

From: Simon Glass 

Allow enabling ASSUME_VALID_INPUT to disable sanity checks on the device
tree and the parameters to libfdt. This assumption covers that cases where
the problem could be with either.

Signed-off-by: Simon Glass 
Message-Id: <20200220214557.176528-5-...@chromium.org>
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt.c| 11 ++---
 cpukit/dtc/libfdt/fdt_ro.c | 61 +++---
 2 files changed, 48 insertions(+), 24 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt.c b/cpukit/dtc/libfdt/fdt.c
index d4daf6096c..0dabb920ad 100644
--- a/cpukit/dtc/libfdt/fdt.c
+++ b/cpukit/dtc/libfdt/fdt.c
@@ -129,10 +129,11 @@ const void *fdt_offset_ptr(const void *fdt, int offset, 
unsigned int len)
 {
unsigned absoffset = offset + fdt_off_dt_struct(fdt);
 
-   if ((absoffset < offset)
-   || ((absoffset + len) < absoffset)
-   || (absoffset + len) > fdt_totalsize(fdt))
-   return NULL;
+   if (!can_assume(VALID_INPUT))
+   if ((absoffset < offset)
+   || ((absoffset + len) < absoffset)
+   || (absoffset + len) > fdt_totalsize(fdt))
+   return NULL;
 
if (fdt_version(fdt) >= 0x11)
if (((offset + len) < offset)
@@ -197,6 +198,8 @@ uint32_t fdt_next_tag(const void *fdt, int startoffset, int 
*nextoffset)
 
 int fdt_check_node_offset_(const void *fdt, int offset)
 {
+   if (can_assume(VALID_INPUT))
+   return offset;
if ((offset < 0) || (offset % FDT_TAGSIZE)
|| (fdt_next_tag(fdt, offset, ) != FDT_BEGIN_NODE))
return -FDT_ERR_BADOFFSET;
diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index 4c26fbeb8d..9c325591ae 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -33,17 +33,26 @@ static int fdt_nodename_eq_(const void *fdt, int offset,
 
 const char *fdt_get_string(const void *fdt, int stroffset, int *lenp)
 {
-   int32_t totalsize = fdt_ro_probe_(fdt);
-   uint32_t absoffset = stroffset + fdt_off_dt_strings(fdt);
+   int32_t totalsize;
+   uint32_t absoffset;
size_t len;
int err;
const char *s, *n;
 
+   if (can_assume(VALID_INPUT)) {
+   s = (const char *)fdt + fdt_off_dt_strings(fdt) + stroffset;
+
+   if (lenp)
+   *lenp = strlen(s);
+   return s;
+   }
+   totalsize = fdt_ro_probe_(fdt);
err = totalsize;
if (totalsize < 0)
goto fail;
 
err = -FDT_ERR_BADOFFSET;
+   absoffset = stroffset + fdt_off_dt_strings(fdt);
if (absoffset >= totalsize)
goto fail;
len = totalsize - absoffset;
@@ -151,10 +160,13 @@ static const struct fdt_reserve_entry *fdt_mem_rsv(const 
void *fdt, int n)
int offset = n * sizeof(struct fdt_reserve_entry);
int absoffset = fdt_off_mem_rsvmap(fdt) + offset;
 
-   if (absoffset < fdt_off_mem_rsvmap(fdt))
-   return NULL;
-   if (absoffset > fdt_totalsize(fdt) - sizeof(struct fdt_reserve_entry))
-   return NULL;
+   if (!can_assume(VALID_INPUT)) {
+   if (absoffset < fdt_off_mem_rsvmap(fdt))
+   return NULL;
+   if (absoffset > fdt_totalsize(fdt) -
+   sizeof(struct fdt_reserve_entry))
+   return NULL;
+   }
return fdt_mem_rsv_(fdt, n);
 }
 
@@ -164,7 +176,7 @@ int fdt_get_mem_rsv(const void *fdt, int n, uint64_t 
*address, uint64_t *size)
 
FDT_RO_PROBE(fdt);
re = fdt_mem_rsv(fdt, n);
-   if (!re)
+   if (!can_assume(VALID_INPUT) && !re)
return -FDT_ERR_BADOFFSET;
 
*address = fdt64_ld(>address);
@@ -346,7 +358,8 @@ static const struct fdt_property 
*fdt_get_property_by_offset_(const void *fdt,
int err;
const struct fdt_property *prop;
 
-   if ((err = fdt_check_prop_offset_(fdt, offset)) < 0) {
+   if (!can_assume(VALID_INPUT) &&
+   (err = fdt_check_prop_offset_(fdt, offset)) < 0) {
if (lenp)
*lenp = err;
return NULL;
@@ -462,14 +475,19 @@ const void *fdt_getprop_by_offset(const void *fdt, int 
offset,
if (namep) {
const char *name;
int namelen;
-   name = fdt_get_string(fdt, fdt32_ld(>nameoff),
- );
-   if (!name) {
-   if (lenp)
-   *lenp = namelen;
-   return NULL;
+
+   if (!can_assume(VALID_INPUT)) {
+   name = fdt_get_string(fdt, fdt32_ld(>nameoff),
+ );
+   if (!name) {
+   if (lenp)
+   *lenp = namelen;
+   

[PATCH 04/27] libfdt: Fix FDT_ERR_NOTFOUND typos in documentation

[Sebastian Huber]

From: Geert Uytterhoeven 

The actual error is FDT_ERR_NOTFOUND, not FDT_ERR_NOT_FOUND.

Fixes: d29126c90acb0d70 ("libfdt: Add iterator over properties")
Fixes: 902d0f0953d0074b ("libfdt: Add a subnodes iterator macro")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: David Gibson 
---
 cpukit/include/libfdt.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index 263b7adf4e..a470d1df6d 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -227,7 +227,7 @@ int fdt_next_subnode(const void *fdt, int offset);
  * ...
  * }
  *
- * if ((node < 0) && (node != -FDT_ERR_NOT_FOUND)) {
+ * if ((node < 0) && (node != -FDT_ERR_NOTFOUND)) {
  * Error handling
  * }
  *
@@ -566,7 +566,7 @@ int fdt_next_property_offset(const void *fdt, int offset);
  * ...
  * }
  *
- * if ((property < 0) && (property != -FDT_ERR_NOT_FOUND)) {
+ * if ((property < 0) && (property != -FDT_ERR_NOTFOUND)) {
  * Error handling
  * }
  *
-- 
2.16.4

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

[PATCH 19/27] libfdt: De-inline fdt_header_size()

[Sebastian Huber]

From: Simon Glass 

There does not seem to be a strong reason to inline this function. Also
we are about to add some extra code to it which will increase its size.

Move it into fdt.c and use a simple declaration in libfdt.h

Signed-off-by: Simon Glass 
Message-Id: <20200220214557.176528-2-...@chromium.org>
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt.c | 5 +
 cpukit/include/libfdt.h | 9 +
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt.c b/cpukit/dtc/libfdt/fdt.c
index d6ce7c052d..3e37a4b8b6 100644
--- a/cpukit/dtc/libfdt/fdt.c
+++ b/cpukit/dtc/libfdt/fdt.c
@@ -70,6 +70,11 @@ size_t fdt_header_size_(uint32_t version)
return FDT_V17_SIZE;
 }
 
+size_t fdt_header_size(const void *fdt)
+{
+   return fdt_header_size_(fdt_version(fdt));
+}
+
 int fdt_check_header(const void *fdt)
 {
size_t hdrsize;
diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index fc4c4962a0..48f375c9c1 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -266,11 +266,12 @@ fdt_set_hdr_(size_dt_struct);
  * fdt_header_size - return the size of the tree's header
  * @fdt: pointer to a flattened device tree
  */
+size_t fdt_header_size(const void *fdt);
+
+/**
+ * fdt_header_size_ - internal function which takes a version number
+ */
 size_t fdt_header_size_(uint32_t version);
-static inline size_t fdt_header_size(const void *fdt)
-{
-   return fdt_header_size_(fdt_version(fdt));
-}
 
 /**
  * fdt_check_header - sanity check a device tree header
-- 
2.16.4

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

[PATCH 11/27] libfdt: Ensure fdt_add_property frees allocated name string on failure

[Sebastian Huber]

From: Nicholas Piggin 

If fdt_add_property or fdt_property_placeholder fail after allocating
a string for the name, they return without freeing that string. This
does not change the structure of the tree, but in very specific cases
it could lead to undesirable space consumption.

Fix this by rolling back the string allocation in this situation.

Signed-off-by: Nicholas Piggin 
Message-Id: <20190509094122.834-2-npig...@gmail.com>
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_rw.c | 22 +++---
 cpukit/dtc/libfdt/fdt_sw.c | 23 ---
 2 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt_rw.c b/cpukit/dtc/libfdt/fdt_rw.c
index 2e49855d7c..9e7661509e 100644
--- a/cpukit/dtc/libfdt/fdt_rw.c
+++ b/cpukit/dtc/libfdt/fdt_rw.c
@@ -136,6 +136,14 @@ static int fdt_splice_struct_(void *fdt, void *p,
return 0;
 }
 
+/* Must only be used to roll back in case of error */
+static void fdt_del_last_string_(void *fdt, const char *s)
+{
+   int newlen = strlen(s) + 1;
+
+   fdt_set_size_dt_strings(fdt, fdt_size_dt_strings(fdt) - newlen);
+}
+
 static int fdt_splice_string_(void *fdt, int newlen)
 {
void *p = (char *)fdt
@@ -149,7 +157,7 @@ static int fdt_splice_string_(void *fdt, int newlen)
return 0;
 }
 
-static int fdt_find_add_string_(void *fdt, const char *s)
+static int fdt_find_add_string_(void *fdt, const char *s, int *allocated)
 {
char *strtab = (char *)fdt + fdt_off_dt_strings(fdt);
const char *p;
@@ -157,6 +165,8 @@ static int fdt_find_add_string_(void *fdt, const char *s)
int len = strlen(s) + 1;
int err;
 
+   *allocated = 0;
+
p = fdt_find_string_(strtab, fdt_size_dt_strings(fdt), s);
if (p)
/* found it */
@@ -167,6 +177,8 @@ static int fdt_find_add_string_(void *fdt, const char *s)
if (err)
return err;
 
+   *allocated = 1;
+
memcpy(new, s, len);
return (new - strtab);
 }
@@ -225,11 +237,12 @@ static int fdt_add_property_(void *fdt, int nodeoffset, 
const char *name,
int nextoffset;
int namestroff;
int err;
+   int allocated;
 
if ((nextoffset = fdt_check_node_offset_(fdt, nodeoffset)) < 0)
return nextoffset;
 
-   namestroff = fdt_find_add_string_(fdt, name);
+   namestroff = fdt_find_add_string_(fdt, name, );
if (namestroff < 0)
return namestroff;
 
@@ -237,8 +250,11 @@ static int fdt_add_property_(void *fdt, int nodeoffset, 
const char *name,
proplen = sizeof(**prop) + FDT_TAGALIGN(len);
 
err = fdt_splice_struct_(fdt, *prop, 0, proplen);
-   if (err)
+   if (err) {
+   if (allocated)
+   fdt_del_last_string_(fdt, name);
return err;
+   }
 
(*prop)->tag = cpu_to_fdt32(FDT_PROP);
(*prop)->nameoff = cpu_to_fdt32(namestroff);
diff --git a/cpukit/dtc/libfdt/fdt_sw.c b/cpukit/dtc/libfdt/fdt_sw.c
index 9fa4a94d83..113f28ad3f 100644
--- a/cpukit/dtc/libfdt/fdt_sw.c
+++ b/cpukit/dtc/libfdt/fdt_sw.c
@@ -262,7 +262,16 @@ int fdt_end_node(void *fdt)
return 0;
 }
 
-static int fdt_find_add_string_(void *fdt, const char *s)
+/* Must only be used to roll back in case of error */
+static void fdt_del_last_string_(void *fdt, const char *s)
+{
+   int strtabsize = fdt_size_dt_strings(fdt);
+   int len = strlen(s) + 1;
+
+   fdt_set_size_dt_strings(fdt, strtabsize - len);
+}
+
+static int fdt_find_add_string_(void *fdt, const char *s, int *allocated)
 {
char *strtab = (char *)fdt + fdt_totalsize(fdt);
const char *p;
@@ -270,11 +279,15 @@ static int fdt_find_add_string_(void *fdt, const char *s)
int len = strlen(s) + 1;
int struct_top, offset;
 
+   *allocated = 0;
+
p = fdt_find_string_(strtab - strtabsize, strtabsize, s);
if (p)
return p - strtab;
 
/* Add it */
+   *allocated = 1;
+
offset = -strtabsize - len;
struct_top = fdt_off_dt_struct(fdt) + fdt_size_dt_struct(fdt);
if (fdt_totalsize(fdt) + offset < struct_top)
@@ -289,16 +302,20 @@ int fdt_property_placeholder(void *fdt, const char *name, 
int len, void **valp)
 {
struct fdt_property *prop;
int nameoff;
+   int allocated;
 
FDT_SW_PROBE_STRUCT(fdt);
 
-   nameoff = fdt_find_add_string_(fdt, name);
+   nameoff = fdt_find_add_string_(fdt, name, );
if (nameoff == 0)
return -FDT_ERR_NOSPACE;
 
prop = fdt_grab_space_(fdt, sizeof(*prop) + FDT_TAGALIGN(len));
-   if (! prop)
+   if (! prop) {
+   if (allocated)
+   fdt_del_last_string_(fdt, name);
return -FDT_ERR_NOSPACE;
+   }
 
prop->tag = cpu_to_fdt32(FDT_PROP);
prop->nameoff = cpu_to_fdt32(nameoff);
-- 
2.16.4

___
devel 

[PATCH 13/27] libfdt: Add FDT_CREATE_FLAG_NO_NAME_DEDUP flag that trades size for speed

[Sebastian Huber]

From: Nicholas Piggin 

Searching for duplicate names scales O(n^2) with the number of names
added to a fdt, which can cause a noticable slowdown with larger device
trees and very slow CPU cores.

Add FDT_CREATE_FLAG_NO_NAME_DEDUP that allow the caller to trade fdt size
for speed in the creation process.

Signed-off-by: Nicholas Piggin 
Message-Id: <20190509094122.834-4-npig...@gmail.com>
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_sw.c | 39 ++-
 cpukit/include/libfdt.h|  8 +++-
 2 files changed, 33 insertions(+), 14 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt_sw.c b/cpukit/dtc/libfdt/fdt_sw.c
index ba05868845..e773157d0f 100644
--- a/cpukit/dtc/libfdt/fdt_sw.c
+++ b/cpukit/dtc/libfdt/fdt_sw.c
@@ -284,6 +284,23 @@ int fdt_end_node(void *fdt)
return 0;
 }
 
+static int fdt_add_string_(void *fdt, const char *s)
+{
+   char *strtab = (char *)fdt + fdt_totalsize(fdt);
+   int strtabsize = fdt_size_dt_strings(fdt);
+   int len = strlen(s) + 1;
+   int struct_top, offset;
+
+   offset = -strtabsize - len;
+   struct_top = fdt_off_dt_struct(fdt) + fdt_size_dt_struct(fdt);
+   if (fdt_totalsize(fdt) + offset < struct_top)
+   return 0; /* no more room :( */
+
+   memcpy(strtab + offset, s, len);
+   fdt_set_size_dt_strings(fdt, strtabsize + len);
+   return offset;
+}
+
 /* Must only be used to roll back in case of error */
 static void fdt_del_last_string_(void *fdt, const char *s)
 {
@@ -296,10 +313,8 @@ static void fdt_del_last_string_(void *fdt, const char *s)
 static int fdt_find_add_string_(void *fdt, const char *s, int *allocated)
 {
char *strtab = (char *)fdt + fdt_totalsize(fdt);
-   const char *p;
int strtabsize = fdt_size_dt_strings(fdt);
-   int len = strlen(s) + 1;
-   int struct_top, offset;
+   const char *p;
 
*allocated = 0;
 
@@ -307,17 +322,9 @@ static int fdt_find_add_string_(void *fdt, const char *s, 
int *allocated)
if (p)
return p - strtab;
 
-   /* Add it */
*allocated = 1;
 
-   offset = -strtabsize - len;
-   struct_top = fdt_off_dt_struct(fdt) + fdt_size_dt_struct(fdt);
-   if (fdt_totalsize(fdt) + offset < struct_top)
-   return 0; /* no more room :( */
-
-   memcpy(strtab + offset, s, len);
-   fdt_set_size_dt_strings(fdt, strtabsize + len);
-   return offset;
+   return fdt_add_string_(fdt, s);
 }
 
 int fdt_property_placeholder(void *fdt, const char *name, int len, void **valp)
@@ -328,7 +335,13 @@ int fdt_property_placeholder(void *fdt, const char *name, 
int len, void **valp)
 
FDT_SW_PROBE_STRUCT(fdt);
 
-   nameoff = fdt_find_add_string_(fdt, name, );
+   /* String de-duplication can be slow, _NO_NAME_DEDUP skips it */
+   if (sw_flags(fdt) & FDT_CREATE_FLAG_NO_NAME_DEDUP) {
+   allocated = 1;
+   nameoff = fdt_add_string_(fdt, name);
+   } else {
+   nameoff = fdt_find_add_string_(fdt, name, );
+   }
if (nameoff == 0)
return -FDT_ERR_NOSPACE;
 
diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index c2dee3eaa6..0684ec22ed 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -1433,7 +1433,13 @@ int fdt_nop_node(void *fdt, int nodeoffset);
 /* Sequential write functions */
 /**/
 
-#define FDT_CREATE_FLAGS_ALL   0
+/* fdt_create_with_flags flags */
+#define FDT_CREATE_FLAG_NO_NAME_DEDUP 0x1
+   /* FDT_CREATE_FLAG_NO_NAME_DEDUP: Do not try to de-duplicate property
+* names in the fdt. This can result in faster creation times, but
+* a larger fdt. */
+
+#define FDT_CREATE_FLAGS_ALL   (FDT_CREATE_FLAG_NO_NAME_DEDUP)
 
 /**
  * fdt_create_with_flags - begin creation of a new fdt
-- 
2.16.4

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

[PATCH 21/27] libfdt: Add support for disabling dtb checks

[Sebastian Huber]

From: Simon Glass 

Support ASSUME_VALID_DTB to disable some sanity checks

If we assume that the DTB itself is valid then we can skip some checks and
save code space. Add various conditions to handle this.

Signed-off-by: Simon Glass 
Message-Id: <20200220214557.176528-4-...@chromium.org>
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt.c| 53 +++---
 cpukit/dtc/libfdt/fdt_ro.c |  3 ++-
 cpukit/dtc/libfdt/fdt_rw.c |  2 ++
 cpukit/dtc/libfdt/fdt_sw.c | 16 --
 4 files changed, 45 insertions(+), 29 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt.c b/cpukit/dtc/libfdt/fdt.c
index 3e37a4b8b6..d4daf6096c 100644
--- a/cpukit/dtc/libfdt/fdt.c
+++ b/cpukit/dtc/libfdt/fdt.c
@@ -19,6 +19,9 @@ int32_t fdt_ro_probe_(const void *fdt)
 {
uint32_t totalsize = fdt_totalsize(fdt);
 
+   if (can_assume(VALID_DTB))
+   return totalsize;
+
if (fdt_magic(fdt) == FDT_MAGIC) {
/* Complete tree */
if (fdt_version(fdt) < FDT_FIRST_SUPPORTED_VERSION)
@@ -81,38 +84,44 @@ int fdt_check_header(const void *fdt)
 
if (fdt_magic(fdt) != FDT_MAGIC)
return -FDT_ERR_BADMAGIC;
-   hdrsize = fdt_header_size(fdt);
if ((fdt_version(fdt) < FDT_FIRST_SUPPORTED_VERSION)
|| (fdt_last_comp_version(fdt) > FDT_LAST_SUPPORTED_VERSION))
return -FDT_ERR_BADVERSION;
if (fdt_version(fdt) < fdt_last_comp_version(fdt))
return -FDT_ERR_BADVERSION;
+   hdrsize = fdt_header_size(fdt);
+   if (!can_assume(VALID_DTB)) {
 
-   if ((fdt_totalsize(fdt) < hdrsize)
-   || (fdt_totalsize(fdt) > INT_MAX))
-   return -FDT_ERR_TRUNCATED;
-
-   /* Bounds check memrsv block */
-   if (!check_off_(hdrsize, fdt_totalsize(fdt), fdt_off_mem_rsvmap(fdt)))
-   return -FDT_ERR_TRUNCATED;
+   if ((fdt_totalsize(fdt) < hdrsize)
+   || (fdt_totalsize(fdt) > INT_MAX))
+   return -FDT_ERR_TRUNCATED;
 
-   /* Bounds check structure block */
-   if (fdt_version(fdt) < 17) {
+   /* Bounds check memrsv block */
if (!check_off_(hdrsize, fdt_totalsize(fdt),
-   fdt_off_dt_struct(fdt)))
+   fdt_off_mem_rsvmap(fdt)))
return -FDT_ERR_TRUNCATED;
-   } else {
+   }
+
+   if (!can_assume(VALID_DTB)) {
+   /* Bounds check structure block */
+   if (fdt_version(fdt) < 17) {
+   if (!check_off_(hdrsize, fdt_totalsize(fdt),
+   fdt_off_dt_struct(fdt)))
+   return -FDT_ERR_TRUNCATED;
+   } else {
+   if (!check_block_(hdrsize, fdt_totalsize(fdt),
+ fdt_off_dt_struct(fdt),
+ fdt_size_dt_struct(fdt)))
+   return -FDT_ERR_TRUNCATED;
+   }
+
+   /* Bounds check strings block */
if (!check_block_(hdrsize, fdt_totalsize(fdt),
- fdt_off_dt_struct(fdt),
- fdt_size_dt_struct(fdt)))
+ fdt_off_dt_strings(fdt),
+ fdt_size_dt_strings(fdt)))
return -FDT_ERR_TRUNCATED;
}
 
-   /* Bounds check strings block */
-   if (!check_block_(hdrsize, fdt_totalsize(fdt),
- fdt_off_dt_strings(fdt), fdt_size_dt_strings(fdt)))
-   return -FDT_ERR_TRUNCATED;
-
return 0;
 }
 
@@ -142,7 +151,7 @@ uint32_t fdt_next_tag(const void *fdt, int startoffset, int 
*nextoffset)
 
*nextoffset = -FDT_ERR_TRUNCATED;
tagp = fdt_offset_ptr(fdt, offset, FDT_TAGSIZE);
-   if (!tagp)
+   if (!can_assume(VALID_DTB) && !tagp)
return FDT_END; /* premature end */
tag = fdt32_to_cpu(*tagp);
offset += FDT_TAGSIZE;
@@ -154,13 +163,13 @@ uint32_t fdt_next_tag(const void *fdt, int startoffset, 
int *nextoffset)
do {
p = fdt_offset_ptr(fdt, offset++, 1);
} while (p && (*p != '\0'));
-   if (!p)
+   if (!can_assume(VALID_DTB) && !p)
return FDT_END; /* premature end */
break;
 
case FDT_PROP:
lenp = fdt_offset_ptr(fdt, offset, sizeof(*lenp));
-   if (!lenp)
+   if (!can_assume(VALID_DTB) && !lenp)
return FDT_END; /* premature end */
/* skip-name offset, length and value */
offset += sizeof(struct fdt_property) - FDT_TAGSIZE
diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index a5c2797cde..4c26fbeb8d 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ 

[PATCH 26/27] libfdt: Allow exclusion of fdt_check_full()

[Sebastian Huber]

From: Simon Glass 

This function is used to perform a full check of the device tree. Allow
it to be excluded if all assumptions are enabled.

Signed-off-by: Simon Glass 
Reviewed-by: David Gibson 
Message-Id: <20200220214557.176528-9-...@chromium.org>
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_ro.c | 63 --
 1 file changed, 63 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index 2fa768e56c..194550344a 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -855,66 +855,3 @@ int fdt_node_offset_by_compatible(const void *fdt, int 
startoffset,
 
return offset; /* error from fdt_next_node() */
 }
-
-int fdt_check_full(const void *fdt, size_t bufsize)
-{
-   int err;
-   int num_memrsv;
-   int offset, nextoffset = 0;
-   uint32_t tag;
-   unsigned depth = 0;
-   const void *prop;
-   const char *propname;
-
-   if (bufsize < FDT_V1_SIZE)
-   return -FDT_ERR_TRUNCATED;
-   err = fdt_check_header(fdt);
-   if (err != 0)
-   return err;
-   if (bufsize < fdt_totalsize(fdt))
-   return -FDT_ERR_TRUNCATED;
-
-   num_memrsv = fdt_num_mem_rsv(fdt);
-   if (num_memrsv < 0)
-   return num_memrsv;
-
-   while (1) {
-   offset = nextoffset;
-   tag = fdt_next_tag(fdt, offset, );
-
-   if (nextoffset < 0)
-   return nextoffset;
-
-   switch (tag) {
-   case FDT_NOP:
-   break;
-
-   case FDT_END:
-   if (depth != 0)
-   return -FDT_ERR_BADSTRUCTURE;
-   return 0;
-
-   case FDT_BEGIN_NODE:
-   depth++;
-   if (depth > INT_MAX)
-   return -FDT_ERR_BADSTRUCTURE;
-   break;
-
-   case FDT_END_NODE:
-   if (depth == 0)
-   return -FDT_ERR_BADSTRUCTURE;
-   depth--;
-   break;
-
-   case FDT_PROP:
-   prop = fdt_getprop_by_offset(fdt, offset, ,
-);
-   if (!prop)
-   return err;
-   break;
-
-   default:
-   return -FDT_ERR_INTERNAL;
-   }
-   }
-}
-- 
2.16.4

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

[PATCH 20/27] Add a way to control the level of checks in the code

[Sebastian Huber]

From: Simon Glass 

Add a new ASSUME_MASK option, which allows for some control over the
checks used in libfdt. With all assumptions enabled, libfdt assumes that
the input data and parameters are all correct and that internal errors
cannot happen.

By default no assumptions are made and all checks are enabled.

Signed-off-by: Simon Glass 
Message-Id: <20200220214557.176528-3-...@chromium.org>
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/libfdt_internal.h | 104 
 1 file changed, 104 insertions(+)

diff --git a/cpukit/dtc/libfdt/libfdt_internal.h 
b/cpukit/dtc/libfdt/libfdt_internal.h
index 058c7358d4..e9913cdfa0 100644
--- a/cpukit/dtc/libfdt/libfdt_internal.h
+++ b/cpukit/dtc/libfdt/libfdt_internal.h
@@ -48,4 +48,108 @@ static inline struct fdt_reserve_entry *fdt_mem_rsv_w_(void 
*fdt, int n)
 
 #define FDT_SW_MAGIC   (~FDT_MAGIC)
 
+/**/
+/* Checking controls  */
+/**/
+
+#ifndef FDT_ASSUME_MASK
+#define FDT_ASSUME_MASK 0
+#endif
+
+/*
+ * Defines assumptions which can be enabled. Each of these can be enabled
+ * individually. For maximum saftey, don't enable any assumptions!
+ *
+ * For minimal code size and no safety, use ASSUME_PERFECT at your own risk.
+ * You should have another method of validating the device tree, such as a
+ * signature or hash check before using libfdt.
+ *
+ * For situations where security is not a concern it may be safe to enable
+ * ASSUME_SANE.
+ */
+enum {
+   /*
+* This does essentially no checks. Only the latest device-tree
+* version is correctly handled. Inconsistencies or errors in the device
+* tree may cause undefined behaviour or crashes. Invalid parameters
+* passed to libfdt may do the same.
+*
+* If an error occurs when modifying the tree it may leave the tree in
+* an intermediate (but valid) state. As an example, adding a property
+* where there is insufficient space may result in the property name
+* being added to the string table even though the property itself is
+* not added to the struct section.
+*
+* Only use this if you have a fully validated device tree with
+* the latest supported version and wish to minimise code size.
+*/
+   ASSUME_PERFECT  = 0xff,
+
+   /*
+* This assumes that the device tree is sane. i.e. header metadata
+* and basic hierarchy are correct.
+*
+* With this assumption enabled, normal device trees produced by libfdt
+* and the compiler should be handled safely. Malicious device trees and
+* complete garbage may cause libfdt to behave badly or crash.
+*
+* Note: Only checks that relate exclusively to the device tree itself
+* (not the parameters passed to libfdt) are disabled by this
+* assumption. This includes checking headers, tags and the like.
+*/
+   ASSUME_VALID_DTB= 1 << 0,
+
+   /*
+* This builds on ASSUME_VALID_DTB and further assumes that libfdt
+* functions are called with valid parameters, i.e. not trigger
+* FDT_ERR_BADOFFSET or offsets that are out of bounds. It disables any
+* extensive checking of parameters and the device tree, making various
+* assumptions about correctness.
+*
+* It doesn't make sense to enable this assumption unless
+* ASSUME_VALID_DTB is also enabled.
+*/
+   ASSUME_VALID_INPUT  = 1 << 1,
+
+   /*
+* This disables checks for device-tree version and removes all code
+* which handles older versions.
+*
+* Only enable this if you know you have a device tree with the latest
+* version.
+*/
+   ASSUME_LATEST   = 1 << 2,
+
+   /*
+* This assume that it is OK for a failed additional to the device tree
+* due to lack of space or some other problem can skip any rollback
+* steps (such as dropping the property name from the string table).
+* This is safe to enable in most circumstances, even though it may
+* leave the tree in a sub-optimal state.
+*/
+   ASSUME_NO_ROLLBACK  = 1 << 3,
+
+   /*
+* This assumes that the device tree components appear in the correct
+* order. As such it disables a check in fdt_open_into() and removes the
+* ability to fix the problem there. This is safe if you know that the
+* device tree is correctly ordered. See fdt_blocks_misordered_().
+*/
+   ASSUME_LIBFDT_ORDER = 1 << 4,
+};
+
+/**
+ * can_assume_() - check if a particular assumption is enabled
+ *
+ * @mask: Mask to check (ASSUME_...)
+ * @return true if that assumption is enabled, else false
+ */
+static 

[PATCH 17/27] libfdt.h: add explicit cast from void* to uint8_t* in fdt(32|64)_st

[Sebastian Huber]

From: Luc Michel 

Including libfdt.h in a C++ project fails during compilation with recent
version of GCC or Clang.

This simple example:

extern "C" {
 #include 
}

int main(void) { return 0; }

leads to the following errors with GCC 9.1.0:

/usr/include/libfdt.h: In function ‘void fdt32_st(void*, uint32_t)’:
/usr/include/libfdt.h:139:16: error: invalid conversion from ‘void*’ to 
‘uint8_t*’ {aka ‘unsigned char*’} [-fpermissive]
  139 |  uint8_t *bp = property;
  |^~~~
  ||
  |void*
/usr/include/libfdt.h: In function ‘void fdt64_st(void*, uint64_t)’:
/usr/include/libfdt.h:163:16: error: invalid conversion from ‘void*’ to 
‘uint8_t*’ {aka ‘unsigned char*’} [-fpermissive]
  163 |  uint8_t *bp = property;
  |^~~~
  ||
  |void*

This commit adds an explicit cast to uint8_t* to fix this issue.

Signed-off-by: Luc Michel 
Message-Id: <20190910104824.1321594-1-luc.mic...@greensocs.com>
Signed-off-by: David Gibson 
---
 cpukit/include/libfdt.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index 8037f391a5..fc4c4962a0 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -136,7 +136,7 @@ static inline uint32_t fdt32_ld(const fdt32_t *p)
 
 static inline void fdt32_st(void *property, uint32_t value)
 {
-   uint8_t *bp = property;
+   uint8_t *bp = (uint8_t *)property;
 
bp[0] = value >> 24;
bp[1] = (value >> 16) & 0xff;
@@ -160,7 +160,7 @@ static inline uint64_t fdt64_ld(const fdt64_t *p)
 
 static inline void fdt64_st(void *property, uint64_t value)
 {
-   uint8_t *bp = property;
+   uint8_t *bp = (uint8_t *)property;
 
bp[0] = value >> 56;
bp[1] = (value >> 48) & 0xff;
-- 
2.16.4

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

[PATCH 02/27] libfdt: Don't use memcpy to handle unaligned reads on ARM

[Sebastian Huber]

From: David Gibson 

6dcb8ba4 "libfdt: Add helpers for accessing unaligned words" introduced
the fdt32_ld() and fdt64_ld() helpers for loading values from the FDT blob
which might not be naturally aligned.  This matters for ARM, where
attempting a plain unaligned load will often cause an exception.

However, it seems the memcpy() we used here was surprisingly expensive,
making libfdt nearly 6x slower on at least some ARM platforms.

This patch takes an alternative approach, using a bunch of 1-byte loads
and shifts to implement the helpers.

Signed-off-by: David Gibson 
---
 cpukit/include/libfdt.h | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index face02c102..fdaa3e6f39 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -163,18 +163,26 @@ uint32_t fdt_next_tag(const void *fdt, int offset, int 
*nextoffset);
 
 static inline uint32_t fdt32_ld(const fdt32_t *p)
 {
-   fdt32_t v;
+   const uint8_t *bp = (const uint8_t *)p;
 
-   memcpy(, p, sizeof(v));
-   return fdt32_to_cpu(v);
+   return ((uint32_t)bp[0] << 24)
+   | ((uint32_t)bp[1] << 16)
+   | ((uint32_t)bp[2] << 8)
+   | bp[3];
 }
 
 static inline uint64_t fdt64_ld(const fdt64_t *p)
 {
-   fdt64_t v;
-
-   memcpy(, p, sizeof(v));
-   return fdt64_to_cpu(v);
+   const uint8_t *bp = (const uint8_t *)p;
+
+   return ((uint64_t)bp[0] << 56)
+   | ((uint64_t)bp[1] << 48)
+   | ((uint64_t)bp[2] << 40)
+   | ((uint64_t)bp[3] << 32)
+   | ((uint64_t)bp[4] << 24)
+   | ((uint64_t)bp[5] << 16)
+   | ((uint64_t)bp[6] << 8)
+   | bp[7];
 }
 
 /**/
-- 
2.16.4

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

[PATCH 14/27] libfdt: Replace GPL/BSD boilerplate/reference with SPDX tags

[Sebastian Huber]

From: Rob Herring 

Replace instances of dual GPLv2 or BSD license boilerplate with SPDX tags.

Signed-off-by: Rob Herring 
Message-Id: <20190620211944.9378-3-r...@kernel.org>
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt.c | 47 +
 cpukit/dtc/libfdt/fdt_addresses.c   | 47 +
 cpukit/dtc/libfdt/fdt_empty_tree.c  | 47 +
 cpukit/dtc/libfdt/fdt_ro.c  | 47 +
 cpukit/dtc/libfdt/fdt_rw.c  | 47 +
 cpukit/dtc/libfdt/fdt_strerror.c| 46 +---
 cpukit/dtc/libfdt/fdt_sw.c  | 47 +
 cpukit/dtc/libfdt/fdt_wip.c | 47 +
 cpukit/dtc/libfdt/libfdt_internal.h | 47 +
 cpukit/include/fdt.h| 47 +
 cpukit/include/libfdt.h | 47 +
 cpukit/include/libfdt_env.h | 47 +
 12 files changed, 12 insertions(+), 551 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt.c b/cpukit/dtc/libfdt/fdt.c
index ae03b11129..179168ec63 100644
--- a/cpukit/dtc/libfdt/fdt.c
+++ b/cpukit/dtc/libfdt/fdt.c
@@ -1,52 +1,7 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
 /*
  * libfdt - Flat Device Tree manipulation
  * Copyright (C) 2006 David Gibson, IBM Corporation.
- *
- * libfdt is dual licensed: you can use it either under the terms of
- * the GPL, or the BSD license, at your option.
- *
- *  a) This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public
- * License along with this library; if not, write to the Free
- * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
- * MA 02110-1301 USA
- *
- * Alternatively,
- *
- *  b) 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 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.
  */
 #include "libfdt_env.h"
 
diff --git a/cpukit/dtc/libfdt/fdt_addresses.c 
b/cpukit/dtc/libfdt/fdt_addresses.c
index 2cc997ea50..d8ba8ec60c 100644
--- a/cpukit/dtc/libfdt/fdt_addresses.c
+++ b/cpukit/dtc/libfdt/fdt_addresses.c
@@ -1,53 +1,8 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
 /*
  * libfdt - Flat Device Tree manipulation
  * Copyright (C) 2014 David Gibson 
  * Copyright (C) 2018 embedded brains GmbH
- *
- * libfdt is dual licensed: you can use it either under the terms of
- * the GPL, or the BSD license, at your option.
- *
- *  a) This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * 

[PATCH 09/27] libfdt: Add phandle generation helper

[Sebastian Huber]

From: Thierry Reding 

The new fdt_generate_phandle() function can be used to generate a new,
unused phandle given a specific device tree blob. The implementation is
somewhat naive in that it simply walks the entire device tree to find
the highest phandle value and then returns a phandle value one higher
than that. A more clever implementation might try to find holes in the
current set of phandle values and fill them. But this implementation is
relatively simple and works reliably.

Also add a test that validates that phandles generated by this new API
are indeed unique.

Signed-off-by: Thierry Reding 
Message-Id: <20190326153302.17109-3-thierry.red...@gmail.com>
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_ro.c | 18 ++
 cpukit/include/libfdt.h| 19 +++
 2 files changed, 37 insertions(+)

diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index 1d0335ee71..817ac39099 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -184,6 +184,24 @@ uint32_t fdt_get_max_phandle(const void *fdt)
return phandle;
 }
 
+int fdt_generate_phandle(const void *fdt, uint32_t *phandle)
+{
+   uint32_t max;
+   int err;
+
+   err = fdt_find_max_phandle(fdt, );
+   if (err < 0)
+   return err;
+
+   if (max == FDT_MAX_PHANDLE)
+   return -FDT_ERR_NOPHANDLES;
+
+   if (phandle)
+   *phandle = max + 1;
+
+   return 0;
+}
+
 static const struct fdt_reserve_entry *fdt_mem_rsv(const void *fdt, int n)
 {
int offset = n * sizeof(struct fdt_reserve_entry);
diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index e1498c3c21..39ff6d5d25 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -140,6 +140,10 @@
 
 #define FDT_ERR_MAX17
 
+/* constants */
+#define FDT_MAX_PHANDLE 0xfffe
+   /* Valid values for phandles range from 1 to 2^32-2. */
+
 /**/
 /* Low-level functions (you probably don't need these)*/
 /**/
@@ -416,6 +420,21 @@ int fdt_find_max_phandle(const void *fdt, uint32_t 
*phandle);
  */
 uint32_t fdt_get_max_phandle(const void *fdt);
 
+/**
+ * fdt_generate_phandle - return a new, unused phandle for a device tree blob
+ * @fdt: pointer to the device tree blob
+ * @phandle: return location for the new phandle
+ *
+ * Walks the device tree blob and looks for the highest phandle value. On
+ * success, the new, unused phandle value (one higher than the previously
+ * highest phandle value in the device tree blob) will be returned in the
+ * @phandle parameter.
+ *
+ * Returns:
+ *   0 on success or a negative error-code on failure
+ */
+int fdt_generate_phandle(const void *fdt, uint32_t *phandle);
+
 /**
  * fdt_num_mem_rsv - retrieve the number of memory reserve map entries
  * @fdt: pointer to the device tree blob
-- 
2.16.4

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

[PATCH 03/27] libfdt: Fix fdt_getprop_by_offset() parameter name in documentation

[Sebastian Huber]

From: Geert Uytterhoeven 

The second parameter of fdt_getprop_by_offset() is called "offset", not
"ffset".

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: David Gibson 
---
 cpukit/include/libfdt.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index fdaa3e6f39..263b7adf4e 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -669,7 +669,7 @@ static inline struct fdt_property *fdt_get_property_w(void 
*fdt, int nodeoffset,
 /**
  * fdt_getprop_by_offset - retrieve the value of a property at a given offset
  * @fdt: pointer to the device tree blob
- * @ffset: offset of the property to read
+ * @offset: offset of the property to read
  * @namep: pointer to a string variable (will be overwritten) or NULL
  * @lenp: pointer to an integer variable (will be overwritten) or NULL
  *
-- 
2.16.4

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

[PATCH 23/27] libfdt: Add support for disabling rollback handling

[Sebastian Huber]

From: Simon Glass 

Allow enabling FDT_ASSUME_NO_ROLLBACK to disable rolling back after a
failed operation.

Signed-off-by: Simon Glass 
Reviewed-by: David Gibson 
Message-Id: <20200220214557.176528-6-...@chromium.org>
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_rw.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt_rw.c b/cpukit/dtc/libfdt/fdt_rw.c
index 707c00aabd..4a95ce2dea 100644
--- a/cpukit/dtc/libfdt/fdt_rw.c
+++ b/cpukit/dtc/libfdt/fdt_rw.c
@@ -114,6 +114,15 @@ static int fdt_splice_string_(void *fdt, int newlen)
return 0;
 }
 
+/**
+ * fdt_find_add_string_() - Find or allocate a string
+ *
+ * @fdt: pointer to the device tree to check/adjust
+ * @s: string to find/add
+ * @allocated: Set to 0 if the string was found, 1 if not found and so
+ * allocated. Ignored if can_assume(NO_ROLLBACK)
+ * @return offset of string in the string table (whether found or added)
+ */
 static int fdt_find_add_string_(void *fdt, const char *s, int *allocated)
 {
char *strtab = (char *)fdt + fdt_off_dt_strings(fdt);
@@ -122,7 +131,8 @@ static int fdt_find_add_string_(void *fdt, const char *s, 
int *allocated)
int len = strlen(s) + 1;
int err;
 
-   *allocated = 0;
+   if (!can_assume(NO_ROLLBACK))
+   *allocated = 0;
 
p = fdt_find_string_(strtab, fdt_size_dt_strings(fdt), s);
if (p)
@@ -134,7 +144,8 @@ static int fdt_find_add_string_(void *fdt, const char *s, 
int *allocated)
if (err)
return err;
 
-   *allocated = 1;
+   if (!can_assume(NO_ROLLBACK))
+   *allocated = 1;
 
memcpy(new, s, len);
return (new - strtab);
@@ -208,7 +219,8 @@ static int fdt_add_property_(void *fdt, int nodeoffset, 
const char *name,
 
err = fdt_splice_struct_(fdt, *prop, 0, proplen);
if (err) {
-   if (allocated)
+   /* Delete the string if we failed to add it */
+   if (!can_assume(NO_ROLLBACK) && allocated)
fdt_del_last_string_(fdt, name);
return err;
}
-- 
2.16.4

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

[PATCH 00/27] Update dtc to the latest upstream master

[Sebastian Huber]

AKASHI Takahiro (1):
  libfdt: add fdt_append_addrrange()

David Gibson (6):
  libfdt: Don't use memcpy to handle unaligned reads on ARM
  Revert "libfdt: Add phandle generation helper"
  libfdt: Make fdt_get_max_phandle() an inline
  libfdt: Tweak data handling to satisfy Coverity
  libfdt: Allow #size-cells of 0
  libfdt: Correct prototype for fdt_ro_probe_()

Geert Uytterhoeven (2):
  libfdt: Fix fdt_getprop_by_offset() parameter name in documentation
  libfdt: Fix FDT_ERR_NOTFOUND typos in documentation

John Clarke (1):
  libfdt: return correct value if #size-cells property is not present

Luc Michel (1):
  libfdt.h: add explicit cast from void* to uint8_t* in fdt(32|64)_st

Nicholas Piggin (3):
  libfdt: Ensure fdt_add_property frees allocated name string on failure
  libfdt: Introduce fdt_create_with_flags()
  libfdt: Add FDT_CREATE_FLAG_NO_NAME_DEDUP flag that trades size for
speed

Rob Herring (1):
  libfdt: Replace GPL/BSD boilerplate/reference with SPDX tags

Sebastian Huber (1):
  dtc: Update VERSION

Simon Glass (8):
  libfdt: De-inline fdt_header_size()
  Add a way to control the level of checks in the code
  libfdt: Add support for disabling dtb checks
  libfdt: Add support for disabling sanity checks
  libfdt: Add support for disabling rollback handling
  libfdt: Add support for disabling version checks
  libfdt: Add support for disabling ordering check/fixup
  libfdt: Allow exclusion of fdt_check_full()

Thierry Reding (3):
  libfdt: Add phandle generation helper
  libfdt: Add new maximum phandle lookup function
  libfdt: Add phandle generation helper

 cpukit/dtc/VERSION  |   6 +-
 cpukit/dtc/libfdt/fdt.c | 153 ++
 cpukit/dtc/libfdt/fdt_addresses.c   | 118 +
 cpukit/dtc/libfdt/fdt_empty_tree.c  |  47 +--
 cpukit/dtc/libfdt/fdt_ro.c  | 249 +---
 cpukit/dtc/libfdt/fdt_rw.c  |  92 ++---
 cpukit/dtc/libfdt/fdt_strerror.c|  47 +--
 cpukit/dtc/libfdt/fdt_sw.c  | 141 +++-
 cpukit/dtc/libfdt/fdt_wip.c |  47 +--
 cpukit/dtc/libfdt/libfdt_internal.h | 163 +++
 cpukit/include/fdt.h|  47 +--
 cpukit/include/libfdt.h | 236 +-
 cpukit/include/libfdt_env.h |  48 +--
 13 files changed, 639 insertions(+), 755 deletions(-)

-- 
2.16.4

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

[PATCH 08/27] libfdt: Add new maximum phandle lookup function

[Sebastian Huber]

From: Thierry Reding 

The fdt_get_max_phandle() function has some shortcomings. On one hand
it returns just a uint32_t which means to check for the "negative"
error code a caller has to explicitly check against the error code
(uint32_t)-1. In addition, the -1 is the only error code that can be
returned, so a caller cannot tell the difference between the various
failures.

Fix this by adding a new fdt_find_max_phandle() function that returns an
error code on failure and 0 on success, just like other APIs, and stores
the maximum phandle value in an output argument on success.

This also refactors fdt_get_max_phandle() to use the new function. Add a
note pointing out that the new fdt_find_max_phandle() function should be
preferred over fdt_get_max_phandle().

Signed-off-by: Thierry Reding 
Message-Id: <20190326153302.17109-1-thierry.red...@gmail.com>
[dwg: Reword for some inaccuracies in the commit message]
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_ro.c  | 44 +---
 cpukit/include/libfdt.h | 16 
 cpukit/include/libfdt_env.h |  1 +
 3 files changed, 46 insertions(+), 15 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index eafc142828..1d0335ee71 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -144,32 +144,46 @@ static int fdt_string_eq_(const void *fdt, int stroffset,
return p && (slen == len) && (memcmp(p, s, len) == 0);
 }
 
-uint32_t fdt_get_max_phandle(const void *fdt)
+int fdt_find_max_phandle(const void *fdt, uint32_t *phandle)
 {
-   uint32_t max_phandle = 0;
-   int offset;
+   uint32_t max = 0;
+   int offset = -1;
 
-   for (offset = fdt_next_node(fdt, -1, NULL);;
-offset = fdt_next_node(fdt, offset, NULL)) {
-   uint32_t phandle;
+   while (true) {
+   uint32_t value;
 
-   if (offset == -FDT_ERR_NOTFOUND)
-   return max_phandle;
+   offset = fdt_next_node(fdt, offset, NULL);
+   if (offset < 0) {
+   if (offset == -FDT_ERR_NOTFOUND)
+   break;
 
-   if (offset < 0)
-   return (uint32_t)-1;
+   return offset;
+   }
 
-   phandle = fdt_get_phandle(fdt, offset);
-   if (phandle == (uint32_t)-1)
-   continue;
+   value = fdt_get_phandle(fdt, offset);
 
-   if (phandle > max_phandle)
-   max_phandle = phandle;
+   if (value > max)
+   max = value;
}
 
+   if (phandle)
+   *phandle = max;
+
return 0;
 }
 
+uint32_t fdt_get_max_phandle(const void *fdt)
+{
+   uint32_t phandle;
+   int err;
+
+   err = fdt_find_max_phandle(fdt, );
+   if (err < 0)
+   return (uint32_t)-1;
+
+   return phandle;
+}
+
 static const struct fdt_reserve_entry *fdt_mem_rsv(const void *fdt, int n)
 {
int offset = n * sizeof(struct fdt_reserve_entry);
diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index e70f5bf7e8..e1498c3c21 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -385,6 +385,20 @@ const char *fdt_get_string(const void *fdt, int stroffset, 
int *lenp);
  */
 const char *fdt_string(const void *fdt, int stroffset);
 
+/**
+ * fdt_find_max_phandle - find and return the highest phandle in a tree
+ * @fdt: pointer to the device tree blob
+ * @phandle: return location for the highest phandle value found in the tree
+ *
+ * fdt_find_max_phandle() finds the highest phandle value in the given device
+ * tree. The value returned in @phandle is only valid if the function returns
+ * success.
+ *
+ * returns:
+ * 0 on success or a negative error code on failure
+ */
+int fdt_find_max_phandle(const void *fdt, uint32_t *phandle);
+
 /**
  * fdt_get_max_phandle - retrieves the highest phandle in a tree
  * @fdt: pointer to the device tree blob
@@ -393,6 +407,8 @@ const char *fdt_string(const void *fdt, int stroffset);
  * device tree. This will ignore badly formatted phandles, or phandles
  * with a value of 0 or -1.
  *
+ * This function is deprecated in favour of fdt_find_max_phandle().
+ *
  * returns:
  *  the highest phandle on success
  *  0, if no phandle was found in the device tree
diff --git a/cpukit/include/libfdt_env.h b/cpukit/include/libfdt_env.h
index eb2053845c..4d1cdfa585 100644
--- a/cpukit/include/libfdt_env.h
+++ b/cpukit/include/libfdt_env.h
@@ -52,6 +52,7 @@
  * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
+#include 
 #include 
 #include 
 #include 
-- 
2.16.4

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

[PATCH 05/27] libfdt: Add phandle generation helper

[Sebastian Huber]

From: Thierry Reding 

The new fdt_generate_phandle() function can be used to generate a new,
unused phandle given a specific device tree blob. The implementation is
somewhat naive in that it simply walks the entire device tree to find
the highest phandle value and then returns a phandle value one higher
than that. A more clever implementation might try to find holes in the
current set of phandle values and fill them. But this implementation is
relatively simple and works reliably.

Also add a test that validates that phandles generated by this new API
are indeed unique.

Signed-off-by: Thierry Reding 
Message-Id: <20190320151003.28941-1-thierry.red...@gmail.com>
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_ro.c  | 31 +++
 cpukit/include/libfdt.h | 19 +++
 cpukit/include/libfdt_env.h |  1 +
 3 files changed, 51 insertions(+)

diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index eafc142828..97cdcda0db 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -170,6 +170,37 @@ uint32_t fdt_get_max_phandle(const void *fdt)
return 0;
 }
 
+int fdt_generate_phandle(const void *fdt, uint32_t *phandle)
+{
+   uint32_t max = 0;
+   int offset = -1;
+
+   while (true) {
+   uint32_t value;
+
+   offset = fdt_next_node(fdt, offset, NULL);
+   if (offset < 0) {
+   if (offset == -FDT_ERR_NOTFOUND)
+   break;
+
+   return offset;
+   }
+
+   value = fdt_get_phandle(fdt, offset);
+
+   if (value > max)
+   max = value;
+   }
+
+   if (max == FDT_MAX_PHANDLE)
+   return -FDT_ERR_NOPHANDLES;
+
+   if (phandle)
+   *phandle = max + 1;
+
+   return 0;
+}
+
 static const struct fdt_reserve_entry *fdt_mem_rsv(const void *fdt, int n)
 {
int offset = n * sizeof(struct fdt_reserve_entry);
diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index a470d1df6d..7e102d188e 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -140,6 +140,10 @@
 
 #define FDT_ERR_MAX17
 
+/* constants */
+#define FDT_MAX_PHANDLE 0xfffe
+   /* Valid values for phandles range from 1 to 2^32-2. */
+
 /**/
 /* Low-level functions (you probably don't need these)*/
 /**/
@@ -376,6 +380,21 @@ const char *fdt_string(const void *fdt, int stroffset);
  */
 uint32_t fdt_get_max_phandle(const void *fdt);
 
+/**
+ * fdt_generate_phandle - return a new, unused phandle for a device tree blob
+ * @fdt: pointer to the device tree blob
+ * @phandle: return location for the new phandle
+ *
+ * Walks the device tree blob and looks for the highest phandle value. On
+ * success, the new, unused phandle value (one higher than the previously
+ * highest phandle value in the device tree blob) will be returned in the
+ * @phandle parameter.
+ *
+ * Returns:
+ *   0 on success or a negative error-code on failure
+ */
+int fdt_generate_phandle(const void *fdt, uint32_t *phandle);
+
 /**
  * fdt_num_mem_rsv - retrieve the number of memory reserve map entries
  * @fdt: pointer to the device tree blob
diff --git a/cpukit/include/libfdt_env.h b/cpukit/include/libfdt_env.h
index eb2053845c..4d1cdfa585 100644
--- a/cpukit/include/libfdt_env.h
+++ b/cpukit/include/libfdt_env.h
@@ -52,6 +52,7 @@
  * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
+#include 
 #include 
 #include 
 #include 
-- 
2.16.4

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

[PATCH 07/27] libfdt: add fdt_append_addrrange()

[Sebastian Huber]

From: AKASHI Takahiro 

This function will append an address range property using parent node's
"#address-cells" and "#size-cells" properties.

It will be used in implementing kdump with kexec_file_load system call
at linux kernel for arm64 once it is merged into kernel tree.

Signed-off-by: AKASHI Takahiro 
Message-Id: <20190327061552.17170-2-takahiro.aka...@linaro.org>
[dwg: Correct a SEGV error in the testcase]
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_addresses.c | 47 ++
 cpukit/include/libfdt.h   | 61 +++
 2 files changed, 108 insertions(+)

diff --git a/cpukit/dtc/libfdt/fdt_addresses.c 
b/cpukit/dtc/libfdt/fdt_addresses.c
index f13a87dfa0..2cc997ea50 100644
--- a/cpukit/dtc/libfdt/fdt_addresses.c
+++ b/cpukit/dtc/libfdt/fdt_addresses.c
@@ -95,3 +95,50 @@ int fdt_size_cells(const void *fdt, int nodeoffset)
return 1;
return val;
 }
+
+/* This function assumes that [address|size]_cells is 1 or 2 */
+int fdt_appendprop_addrrange(void *fdt, int parent, int nodeoffset,
+const char *name, uint64_t addr, uint64_t size)
+{
+   int addr_cells, size_cells, ret;
+   uint8_t data[sizeof(fdt64_t) * 2], *prop;
+
+   ret = fdt_address_cells(fdt, parent);
+   if (ret < 0)
+   return ret;
+   addr_cells = ret;
+
+   ret = fdt_size_cells(fdt, parent);
+   if (ret < 0)
+   return ret;
+   size_cells = ret;
+
+   /* check validity of address */
+   prop = data;
+   if (addr_cells == 1) {
+   if ((addr > UINT32_MAX) || ((UINT32_MAX + 1 - addr) < size))
+   return -FDT_ERR_BADVALUE;
+
+   fdt32_st(prop, (uint32_t)addr);
+   } else if (addr_cells == 2) {
+   fdt64_st(prop, addr);
+   } else {
+   return -FDT_ERR_BADNCELLS;
+   }
+
+   /* check validity of size */
+   prop += addr_cells * sizeof(fdt32_t);
+   if (size_cells == 1) {
+   if (size > UINT32_MAX)
+   return -FDT_ERR_BADVALUE;
+
+   fdt32_st(prop, (uint32_t)size);
+   } else if (size_cells == 2) {
+   fdt64_st(prop, size);
+   } else {
+   return -FDT_ERR_BADNCELLS;
+   }
+
+   return fdt_appendprop(fdt, nodeoffset, name, data,
+ (addr_cells + size_cells) * sizeof(fdt32_t));
+}
diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index a470d1df6d..e70f5bf7e8 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -171,6 +171,16 @@ static inline uint32_t fdt32_ld(const fdt32_t *p)
| bp[3];
 }
 
+static inline void fdt32_st(void *property, uint32_t value)
+{
+   uint8_t *bp = property;
+
+   bp[0] = value >> 24;
+   bp[1] = (value >> 16) & 0xff;
+   bp[2] = (value >> 8) & 0xff;
+   bp[3] = value & 0xff;
+}
+
 static inline uint64_t fdt64_ld(const fdt64_t *p)
 {
const uint8_t *bp = (const uint8_t *)p;
@@ -185,6 +195,20 @@ static inline uint64_t fdt64_ld(const fdt64_t *p)
| bp[7];
 }
 
+static inline void fdt64_st(void *property, uint64_t value)
+{
+   uint8_t *bp = property;
+
+   bp[0] = value >> 56;
+   bp[1] = (value >> 48) & 0xff;
+   bp[2] = (value >> 40) & 0xff;
+   bp[3] = (value >> 32) & 0xff;
+   bp[4] = (value >> 24) & 0xff;
+   bp[5] = (value >> 16) & 0xff;
+   bp[6] = (value >> 8) & 0xff;
+   bp[7] = value & 0xff;
+}
+
 /**/
 /* Traversal functions*/
 /**/
@@ -1831,6 +1855,43 @@ static inline int fdt_appendprop_cell(void *fdt, int 
nodeoffset,
 #define fdt_appendprop_string(fdt, nodeoffset, name, str) \
fdt_appendprop((fdt), (nodeoffset), (name), (str), strlen(str)+1)
 
+/**
+ * fdt_appendprop_addrrange - append a address range property
+ * @fdt: pointer to the device tree blob
+ * @parent: offset of the parent node
+ * @nodeoffset: offset of the node to add a property at
+ * @name: name of property
+ * @addr: start address of a given range
+ * @size: size of a given range
+ *
+ * fdt_appendprop_addrrange() appends an address range value (start
+ * address and size) to the value of the named property in the given
+ * node, or creates a new property with that value if it does not
+ * already exist.
+ * If "name" is not specified, a default "reg" is used.
+ * Cell sizes are determined by parent's #address-cells and #size-cells.
+ *
+ * This function may insert data into the blob, and will therefore
+ * change the offsets of some existing nodes.
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADNCELLS, if the node has a badly formatted or invalid
+ * #address-cells property

[PATCH 01/27] libfdt: return correct value if #size-cells property is not present

[Sebastian Huber]

From: John Clarke 

According to the device tree specification, the default value for
#size-cells is 1, but fdt_size_cells() was returning 2 if this property
was not present.

This patch also makes fdt_address_cells() and fdt_size_cells() conform
to the behaviour documented in libfdt.h. The defaults are only returned
if fdt_getprop() returns -FDT_ERR_NOTFOUND, otherwise the actual error
is returned.

Signed-off-by: John Clarke 
---
 cpukit/dtc/libfdt/fdt_addresses.c | 16 +---
 cpukit/include/libfdt.h   |  2 +-
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt_addresses.c 
b/cpukit/dtc/libfdt/fdt_addresses.c
index 49537b578d..f13a87dfa0 100644
--- a/cpukit/dtc/libfdt/fdt_addresses.c
+++ b/cpukit/dtc/libfdt/fdt_addresses.c
@@ -64,7 +64,7 @@ static int fdt_cells(const void *fdt, int nodeoffset, const 
char *name)
 
c = fdt_getprop(fdt, nodeoffset, name, );
if (!c)
-   return 2;
+   return len;
 
if (len != sizeof(*c))
return -FDT_ERR_BADNCELLS;
@@ -78,10 +78,20 @@ static int fdt_cells(const void *fdt, int nodeoffset, const 
char *name)
 
 int fdt_address_cells(const void *fdt, int nodeoffset)
 {
-   return fdt_cells(fdt, nodeoffset, "#address-cells");
+   int val;
+
+   val = fdt_cells(fdt, nodeoffset, "#address-cells");
+   if (val == -FDT_ERR_NOTFOUND)
+   return 2;
+   return val;
 }
 
 int fdt_size_cells(const void *fdt, int nodeoffset)
 {
-   return fdt_cells(fdt, nodeoffset, "#size-cells");
+   int val;
+
+   val = fdt_cells(fdt, nodeoffset, "#size-cells");
+   if (val == -FDT_ERR_NOTFOUND)
+   return 1;
+   return val;
 }
diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index 830b77e4be..face02c102 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -1145,7 +1145,7 @@ int fdt_address_cells(const void *fdt, int nodeoffset);
  *
  * returns:
  * 0 <= n < FDT_MAX_NCELLS, on success
- *  2, if the node has no #size-cells property
+ *  1, if the node has no #size-cells property
  *  -FDT_ERR_BADNCELLS, if the node has a badly formatted or invalid
  * #size-cells property
  * -FDT_ERR_BADMAGIC,
-- 
2.16.4

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

[PATCH 25/27] libfdt: Add support for disabling ordering check/fixup

[Sebastian Huber]

From: Simon Glass 

Add a way to remove this check and the reordering code, which is
unnecessary if the dtb is known to be correctly ordered.

Signed-off-by: Simon Glass 
Reviewed-by: David Gibson 
Message-Id: <20200220214557.176528-8-...@chromium.org>
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_rw.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/cpukit/dtc/libfdt/fdt_rw.c b/cpukit/dtc/libfdt/fdt_rw.c
index fe13671eb6..13854253ff 100644
--- a/cpukit/dtc/libfdt/fdt_rw.c
+++ b/cpukit/dtc/libfdt/fdt_rw.c
@@ -435,7 +435,8 @@ int fdt_open_into(const void *fdt, void *buf, int bufsize)
return struct_size;
}
 
-   if (!fdt_blocks_misordered_(fdt, mem_rsv_size, struct_size)) {
+   if (can_assume(LIBFDT_ORDER) |
+   !fdt_blocks_misordered_(fdt, mem_rsv_size, struct_size)) {
/* no further work necessary */
err = fdt_move(fdt, buf, bufsize);
if (err)
-- 
2.16.4

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

[PATCH 10/27] libfdt: Make fdt_get_max_phandle() an inline

[Sebastian Huber]

From: David Gibson 

It's now a trivial wrapper around fdt_find_max_phandle() so we might as
well inline it.  We also remove it from the versioning linker script.
Theoretically, that's a breaking ABI change except that we haven't yet
released a version with it exposed in the shared object, so we can get
away with it.

Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_ro.c | 12 
 cpukit/include/libfdt.h| 12 +++-
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index 817ac39099..2c393a100b 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -172,18 +172,6 @@ int fdt_find_max_phandle(const void *fdt, uint32_t 
*phandle)
return 0;
 }
 
-uint32_t fdt_get_max_phandle(const void *fdt)
-{
-   uint32_t phandle;
-   int err;
-
-   err = fdt_find_max_phandle(fdt, );
-   if (err < 0)
-   return (uint32_t)-1;
-
-   return phandle;
-}
-
 int fdt_generate_phandle(const void *fdt, uint32_t *phandle)
 {
uint32_t max;
diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index 39ff6d5d25..1f44177f34 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -418,7 +418,17 @@ int fdt_find_max_phandle(const void *fdt, uint32_t 
*phandle);
  *  0, if no phandle was found in the device tree
  *  -1, if an error occurred
  */
-uint32_t fdt_get_max_phandle(const void *fdt);
+static inline uint32_t fdt_get_max_phandle(const void *fdt)
+{
+   uint32_t phandle;
+   int err;
+
+   err = fdt_find_max_phandle(fdt, );
+   if (err < 0)
+   return (uint32_t)-1;
+
+   return phandle;
+}
 
 /**
  * fdt_generate_phandle - return a new, unused phandle for a device tree blob
-- 
2.16.4

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

[PATCH 06/27] Revert "libfdt: Add phandle generation helper"

[Sebastian Huber]

From: David Gibson 

This reverts commit 54ea41c22415cb0e283d22faf71202051c89400c.

Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_ro.c  | 31 ---
 cpukit/include/libfdt.h | 19 ---
 cpukit/include/libfdt_env.h |  1 -
 3 files changed, 51 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index 97cdcda0db..eafc142828 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -170,37 +170,6 @@ uint32_t fdt_get_max_phandle(const void *fdt)
return 0;
 }
 
-int fdt_generate_phandle(const void *fdt, uint32_t *phandle)
-{
-   uint32_t max = 0;
-   int offset = -1;
-
-   while (true) {
-   uint32_t value;
-
-   offset = fdt_next_node(fdt, offset, NULL);
-   if (offset < 0) {
-   if (offset == -FDT_ERR_NOTFOUND)
-   break;
-
-   return offset;
-   }
-
-   value = fdt_get_phandle(fdt, offset);
-
-   if (value > max)
-   max = value;
-   }
-
-   if (max == FDT_MAX_PHANDLE)
-   return -FDT_ERR_NOPHANDLES;
-
-   if (phandle)
-   *phandle = max + 1;
-
-   return 0;
-}
-
 static const struct fdt_reserve_entry *fdt_mem_rsv(const void *fdt, int n)
 {
int offset = n * sizeof(struct fdt_reserve_entry);
diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index 7e102d188e..a470d1df6d 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -140,10 +140,6 @@
 
 #define FDT_ERR_MAX17
 
-/* constants */
-#define FDT_MAX_PHANDLE 0xfffe
-   /* Valid values for phandles range from 1 to 2^32-2. */
-
 /**/
 /* Low-level functions (you probably don't need these)*/
 /**/
@@ -380,21 +376,6 @@ const char *fdt_string(const void *fdt, int stroffset);
  */
 uint32_t fdt_get_max_phandle(const void *fdt);
 
-/**
- * fdt_generate_phandle - return a new, unused phandle for a device tree blob
- * @fdt: pointer to the device tree blob
- * @phandle: return location for the new phandle
- *
- * Walks the device tree blob and looks for the highest phandle value. On
- * success, the new, unused phandle value (one higher than the previously
- * highest phandle value in the device tree blob) will be returned in the
- * @phandle parameter.
- *
- * Returns:
- *   0 on success or a negative error-code on failure
- */
-int fdt_generate_phandle(const void *fdt, uint32_t *phandle);
-
 /**
  * fdt_num_mem_rsv - retrieve the number of memory reserve map entries
  * @fdt: pointer to the device tree blob
diff --git a/cpukit/include/libfdt_env.h b/cpukit/include/libfdt_env.h
index 4d1cdfa585..eb2053845c 100644
--- a/cpukit/include/libfdt_env.h
+++ b/cpukit/include/libfdt_env.h
@@ -52,7 +52,6 @@
  * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
-#include 
 #include 
 #include 
 #include 
-- 
2.16.4

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

Re: SPDX License Identifier Only and Full Copy?

[Sebastian Huber]

On 26/02/2020 05:51, Chris Johns wrote:



On 26/2/20 3:46 pm, Gedare Bloom wrote:

On Tue, Feb 25, 2020 at 9:18 PM Chris Johns  wrote:




On 26/2/20 3:06 pm, Gedare Bloom wrote:

On Tue, Feb 25, 2020 at 6:57 PM Chris Johns  wrote:


On 24/2/20 6:52 pm, Sebastian Huber wrote:

Hello,

I updated the File Template section:

https://docs.rtems.org/branches/master/eng/coding-file-hdr.html

Please have a look at it and check if it is all right for you.



Does there need to be something about code copied into the source tree?

Chris

Do you mean 3rd party code / code that is not licensed with 2-BSD?



Take this file ...

https://git.rtems.org/rtems/tree/cpukit/dtc/README.license

Does the procedure need to manage the process a user follows to add a file like
this? The procedure in the link covers code written by the user which is great
but not code that is imported. Should it?

Chris

OK, I think of this as 3rd party code. This case is important to
capture in our processes, and I'm glad you pointed it out. We always
strive to minimize changes to 3rd party code to enhance
maintainability. However, I could see there are benefits to adding our
own header information to 3rd party source files, in order to capture
their license information in SPDX for automated compliance checking,
if nothing else.


Yes there are conflicting requirements here. Maybe the procedure could suggest
working with the upstream project adding the head?


The File Template section is a subsection of Coding Standards. Maybe we 
should make it more clear that this targets code specifically written 
for RTEMS.


The third-party code guide lines are still in the wiki:

https://devel.rtems.org/wiki/Developer/Coding/ThirdPartyCode

We should first try to fix things with the upstream project and then 
merge it back.


In the dtc example, the SPDX License Identifiers are already present in 
a later version.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] c-user: rtems_scheduler_map_to_posix_priority()

[Sebastian Huber]

Are maybe

rtems_scheduler_map_priority_to_posix()

rtems_scheduler_map_priority_from_posix()

better than the

rtems_scheduler_map_to_posix_priority()

rtems_scheduler_map_from_posix_priority()

of the patch?

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Link issue on xilinx_zynq_a9_qemu BSP on rtems-libbsd head

[Sebastian Huber]

On 28/02/2020 04:40, Alan Cudmore wrote:

Hi Lou,
Did you ever solve this problem?
I just tried linking an out of tree program for the beaglebone black
BSP and have the same undefined symbols. The testsuite links correctly
and the symbols are in the testsuite binaries, but not in libbsd.a


For libbsd it is required that you link with the section garbage 
collection enabled: -Wl,--gc-sections


This is how the tests are linked. If you omit the -Wl,--gc-sections in 
your application you do something which is not tested.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Libbsd 5-freebsd-12 does not build for BBB

[Sebastian Huber]

On 28/02/2020 06:23, Chris Johns wrote:

Hi,

Please find attached an error log for libbsd for the BBB.


This should be already fixed:

https://git.rtems.org/rtems-libbsd/commit/?id=7606ec29778f1fabf70f3fc10edca02155d02c8c

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Libbsd 5-freebsd-12 does not build for BBB

[Chris Johns]

Hi,

Please find attached an error log for libbsd for the BBB.

Chris
RTEMS Tools Project - Source Builder Error Report
 Build: error: building 
rtems-libbsd-ve562e3bdf33f5de01ede936d5621ab7de88f74d3-x86_64-freebsd11.2-1
 Command Line: ../source-builder/sb-set-builder --prefix=/opt/work/rtems/5 
--log=xilinx_zynq_zc706.txt --with-rtems-smp 5/bsps/xilinx_zynq_zc706
 Python: 2.7.15 (default, Oct  2 2018, 01:21:44) [GCC 4.2.1 Compatible FreeBSD 
Clang 6.0.0 (tags/RELEASE_600/final 326565)]
 
git://git.rtems.org/rtems-source-builder.git/origin/25f1d894a30daf669302bbf7a7c26d0127fb4e07
 FreeBSD kaka 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4 #0: Thu Sep 27 08:16:24 
UTC 2018 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC 
amd64
Tail of the build log:
[1506/1916] Compiling freebsd/sbin/nvmecontrol/devlist.c
[1507/1916] Compiling freebsd/sys/dev/mii/ukphy.c
[1508/1916] Compiling freebsd/sys/kern/init_main.c
[1509/1916] Compiling freebsd/sys/dev/usb/controller/usb_controller.c
[1510/1916] Compiling freebsd/sys/kern/kern_uuid.c
[1511/1916] Compiling rtemsbsd/sys/dev/atsam/if_atsam.c
[1512/1916] Compiling rtemsbsd/rtems/rtems-kernel-bus-dma-mbuf.c
[1513/1916] Compiling mDNSResponder/mDNSShared/mDNSDebug.c
[1514/1916] Compiling rtemsbsd/local/usb_if.c
[1515/1916] Compiling freebsd/sys/kern/kern_module.c
[1516/1916] Compiling rtemsbsd/rtems/rtems-bsd-shell-stty.c
[1517/1916] Compiling freebsd/sys/dev/usb/usb_msctest.c
[1518/1916] Compiling freebsd/sys/dev/usb/usb_process.c
[1519/1916] Compiling freebsd/sys/dev/usb/usb_busdma.c
[1520/1916] Compiling freebsd/sys/dev/usb/usb_debug.c
[1521/1916] Compiling rtemsbsd/local/gpiobus_if.c
[1522/1916] Compiling rtemsbsd/local/mmcbus_if.c
[1523/1916] Compiling freebsd/sys/dev/usb/usb_dev.c
[1524/1916] Compiling freebsd/sys/dev/bce/if_bce.c
[1525/1916] Compiling freebsd/sbin/nvmecontrol/firmware.c
[1526/1916] Compiling freebsd/sys/kern/subr_sleepqueue.c
[1527/1916] Compiling rtemsbsd/rtems/rtems-bsd-shell-nvmecontrol.c
[1528/1916] Compiling freebsd/sys/dev/usb/serial/ubser.c
[1529/1916] Compiling rtemsbsd/local/ifdi_if.c
[1530/1916] Compiling freebsd/sys/dev/usb/quirk/usb_quirk.c
[1531/1916] Compiling freebsd/sys/dev/usb/serial/u3g.c
[1532/1916] Compiling freebsd/sys/dev/e1000/e1000_phy.c
[1533/1916] Compiling freebsd/sys/dev/usb/net/if_kue.c
[1534/1916] Compiling freebsd/sys/netinet/libalias/alias_util.c
[1535/1916] Compiling freebsd/sys/dev/usb/input/uhid.c
[1536/1916] Compiling freebsd/sys/dev/usb/controller/ohci.c
[1537/1916] Compiling freebsd/sys/dev/usb/controller/saf1761_otg.c
[1538/1916] Compiling rtemsbsd/rtems/rtems-kernel-mbuf.c
[1539/1916] Compiling freebsd/sys/netinet/ip_icmp.c
[1540/1916] Compiling freebsd/sys/dev/mii/e1000phy.c
[1541/1916] Compiling freebsd/sbin/nvmecontrol/sanitize.c
[1542/1916] Compiling freebsd/sys/opencrypto/skipjack.c
[1543/1916] Compiling mDNSResponder/mDNSCore/DNSDigest.c
[1544/1916] Compiling freebsd/sys/dev/usb/serial/umcs.c
[1545/1916] Compiling freebsd/sys/dev/fdt/fdt_common.c
[1546/1916] Compiling freebsd/sys/dev/mii/mii_fdt.c
[1547/1916] Compiling freebsd/sys/dev/mmc/mmc.c
[1548/1916] Compiling freebsd/sys/dev/e1000/e1000_82541.c
[1549/1916] Compiling freebsd/sys/dev/fxp/if_fxp.c
[1550/1916] Compiling freebsd/sys/dev/evdev/evdev_utils.c
[1551/1916] Compiling freebsd/sys/opencrypto/gmac.c
[1552/1916] Compiling rtemsbsd/pppd/upap.c
[1553/1916] Compiling rtemsbsd/sys/dev/input/touchscreen/tsc_lpc32xx.c
[1554/1916] Compiling freebsd/sys/dev/e1000/e1000_82543.c
[1555/1916] Compiling freebsd/sys/dev/e1000/e1000_82571.c
[1556/1916] Compiling freebsd/sys/dev/mmc/mmcsd.c
[1557/1916] Compiling freebsd/sys/dev/bfe/if_bfe.c
[1558/1916] Compiling rtemsbsd/pppd/chat.c
[1559/1916] Compiling freebsd/sys/crypto/rijndael/rijndael-api-fst.c
[1560/1916] Compiling freebsd/sys/crypto/blowfish/bf_enc.c
[1561/1916] Compiling freebsd/sys/fs/devfs/devfs_vnops.c
[1562/1916] Compiling rtemsbsd/pppd/demand.c
[1563/1916] Compiling freebsd/sys/arm/ti/am335x/am335x_prcm.c
[1564/1916] Compiling freebsd/sys/arm/ti/cpsw/if_cpsw.c
[1565/1916] Compiling rtemsbsd/rtems/rtems-kernel-sysctlbyname.c
[1566/1916] Compiling freebsd/sys/netinet/tcp_sack.c
[1567/1916] Compiling freebsd/sys/opencrypto/cast.c
[1568/1916] Compiling freebsd/sys/arm/ti/ti_hwmods.c
[1569/1916] Compiling freebsd/sys/netinet6/scope6.c
[1570/1916] Compiling freebsd/sys/netinet6/udp6_usrreq.c
[1571/1916] Compiling rtemsbsd/sys/dev/dw_mmc/dw_mmc.c
[1572/1916] Compiling freebsd/sys/kern/subr_firmware.c
[1573/1916] Compiling freebsd/sys/netpfil/pf/in4_cksum.c
[1574/1916] Compiling freebsd/sys/netinet6/nd6_rtr.c
[1575/1916] Compiling freebsd/sys/netinet6/dest6.c
[1576/1916] Compiling freebsd/sbin/nvmecontrol/nvmecontrol.c
[1577/1916] Compiling freebsd/sys/netinet6/ip6_id.c
[1578/1916] Compiling freebsd/sys/kern/subr_prf.c
[1579/1916] Compiling rtemsbsd/rtems/rtems-kernel-thread.c
[1580/1916] Compiling freebsd/sbin/nvmecontrol/format.c
[1581/1916] Compiling freebsd/sys/netinet6/frag6.c

Re: Project query #2920

[Anmol Mishra]

Thank you for the reply, I am going through the tickets and will be fixing
the bugs for the same. I will be submitting the draft proposal as soon as
possible. Meanwhile, I will study previous student's work to get a heads-up.

Regards
Anmol Mishra

On Wed, Feb 26, 2020 at 5:34 PM Joel Sherrill  wrote:

>
>
> On Wed, Feb 26, 2020, 2:06 AM Anmol Mishra  wrote:
>
>> Hello, My name is Anmol, I am a Google Summer of Code, Student developer
>> aspirant for 2020.
>> I have completed the Hello-world task.
>>
>> I am interested in Ticket #2920 i.e "Improve Coverage Analysis Toolset".
>> I know that Dr. Joel is the owner and Dr. Gedare has reported it as per the
>> information provided on the wiki page. Is there any mentor interested to
>> mentor me for this project? I sincerely want to commit myself to this
>> project and Is this project under high priority to be considered for GSoC?
>>
>
> It would likely be me as mentor. Former students who have worked on
> coverage help out also.
>
> I suggest looking at all the coverage tickets filed and back through this
> mailing list for help in reproducing the bugs. There are a couple of bugs
> and a few desired improvements.
>
> --joel
>
>>
>>
>> Best Regards
>> Anmol
>> ___
>> 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: Link issue on xilinx_zynq_a9_qemu BSP on rtems-libbsd head

[Alan Cudmore]

Hi Lou,
Did you ever solve this problem?
I just tried linking an out of tree program for the beaglebone black
BSP and have the same undefined symbols. The testsuite links correctly
and the symbols are in the testsuite binaries, but not in libbsd.a

doing a grep of the rtems-libbsd source there is a PHYS_TO_VM_PAGE in
rtemsbsd/powerpc/include/linux/page.h
When I grep the directory where I installed the bsd library and
headers, this file is not present.

Any ideas?

Thanks,
Alan

On Wed, Jan 15, 2020 at 1:59 PM Lou Woods  wrote:
>
> Hello all,
>
> I just pulled from the master of both rtems 
> (362cf319d44e7e64987f12aa36ea030e6298c586) and rtems-libbsd 
> (d892051f37c2c4ad7f345f6a817ea3d38e56a431) trees and ran into an couple 
> undefined references when linking an application outside of the tree.  The 
> application doesn't directly use either symbol and has worked unmodified on 
> older trees.  This build issue is not present when using the 5-freebsd-12 
> branch of rtems-libbsd on the same application code.  I can move forward with 
> the 5-freebsd-12 branch so this isn't a show stopper for me.
>
> $ make
> arm-rtems5-gcc --pipe -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard 
> -mtune=cortex-a9 -O0 -g -ffunction-sections -fdata-sections -Wall 
> -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes 
> -Wnested-externs -B 
> /home/woods/zynq-quickstart-trial/bsp-install/arm-rtems5/xilinx_zynq_a9_qemu/lib/
>  -specs bsp_specs -qrtems init.c  -o init.exe -lbsd -lm -ltelnetd
> /data/home/woods/zynq-quickstart-trial/tools/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:
>  
> /home/woods/zynq-quickstart-trial/bsp-install/arm-rtems5/xilinx_zynq_a9_qemu/lib/libbsd.a(uipc_mbuf.c.18.o):
>  in function `m_unmappedtouio':
> /data/home/woods/zynq-quickstart-trial/rtems-libbsd/build/arm-rtems5-xilinx_zynq_a9_qemu-default/../../freebsd/sys/kern/uipc_mbuf.c:1813:
>  undefined reference to `PHYS_TO_VM_PAGE'
> /data/home/woods/zynq-quickstart-trial/tools/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:
>  
> /data/home/woods/zynq-quickstart-trial/rtems-libbsd/build/arm-rtems5-xilinx_zynq_a9_qemu-default/../../freebsd/sys/kern/uipc_mbuf.c:1814:
>  undefined reference to `uiomove_fromphys'
> collect2: error: ld returned 1 exit status
> make: *** [init.exe] Error 1
>
> RTEMS was configured like this:
> ../rtems/configure --prefix=${rw}/bsp-install --target=arm-rtems5 \
>  --enable-rtemsbsp=xilinx_zynq_a9_qemu --disable-networking
>
> libbsd was configured like this:
> $ git clone git://git.rtems.org/rtems-libbsd.git
> $ cd ./rtems-libbsd
> $ git submodule init
> $ git submodule update rtems_waf
> $ python3 ./waf configure --rtems-tools=${rw}/tools --rtems=${rw}/bsp-install 
> \
>  --prefix=${rw}/bsp-install --rtems-bsps=arm/xilinx_zynq_a9_qemu
> $ python3 ./waf
> $ python3 ./waf install
>
> Makefile
>
> include $(RTEMS_MAKEFILE_PATH)/Makefile.inc
> include $(RTEMS_MAKEFILE_PATH)/make/target.cfg
> include $(RTEMS_CUSTOM)
>
> all: init.exe
>
> CFLAGS += -B ${RTEMS_MAKEFILE_PATH}/lib/ -specs bsp_specs -qrtems
>
> init.exe: init.c
> $(CC) $(CFLAGS) init.c  -o $@ -lbsd -lm -ltelnetd
>
>  clean:
>  init.exe
>
> If any other information can be useful, please let me know.
>
> Thanks,
> Lou Woods
> On-Line Applications Research
>
> ___
> 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-libbsd-5-freebsd-12] rtems_waf: Update to master (096372fc4504)

[chrisj]

From: Chris Johns 

Closes #3888
---
 rtems_waf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rtems_waf b/rtems_waf
index 1b896361..096372fc 16
--- a/rtems_waf
+++ b/rtems_waf
@@ -1 +1 @@
-Subproject commit 1b896361d302aeda0145af90972aea863e28898f
+Subproject commit 096372fc4504730e50b51b952ce47ca603b35f01
-- 
2.23.0

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

[PATCH] rtems_waf: Update to master (096372fc4504)

[chrisj]

From: Chris Johns 

Updates #3888
---
 rtems_waf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rtems_waf b/rtems_waf
index 1b896361..096372fc 16
--- a/rtems_waf
+++ b/rtems_waf
@@ -1 +1 @@
-Subproject commit 1b896361d302aeda0145af90972aea863e28898f
+Subproject commit 096372fc4504730e50b51b952ce47ca603b35f01
-- 
2.23.0

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

Re: [PATCH 0/1] Add generated glossary

[Chris Johns]

On 28/2/20 1:04 am, Sebastian Huber wrote:
> A contribution of the scripts and the specification items to the RTEMS Project
> is currently blocked due to several undecided things related to the RTEMS
> Qualification Project:
> 
> https://lists.rtems.org/pipermail/devel/2020-February/057246.html
> 

A review is on my list but I am struggling to find the time to give it the
consideration is deserves. I will review it.

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

Google Summer of Code 2020

[Joel Sherrill]

Hi

Please post the flyer in the link and encourage students. :)

Google has decided to sponsor the Summer of Code again. This year they
have accepted about 200 open source organizations including RTEMS.
As thrilled as I am to have students work with RTEMS, there are a LOT of
other free software projects that they might find more interesting to
them.  It is about learning, having fun, and being productive.

Last year they sponsored over 1300 students with a successful student
getting a stipend of USD6000.  This is a virtual program with students
working at their home location.

We are now in the part of the program where students find a participating
open source organization they are interested in. They need to work with
that organization's mentors and project ideas and then prepare a proposal.
The Google site guides them through this but I am happy to answer questions.

Information about the program is at:

https://summerofcode.withgoogle.com/

This is a link to the flyer for the program. Please post:

https://developers.google.com/open-source/gsoc/resources/downloads/GSoC2020Flyer.pdf

RTEMS has mentored over 100 students in the past 14 years of participating.

if anyone has questions, feel free to send them to me or Gedare Bloom (
ged...@rtems.org).

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

Re: Device Tree Blob for Beaglebone Black?

[Amar Takhar]

On 2020-02-28 09:01 +1100, Chris Johns wrote:


> The issue of RTEMS version mismatch of blobs is a real issue waiting to hit 
> our
> users and simply linking the blobs into the executable would solve this.

 
> This also looks like a blocker for CI testing.

I agree with everything you said but I'd like to add a bit to this:

The only two ways this can be dealt with is to have an order of magnitude more 
boards for testing running different versions.  The second way is to boot to 
RTEMS or something else and write new files back to the card.  The 2nd will 
result in heavy SD card wear and is complicated to get working correctly over 
time.

I've had to do this before but not with FDT.  The issue is things change 
over time and this 'write back' becomes a moving target.  This results in 
multiple test environments based on specific sets of source it's a lot of 
overhead.

It's easy to say it looks good now but that's rarely true in 5, 10, 15 years 
down the road when you still have to support old branches and sometimes 
multiple 
versions within those branches.


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

Re: Build Linux: PASSED 5/rtems-arm on x86_64-linux-gnu

[Chris Johns]

On 28/2/20 2:35 am, Gedare Bloom wrote:
> On Wed, Feb 26, 2020 at 11:56 PM Sebastian Huber
>  wrote:
>> On 27/02/2020 07:38, Chris Johns wrote:
>>> On 27/2/20 5:25 pm, Sebastian Huber wrote:
 On 26/02/2020 23:15, Chris Johns wrote:
> On 27/2/20 12:26 am, Sebastian Huber wrote:
>> On 26/02/2020 14:21,sebastian.hu...@embedded-brains.de   wrote:
>>> RTEMS Source Builder Repository Status
>>> Remotes:
>>>   1: 
>>> origin:ssh://s...@dispatch.rtems.org/data/git/rtems-source-builder.git
>>>   2:
>>> main:g...@main.eb.localhost:eb/101-embedded-brains/oss/rtems-source-builder.git
>>>   
>>> 3:esa:g...@gitrepos.estec.esa.int:external/rtems-smp-qualification-rsb.git
>> Why are the remote repositories reported?
> It provides the git environment being used. The report needs a repo and I 
> am not
> sure you can tell which is the source of branch programmatically.
>
>> I think we should remove this private and user-dependent information.
> I have a specific repo I use for these types of publicly posted build ...
>
> RTEMS Source Builder Repository Status
>Remotes:
>  1: origin: git://git.rtems.org/rtems-source-builder.git
>Status:
> Clean
>Head:
> Commit: 14c5cb77132a3e66afab571afbf67dacad433ec3
 The Status and Head are very important information. Which remote 
 repositories
 you use should be none of the business of the RTEMS Project. It can leak
 business relationships and project names. We should not do this without 
 asking
 the user. I suggest to remove this part of the report.
>>> I think the repo used is important information especially if someone is 
>>> wanting
>>> to replicate post results.
>>
>> To replicate results all you need is the commit hash and the original
>> report must show a clean status. If the commit hash is not included in
>> the RTEMS repositories you can ask the reporter.
>>
>> I think if a user requests to send a report and the status is not clean,
>> then the RSB should stop with an error.

This is a good idea.

> I agree with Sebastian. We should remove the "Remotes:" part.

What if I change the Remotes to ...

 Remotes:
   [ removed, contact m...@there.here for details ]

.. and it is kept for local builds? I believe in an environment that is audited
this valuable information.

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

Re: Device Tree Blob for Beaglebone Black?

[Chris Johns]

On 28/2/20 9:14 am, Gedare Bloom wrote:
> On Thu, Feb 27, 2020 at 3:01 PM Chris Johns  wrote:
>>
>> On 28/2/20 7:23 am, Alan Cudmore wrote:
>>> I noticed that the Zephyr RTOS (https://www.zephyrproject.org) uses a
>>> device tree based initialization for all of its BSPs.
>>> For example, here is the top level device tree source for the Adafruit
>>> Trinket M0, which is a very small Atmel Cortex M0 based board:
>>> https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/adafruit_trinket_m0/adafruit_trinket_m0.dts
>>>
>>> The rest of the device tree source for common processors and devices are 
>>> here:
>>> https://github.com/zephyrproject-rtos/zephyr/tree/master/dts
>>>
>>> To me, it looks like they have to develop (or port) and maintain
>>> device trees for each board and device that is supported.
>>>
>>> Does that look like a model that RTEMS could use? I'm not sure I
>>> understand everything that deploying such a model implies, or if it
>>> just makes more sense to use the existing FreeBSD or linux device
>>> trees.
>>
>> This is where I was heading in my thinking but I am not sure. I am settling 
>> on
>> having a dts tree in rtems.git and we may just have to manually manage the
>> files. I am not sure there are enough files to warrant a system like libbsd 
>> and
>> FreeBSD at this point in time. That may change with the new build system and
>> python being available however until then manual is fine. Let me explain ...
>>
>> I have been looking beyond the internal development aspects and to how we use
>> FDT blobs and I am wondering if the approach we have with the shared FDT BSP
>> support is the right fit for RTEMS and a statically linked executable.
>>
>> I believe currently we need a suitable bootloader, ie u-boot, to load a blob.
>> This is the Linux way of doing things and this may be the right approach for
>> Linux but I am not so sure it is for us. It means you need u-boot and a 
>> suitable
>> file system plus you have a lot more items to configuration manage in 
>> production
>> systems and a lot more complexity for self upgrading.
>>
>> Why do we have a bootloader load the FDT files when we statically link
>> everything else?
>>
>> Why not link them into the executable and register them? It s easy to do.
>>
>> The flow on from doing this has some real advantages. FDT files that are 
>> linked
>> into an executable can then live in the rtems.git repo. If you move branches
>> when testing or in production you do not need to manage and match suitable 
>> FDT
>> blobs.
>>
>> I am not advocating this is the only solution. I can see for some BSPs this 
>> will
>> not work and u-boot loading is the only or best solution. I however believe 
>> for
>> DTS that is open and available we should avoid the whole mess of needing to
>> build and manage them on boot media separately to the executable.
>>
>> The issue of RTEMS version mismatch of blobs is a real issue waiting to hit 
>> our
>> users and simply linking the blobs into the executable would solve this.
>>
>> I am confronted by this now. I have a BBB with FDT blobs for libbsd master 
>> and
>> now I need to run libbsd 5-freebsd-12 to test a release. I have to open my 
>> test
>> set up open, pop the SD card and then update it. This seems unnecessary and
>> avoidable to me.
>>
>> This also looks like a blocker for CI testing.
>>
>> Chris
>>
> Hi Chris,
> 
> I'm 100% with you. I will also go a step further and advocate that
> source-based DTS -> dtc -> FDT in static images seems beneficial to
> users. I don't know if we could get any input from users to justify
> that, but I can see advantages for pre-qual and license compliance
> that go beyond the technical advantages that you discuss above.

Thanks and yes what I raised was a small part of the problem space.

> Initial steps in this direction would make a good GSoC for the right
> (strong) student.

This is a good idea. I am not sure how much work is needed or how to define the
work. I think the RTEMS side of things should not be hard but I am not sure
about the interface to libbsd and what is required here. I would help mentor
this project if is suitable for GSoC.

If this goes ahead we can start to populate a dts tree in RTEMS and that would
mean a release could be made.

One issue this raises is the libbds master vs 5-freebsd-12 branch. I am not sure
what happens here and which dts is placed in the rtems.git repo. Maybe placing
5-freebsd-12 dts in rtems.git is done up to the release of RTEMS 5 then we
update rtems.git master to match libbsd's master?

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

Re: tar/psx/bsdtar on CentOS 8

[Joel Sherrill]

Jeff.. try the stuff below and let us know.

On Tue, Feb 25, 2020 at 9:12 PM Chris Johns  wrote:

> On 25/2/20 5:09 am, Joel Sherrill wrote:
> > Hi
> >
> > CentOS 8 does not have a package for pax. It does have a package for
> bsdtar.
> >
> > Is bsdtar sufficient for the tests? I don't call the precise issue we
> favored
> > pax over
> > GNU tar.
> >
> > If so, could testsuites/libtests/configure.ac 
> accept both?
> >
> > Pax appears to be used only for the dl* and tar* tests. I had thought
> about it
> > not being a hard fail but those seem like bad tests to drop out.
>
> Does RTEMS understand the standard tar format? If PAX format is needed
> does your
> tar accept `--posix` or `--format pax`. I am happy for a change like this
> but it
> may only work on FreeBSD ;)
>

Long ago, I swear it was just tar but something broke on some host. My
vague recollection
is very large user ids in a Mac networked environment. But the ustar format
allows 8 octets
for user ids.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_06


That may not have tripped the switch to pax except that pax is the POSIX
name of the
command.

Looking for the RHEL 8 release notes about this, I found

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/considerations_in_adopting_rhel_8/index


which indicates it moved to the "CodeReady Linux Builder repository" along
with a
number of other packages. That is in the PowerTools repo for CentOS.

https://serverfault.com/questions/997896/how-to-enable-powertools-repository-in-centos-8


Hopefully it works. Jeff will let us know.

--joel





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

Re: Device Tree Blob for Beaglebone Black?

[Gedare Bloom]

On Thu, Feb 27, 2020 at 3:01 PM Chris Johns  wrote:
>
> On 28/2/20 7:23 am, Alan Cudmore wrote:
> > I noticed that the Zephyr RTOS (https://www.zephyrproject.org) uses a
> > device tree based initialization for all of its BSPs.
> > For example, here is the top level device tree source for the Adafruit
> > Trinket M0, which is a very small Atmel Cortex M0 based board:
> > https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/adafruit_trinket_m0/adafruit_trinket_m0.dts
> >
> > The rest of the device tree source for common processors and devices are 
> > here:
> > https://github.com/zephyrproject-rtos/zephyr/tree/master/dts
> >
> > To me, it looks like they have to develop (or port) and maintain
> > device trees for each board and device that is supported.
> >
> > Does that look like a model that RTEMS could use? I'm not sure I
> > understand everything that deploying such a model implies, or if it
> > just makes more sense to use the existing FreeBSD or linux device
> > trees.
>
> This is where I was heading in my thinking but I am not sure. I am settling on
> having a dts tree in rtems.git and we may just have to manually manage the
> files. I am not sure there are enough files to warrant a system like libbsd 
> and
> FreeBSD at this point in time. That may change with the new build system and
> python being available however until then manual is fine. Let me explain ...
>
> I have been looking beyond the internal development aspects and to how we use
> FDT blobs and I am wondering if the approach we have with the shared FDT BSP
> support is the right fit for RTEMS and a statically linked executable.
>
> I believe currently we need a suitable bootloader, ie u-boot, to load a blob.
> This is the Linux way of doing things and this may be the right approach for
> Linux but I am not so sure it is for us. It means you need u-boot and a 
> suitable
> file system plus you have a lot more items to configuration manage in 
> production
> systems and a lot more complexity for self upgrading.
>
> Why do we have a bootloader load the FDT files when we statically link
> everything else?
>
> Why not link them into the executable and register them? It s easy to do.
>
> The flow on from doing this has some real advantages. FDT files that are 
> linked
> into an executable can then live in the rtems.git repo. If you move branches
> when testing or in production you do not need to manage and match suitable FDT
> blobs.
>
> I am not advocating this is the only solution. I can see for some BSPs this 
> will
> not work and u-boot loading is the only or best solution. I however believe 
> for
> DTS that is open and available we should avoid the whole mess of needing to
> build and manage them on boot media separately to the executable.
>
> The issue of RTEMS version mismatch of blobs is a real issue waiting to hit 
> our
> users and simply linking the blobs into the executable would solve this.
>
> I am confronted by this now. I have a BBB with FDT blobs for libbsd master and
> now I need to run libbsd 5-freebsd-12 to test a release. I have to open my 
> test
> set up open, pop the SD card and then update it. This seems unnecessary and
> avoidable to me.
>
> This also looks like a blocker for CI testing.
>
> Chris
>
Hi Chris,

I'm 100% with you. I will also go a step further and advocate that
source-based DTS -> dtc -> FDT in static images seems beneficial to
users. I don't know if we could get any input from users to justify
that, but I can see advantages for pre-qual and license compliance
that go beyond the technical advantages that you discuss above.

Initial steps in this direction would make a good GSoC for the right
(strong) student.

Gedare

> >
> > Just a thought.. I'm still catching up!
> > Thanks,
> > Alan
> >
> > On Thu, Feb 27, 2020 at 2:44 PM Amar Takhar  wrote:
> >>
> >> On 2020-02-27 20:06 +0100, Christian Mauderer wrote:
> >>
>  The only good way to handle this is to have it all in 1 giant repository 
>  we work
>  with.  Every other solution is a pain no matter how well thought out it 
>  is.  I
>  personally lean more on the service side of things that it should be 
>  *our*
>  problem to maintain this and for users it should just work.>
>  The easiest way to handle this is to have the minimum version required 
>  in the
>  commit message.  Eg, when pushing to libbsd have:
> 
>    Minimum RTEMS: 
> 
>  After that it's up to the user to ensure to keep up-to-date.  The first 
>  thing
>  most developers do is check the log.
> >>>
> >>> Sounds like a nice suggestion. But it needs quite a lot of discipline
> >>> for the developers. So most likely a lot of errors will happen. Beneath
> >>> that it's not far from what we do now: Suggest to use commits from the
> >>> same date.
> >>
> >> There are two ways to look at it -- requiring discipline or simply doing
> >> something we should already be doing.  Because right now there is no way 
> 

Re: Device Tree Blob for Beaglebone Black?

[Chris Johns]

On 28/2/20 7:23 am, Alan Cudmore wrote:
> I noticed that the Zephyr RTOS (https://www.zephyrproject.org) uses a
> device tree based initialization for all of its BSPs.
> For example, here is the top level device tree source for the Adafruit
> Trinket M0, which is a very small Atmel Cortex M0 based board:
> https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/adafruit_trinket_m0/adafruit_trinket_m0.dts
> 
> The rest of the device tree source for common processors and devices are here:
> https://github.com/zephyrproject-rtos/zephyr/tree/master/dts
> 
> To me, it looks like they have to develop (or port) and maintain
> device trees for each board and device that is supported.
> 
> Does that look like a model that RTEMS could use? I'm not sure I
> understand everything that deploying such a model implies, or if it
> just makes more sense to use the existing FreeBSD or linux device
> trees.

This is where I was heading in my thinking but I am not sure. I am settling on
having a dts tree in rtems.git and we may just have to manually manage the
files. I am not sure there are enough files to warrant a system like libbsd and
FreeBSD at this point in time. That may change with the new build system and
python being available however until then manual is fine. Let me explain ...

I have been looking beyond the internal development aspects and to how we use
FDT blobs and I am wondering if the approach we have with the shared FDT BSP
support is the right fit for RTEMS and a statically linked executable.

I believe currently we need a suitable bootloader, ie u-boot, to load a blob.
This is the Linux way of doing things and this may be the right approach for
Linux but I am not so sure it is for us. It means you need u-boot and a suitable
file system plus you have a lot more items to configuration manage in production
systems and a lot more complexity for self upgrading.

Why do we have a bootloader load the FDT files when we statically link
everything else?

Why not link them into the executable and register them? It s easy to do.

The flow on from doing this has some real advantages. FDT files that are linked
into an executable can then live in the rtems.git repo. If you move branches
when testing or in production you do not need to manage and match suitable FDT
blobs.

I am not advocating this is the only solution. I can see for some BSPs this will
not work and u-boot loading is the only or best solution. I however believe for
DTS that is open and available we should avoid the whole mess of needing to
build and manage them on boot media separately to the executable.

The issue of RTEMS version mismatch of blobs is a real issue waiting to hit our
users and simply linking the blobs into the executable would solve this.

I am confronted by this now. I have a BBB with FDT blobs for libbsd master and
now I need to run libbsd 5-freebsd-12 to test a release. I have to open my test
set up open, pop the SD card and then update it. This seems unnecessary and
avoidable to me.

This also looks like a blocker for CI testing.

Chris

> 
> Just a thought.. I'm still catching up!
> Thanks,
> Alan
> 
> On Thu, Feb 27, 2020 at 2:44 PM Amar Takhar  wrote:
>>
>> On 2020-02-27 20:06 +0100, Christian Mauderer wrote:
>>
 The only good way to handle this is to have it all in 1 giant repository 
 we work
 with.  Every other solution is a pain no matter how well thought out it 
 is.  I
 personally lean more on the service side of things that it should be *our*
 problem to maintain this and for users it should just work.>
 The easiest way to handle this is to have the minimum version required in 
 the
 commit message.  Eg, when pushing to libbsd have:

   Minimum RTEMS: 

 After that it's up to the user to ensure to keep up-to-date.  The first 
 thing
 most developers do is check the log.
>>>
>>> Sounds like a nice suggestion. But it needs quite a lot of discipline
>>> for the developers. So most likely a lot of errors will happen. Beneath
>>> that it's not far from what we do now: Suggest to use commits from the
>>> same date.
>>
>> There are two ways to look at it -- requiring discipline or simply doing
>> something we should already be doing.  Because right now there is no way to 
>> tell
>> other than updating to the latest and if you are trying to bisect an issue 
>> this
>> because huge because you could feasibly jump into a comment that skips a
>> version.  How would a user know which version of the library *or* RTEMS to 
>> use?
>>
>>
>>> But maybe we should move that discussion. It's not FDT related anymore
>>> so no one will find it in this toppic. And I think for Chris the
>>> pressing matter is FDT just now because it blocks the release.
>>
>> Yes that's true.
>>
>>> The BSP groups that use bsps/shared/start/bsp-fdt.c are:
>>>
>>> - riscv/riscv
>>> - arm/imx
>>> - arm/beagle
>>> - arm/raspberrypi
>>> - arm/altera-cyclone-v
>>> - powerpc/qoriq
>>>
>>> For 

Re: Device Tree Blob for Beaglebone Black?

[Alan Cudmore]

I noticed that the Zephyr RTOS (https://www.zephyrproject.org) uses a
device tree based initialization for all of its BSPs.
For example, here is the top level device tree source for the Adafruit
Trinket M0, which is a very small Atmel Cortex M0 based board:
https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/adafruit_trinket_m0/adafruit_trinket_m0.dts

The rest of the device tree source for common processors and devices are here:
https://github.com/zephyrproject-rtos/zephyr/tree/master/dts

To me, it looks like they have to develop (or port) and maintain
device trees for each board and device that is supported.

Does that look like a model that RTEMS could use? I'm not sure I
understand everything that deploying such a model implies, or if it
just makes more sense to use the existing FreeBSD or linux device
trees.

Just a thought.. I'm still catching up!
Thanks,
Alan

On Thu, Feb 27, 2020 at 2:44 PM Amar Takhar  wrote:
>
> On 2020-02-27 20:06 +0100, Christian Mauderer wrote:
>
> > > The only good way to handle this is to have it all in 1 giant repository 
> > > we work
> > > with.  Every other solution is a pain no matter how well thought out it 
> > > is.  I
> > > personally lean more on the service side of things that it should be *our*
> > > problem to maintain this and for users it should just work.>
> > > The easiest way to handle this is to have the minimum version required in 
> > > the
> > > commit message.  Eg, when pushing to libbsd have:
> > >
> > >   Minimum RTEMS: 
> > >
> > > After that it's up to the user to ensure to keep up-to-date.  The first 
> > > thing
> > > most developers do is check the log.
> >
> > Sounds like a nice suggestion. But it needs quite a lot of discipline
> > for the developers. So most likely a lot of errors will happen. Beneath
> > that it's not far from what we do now: Suggest to use commits from the
> > same date.
>
> There are two ways to look at it -- requiring discipline or simply doing
> something we should already be doing.  Because right now there is no way to 
> tell
> other than updating to the latest and if you are trying to bisect an issue 
> this
> because huge because you could feasibly jump into a comment that skips a
> version.  How would a user know which version of the library *or* RTEMS to 
> use?
>
>
> > But maybe we should move that discussion. It's not FDT related anymore
> > so no one will find it in this toppic. And I think for Chris the
> > pressing matter is FDT just now because it blocks the release.
>
> Yes that's true.
>
> > The BSP groups that use bsps/shared/start/bsp-fdt.c are:
> >
> > - riscv/riscv
> > - arm/imx
> > - arm/beagle
> > - arm/raspberrypi
> > - arm/altera-cyclone-v
> > - powerpc/qoriq
> >
> > For beagle and raspberry it should be definitely the FreeBSD FDT.
> >
> > For imx: I'm currently working on imx6 support in the imx BSP and that
> > one will use a FreeBSD derived one too. Not sure about the original imx7
> > support in that BSP.
> >
> > For the other BSPs I don't have any idea which FDT has been used during
> > development.
>
>
> Okay that list is already compelling enough to have the split model of having
> source based files in-tree and binary outside.  I think it makes sense to have
> it 'just work' for opensource boards like the beagle and rpi even if that's 
> the
> only two that require it.
>
>
> Amar.
> ___
> 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] removed unneccesary assigning to rc triggering unused value error in coverity

[Gedare Bloom]

On Thu, Feb 27, 2020 at 9:30 AM Joel Sherrill  wrote:
>
>
>
> On Thu, Feb 27, 2020 at 9:48 AM Gedare Bloom  wrote:
>>
>> Hi Suyash,
>>
>> I have a  few comments for you.
>>
>> First, the commit message should follow the guidance at
>> https://docs.rtems.org/branches/master/eng/vc-users.html#creating-a-patch
>> and follow through the link about Commit Messages. We like to have a
>> short "tag" at the start of the commit to indicate the area of RTEMS
>> the commit applies to, in this case, maybe "bsps/shared: ignore return
>> value in display driver"  -- We don't currently have a set of standard
>> tags.
>
>
> The tag before the colon should be as specific as possible. This only
> impacts one file not a lot under bsps/shared. I do something like this:
>
> bsps/shared/.../disp_hcms29xx.c   Address unused return code warning
>
> Calls to rtems methods were putting the return status into a local variable
> and not testing it. This patch adds debug assert to check the value and
> annotation that it is deliberately ignored when not in debug.
>
> Coverity ID...
>
The CID is optional in commit message, but Joel likes to see it ;)

>>
>> Second, avoid making unnecessary changes in whitespace elsewhere in
>> source code. My guess is that your text editor did this for you
>> automatically. You may want to investigate how to disable it from
>> rewriting the entire file for formatting on open.
>
>
> Yes please. If the white space changes are needed because the file
> doesn't follow the RTEMS style, make a separate patch.
>
>>
>>
>> Third, if a return value is unused, there are two options to consider:
>> (a) it should be used, or (b) it should be ignored. Either way, we
>> would prefer to be explicit about the programmer intent. In this case,
>> does it make sense to check the return status of
>> rtems_semaphore_release? Can it fail? Would it matter if it does?
>>
>> To explicitly ignore a return value, you can do this instead:
>>
>> rc = rtems_semaphore_release(...)
>> (void) rc;
>>
>> As directed by our coding standards: "Use ‘(void) unused;’ to mark
>> unused parameters and set-but-unused variables immediately after being
>> set."
>
>
> RTEMS is old and some of the code pre-dates having a debug build. I would
> lean to something like this these days (as indicated in my comment above):
>
>   rc = rtems_semaphore_release(...)
>   RTEMS_DEBUG_ASSERT(rc == RTEMS_SUCCESSFUL);
>   (void) rc;
>
> It will be unused unless Debug is defined. And that might not be the
> right macro name.
>
> Similarly, I wouldn't mind seeing calls which do (void) rtems_...
> also do a debug assert. But that should be broadly discussed
> in the community. It is just a bad habit to ignore return values.
>
> It's funny how a VERY VERY simple change for an obvious warning
> can lead to what feel like out of proportion discussions. LOL
>
Yeah, there's a lot to unpack here. it almost might be worth having a macro..
#ifdef RTEMS_DEBUG
RTEMS_DEBUG_ASSERT_RV(err, cond) RTEMS_DEBUG_ASSERT(err == cond)
#else
RTEMS_DEBUG_ASSERT_RV(err, cond) (void) err;
#endif

Thinking out loud here.

> --joel
>
>>
>>
>>
>> On Thu, Feb 27, 2020 at 3:24 AM suyash singh  
>> wrote:
>> >
>> > ---
>> >  bsps/shared/dev/display/disp_hcms29xx.c | 8 
>> >  1 file changed, 4 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/bsps/shared/dev/display/disp_hcms29xx.c 
>> > b/bsps/shared/dev/display/disp_hcms29xx.c
>> > index 5730b36ea9..9d3e7220cf 100644
>> > --- a/bsps/shared/dev/display/disp_hcms29xx.c
>> > +++ b/bsps/shared/dev/display/disp_hcms29xx.c
>> > @@ -530,7 +530,7 @@ static rtems_task disp_hcms29xx_update_task
>> >  
>> > +---+
>> >  | Input Parameters:   
>> >   |
>> >  
>> > \*-*/
>> > -   rtems_task_argument argument
>> > +   rtems_task_argument argument
>> >  )
>> >  
>> > /*-*\
>> >  | Return Value:   
>> >   |
>> > @@ -597,7 +597,7 @@ static rtems_task disp_hcms29xx_update_task
>> >   (int) strlen(softc_ptr->disp_param.disp_buffer);
>> >}
>> >if (rc == RTEMS_SUCCESSFUL) {
>> > -   rc = rtems_semaphore_release(softc_ptr->disp_param.trns_sema_id);
>> > +rtems_semaphore_release(softc_ptr->disp_param.trns_sema_id);
>> >}
>> >/*
>> > * set initial offset to negative value
>> > @@ -911,7 +911,7 @@ static rtems_driver_address_table disp_hcms29xx_ops = {
>> >
>> >  static disp_hcms29xx_drv_t disp_hcms29xx_drv_tbl = {
>> >{/* public fields */
>> > -.ops = _hcms29xx_ops,
>> > +.ops = _hcms29xx_ops,
>> >  .size =sizeof (disp_hcms29xx_drv_t),
>> >},
>> >{ /* our private fields */
>> > @@ -927,6 +927,6 @@ static disp_hcms29xx_drv_t 

Re: Device Tree Blob for Beaglebone Black?

[Amar Takhar]

On 2020-02-27 20:06 +0100, Christian Mauderer wrote:

> > The only good way to handle this is to have it all in 1 giant repository we 
> > work 
> > with.  Every other solution is a pain no matter how well thought out it is. 
> >  I 
> > personally lean more on the service side of things that it should be *our* 
> > problem to maintain this and for users it should just work.>
> > The easiest way to handle this is to have the minimum version required in 
> > the 
> > commit message.  Eg, when pushing to libbsd have:
> > 
> >   Minimum RTEMS: 
> > 
> > After that it's up to the user to ensure to keep up-to-date.  The first 
> > thing 
> > most developers do is check the log.
> 
> Sounds like a nice suggestion. But it needs quite a lot of discipline
> for the developers. So most likely a lot of errors will happen. Beneath
> that it's not far from what we do now: Suggest to use commits from the
> same date.

There are two ways to look at it -- requiring discipline or simply doing 
something we should already be doing.  Because right now there is no way to 
tell 
other than updating to the latest and if you are trying to bisect an issue this 
because huge because you could feasibly jump into a comment that skips a 
version.  How would a user know which version of the library *or* RTEMS to use?


> But maybe we should move that discussion. It's not FDT related anymore
> so no one will find it in this toppic. And I think for Chris the
> pressing matter is FDT just now because it blocks the release.

Yes that's true.

> The BSP groups that use bsps/shared/start/bsp-fdt.c are:
> 
> - riscv/riscv
> - arm/imx
> - arm/beagle
> - arm/raspberrypi
> - arm/altera-cyclone-v
> - powerpc/qoriq
> 
> For beagle and raspberry it should be definitely the FreeBSD FDT.
> 
> For imx: I'm currently working on imx6 support in the imx BSP and that
> one will use a FreeBSD derived one too. Not sure about the original imx7
> support in that BSP.
> 
> For the other BSPs I don't have any idea which FDT has been used during
> development.


Okay that list is already compelling enough to have the split model of having 
source based files in-tree and binary outside.  I think it makes sense to have 
it 'just work' for opensource boards like the beagle and rpi even if that's the 
only two that require it.


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

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 27/02/2020 18:14, Amar Takhar wrote:
> On 2020-02-27 08:45 +0100, Christian Mauderer wrote:
>>
>> It's just another problem that I noted sometimes on the mailing list
>> with RTEMS and libbsd: Sometimes libbsd doesn't compile with some odd
>> error messages like unresolved symbols. Most of the time the problem is
>> that libbsd has been updated by the user but RTEMS hasn't. Having
>> defined versions in a master repository could help the average user to
>> see which version should be used together. On the other hand someone
>> would have to keep it up to date and I'm not sure whether all
>> maintainers would be happy about another necessary maintainance task.
>> Therefore it's not yet a well thought through idea.
> 
> The only good way to handle this is to have it all in 1 giant repository we 
> work 
> with.  Every other solution is a pain no matter how well thought out it is.  
> I 
> personally lean more on the service side of things that it should be *our* 
> problem to maintain this and for users it should just work.>
> The easiest way to handle this is to have the minimum version required in the 
> commit message.  Eg, when pushing to libbsd have:
> 
>   Minimum RTEMS: 
> 
> After that it's up to the user to ensure to keep up-to-date.  The first thing 
> most developers do is check the log.

Sounds like a nice suggestion. But it needs quite a lot of discipline
for the developers. So most likely a lot of errors will happen. Beneath
that it's not far from what we do now: Suggest to use commits from the
same date.

But maybe we should move that discussion. It's not FDT related anymore
so no one will find it in this toppic. And I think for Chris the
pressing matter is FDT just now because it blocks the release.



> 
> Regardless of what we choose none of it will work if the user is not updating 
> their repository or checking online for changes.  Having it in the commit 
> message also helps for build automation.  I've used git tags for this in the 
> past but hardly anyone uses or checks those which is too bad.
> >
>> If you are a new user and see "for this BSP use the FDT from X" but you
>> want to use some other BSP and someone tells you "for that BSP the FDT
>> isn't in X but at Y" it maybe isn't really that clear. Therefore - if we
>> introduce some handling - I would be in favor of only one location and
>> not a mix of two or three. Otherwise the situation is only slightly
>> better than now.
> 
> Having a section in the documentation to manage this is fine I think.  It's 
> either going to say:
> 
>   1. The FDT source is in rtems-fdt.git
>   2. The FDT source is already in RTEMS you don't need to do anything.
>   3. You need to purchase a board and place the files 
>   4. Covers all: If you want to roll your own place the files  -- same 
>  place as #3 maybe.
> 
> An easier way to make a decision would be to see what we're looking at right 
> now.  How many would be in-tree and how many external?
> 

The BSP groups that use bsps/shared/start/bsp-fdt.c are:

- riscv/riscv
- arm/imx
- arm/beagle
- arm/raspberrypi
- arm/altera-cyclone-v
- powerpc/qoriq

For beagle and raspberry it should be definitely the FreeBSD FDT.

For imx: I'm currently working on imx6 support in the imx BSP and that
one will use a FreeBSD derived one too. Not sure about the original imx7
support in that BSP.

For the other BSPs I don't have any idea which FDT has been used during
development.

Best regards

Christian

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

[PATCH] rtems/5 bsets: Update to newlib fbaa096

[Joel Sherrill]

This picks up fixes for at least the RTEMS reported issues for missing
extern C in devctl.h and the symlink issue with bsdtar.
---
 rtems/config/5/rtems-default.bset  |  2 +-
 rtems/config/5/rtems-epiphany.bset |  2 +-
 rtems/config/5/rtems-or1k.bset |  2 +-
 rtems/config/5/rtems-riscv.bset|  2 +-
 rtems/config/5/rtems-x86_64.bset   |  2 +-
 .../tools/rtems-gcc-7.5.0-newlib-fbaa096.cfg   | 42 ++
 .../tools/rtems-gcc-9.2.0-newlib-fbaa096.cfg   | 28 +++
 7 files changed, 75 insertions(+), 5 deletions(-)
 create mode 100644 rtems/config/tools/rtems-gcc-7.5.0-newlib-fbaa096.cfg
 create mode 100644 rtems/config/tools/rtems-gcc-9.2.0-newlib-fbaa096.cfg

diff --git a/rtems/config/5/rtems-default.bset 
b/rtems/config/5/rtems-default.bset
index 83512d6..0b67b9e 100644
--- a/rtems/config/5/rtems-default.bset
+++ b/rtems/config/5/rtems-default.bset
@@ -18,5 +18,5 @@ devel/expat-2.1.0-1
 tools/rtems-gdb-9.1-1
 
 tools/rtems-binutils-2.34
-tools/rtems-gcc-7.5.0-newlib-d14714c69
+tools/rtems-gcc-7.5.0-newlib-fbaa096
 tools/rtems-tools-5-1
diff --git a/rtems/config/5/rtems-epiphany.bset 
b/rtems/config/5/rtems-epiphany.bset
index 13351e4..58f81ef 100644
--- a/rtems/config/5/rtems-epiphany.bset
+++ b/rtems/config/5/rtems-epiphany.bset
@@ -34,6 +34,6 @@
 5/rtems-autotools
 devel/expat-2.1.0-1
 tools/rtems-binutils-2.34
-tools/rtems-gcc-7.5.0-newlib-d14714c69
+tools/rtems-gcc-7.5.0-newlib-fbaa096
 tools/rtems-gdb-7.8.1-1
 tools/rtems-tools-5-1
diff --git a/rtems/config/5/rtems-or1k.bset b/rtems/config/5/rtems-or1k.bset
index c68cfc9..d2f659d 100644
--- a/rtems/config/5/rtems-or1k.bset
+++ b/rtems/config/5/rtems-or1k.bset
@@ -11,5 +11,5 @@
 devel/expat-2.1.0-1
 tools/rtems-gdb-8.2.1-1
 tools/rtems-binutils-2.34
-tools/rtems-gcc-9.2.0-newlib-d14714c69
+tools/rtems-gcc-9.2.0-newlib-fbaa096
 tools/rtems-tools-5-1
diff --git a/rtems/config/5/rtems-riscv.bset b/rtems/config/5/rtems-riscv.bset
index a982411..6678a47 100644
--- a/rtems/config/5/rtems-riscv.bset
+++ b/rtems/config/5/rtems-riscv.bset
@@ -12,6 +12,6 @@
 devel/expat-2.1.0-1
 tools/rtems-gdb-8.3-1
 tools/rtems-binutils-2.34
-tools/rtems-gcc-9.2.0-newlib-d14714c69
+tools/rtems-gcc-9.2.0-newlib-fbaa096
 tools/rtems-tools-5-1
 devel/sis-2-1
diff --git a/rtems/config/5/rtems-x86_64.bset b/rtems/config/5/rtems-x86_64.bset
index e859ddf..7d13ce0 100644
--- a/rtems/config/5/rtems-x86_64.bset
+++ b/rtems/config/5/rtems-x86_64.bset
@@ -9,5 +9,5 @@
 devel/expat-2.1.0-1
 tools/rtems-gdb-8.2.1-1
 tools/rtems-binutils-2.34
-tools/rtems-gcc-9.2.0-newlib-d14714c69
+tools/rtems-gcc-9.2.0-newlib-fbaa096
 tools/rtems-tools-5-1
diff --git a/rtems/config/tools/rtems-gcc-7.5.0-newlib-fbaa096.cfg 
b/rtems/config/tools/rtems-gcc-7.5.0-newlib-fbaa096.cfg
new file mode 100644
index 000..62c93c3
--- /dev/null
+++ b/rtems/config/tools/rtems-gcc-7.5.0-newlib-fbaa096.cfg
@@ -0,0 +1,42 @@
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+#
+# FreeBSD specific fix for MIPS
+#
+%if %{_build_os} == freebsd || %{_build_os} == darwin
+ %patch add gcc --rsb-file=freebsd-libgcc-sed-fix.patch -p0 
https://gcc.gnu.org/bugzilla/attachment.cgi?id=41380
+ %hash  sha256 freebsd-libgcc-sed-fix.patch 
8a11bd619c2e55466688e328da00b387d02395c1e8ff4a99225152387a1e60a4
+%endif
+
+%if %{_build_os} == darwin
+ %patch add gcc -p1 
https://devel.rtems.org/raw-attachment/ticket/3171/darwin-libstdcpp-noparallel-fix.patch
+ %hash sha512 darwin-libstdcpp-noparallel-fix.patch 
01fa1bd55f19b01f10c41fdfe31356a7a4ddf265ebac8f4b974ccd1718181fd56bcb18a96e0492aa37511f08b37f94052a5557e21075604fceee06d80ffbb7d8
+%endif
+
+%define gcc_version 7.5.0
+%hash sha512 gcc-%{gcc_version}.tar.xz 
fe716cc19f2e3255d3a8b1b8290777bf769c6d98e6e0b07b81a3d6ad43f8af74cb170dfa18b1555dbfcd3f55ae582b91a286ccef496b9b65c1579902f96a1f60
+
+%define newlib_version fbaa096
+%define newlib_external 1
+%define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
+%source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
+%hash sha512 newlib-%{newlib_version}.tar.gz 
8553fcc33ceb10fddd5970d34c3e8de83e63231eea0550b4caee686109045291873843416736ecce7168d9b0386e65cea29eeb6743c816b11ff29ecc1bc05d32
+
+%define isl_version 0.16.1
+%hash sha512 isl-%{isl_version}.tar.bz2 
c188667a84dc5bdddb4ab7c35f89c91bf15a8171f4fcaf41301cf285fb7328846d9a367c096012fec4cc69d244f0bc9e95d84c09ec097394cd4093076f2a041b
+
+%define mpfr_version 3.1.4
+%hash sha512 mpfr-%{mpfr_version}.tar.bz2 
51066066ff2c12ed2198605ecf68846b0c96b548adafa5b80e0c786d0df488411a5e8973358fce7192dc977ad4e68414cf14500e3c39746de62465eb145bb819
+
+%define mpc_version 1.0.3
+%hash sha512 mpc-%{mpc_version}.tar.gz 
0028b76df130720c1fad7de937a0d041224806ce5ef76589f19c7b49d956071a683e2f20d154c192a231e69756b19e48208f2889b0c13950ceb7b3cfaf059a43
+
+%define 

Odd Microblaze Tool Build Failure

[Joel Sherrill]

Hi

The Microblaze uses the rtems-default.bset and is the only target that
isn't compiling.
It ends with this error which seems like something is off in a way that
should impact
all targets but doesn't. Any ideas?

FWIW I am proceeding with the update. Since we don't actually have a
Microblaze
port yet, this is far from a blocker.

=
$ make >/dev/null
../../../../../../../gcc-7.5.0/newlib/libc/sys/rtems/crt0.c:197:18: error:
conflicting types for '__assert_func'
 RTEMS_STUB(void, __assert_func(const char *file, int line, const char
*failedexpr), { })
  ^
../../../../../../../gcc-7.5.0/newlib/libc/sys/rtems/crt0.c:28:5: note: in
definition of macro 'RTEMS_STUB'
 ret func body
 ^~~~
In file included from
/data/home/joel/rtems-work/rtems-source-builder/rtems/build/microblaze-rtems5-gcc-7.5.0-newlib-fbaa096-x86_64-linux-gnu-1/gcc-7.5.0/newlib/libc/include/sys/reent.h:503:0,
 from
/data/home/joel/rtems-work/rtems-source-builder/rtems/build/microblaze-rtems5-gcc-7.5.0-newlib-fbaa096-x86_64-linux-gnu-1/gcc-7.5.0/newlib/libc/include/time.h:12,
 from
/data/home/joel/rtems-work/rtems-source-builder/rtems/build/microblaze-rtems5-gcc-7.5.0-newlib-fbaa096-x86_64-linux-gnu-1/gcc-7.5.0/newlib/libc/include/sys/stat.h:9,
 from
../../../../../../../gcc-7.5.0/newlib/libc/sys/rtems/crt0.c:14:
/data/home/joel/rtems-work/rtems-source-builder/rtems/build/microblaze-rtems5-gcc-7.5.0-newlib-fbaa096-x86_64-linux-gnu-1/gcc-7.5.0/newlib/libc/include/assert.h:41:6:
note: previous declaration of '__assert_func' was here
 void __assert_func (const char *, int, const char *, const char *)
  ^
make[9]: *** [crt0.o] Error 1
cp: cannot stat ‘rtems/crt0.o’: No such file or directory
make[9]: *** [crt0.o] Error 1
===
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Device Tree Blob for Beaglebone Black?

[Amar Takhar]

On 2020-02-27 08:45 +0100, Christian Mauderer wrote:
> 
> It's just another problem that I noted sometimes on the mailing list
> with RTEMS and libbsd: Sometimes libbsd doesn't compile with some odd
> error messages like unresolved symbols. Most of the time the problem is
> that libbsd has been updated by the user but RTEMS hasn't. Having
> defined versions in a master repository could help the average user to
> see which version should be used together. On the other hand someone
> would have to keep it up to date and I'm not sure whether all
> maintainers would be happy about another necessary maintainance task.
> Therefore it's not yet a well thought through idea.

The only good way to handle this is to have it all in 1 giant repository we 
work 
with.  Every other solution is a pain no matter how well thought out it is.  I 
personally lean more on the service side of things that it should be *our* 
problem to maintain this and for users it should just work.

The easiest way to handle this is to have the minimum version required in the 
commit message.  Eg, when pushing to libbsd have:

  Minimum RTEMS: 

After that it's up to the user to ensure to keep up-to-date.  The first thing 
most developers do is check the log.

Regardless of what we choose none of it will work if the user is not updating 
their repository or checking online for changes.  Having it in the commit 
message also helps for build automation.  I've used git tags for this in the 
past but hardly anyone uses or checks those which is too bad.


> If you are a new user and see "for this BSP use the FDT from X" but you
> want to use some other BSP and someone tells you "for that BSP the FDT
> isn't in X but at Y" it maybe isn't really that clear. Therefore - if we
> introduce some handling - I would be in favor of only one location and
> not a mix of two or three. Otherwise the situation is only slightly
> better than now.

Having a section in the documentation to manage this is fine I think.  It's 
either going to say:

  1. The FDT source is in rtems-fdt.git
  2. The FDT source is already in RTEMS you don't need to do anything.
  3. You need to purchase a board and place the files 
  4. Covers all: If you want to roll your own place the files  -- same 
 place as #3 maybe.

An easier way to make a decision would be to see what we're looking at right 
now.  How many would be in-tree and how many external?


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

Re: [PATCH] removed unneccesary assigning to rc triggering unused value error in coverity

[Joel Sherrill]

On Thu, Feb 27, 2020 at 9:48 AM Gedare Bloom  wrote:

> Hi Suyash,
>
> I have a  few comments for you.
>
> First, the commit message should follow the guidance at
> https://docs.rtems.org/branches/master/eng/vc-users.html#creating-a-patch
> and follow through the link about Commit Messages. We like to have a
> short "tag" at the start of the commit to indicate the area of RTEMS
> the commit applies to, in this case, maybe "bsps/shared: ignore return
> value in display driver"  -- We don't currently have a set of standard
> tags.
>

The tag before the colon should be as specific as possible. This only
impacts one file not a lot under bsps/shared. I do something like this:

bsps/shared/.../disp_hcms29xx.c   Address unused return code warning

Calls to rtems methods were putting the return status into a local variable
and not testing it. This patch adds debug assert to check the value and
annotation that it is deliberately ignored when not in debug.

Coverity ID...


> Second, avoid making unnecessary changes in whitespace elsewhere in
> source code. My guess is that your text editor did this for you
> automatically. You may want to investigate how to disable it from
> rewriting the entire file for formatting on open.
>

Yes please. If the white space changes are needed because the file
doesn't follow the RTEMS style, make a separate patch.


>
> Third, if a return value is unused, there are two options to consider:
> (a) it should be used, or (b) it should be ignored. Either way, we
> would prefer to be explicit about the programmer intent. In this case,
> does it make sense to check the return status of
> rtems_semaphore_release? Can it fail? Would it matter if it does?
>
> To explicitly ignore a return value, you can do this instead:
>
> rc = rtems_semaphore_release(...)
> (void) rc;
>
> As directed by our coding standards: "Use ‘(void) unused;’ to mark
> unused parameters and set-but-unused variables immediately after being
> set."
>

RTEMS is old and some of the code pre-dates having a debug build. I would
lean to something like this these days (as indicated in my comment above):

  rc = rtems_semaphore_release(...)
  RTEMS_DEBUG_ASSERT(rc == RTEMS_SUCCESSFUL);
  (void) rc;

It will be unused unless Debug is defined. And that might not be the
right macro name.

Similarly, I wouldn't mind seeing calls which do (void) rtems_...
also do a debug assert. But that should be broadly discussed
in the community. It is just a bad habit to ignore return values.

It's funny how a VERY VERY simple change for an obvious warning
can lead to what feel like out of proportion discussions. LOL

--joel


>
>
> On Thu, Feb 27, 2020 at 3:24 AM suyash singh 
> wrote:
> >
> > ---
> >  bsps/shared/dev/display/disp_hcms29xx.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/bsps/shared/dev/display/disp_hcms29xx.c
> b/bsps/shared/dev/display/disp_hcms29xx.c
> > index 5730b36ea9..9d3e7220cf 100644
> > --- a/bsps/shared/dev/display/disp_hcms29xx.c
> > +++ b/bsps/shared/dev/display/disp_hcms29xx.c
> > @@ -530,7 +530,7 @@ static rtems_task disp_hcms29xx_update_task
> >
> +---+
> >  | Input Parameters:
>  |
> >
> \*-*/
> > -   rtems_task_argument argument
> > +   rtems_task_argument argument
> >  )
> >
> /*-*\
> >  | Return Value:
>  |
> > @@ -597,7 +597,7 @@ static rtems_task disp_hcms29xx_update_task
> >   (int) strlen(softc_ptr->disp_param.disp_buffer);
> >}
> >if (rc == RTEMS_SUCCESSFUL) {
> > -   rc = rtems_semaphore_release(softc_ptr->disp_param.trns_sema_id);
> > +rtems_semaphore_release(softc_ptr->disp_param.trns_sema_id);
> >}
> >/*
> > * set initial offset to negative value
> > @@ -911,7 +911,7 @@ static rtems_driver_address_table disp_hcms29xx_ops
> = {
> >
> >  static disp_hcms29xx_drv_t disp_hcms29xx_drv_tbl = {
> >{/* public fields */
> > -.ops = _hcms29xx_ops,
> > +.ops = _hcms29xx_ops,
> >  .size =sizeof (disp_hcms29xx_drv_t),
> >},
> >{ /* our private fields */
> > @@ -927,6 +927,6 @@ static disp_hcms29xx_drv_t disp_hcms29xx_drv_tbl = {
> >}
> >  };
> >
> > -rtems_libi2c_drv_t *disp_hcms29xx_driver_descriptor =
> > +rtems_libi2c_drv_t *disp_hcms29xx_driver_descriptor =
> >_hcms29xx_drv_tbl.libi2c_drv_entry;
> >
> > --
> > 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] removed unneccesary assigning to rc triggering unused value error in coverity

[suyash singh]

Okay sorry I missed out on the coding standards docs.
yes code blocks edited without telling I will change its settings



On Thu, Feb 27, 2020 at 9:18 PM Gedare Bloom  wrote:

> Hi Suyash,
>
> I have a  few comments for you.
>
> First, the commit message should follow the guidance at
> https://docs.rtems.org/branches/master/eng/vc-users.html#creating-a-patch
> and follow through the link about Commit Messages. We like to have a
> short "tag" at the start of the commit to indicate the area of RTEMS
> the commit applies to, in this case, maybe "bsps/shared: ignore return
> value in display driver"  -- We don't currently have a set of standard
> tags.
>
> Second, avoid making unnecessary changes in whitespace elsewhere in
> source code. My guess is that your text editor did this for you
> automatically. You may want to investigate how to disable it from
> rewriting the entire file for formatting on open.
>
> Third, if a return value is unused, there are two options to consider:
> (a) it should be used, or (b) it should be ignored. Either way, we
> would prefer to be explicit about the programmer intent. In this case,
> does it make sense to check the return status of
> rtems_semaphore_release? Can it fail? Would it matter if it does?
>
> To explicitly ignore a return value, you can do this instead:
>
> rc = rtems_semaphore_release(...)
> (void) rc;
>
> As directed by our coding standards: "Use ‘(void) unused;’ to mark
> unused parameters and set-but-unused variables immediately after being
> set."
>
>
> On Thu, Feb 27, 2020 at 3:24 AM suyash singh 
> wrote:
> >
> > ---
> >  bsps/shared/dev/display/disp_hcms29xx.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/bsps/shared/dev/display/disp_hcms29xx.c
> b/bsps/shared/dev/display/disp_hcms29xx.c
> > index 5730b36ea9..9d3e7220cf 100644
> > --- a/bsps/shared/dev/display/disp_hcms29xx.c
> > +++ b/bsps/shared/dev/display/disp_hcms29xx.c
> > @@ -530,7 +530,7 @@ static rtems_task disp_hcms29xx_update_task
> >
> +---+
> >  | Input Parameters:
>  |
> >
> \*-*/
> > -   rtems_task_argument argument
> > +   rtems_task_argument argument
> >  )
> >
> /*-*\
> >  | Return Value:
>  |
> > @@ -597,7 +597,7 @@ static rtems_task disp_hcms29xx_update_task
> >   (int) strlen(softc_ptr->disp_param.disp_buffer);
> >}
> >if (rc == RTEMS_SUCCESSFUL) {
> > -   rc = rtems_semaphore_release(softc_ptr->disp_param.trns_sema_id);
> > +rtems_semaphore_release(softc_ptr->disp_param.trns_sema_id);
> >}
> >/*
> > * set initial offset to negative value
> > @@ -911,7 +911,7 @@ static rtems_driver_address_table disp_hcms29xx_ops
> = {
> >
> >  static disp_hcms29xx_drv_t disp_hcms29xx_drv_tbl = {
> >{/* public fields */
> > -.ops = _hcms29xx_ops,
> > +.ops = _hcms29xx_ops,
> >  .size =sizeof (disp_hcms29xx_drv_t),
> >},
> >{ /* our private fields */
> > @@ -927,6 +927,6 @@ static disp_hcms29xx_drv_t disp_hcms29xx_drv_tbl = {
> >}
> >  };
> >
> > -rtems_libi2c_drv_t *disp_hcms29xx_driver_descriptor =
> > +rtems_libi2c_drv_t *disp_hcms29xx_driver_descriptor =
> >_hcms29xx_drv_tbl.libi2c_drv_entry;
> >
> > --
> > 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] removed unneccesary assigning to rc triggering unused value error in coverity

[Gedare Bloom]

Hi Suyash,

I have a  few comments for you.

First, the commit message should follow the guidance at
https://docs.rtems.org/branches/master/eng/vc-users.html#creating-a-patch
and follow through the link about Commit Messages. We like to have a
short "tag" at the start of the commit to indicate the area of RTEMS
the commit applies to, in this case, maybe "bsps/shared: ignore return
value in display driver"  -- We don't currently have a set of standard
tags.

Second, avoid making unnecessary changes in whitespace elsewhere in
source code. My guess is that your text editor did this for you
automatically. You may want to investigate how to disable it from
rewriting the entire file for formatting on open.

Third, if a return value is unused, there are two options to consider:
(a) it should be used, or (b) it should be ignored. Either way, we
would prefer to be explicit about the programmer intent. In this case,
does it make sense to check the return status of
rtems_semaphore_release? Can it fail? Would it matter if it does?

To explicitly ignore a return value, you can do this instead:

rc = rtems_semaphore_release(...)
(void) rc;

As directed by our coding standards: "Use ‘(void) unused;’ to mark
unused parameters and set-but-unused variables immediately after being
set."


On Thu, Feb 27, 2020 at 3:24 AM suyash singh  wrote:
>
> ---
>  bsps/shared/dev/display/disp_hcms29xx.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/bsps/shared/dev/display/disp_hcms29xx.c 
> b/bsps/shared/dev/display/disp_hcms29xx.c
> index 5730b36ea9..9d3e7220cf 100644
> --- a/bsps/shared/dev/display/disp_hcms29xx.c
> +++ b/bsps/shared/dev/display/disp_hcms29xx.c
> @@ -530,7 +530,7 @@ static rtems_task disp_hcms29xx_update_task
>  +---+
>  | Input Parameters: |
>  \*-*/
> -   rtems_task_argument argument
> +   rtems_task_argument argument
>  )
>  /*-*\
>  | Return Value: |
> @@ -597,7 +597,7 @@ static rtems_task disp_hcms29xx_update_task
>   (int) strlen(softc_ptr->disp_param.disp_buffer);
>}
>if (rc == RTEMS_SUCCESSFUL) {
> -   rc = rtems_semaphore_release(softc_ptr->disp_param.trns_sema_id);
> +rtems_semaphore_release(softc_ptr->disp_param.trns_sema_id);
>}
>/*
> * set initial offset to negative value
> @@ -911,7 +911,7 @@ static rtems_driver_address_table disp_hcms29xx_ops = {
>
>  static disp_hcms29xx_drv_t disp_hcms29xx_drv_tbl = {
>{/* public fields */
> -.ops = _hcms29xx_ops,
> +.ops = _hcms29xx_ops,
>  .size =sizeof (disp_hcms29xx_drv_t),
>},
>{ /* our private fields */
> @@ -927,6 +927,6 @@ static disp_hcms29xx_drv_t disp_hcms29xx_drv_tbl = {
>}
>  };
>
> -rtems_libi2c_drv_t *disp_hcms29xx_driver_descriptor =
> +rtems_libi2c_drv_t *disp_hcms29xx_driver_descriptor =
>_hcms29xx_drv_tbl.libi2c_drv_entry;
>
> --
> 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: Build Linux: PASSED 5/rtems-arm on x86_64-linux-gnu

[Gedare Bloom]

On Wed, Feb 26, 2020 at 11:56 PM Sebastian Huber
 wrote:
>
> On 27/02/2020 07:38, Chris Johns wrote:
> > On 27/2/20 5:25 pm, Sebastian Huber wrote:
> >> On 26/02/2020 23:15, Chris Johns wrote:
> >>> On 27/2/20 12:26 am, Sebastian Huber wrote:
>  On 26/02/2020 14:21,sebastian.hu...@embedded-brains.de   wrote:
> > RTEMS Source Builder Repository Status
> > Remotes:
> >   1: 
> > origin:ssh://s...@dispatch.rtems.org/data/git/rtems-source-builder.git
> >   2:
> > main:g...@main.eb.localhost:eb/101-embedded-brains/oss/rtems-source-builder.git
> >   
> > 3:esa:g...@gitrepos.estec.esa.int:external/rtems-smp-qualification-rsb.git
>  Why are the remote repositories reported?
> >>> It provides the git environment being used. The report needs a repo and I 
> >>> am not
> >>> sure you can tell which is the source of branch programmatically.
> >>>
>  I think we should remove this private and user-dependent information.
> >>> I have a specific repo I use for these types of publicly posted build ...
> >>>
> >>> RTEMS Source Builder Repository Status
> >>>Remotes:
> >>>  1: origin: git://git.rtems.org/rtems-source-builder.git
> >>>Status:
> >>> Clean
> >>>Head:
> >>> Commit: 14c5cb77132a3e66afab571afbf67dacad433ec3
> >> The Status and Head are very important information. Which remote 
> >> repositories
> >> you use should be none of the business of the RTEMS Project. It can leak
> >> business relationships and project names. We should not do this without 
> >> asking
> >> the user. I suggest to remove this part of the report.
> > I think the repo used is important information especially if someone is 
> > wanting
> > to replicate post results.
>
> To replicate results all you need is the commit hash and the original
> report must show a clean status. If the commit hash is not included in
> the RTEMS repositories you can ask the reporter.
>
> I think if a user requests to send a report and the status is not clean,
> then the RSB should stop with an error.
>
I agree with Sebastian. We should remove the "Remotes:" part.

> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: ticket #2970 Add ftw.h to newlib

[Joel Sherrill]

On Thu, Feb 27, 2020 at 5:49 AM Eshan Dhawan 
wrote:

> Also, Should look into ticket #3642 related to adding function prototypes
> to wchar.h
>

Make sure what's left to do is always the first step. :)

And make sure you are making progress on a proposal.


>
> On Thu, Feb 27, 2020 at 5:11 PM Eshan Dhawan 
> wrote:
>
>>
>>
>> On Wed, Feb 26, 2020 at 8:50 PM Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Wed, Feb 26, 2020 at 9:06 AM Eshan Dhawan 
>>> wrote:
>>>
 so the subtasks would consist of adding missing functions to stat.h ,
 types.h mainly I suppose

>>>
>>> What do you think is missing in those? My reading of the POSIX standard
>>> has is implying that
>>>  includes  to get st_mode and the stat structure.
>>>
>> Not much related to ftw.h but there are unsupported functions in
>> sys/stat.h which can be added
>> to Newlib
>>
>
What does your analysis show is missing? The POSIX Compliance document
should be right
but it is always good to know.

For analysis purposes, I would build arm with the xilinx zynq qemu BSP.
Then add on rtems-libbsd.
The methods can appear in newlib, RTEMS base, or rtems-libbsd. Most likely
if it isn't networking
related, it will be in the first two.

But my tracking spreadsheet indicates mknod() is there with networking
which I think sounds odd.

Anyway, the Compliance Guide is a good first cut but may have mistakes.
Start with good information.

>
>> Also wanted to know which headers which aren't present in newlib or RTEMS
>> which could make my GSOC proposal more acceptable?
>>
>>>
>>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ftw.h.html
>>>
>>> The subtasks I referred to as the same for every time a new C Library or
>>> POSIX method
>>> is added to RTEMS or Newlib:
>>>
>>> + the code itself
>>> + test code
>>> + addition to documentation as needed
>>> + update to compliance tracking spreadsheet (usually I will do this)
>>>

 - Eshan

 On Wed, Feb 26, 2020 at 7:30 PM Joel Sherrill  wrote:

>
>
> On Wed, Feb 26, 2020 at 7:03 AM Eshan Dhawan 
> wrote:
>
>> I wanted to know the status of implementation of ftw.h in newlib
>> and the dependencies it requires?
>>
>
> FIrst hint is that the ticket is still open. :)
>
> The next is a way to check if it is part of the installed C Library.
> Wherever
> you installed the tools (TOOLS_PREFIX) for CPU-rtems5
>
> find TOOLS_PREFIX -name ftw.h
> CPU-rtems5-nm TOOLS_PREFIX/CPU-rtems5/lib/libc.a | grep ftw
>
> In this case, you will see it isn't there.
>
>
>>
>> As it could be ported from FreeBSD since it lies under favourable
>> licence
>>
>
> Yep. And this would almost certainly need to be merged into the newlib
> C library
> with tests added to RTEMS.
>
> Documentation added to the POSIX Users Guide and the tracking
> spreadsheet
> updated.
>
> Just to list all the subtasks. :)
>
> --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

[PATCH 0/1] Add generated glossary

[Sebastian Huber]

This patch demonstrates the automatic generation of the general glossary and the
new glossary for the RTEMS Software Engineering manual. In a private repository
I have specification items for groups of glossary terms (e.g. the general
glossary) and glossary terms. I also have a prototype for a generator script
which reads the specification items and the Sphinx format sources.  The script
outputs the glossary.rst files.

The licence and copyright information is aggregated from the individual
specification items, e.g.

SPDX-License-Identifier: CC-BY-SA-4.0
active: true
copyrights:
- Copyright (C) 1988, 1998 On-Line Applications Research Corporation 
(OAR)
derived: false
enabled-by: []
glossary-term: TCB
glossary-type: term
header: ''
level: 1.172
links:
- RTEMS-GLOS-GENERAL: y-DGLwoqVNRBlzUau_mx_yR3iKlhE02h2mRxK7VkLQE=
normative: true
ref: ''
reviewed: KJcc81zY_4KUf8oXIu-oJZ5DRMiFc9DoDsmhl9PZxac=
text: |
  An acronym for @term{RTEMS-GLOS-TERM-TASKCONTROLBLOCK}.
type: glossary

The specification text can use macros to reference other specification items,
e.g. @term{RTEMS-GLOS-TERM-TASKCONTROLBLOCK} in the example above.

A contribution of the scripts and the specification items to the RTEMS Project
is currently blocked due to several undecided things related to the RTEMS
Qualification Project:

https://lists.rtems.org/pipermail/devel/2020-February/057246.html

Sebastian Huber (1):
  eng: Add glossary

 c-user/glossary.rst | 51 +++-
 eng/glossary.rst| 61 +
 eng/index.rst   |  1 +
 3 files changed, 112 insertions(+), 1 deletion(-)
 create mode 100644 eng/glossary.rst

-- 
2.16.4

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

[PATCH 1/1] eng: Add glossary

[Sebastian Huber]

Update #3853.
---
 c-user/glossary.rst | 51 +++-
 eng/glossary.rst| 61 +
 eng/index.rst   |  1 +
 3 files changed, 112 insertions(+), 1 deletion(-)
 create mode 100644 eng/glossary.rst

diff --git a/c-user/glossary.rst b/c-user/glossary.rst
index c9a1dfb..d0996e8 100644
--- a/c-user/glossary.rst
+++ b/c-user/glossary.rst
@@ -1,6 +1,6 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
-.. Copyright (C) 2017 embedded brains GmbH (http://www.embedded-brains.de)
+.. Copyright (C) 2017, 2019 embedded brains GmbH 
(http://www.embedded-brains.de)
 .. Copyright (C) 1988, 1998 On-Line Applications Research Corporation (OAR)
 
 Glossary
@@ -9,6 +9,9 @@ Glossary
 .. glossary::
 :sorted:
 
+ABI
+An acronym for Application Binary Interface.
+
 active
 A term used to describe an object which has been created by an
 application.
@@ -85,6 +88,9 @@ Glossary
 the passing of arguments, the call and return mechanism, and the 
register
 set which must be preserved.
 
+CCB
+An acronym for Change Control Board.
+
 Central Processing Unit
 This term is equivalent to the terms processor and microprocessor.
 
@@ -157,6 +163,10 @@ Glossary
 The act of loading a task's context onto the CPU and transferring 
control
 of the CPU to that task.
 
+Doorstop
+`Doorstop `_ is a
+requirements management tool.
+
 dormant
 The state entered by a task after it is created and before it has been
 started.
@@ -165,6 +175,9 @@ Glossary
 A term used to describe memory which can be accessed at two different
 addresses.
 
+EARS
+An acronym for Easy Approach to Requirements Syntax.
+
 embedded
 An application that is delivered as a hidden part of a larger system.
 For example, the software in a fuel-injection control system is an
@@ -222,10 +235,20 @@ Glossary
 freed
 A resource that has been released by the application to RTEMS.
 
+GCC
+An acronym for `GNU Compiler Collection `_.
+
 global
 An object that has been created with the GLOBAL attribute and exported 
to
 all nodes in a multiprocessor system.
 
+GNAT
+*GNAT* is the :term:`GNU` compiler for Ada, integrated into the
+:term:`GCC`.
+
+GNU
+An acronym for `GNU's Not Unix `_.
+
 handler
 The equivalent of a manager, except that it is internal to RTEMS and
 forms part of the core.  A handler is a collection of routines which
@@ -287,6 +310,9 @@ Glossary
 ISR
 An acronym for :term:`Interrupt Service Routine`.
 
+ISVV
+An acronym for Independent Software Verification and Validation.
+
 kernel
 In this document, this term is used as a synonym for executive.
 
@@ -548,6 +574,10 @@ Glossary
 The manipulation of an object which does not reside on the same node as
 the calling task.
 
+ReqIF
+An acronym for
+`Requirements Interchange Format 
`_.
+
 resource
 A hardware or software entity to which access must be controlled.
 
@@ -573,6 +603,9 @@ Glossary
 RS-232
 A standard for serial communications.
 
+RTEMS
+An acronym for Real-Time Executive for Multiprocessor Systems.
+
 running
 The state of a rate monotonic timer while it is being used to 
delineate a
 period.  The timer exits this state by either expiring or being 
canceled.
@@ -650,6 +683,19 @@ Glossary
 A real-time system in which a missed deadline does not compromise the
 integrity of the system.
 
+software item
+This term has the same meaning as :term:`software product`.
+
+software product
+The *software product* is the :term:`RTEMS` real-time operating system.
+
+source code
+This project uses the *source code* definition of the
+`Linux Information Project `_:
+"Source code (also referred to as source or code) is the version of
+software as it is originally written (i.e., typed into a computer) by a
+human in plain text (i.e., human readable alphanumeric characters)."
+
 sporadic task
 A task which executes at irregular intervals and must comply with a 
hard
 deadline.  A minimum period of time between successive iterations of 
the
@@ -787,5 +833,8 @@ Glossary
 Message queues, regions, and semaphores have a wait queue associated 
with
 them.
 
+YAML
+An acronym for `YAML Ain't Markup Language `_.
+
 yield
 When a task voluntarily releases control of the processor.
diff --git a/eng/glossary.rst b/eng/glossary.rst
new file 

[PATCH 2/5] c-user: Clarify return code related terms

[Sebastian Huber]

Remove duplicate "return code" definition.  Add all related terms and
use references.

Update #3853.
---
 c-user/glossary.rst | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/c-user/glossary.rst b/c-user/glossary.rst
index 67dce76..9a88b5e 100644
--- a/c-user/glossary.rst
+++ b/c-user/glossary.rst
@@ -177,6 +177,9 @@ Glossary
 The address at which a function or task begins to execute.  In C, the
 entry point of a function is the function's name.
 
+error code
+This term has the same meaning as :term:`status code`.
+
 events
 A method for task communication and synchronization. The directives
 provided by the event manager are used to service events.
@@ -540,9 +543,6 @@ Glossary
 The manipulation of an object which does not reside on the same node as
 the calling task.
 
-return code
-Also known as error code or return value.
-
 resource
 A hardware or software entity to which access must be controlled.
 
@@ -552,8 +552,11 @@ Glossary
 available for scheduling.
 
 return code
-A value returned by RTEMS directives to indicate the completion status 
of
-the directive.
+This term has the same meaning as :term:`status code`.
+
+return value
+The value returned by a function.  A return value may be a
+:term:`status code`.
 
 RNCB
 An acronym for :term:`Region Control Block`.
@@ -653,7 +656,10 @@ Glossary
 store return information and local variables.
 
 status code
-Also known as error code or return value.
+A status code indicates the completion status of an operation.  For
+example most RTEMS directives return a status code through the
+:term:`return value` to indicate a successful operation or error
+conditions.
 
 suspend
 A term used to describe a task that is not competing for the CPU 
because it
-- 
2.16.4

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

[PATCH 1/5] c-user: Use four spaces per indent level

[Sebastian Huber]

Four spaces per indent level is used in most files.

Update #3853.
---
 c-user/glossary.rst | 1284 +--
 1 file changed, 642 insertions(+), 642 deletions(-)

diff --git a/c-user/glossary.rst b/c-user/glossary.rst
index a230d6c..67dce76 100644
--- a/c-user/glossary.rst
+++ b/c-user/glossary.rst
@@ -4,777 +4,777 @@ Glossary
 
 
 .. glossary::
-   :sorted:
+:sorted:
 
-   active
-  A term used to describe an object which has been created by an
-  application.
+active
+A term used to describe an object which has been created by an
+application.
 
-   aperiodic task
-  A task which must execute only at irregular intervals and has only a soft
-  deadline.
+aperiodic task
+A task which must execute only at irregular intervals and has only a 
soft
+deadline.
 
-   API
-  An acronym for Application Programming Interface.
+API
+An acronym for Application Programming Interface.
 
-   application
-  In this document, software which makes use of RTEMS.
+application
+In this document, software which makes use of RTEMS.
 
-   ASR
-  An acronym for :term:`Asynchronous Signal Routine`.
+ASR
+An acronym for :term:`Asynchronous Signal Routine`.
 
-   asynchronous
-  Not related in order or timing to other occurrences in the system.
+asynchronous
+Not related in order or timing to other occurrences in the system.
 
-   Asynchronous Signal Routine
-  Similar to a hardware interrupt except that it is associated with a task
-  and is run in the context of a task.  The directives provided by the
-  signal manager are used to service signals.
+Asynchronous Signal Routine
+Similar to a hardware interrupt except that it is associated with a 
task
+and is run in the context of a task.  The directives provided by the
+signal manager are used to service signals.
 
-   atomic operations
-  Atomic operations are defined in terms of :term:`C11`.
+atomic operations
+Atomic operations are defined in terms of :term:`C11`.
 
-   awakened
-  A term used to describe a task that has been unblocked and may be
-  scheduled to the CPU.
+awakened
+A term used to describe a task that has been unblocked and may be
+scheduled to the CPU.
 
-   big endian
-  A data representation scheme in which the bytes composing a numeric value
-  are arranged such that the most significant byte is at the lowest
-  address.
+big endian
+A data representation scheme in which the bytes composing a numeric 
value
+are arranged such that the most significant byte is at the lowest
+address.
 
-   bit-mapped
-  A data encoding scheme in which each bit in a variable is used to
-  represent something different.  This makes for compact data
-  representation.
+bit-mapped
+A data encoding scheme in which each bit in a variable is used to
+represent something different.  This makes for compact data
+representation.
 
-   block
-  A physically contiguous area of memory.
+block
+A physically contiguous area of memory.
 
-   blocked task
-  The task state entered by a task which has been previously started and
-  cannot continue execution until the reason for waiting has been
-  satisfied.  Blocked tasks are not an element of the set of ready tasks of
-  a scheduler instance.
+blocked task
+The task state entered by a task which has been previously started and
+cannot continue execution until the reason for waiting has been
+satisfied.  Blocked tasks are not an element of the set of ready tasks 
of
+a scheduler instance.
 
-   broadcast
-  To simultaneously send a message to a logical set of destinations.
+broadcast
+To simultaneously send a message to a logical set of destinations.
 
-   Board Support Package
-  A collection of device initialization and control routines specific to a
-  particular type of board or collection of boards.
+Board Support Package
+A collection of device initialization and control routines specific to 
a
+particular type of board or collection of boards.
 
-   buffer
-  A fixed length block of memory allocated from a partition.
+buffer
+A fixed length block of memory allocated from a partition.
 
-   BSP
-  An acronym for :term:`Board Support Package`.
+BSP
+An acronym for :term:`Board Support Package`.
 
-   C11
-  The standard ISO/IEC 9899:2011.
+C11
+The standard ISO/IEC 9899:2011.
 
-   C++11
-  The standard ISO/IEC 14882:2011.
+C++11
+The standard ISO/IEC 14882:2011.
 
-   calling convention
-  The processor and compiler dependent rules which define the mechanism
-  used to invoke subroutines in a high-level language.  These 

[PATCH 5/5] c-user: Add copyrights to glossary

[Sebastian Huber]

Use the file history to derive the copyright information.

Update #3853.
---
 c-user/glossary.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/c-user/glossary.rst b/c-user/glossary.rst
index 9b9c3c0..c9a1dfb 100644
--- a/c-user/glossary.rst
+++ b/c-user/glossary.rst
@@ -1,5 +1,8 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
+.. Copyright (C) 2017 embedded brains GmbH (http://www.embedded-brains.de)
+.. Copyright (C) 1988, 1998 On-Line Applications Research Corporation (OAR)
+
 Glossary
 
 
-- 
2.16.4

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

[PATCH 0/5] Rework glossary of terms

[Sebastian Huber]

This patch set reworks the glossary of terms so that it can be automatically
generated from specification items.

Sebastian Huber (5):
  c-user: Use four spaces per indent level
  c-user: Clarify return code related terms
  c-user: Sort glossary terms
  c-user: Merge parition term definitions
  c-user: Add copyrights to glossary

 c-user/glossary.rst | 1295 ++-
 1 file changed, 653 insertions(+), 642 deletions(-)

-- 
2.16.4

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

[PATCH 4/5] c-user: Merge parition term definitions

[Sebastian Huber]

Update #3853.
---
 c-user/glossary.rst | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/c-user/glossary.rst b/c-user/glossary.rst
index 3f53634..9b9c3c0 100644
--- a/c-user/glossary.rst
+++ b/c-user/glossary.rst
@@ -419,11 +419,13 @@ Glossary
 multiprocessor system.  A packet is the contents of an envelope.
 
 partition
-An RTEMS object which is used to allocate and deallocate fixed size
-blocks of memory from an dynamically specified area of memory.
+This term has two definitions:
 
-partition
-Clusters with a cardinality of one are partitions.
+1. A partition is an RTEMS object which is used to allocate and
+   deallocate fixed size blocks of memory from an dynamically specified
+   area of memory.
+
+2. A :term:`cluster` with a cardinality of one is a partition.
 
 Partition Control Block
 A data structure associated with each partition used by RTEMS to manage
-- 
2.16.4

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

[PATCH 3/5] c-user: Sort glossary terms

[Sebastian Huber]

Update #3853.
---
 c-user/glossary.rst | 66 ++---
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/c-user/glossary.rst b/c-user/glossary.rst
index 9a88b5e..3f53634 100644
--- a/c-user/glossary.rst
+++ b/c-user/glossary.rst
@@ -57,25 +57,25 @@ Glossary
 satisfied.  Blocked tasks are not an element of the set of ready tasks 
of
 a scheduler instance.
 
-broadcast
-To simultaneously send a message to a logical set of destinations.
-
 Board Support Package
 A collection of device initialization and control routines specific to 
a
 particular type of board or collection of boards.
 
-buffer
-A fixed length block of memory allocated from a partition.
+broadcast
+To simultaneously send a message to a logical set of destinations.
 
 BSP
 An acronym for :term:`Board Support Package`.
 
-C11
-The standard ISO/IEC 9899:2011.
+buffer
+A fixed length block of memory allocated from a partition.
 
 C++11
 The standard ISO/IEC 14882:2011.
 
+C11
+The standard ISO/IEC 9899:2011.
+
 calling convention
 The processor and compiler dependent rules which define the mechanism
 used to invoke subroutines in a high-level language.  These rules 
define
@@ -142,6 +142,10 @@ Glossary
 device driver
 Control software for special peripheral devices used by the 
application.
 
+Device Driver Table
+A table which contains the entry points for each of the configured 
device
+drivers.
+
 directives
 RTEMS' provided routines that provide support mechanisms for real-time
 applications.
@@ -154,10 +158,6 @@ Glossary
 The state entered by a task after it is created and before it has been
 started.
 
-Device Driver Table
-A table which contains the entry points for each of the configured 
device
-drivers.
-
 dual-ported
 A term used to describe memory which can be accessed at two different
 addresses.
@@ -167,16 +167,16 @@ Glossary
 For example, the software in a fuel-injection control system is an
 embedded application found in many late-model automobiles.
 
+entry point
+The address at which a function or task begins to execute.  In C, the
+entry point of a function is the function's name.
+
 envelope
 A buffer provided by the MPCI layer to RTEMS which is used to pass
 messages between nodes in a multiprocessor system.  It typically 
contains
 routing information needed by the MPCI.  The contents of an envelope 
are
 referred to as a packet.
 
-entry point
-The address at which a function or task begins to execute.  In C, the
-entry point of a function is the function's name.
-
 error code
 This term has the same meaning as :term:`status code`.
 
@@ -251,6 +251,9 @@ Glossary
 homogeneous
 A multiprocessor computer system composed of a single type of 
processor.
 
+I/O
+An acronym for Input/Output.
+
 ID
 An RTEMS assigned identification tag used to access an active object.
 
@@ -278,9 +281,6 @@ Glossary
 Interrupt Service Routine
 An ISR is invoked by the CPU to process a pending interrupt.
 
-I/O
-An acronym for Input/Output.
-
 ISR
 An acronym for :term:`Interrupt Service Routine`.
 
@@ -499,15 +499,15 @@ Glossary
 PXCB
 An acronym for :term:`Proxy Control Block`.
 
+QCB
+An acronym for :term:`Message Queue Control Block`.
+
 quantum
 The application defined unit of time in which the processor is 
allocated.
 
 queue
 Alternate term for message queue.
 
-QCB
-An acronym for :term:`Message Queue Control Block`.
-
 ready task
 A task occupies this state when it is available to be given control of 
a
 processor.  A ready task has no processor assigned.  The scheduler
@@ -629,18 +629,18 @@ Glossary
 SMP
 An acronym for Symmetric Multiprocessing.
 
-SMP locks
-The SMP locks ensure mutual exclusion on the lowest level and are a
-replacement for the sections of disabled interrupts.  Interrupts are
-usually disabled while holding an SMP lock.  They are implemented using
-atomic operations.  Currently a ticket lock is used in RTEMS.
-
 SMP barriers
 The SMP barriers ensure that a defined set of independent threads of
 execution on a set of processors reaches a common synchronization point
 in time.  They are implemented using atomic operations.  Currently a
 sense barrier is used in RTEMS.
 
+SMP locks
+The SMP locks ensure mutual exclusion on the lowest level and are a
+replacement for the sections of disabled interrupts.  Interrupts are
+usually disabled while holding 

Re: ticket #2970 Add ftw.h to newlib

[Eshan Dhawan]

Also, Should look into ticket #3642 related to adding function prototypes
to wchar.h

On Thu, Feb 27, 2020 at 5:11 PM Eshan Dhawan 
wrote:

>
>
> On Wed, Feb 26, 2020 at 8:50 PM Joel Sherrill  wrote:
>
>>
>>
>> On Wed, Feb 26, 2020 at 9:06 AM Eshan Dhawan 
>> wrote:
>>
>>> so the subtasks would consist of adding missing functions to stat.h ,
>>> types.h mainly I suppose
>>>
>>
>> What do you think is missing in those? My reading of the POSIX standard
>> has is implying that
>>  includes  to get st_mode and the stat structure.
>>
> Not much related to ftw.h but there are unsupported functions in
> sys/stat.h which can be added
> to Newlib
>
> Also wanted to know which headers which aren't present in newlib or RTEMS
> which could make my GSOC proposal more acceptable?
>
>>
>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ftw.h.html
>>
>> The subtasks I referred to as the same for every time a new C Library or
>> POSIX method
>> is added to RTEMS or Newlib:
>>
>> + the code itself
>> + test code
>> + addition to documentation as needed
>> + update to compliance tracking spreadsheet (usually I will do this)
>>
>>>
>>> - Eshan
>>>
>>> On Wed, Feb 26, 2020 at 7:30 PM Joel Sherrill  wrote:
>>>


 On Wed, Feb 26, 2020 at 7:03 AM Eshan Dhawan 
 wrote:

> I wanted to know the status of implementation of ftw.h in newlib
> and the dependencies it requires?
>

 FIrst hint is that the ticket is still open. :)

 The next is a way to check if it is part of the installed C Library.
 Wherever
 you installed the tools (TOOLS_PREFIX) for CPU-rtems5

 find TOOLS_PREFIX -name ftw.h
 CPU-rtems5-nm TOOLS_PREFIX/CPU-rtems5/lib/libc.a | grep ftw

 In this case, you will see it isn't there.


>
> As it could be ported from FreeBSD since it lies under favourable
> licence
>

 Yep. And this would almost certainly need to be merged into the newlib
 C library
 with tests added to RTEMS.

 Documentation added to the POSIX Users Guide and the tracking
 spreadsheet
 updated.

 Just to list all the subtasks. :)

 --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: ticket #2970 Add ftw.h to newlib

[Eshan Dhawan]

On Wed, Feb 26, 2020 at 8:50 PM Joel Sherrill  wrote:

>
>
> On Wed, Feb 26, 2020 at 9:06 AM Eshan Dhawan 
> wrote:
>
>> so the subtasks would consist of adding missing functions to stat.h ,
>> types.h mainly I suppose
>>
>
> What do you think is missing in those? My reading of the POSIX standard
> has is implying that
>  includes  to get st_mode and the stat structure.
>
Not much related to ftw.h but there are unsupported functions in sys/stat.h
which can be added
to Newlib

Also wanted to know which headers which aren't present in newlib or RTEMS
which could make my GSOC proposal more acceptable?

>
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ftw.h.html
>
> The subtasks I referred to as the same for every time a new C Library or
> POSIX method
> is added to RTEMS or Newlib:
>
> + the code itself
> + test code
> + addition to documentation as needed
> + update to compliance tracking spreadsheet (usually I will do this)
>
>>
>> - Eshan
>>
>> On Wed, Feb 26, 2020 at 7:30 PM Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Wed, Feb 26, 2020 at 7:03 AM Eshan Dhawan 
>>> wrote:
>>>
 I wanted to know the status of implementation of ftw.h in newlib
 and the dependencies it requires?

>>>
>>> FIrst hint is that the ticket is still open. :)
>>>
>>> The next is a way to check if it is part of the installed C Library.
>>> Wherever
>>> you installed the tools (TOOLS_PREFIX) for CPU-rtems5
>>>
>>> find TOOLS_PREFIX -name ftw.h
>>> CPU-rtems5-nm TOOLS_PREFIX/CPU-rtems5/lib/libc.a | grep ftw
>>>
>>> In this case, you will see it isn't there.
>>>
>>>

 As it could be ported from FreeBSD since it lies under favourable
 licence

>>>
>>> Yep. And this would almost certainly need to be merged into the newlib C
>>> library
>>> with tests added to RTEMS.
>>>
>>> Documentation added to the POSIX Users Guide and the tracking spreadsheet
>>> updated.
>>>
>>> Just to list all the subtasks. :)
>>>
>>> --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

[PATCH] removed unneccesary assigning to rc triggering unused value error in coverity

[suyash singh]

---
 bsps/shared/dev/display/disp_hcms29xx.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/bsps/shared/dev/display/disp_hcms29xx.c 
b/bsps/shared/dev/display/disp_hcms29xx.c
index 5730b36ea9..9d3e7220cf 100644
--- a/bsps/shared/dev/display/disp_hcms29xx.c
+++ b/bsps/shared/dev/display/disp_hcms29xx.c
@@ -530,7 +530,7 @@ static rtems_task disp_hcms29xx_update_task
 +---+
 | Input Parameters: |
 \*-*/
-   rtems_task_argument argument 
+   rtems_task_argument argument
 )
 /*-*\
 | Return Value: |
@@ -597,7 +597,7 @@ static rtems_task disp_hcms29xx_update_task
  (int) strlen(softc_ptr->disp_param.disp_buffer);
   }
   if (rc == RTEMS_SUCCESSFUL) {
-   rc = rtems_semaphore_release(softc_ptr->disp_param.trns_sema_id);
+rtems_semaphore_release(softc_ptr->disp_param.trns_sema_id);
   }
   /*
* set initial offset to negative value
@@ -911,7 +911,7 @@ static rtems_driver_address_table disp_hcms29xx_ops = {
 
 static disp_hcms29xx_drv_t disp_hcms29xx_drv_tbl = {
   {/* public fields */
-.ops = _hcms29xx_ops, 
+.ops = _hcms29xx_ops,
 .size =sizeof (disp_hcms29xx_drv_t),
   },
   { /* our private fields */
@@ -927,6 +927,6 @@ static disp_hcms29xx_drv_t disp_hcms29xx_drv_tbl = {
   }
 };
 
-rtems_libi2c_drv_t *disp_hcms29xx_driver_descriptor = 
+rtems_libi2c_drv_t *disp_hcms29xx_driver_descriptor =
   _hcms29xx_drv_tbl.libi2c_drv_entry;
 
-- 
2.17.1

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

Re: Update to waf 2.0.19?

[Sebastian Huber]

On 25/02/2020 09:02, Sebastian Huber wrote:

Hello,

in order to close this bug:

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

I would like to update waf to the latest version 2.0.19 in:

rtems-docs
rtems-tools
rtems-libbsd
rtems-examples


I updated these repositories to waf version 2.0.19 and also the new 
build system.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel