Re: Fwd: [rtems-bsp-builder] 2020-10-13 09:15:22: Profile(s): everything

[Chris Johns]

On 15/10/20 5:43 pm, Sebastian Huber wrote:
> On 15/10/2020 08:41, Chris Johns wrote:
> 
>> On 15/10/20 5:34 pm, Sebastian Huber wrote:
>>> On 15/10/2020 08:30, Chris Johns wrote:
>>>
 On 15/10/20 5:26 pm, Sebastian Huber wrote:
> On 15/10/2020 08:23, Chris Johns wrote:
>
>> On 15/10/20 5:15 pm, Sebastian Huber wrote:
>>> On 15/10/2020 08:05, Chris Johns wrote:
>>>
 On 15/10/20 4:35 pm, Sebastian Huber wrote:
> On 15/10/2020 00:48, Chris Johns wrote:
>
>> On 15/10/20 2:27 am, Joel Sherrill wrote:
>>> On Wed, Oct 14, 2020 at 10:20 AM Sebastian Huber
>>> >> >
>>> wrote:
>>>  On 14/10/2020 17:17, Joel Sherrill wrote:
>>>  > On Wed, Oct 14, 2020 at 9:45 AM Sebastian Huber
>>>  > >>  
>>>  > >>  >> wrote:
>>>  >     On 14/10/2020 15:35, Joel Sherrill wrote:
>>>  >
>>>  >     > BSP builder has 81 failures. :(
>>>  >     It tried to build BSPs which no longer exist.
>>>  >
>>>  > Well that is an easier thing to fix than my concern that
>>> it was
>>> related to
>>>  > giving errors when a BSP does not support a feature. I
>>> suppose that
>>> will
>>>  > show up when the bsp builder switches to waf.
>>>  >
>>>  > Can you patch ./config/rtems-bsps-tiers.ini to reflect
>>> what you
>>> removed?
>>>  We should try try to reduce the redundancy in our data 
>>> sets.
>>> Why
>>> don't
>>>  we record the tier status in the BSP items?
>>>
>>> That's a Chris discussion when the builder is switched to using waf.
>> The current data is in rtems-tools.git/config. I needed a spot and 
>> could
>> not
>> think of another place that was easy and low impact. I would welcome
>> alternatives. If this data can be generated and updated or runtime 
>> loaded
>> from
>> another source, ie spec files, I would welcome this.
>>
>> The current blocker with the spec files is being able to use some 
>> shared
>> code to
>> parse and load the YAML data plus being able to load the data 
>> quickly.
>> Waf
>> has
>> the loading code in the wscript file so that cannot be easily shared
>> and it
>> uses
>> saved pickled data which I do not think is shareable.
> We have a couple of options to re-use the build specification items. 
> In
> general,
> the Python module to work with these items outside the wscript is in
> rtems-central:
>
> https://git.rtems.org/rtems-central/tree/rtemsspec/items.py
 How long does this code take to load the build spec files in rtems.git?

>>> It uses an item cache in pickle format. If you start with an empty 
>>> cache it
>>> needs a couple of seconds. Once the cache is set up it loads in less 
>>> than
>>> half a
>>> second.
>> Oh nice, that functionality is part of this code? I had (incorrectly it
>> seems)
>> assumed the dependency checking was being done by waf.
> The wscript uses one pickle file for the complete build specification. The
> rtemsspec/item uses one pickle file per directory. This allows faster
> updates if
> you just modify just one file of the specification.
 Could the module be exported or published from rtems-central into
 rtems-tools to
 it can used? Placing it into rtemstoolkit/rtemsspec/items.py to 
 rtems-tools and
 the tool kit can use it?
>>> Yes, but it is written in Python 3.6.
>> Ah ... but waf is python 2 and 3?
> Yes, waf works with Python 2 and 3.

... and it can load the spec files?

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

Re: Fwd: [rtems-bsp-builder] 2020-10-13 09:15:22: Profile(s): everything

[Sebastian Huber]

On 15/10/2020 08:41, Chris Johns wrote:


On 15/10/20 5:34 pm, Sebastian Huber wrote:

On 15/10/2020 08:30, Chris Johns wrote:


On 15/10/20 5:26 pm, Sebastian Huber wrote:

On 15/10/2020 08:23, Chris Johns wrote:


On 15/10/20 5:15 pm, Sebastian Huber wrote:

On 15/10/2020 08:05, Chris Johns wrote:


On 15/10/20 4:35 pm, Sebastian Huber wrote:

On 15/10/2020 00:48, Chris Johns wrote:


On 15/10/20 2:27 am, Joel Sherrill wrote:

On Wed, Oct 14, 2020 at 10:20 AM Sebastian Huber
>

wrote:
     On 14/10/2020 17:17, Joel Sherrill wrote:
     > On Wed, Oct 14, 2020 at 9:45 AM Sebastian Huber
     > mailto:sebastian.hu...@embedded-brains.de>
     > >> wrote:
     >     On 14/10/2020 15:35, Joel Sherrill wrote:
     >
     >     > BSP builder has 81 failures. :(
     >     It tried to build BSPs which no longer exist.
     >
     > Well that is an easier thing to fix than my concern that it was
related to
     > giving errors when a BSP does not support a feature. I
suppose that
will
     > show up when the bsp builder switches to waf.
     >
     > Can you patch ./config/rtems-bsps-tiers.ini to reflect what you
removed?
     We should try try to reduce the redundancy in our data sets. Why
don't
     we record the tier status in the BSP items?

That's a Chris discussion when the builder is switched to using waf.

The current data is in rtems-tools.git/config. I needed a spot and could
not
think of another place that was easy and low impact. I would welcome
alternatives. If this data can be generated and updated or runtime loaded
from
another source, ie spec files, I would welcome this.

The current blocker with the spec files is being able to use some shared
code to
parse and load the YAML data plus being able to load the data quickly. Waf
has
the loading code in the wscript file so that cannot be easily shared and it
uses
saved pickled data which I do not think is shareable.

We have a couple of options to re-use the build specification items. In
general,
the Python module to work with these items outside the wscript is in
rtems-central:

https://git.rtems.org/rtems-central/tree/rtemsspec/items.py

How long does this code take to load the build spec files in rtems.git?


It uses an item cache in pickle format. If you start with an empty cache it
needs a couple of seconds. Once the cache is set up it loads in less than
half a
second.

Oh nice, that functionality is part of this code? I had (incorrectly it seems)
assumed the dependency checking was being done by waf.

The wscript uses one pickle file for the complete build specification. The
rtemsspec/item uses one pickle file per directory. This allows faster updates if
you just modify just one file of the specification.

Could the module be exported or published from rtems-central into rtems-tools to
it can used? Placing it into rtemstoolkit/rtemsspec/items.py to rtems-tools and
the tool kit can use it?

Yes, but it is written in Python 3.6.

Ah ... but waf is python 2 and 3?

Yes, waf works with Python 2 and 3.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Fwd: [rtems-bsp-builder] 2020-10-13 09:15:22: Profile(s): everything

[Chris Johns]

On 15/10/20 5:34 pm, Sebastian Huber wrote:
> On 15/10/2020 08:30, Chris Johns wrote:
> 
>> On 15/10/20 5:26 pm, Sebastian Huber wrote:
>>> On 15/10/2020 08:23, Chris Johns wrote:
>>>
 On 15/10/20 5:15 pm, Sebastian Huber wrote:
> On 15/10/2020 08:05, Chris Johns wrote:
>
>> On 15/10/20 4:35 pm, Sebastian Huber wrote:
>>> On 15/10/2020 00:48, Chris Johns wrote:
>>>
 On 15/10/20 2:27 am, Joel Sherrill wrote:
> On Wed, Oct 14, 2020 at 10:20 AM Sebastian Huber
>  >
> wrote:
>     On 14/10/2020 17:17, Joel Sherrill wrote:
>     > On Wed, Oct 14, 2020 at 9:45 AM Sebastian Huber
>     >      
>     >      >> wrote:
>     >     On 14/10/2020 15:35, Joel Sherrill wrote:
>     >
>     >     > BSP builder has 81 failures. :(
>     >     It tried to build BSPs which no longer exist.
>     >
>     > Well that is an easier thing to fix than my concern that it 
> was
> related to
>     > giving errors when a BSP does not support a feature. I
> suppose that
> will
>     > show up when the bsp builder switches to waf.
>     >
>     > Can you patch ./config/rtems-bsps-tiers.ini to reflect what 
> you
> removed?
>     We should try try to reduce the redundancy in our data sets. 
> Why
> don't
>     we record the tier status in the BSP items?
>
> That's a Chris discussion when the builder is switched to using waf.
 The current data is in rtems-tools.git/config. I needed a spot and 
 could
 not
 think of another place that was easy and low impact. I would welcome
 alternatives. If this data can be generated and updated or runtime 
 loaded
 from
 another source, ie spec files, I would welcome this.

 The current blocker with the spec files is being able to use some 
 shared
 code to
 parse and load the YAML data plus being able to load the data quickly. 
 Waf
 has
 the loading code in the wscript file so that cannot be easily shared 
 and it
 uses
 saved pickled data which I do not think is shareable.
>>> We have a couple of options to re-use the build specification items. In
>>> general,
>>> the Python module to work with these items outside the wscript is in
>>> rtems-central:
>>>
>>> https://git.rtems.org/rtems-central/tree/rtemsspec/items.py
>> How long does this code take to load the build spec files in rtems.git?
>>
> It uses an item cache in pickle format. If you start with an empty cache 
> it
> needs a couple of seconds. Once the cache is set up it loads in less than
> half a
> second.
 Oh nice, that functionality is part of this code? I had (incorrectly it 
 seems)
 assumed the dependency checking was being done by waf.
>>> The wscript uses one pickle file for the complete build specification. The
>>> rtemsspec/item uses one pickle file per directory. This allows faster 
>>> updates if
>>> you just modify just one file of the specification.
>> Could the module be exported or published from rtems-central into 
>> rtems-tools to
>> it can used? Placing it into rtemstoolkit/rtemsspec/items.py to rtems-tools 
>> and
>> the tool kit can use it?
> Yes, but it is written in Python 3.6.

Ah ... but waf is python 2 and 3?

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

[PATCH 5] libfs/rfs: Check search bit map end on last bit

[chrisj]

From: Chris Johns 

- Do not write past the last location of the search bit map
  whe nit is being created.

Closes #4149
---
 cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c 
b/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
index 7973e85083..6da555d50e 100644
--- a/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
+++ b/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
@@ -34,6 +34,12 @@
 #include 
 #include 
 
+#define rtems_rfs_bitmap_check(_c, _sm) \
+   _Assert(_sm >= _c->search_bits && \
+   _sm < (_c->search_bits + \
+ rtems_rfs_bitmap_elements(rtems_rfs_bitmap_elements(_c->size
+
+
 /**
  * Test a bit in an element. If set return true else return false.
  *
@@ -220,6 +226,7 @@ rtems_rfs_bitmap_map_set (rtems_rfs_bitmap_control* control,
 index  = rtems_rfs_bitmap_map_index (bit);
 offset = rtems_rfs_bitmap_map_offset (bit);
 search_map[index] = rtems_rfs_bitmap_set (search_map[index], 1 << offset);
+rtems_rfs_bitmap_check(control, &search_map[index]);
   }
 
   return 0;
@@ -260,6 +267,7 @@ rtems_rfs_bitmap_map_clear (rtems_rfs_bitmap_control* 
control,
   index = rtems_rfs_bitmap_map_index (bit);
   offset= rtems_rfs_bitmap_map_offset(bit);
   search_map[index] = rtems_rfs_bitmap_clear (search_map[index], 1 << offset);
+  rtems_rfs_bitmap_check(control, &search_map[index]);
   rtems_rfs_buffer_mark_dirty (control->buffer);
   control->free++;
 
@@ -599,6 +607,7 @@ rtems_rfs_bitmap_create_search (rtems_rfs_bitmap_control* 
control)
   size = control->size;
   bit = 0;
 
+  rtems_rfs_bitmap_check(control, search_map);
   *search_map = RTEMS_RFS_BITMAP_ELEMENT_CLEAR;
   while (size)
   {
@@ -633,8 +642,12 @@ rtems_rfs_bitmap_create_search (rtems_rfs_bitmap_control* 
control)
 if (bit == (rtems_rfs_bitmap_element_bits () - 1))
 {
   bit = 0;
-  search_map++;
-  *search_map = RTEMS_RFS_BITMAP_ELEMENT_CLEAR;
+  if (size > 0)
+  {
+search_map++;
+rtems_rfs_bitmap_check(control, search_map);
+*search_map = RTEMS_RFS_BITMAP_ELEMENT_CLEAR;
+  }
 }
 else
   bit++;
-- 
2.24.1

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

Re: Fwd: [rtems-bsp-builder] 2020-10-13 09:15:22: Profile(s): everything

[Sebastian Huber]

On 15/10/2020 08:30, Chris Johns wrote:


On 15/10/20 5:26 pm, Sebastian Huber wrote:

On 15/10/2020 08:23, Chris Johns wrote:


On 15/10/20 5:15 pm, Sebastian Huber wrote:

On 15/10/2020 08:05, Chris Johns wrote:


On 15/10/20 4:35 pm, Sebastian Huber wrote:

On 15/10/2020 00:48, Chris Johns wrote:


On 15/10/20 2:27 am, Joel Sherrill wrote:

On Wed, Oct 14, 2020 at 10:20 AM Sebastian Huber
>

wrote:
    On 14/10/2020 17:17, Joel Sherrill wrote:
    > On Wed, Oct 14, 2020 at 9:45 AM Sebastian Huber
    > mailto:sebastian.hu...@embedded-brains.de>
    > >> wrote:
    >     On 14/10/2020 15:35, Joel Sherrill wrote:
    >
    >     > BSP builder has 81 failures. :(
    >     It tried to build BSPs which no longer exist.
    >
    > Well that is an easier thing to fix than my concern that it was
related to
    > giving errors when a BSP does not support a feature. I suppose that
will
    > show up when the bsp builder switches to waf.
    >
    > Can you patch ./config/rtems-bsps-tiers.ini to reflect what you
removed?
    We should try try to reduce the redundancy in our data sets. Why
don't
    we record the tier status in the BSP items?

That's a Chris discussion when the builder is switched to using waf.

The current data is in rtems-tools.git/config. I needed a spot and could not
think of another place that was easy and low impact. I would welcome
alternatives. If this data can be generated and updated or runtime loaded
from
another source, ie spec files, I would welcome this.

The current blocker with the spec files is being able to use some shared
code to
parse and load the YAML data plus being able to load the data quickly. Waf
has
the loading code in the wscript file so that cannot be easily shared and it
uses
saved pickled data which I do not think is shareable.

We have a couple of options to re-use the build specification items. In
general,
the Python module to work with these items outside the wscript is in
rtems-central:

https://git.rtems.org/rtems-central/tree/rtemsspec/items.py

How long does this code take to load the build spec files in rtems.git?


It uses an item cache in pickle format. If you start with an empty cache it
needs a couple of seconds. Once the cache is set up it loads in less than half a
second.

Oh nice, that functionality is part of this code? I had (incorrectly it seems)
assumed the dependency checking was being done by waf.

The wscript uses one pickle file for the complete build specification. The
rtemsspec/item uses one pickle file per directory. This allows faster updates if
you just modify just one file of the specification.

Could the module be exported or published from rtems-central into rtems-tools to
it can used? Placing it into rtemstoolkit/rtemsspec/items.py to rtems-tools and
the tool kit can use it?

Yes, but it is written in Python 3.6.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Fwd: [rtems-bsp-builder] 2020-10-13 09:15:22: Profile(s): everything

[Chris Johns]

On 15/10/20 5:26 pm, Sebastian Huber wrote:
> On 15/10/2020 08:23, Chris Johns wrote:
> 
>> On 15/10/20 5:15 pm, Sebastian Huber wrote:
>>> On 15/10/2020 08:05, Chris Johns wrote:
>>>
 On 15/10/20 4:35 pm, Sebastian Huber wrote:
> On 15/10/2020 00:48, Chris Johns wrote:
>
>> On 15/10/20 2:27 am, Joel Sherrill wrote:
>>> On Wed, Oct 14, 2020 at 10:20 AM Sebastian Huber
>>> >> >
>>> wrote:
>>>    On 14/10/2020 17:17, Joel Sherrill wrote:
>>>    > On Wed, Oct 14, 2020 at 9:45 AM Sebastian Huber
>>>    > >>    
>>>    > >>    >> wrote:
>>>    >     On 14/10/2020 15:35, Joel Sherrill wrote:
>>>    >
>>>    >     > BSP builder has 81 failures. :(
>>>    >     It tried to build BSPs which no longer exist.
>>>    >
>>>    > Well that is an easier thing to fix than my concern that it was
>>> related to
>>>    > giving errors when a BSP does not support a feature. I suppose 
>>> that
>>> will
>>>    > show up when the bsp builder switches to waf.
>>>    >
>>>    > Can you patch ./config/rtems-bsps-tiers.ini to reflect what you
>>> removed?
>>>    We should try try to reduce the redundancy in our data sets. Why
>>> don't
>>>    we record the tier status in the BSP items?
>>>
>>> That's a Chris discussion when the builder is switched to using waf.
>> The current data is in rtems-tools.git/config. I needed a spot and could 
>> not
>> think of another place that was easy and low impact. I would welcome
>> alternatives. If this data can be generated and updated or runtime loaded
>> from
>> another source, ie spec files, I would welcome this.
>>
>> The current blocker with the spec files is being able to use some shared
>> code to
>> parse and load the YAML data plus being able to load the data quickly. 
>> Waf
>> has
>> the loading code in the wscript file so that cannot be easily shared and 
>> it
>> uses
>> saved pickled data which I do not think is shareable.
> We have a couple of options to re-use the build specification items. In
> general,
> the Python module to work with these items outside the wscript is in
> rtems-central:
>
> https://git.rtems.org/rtems-central/tree/rtemsspec/items.py
 How long does this code take to load the build spec files in rtems.git?

>>> It uses an item cache in pickle format. If you start with an empty cache it
>>> needs a couple of seconds. Once the cache is set up it loads in less than 
>>> half a
>>> second.
>> Oh nice, that functionality is part of this code? I had (incorrectly it 
>> seems)
>> assumed the dependency checking was being done by waf.
> The wscript uses one pickle file for the complete build specification. The
> rtemsspec/item uses one pickle file per directory. This allows faster updates 
> if
> you just modify just one file of the specification.

Could the module be exported or published from rtems-central into rtems-tools to
it can used? Placing it into rtemstoolkit/rtemsspec/items.py to rtems-tools and
the tool kit can use it?

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

Re: Fwd: [rtems-bsp-builder] 2020-10-13 09:15:22: Profile(s): everything

[Sebastian Huber]

On 15/10/2020 08:23, Chris Johns wrote:


On 15/10/20 5:15 pm, Sebastian Huber wrote:

On 15/10/2020 08:05, Chris Johns wrote:


On 15/10/20 4:35 pm, Sebastian Huber wrote:

On 15/10/2020 00:48, Chris Johns wrote:


On 15/10/20 2:27 am, Joel Sherrill wrote:

On Wed, Oct 14, 2020 at 10:20 AM Sebastian Huber
>

wrote:
   On 14/10/2020 17:17, Joel Sherrill wrote:
   > On Wed, Oct 14, 2020 at 9:45 AM Sebastian Huber
   > mailto:sebastian.hu...@embedded-brains.de>
   > >> wrote:
   >     On 14/10/2020 15:35, Joel Sherrill wrote:
   >
   >     > BSP builder has 81 failures. :(
   >     It tried to build BSPs which no longer exist.
   >
   > Well that is an easier thing to fix than my concern that it was
related to
   > giving errors when a BSP does not support a feature. I suppose that
will
   > show up when the bsp builder switches to waf.
   >
   > Can you patch ./config/rtems-bsps-tiers.ini to reflect what you
removed?
   We should try try to reduce the redundancy in our data sets. Why don't
   we record the tier status in the BSP items?

That's a Chris discussion when the builder is switched to using waf.

The current data is in rtems-tools.git/config. I needed a spot and could not
think of another place that was easy and low impact. I would welcome
alternatives. If this data can be generated and updated or runtime loaded from
another source, ie spec files, I would welcome this.

The current blocker with the spec files is being able to use some shared
code to
parse and load the YAML data plus being able to load the data quickly. Waf has
the loading code in the wscript file so that cannot be easily shared and it
uses
saved pickled data which I do not think is shareable.

We have a couple of options to re-use the build specification items. In general,
the Python module to work with these items outside the wscript is in
rtems-central:

https://git.rtems.org/rtems-central/tree/rtemsspec/items.py

How long does this code take to load the build spec files in rtems.git?


It uses an item cache in pickle format. If you start with an empty cache it
needs a couple of seconds. Once the cache is set up it loads in less than half a
second.

Oh nice, that functionality is part of this code? I had (incorrectly it seems)
assumed the dependency checking was being done by waf.
The wscript uses one pickle file for the complete build specification. 
The rtemsspec/item uses one pickle file per directory. This allows 
faster updates if you just modify just one file of the specification.

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

Re: Fwd: [rtems-bsp-builder] 2020-10-13 09:15:22: Profile(s): everything

[Chris Johns]

On 15/10/20 5:15 pm, Sebastian Huber wrote:
> On 15/10/2020 08:05, Chris Johns wrote:
> 
>> On 15/10/20 4:35 pm, Sebastian Huber wrote:
>>> On 15/10/2020 00:48, Chris Johns wrote:
>>>
 On 15/10/20 2:27 am, Joel Sherrill wrote:
> On Wed, Oct 14, 2020 at 10:20 AM Sebastian Huber
>  >
> wrote:
>   On 14/10/2020 17:17, Joel Sherrill wrote:
>   > On Wed, Oct 14, 2020 at 9:45 AM Sebastian Huber
>   >    
>   >    >> wrote:
>   >     On 14/10/2020 15:35, Joel Sherrill wrote:
>   >
>   >     > BSP builder has 81 failures. :(
>   >     It tried to build BSPs which no longer exist.
>   >
>   > Well that is an easier thing to fix than my concern that it was
> related to
>   > giving errors when a BSP does not support a feature. I suppose 
> that
> will
>   > show up when the bsp builder switches to waf.
>   >
>   > Can you patch ./config/rtems-bsps-tiers.ini to reflect what you
> removed?
>   We should try try to reduce the redundancy in our data sets. Why 
> don't
>   we record the tier status in the BSP items?
>
> That's a Chris discussion when the builder is switched to using waf.
 The current data is in rtems-tools.git/config. I needed a spot and could 
 not
 think of another place that was easy and low impact. I would welcome
 alternatives. If this data can be generated and updated or runtime loaded 
 from
 another source, ie spec files, I would welcome this.

 The current blocker with the spec files is being able to use some shared
 code to
 parse and load the YAML data plus being able to load the data quickly. Waf 
 has
 the loading code in the wscript file so that cannot be easily shared and it
 uses
 saved pickled data which I do not think is shareable.
>>> We have a couple of options to re-use the build specification items. In 
>>> general,
>>> the Python module to work with these items outside the wscript is in
>>> rtems-central:
>>>
>>> https://git.rtems.org/rtems-central/tree/rtemsspec/items.py
>> How long does this code take to load the build spec files in rtems.git?
>>
> It uses an item cache in pickle format. If you start with an empty cache it
> needs a couple of seconds. Once the cache is set up it loads in less than 
> half a
> second.

Oh nice, that functionality is part of this code? I had (incorrectly it seems)
assumed the dependency checking was being done by waf.

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

[PATCH] libfs/rfs: Check search bit map end on last bit

[chrisj]

From: Chris Johns 

- Do not write past the last location of the search bit map
  whe nit is being created.

Closes #4148
---
 cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c 
b/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
index 7973e85083..6da555d50e 100644
--- a/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
+++ b/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
@@ -34,6 +34,12 @@
 #include 
 #include 
 
+#define rtems_rfs_bitmap_check(_c, _sm) \
+   _Assert(_sm >= _c->search_bits && \
+   _sm < (_c->search_bits + \
+ rtems_rfs_bitmap_elements(rtems_rfs_bitmap_elements(_c->size
+
+
 /**
  * Test a bit in an element. If set return true else return false.
  *
@@ -220,6 +226,7 @@ rtems_rfs_bitmap_map_set (rtems_rfs_bitmap_control* control,
 index  = rtems_rfs_bitmap_map_index (bit);
 offset = rtems_rfs_bitmap_map_offset (bit);
 search_map[index] = rtems_rfs_bitmap_set (search_map[index], 1 << offset);
+rtems_rfs_bitmap_check(control, &search_map[index]);
   }
 
   return 0;
@@ -260,6 +267,7 @@ rtems_rfs_bitmap_map_clear (rtems_rfs_bitmap_control* 
control,
   index = rtems_rfs_bitmap_map_index (bit);
   offset= rtems_rfs_bitmap_map_offset(bit);
   search_map[index] = rtems_rfs_bitmap_clear (search_map[index], 1 << offset);
+  rtems_rfs_bitmap_check(control, &search_map[index]);
   rtems_rfs_buffer_mark_dirty (control->buffer);
   control->free++;
 
@@ -599,6 +607,7 @@ rtems_rfs_bitmap_create_search (rtems_rfs_bitmap_control* 
control)
   size = control->size;
   bit = 0;
 
+  rtems_rfs_bitmap_check(control, search_map);
   *search_map = RTEMS_RFS_BITMAP_ELEMENT_CLEAR;
   while (size)
   {
@@ -633,8 +642,12 @@ rtems_rfs_bitmap_create_search (rtems_rfs_bitmap_control* 
control)
 if (bit == (rtems_rfs_bitmap_element_bits () - 1))
 {
   bit = 0;
-  search_map++;
-  *search_map = RTEMS_RFS_BITMAP_ELEMENT_CLEAR;
+  if (size > 0)
+  {
+search_map++;
+rtems_rfs_bitmap_check(control, search_map);
+*search_map = RTEMS_RFS_BITMAP_ELEMENT_CLEAR;
+  }
 }
 else
   bit++;
-- 
2.24.1

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

Re: Fwd: [rtems-bsp-builder] 2020-10-13 09:15:22: Profile(s): everything

[Sebastian Huber]

On 15/10/2020 08:05, Chris Johns wrote:


On 15/10/20 4:35 pm, Sebastian Huber wrote:

On 15/10/2020 00:48, Chris Johns wrote:


On 15/10/20 2:27 am, Joel Sherrill wrote:

On Wed, Oct 14, 2020 at 10:20 AM Sebastian Huber
mailto:sebastian.hu...@embedded-brains.de>>
wrote:
  On 14/10/2020 17:17, Joel Sherrill wrote:
  > On Wed, Oct 14, 2020 at 9:45 AM Sebastian Huber
  > mailto:sebastian.hu...@embedded-brains.de>
  > >> wrote:
  >     On 14/10/2020 15:35, Joel Sherrill wrote:
  >
  >     > BSP builder has 81 failures. :(
  >     It tried to build BSPs which no longer exist.
  >
  > Well that is an easier thing to fix than my concern that it was
related to
  > giving errors when a BSP does not support a feature. I suppose that will
  > show up when the bsp builder switches to waf.
  >
  > Can you patch ./config/rtems-bsps-tiers.ini to reflect what you removed?
  We should try try to reduce the redundancy in our data sets. Why don't
  we record the tier status in the BSP items?

That's a Chris discussion when the builder is switched to using waf.

The current data is in rtems-tools.git/config. I needed a spot and could not
think of another place that was easy and low impact. I would welcome
alternatives. If this data can be generated and updated or runtime loaded from
another source, ie spec files, I would welcome this.

The current blocker with the spec files is being able to use some shared code to
parse and load the YAML data plus being able to load the data quickly. Waf has
the loading code in the wscript file so that cannot be easily shared and it uses
saved pickled data which I do not think is shareable.

We have a couple of options to re-use the build specification items. In general,
the Python module to work with these items outside the wscript is in 
rtems-central:

https://git.rtems.org/rtems-central/tree/rtemsspec/items.py

How long does this code take to load the build spec files in rtems.git?

It uses an item cache in pickle format. If you start with an empty cache 
it needs a couple of seconds. Once the cache is set up it loads in less 
than half a second.

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

Re: RTEMS 5.1 pc686 BSP malloc_info problem?

[Chris Johns]

On 13/10/20 4:13 am, Joel Sherrill wrote:
> On Mon, Oct 12, 2020 at 11:15 AM Alan Cudmore  > wrote:
> 
> Hi Chris,
> I'm not sure that I can easily create a test to show that this
> condition exists. I think the rtems_rfs_bitmap_create_search function
> works as it is intended to, but during the last iteration of the for
> loop, if 'size' is zero and 'bit' is 31, the 'search_map' variable is
> incremented once more, and the value of RTEMS_RFS_BITMAP_ELEMENT_CLEAR
> (0x) is written to that location. This location is one address
> beyond the memory that was allocated for the search_map in
> rtems_rfs_bitmap_open.
> I guess that most of the time this is a silent side effect, but my
> application just happened to have memory lined up such that the extra
> write causes the malloc Allocator mutex to fail, causing the
> malloc_info call to block indefinitely. I would consider this a lucky
> break!
> The exact same example application does not fail on RTEMS 4.11. I
> think the problem still exists, but in that case, the word that gets
> written is different.
> 
> Here are some debug printfs from rtems_rfs_bitmap_open and
> rtems_rfs_bitmap_create_search:
> 
> From rtems_rfs_bitmap_open:
> RFS - rtems_rfs_bitmap_open - search_bits malloced size = 16 bytes
> RFS - rtems_rfs_bitmap_open - addr of search_bits = 0x00C03814
> RFS -> size of search_map = 4
> RFS -> control->size = 4095
> 
> From the subsequent call to rtems_rfs_bitmap_create_search:
> These printfs are in the if clause where bit == 31 (line 633)
> RFS --> search_map before increment addr 00C03814, size = 3071
> RFS --> search_map after increment -> writing
> RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03818
> RFS --> search_map before increment addr 00C03818, size = 2047
> RFS --> search_map after increment -> writing
> RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C0381C
> RFS --> search_map before increment addr 00C0381C, size = 1023
> RFS --> search_map after increment -> writing
> RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03820
> RFS --> search_map before increment addr 00C03820, size = 0
> RFS --> search_map after increment -> writing
> RTEMS_RFS_BITMAP_ELEMENT_CLEAR (-1) to addr 00C03824
> 
> It's this last write to 00C03824 that causes the problem. I think the
> fix just involves checking to see if size == 0 before executing the if
> clause. I wanted to be sure that this extra write was not needed.
> 
> If you have an idea for a test case, I can work on it, but if you
> think that this is good enough, I can propose a patch.
> 
> Also, thanks for the idea of using RTEMS_DEBUG Sebastian, I need to
> upgrade my RTEMS toolbox with the latest techniques.
> 
> 
> If, while analysing this issues, you came up with any consistency checks
> or assertions that can be added to the code when debug is enabled, 
> those would be welcomed. It is hard to go back and add them without 
> the analysis like you did hunting this bug.

I have added an _Assert (thanks Sebastian) and I now see:

*** BEGIN OF TEST FSRFSBITMAP 1 ***

*** TEST VERSION: 6.0.0.df9cc1aee87da6c6ba41d52454fa5f45fba74501

*** TEST STATE: EXPECTED_PASS

*** TEST BUILD: RTEMS_DEBUG

*** TEST TOOLS: 10.2.1 20200918 (RTEMS 6, RSB
ed5030bc24dbfdfac52074ed78cf4231bf1f353d, Newlib 749cbcc)
Initializing filesystem RFS

assertion "search_map >= control->search_bits && search_map <
(control->search_bits +
rtems_rfs_bitmap_elements(rtems_rfs_bitmap_elements(control->size)))" failed:
file "../../../cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c", line 648, function:
rtems_rfs_bitmap_create_search



I have a patch to fix this I will post.

Thank you Alan for the report and the analysis. It made my job nice and simple.

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

Re: Fwd: [rtems-bsp-builder] 2020-10-13 09:15:22: Profile(s): everything

[Chris Johns]

On 15/10/20 4:35 pm, Sebastian Huber wrote:
> On 15/10/2020 00:48, Chris Johns wrote:
> 
>> On 15/10/20 2:27 am, Joel Sherrill wrote:
>>> On Wed, Oct 14, 2020 at 10:20 AM Sebastian Huber
>>> >> >
>>> wrote:
>>>  On 14/10/2020 17:17, Joel Sherrill wrote:
>>>  > On Wed, Oct 14, 2020 at 9:45 AM Sebastian Huber
>>>  > >>  
>>>  > >>  >> wrote:
>>>  >     On 14/10/2020 15:35, Joel Sherrill wrote:
>>>  >
>>>  >     > BSP builder has 81 failures. :(
>>>  >     It tried to build BSPs which no longer exist.
>>>  >
>>>  > Well that is an easier thing to fix than my concern that it was
>>> related to
>>>  > giving errors when a BSP does not support a feature. I suppose that 
>>> will
>>>  > show up when the bsp builder switches to waf.
>>>  >
>>>  > Can you patch ./config/rtems-bsps-tiers.ini to reflect what you 
>>> removed?
>>>  We should try try to reduce the redundancy in our data sets. Why don't
>>>  we record the tier status in the BSP items?
>>>
>>> That's a Chris discussion when the builder is switched to using waf.
>> The current data is in rtems-tools.git/config. I needed a spot and could not
>> think of another place that was easy and low impact. I would welcome
>> alternatives. If this data can be generated and updated or runtime loaded 
>> from
>> another source, ie spec files, I would welcome this.
>>
>> The current blocker with the spec files is being able to use some shared 
>> code to
>> parse and load the YAML data plus being able to load the data quickly. Waf 
>> has
>> the loading code in the wscript file so that cannot be easily shared and it 
>> uses
>> saved pickled data which I do not think is shareable.
> 
> We have a couple of options to re-use the build specification items. In 
> general,
> the Python module to work with these items outside the wscript is in 
> rtems-central:
> 
> https://git.rtems.org/rtems-central/tree/rtemsspec/items.py

How long does this code take to load the build spec files in rtems.git?

> We could add the rtems-tools to the modules:
> 
> https://git.rtems.org/rtems-central/tree/modules
> 
> We can read the build specification and convert it to pickle or JSON and save 
> it
> completely somewhere in rtems-tools. Another option is to generate the *.ini
> files in rtems-tools/config.

My preference is to read the spec files each time so the bsp builder can be run
on a development tree when testing. After that the INI file generation is next
best option as it is human readable and can be hack when testing.

I am happy with the rtems-central concept but moving to it for my work flow will
take time.

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

Re: Fwd: [rtems-bsp-builder] 2020-10-13 09:15:22: Profile(s): everything

[Sebastian Huber]

On 15/10/2020 00:48, Chris Johns wrote:


On 15/10/20 2:27 am, Joel Sherrill wrote:

On Wed, Oct 14, 2020 at 10:20 AM Sebastian Huber
mailto:sebastian.hu...@embedded-brains.de>>
wrote:
 On 14/10/2020 17:17, Joel Sherrill wrote:
 > On Wed, Oct 14, 2020 at 9:45 AM Sebastian Huber
 > mailto:sebastian.hu...@embedded-brains.de>
 > >> wrote:
 >     On 14/10/2020 15:35, Joel Sherrill wrote:
 >
 >     > BSP builder has 81 failures. :(
 >     It tried to build BSPs which no longer exist.
 >
 > Well that is an easier thing to fix than my concern that it was related 
to
 > giving errors when a BSP does not support a feature. I suppose that will
 > show up when the bsp builder switches to waf.
 >
 > Can you patch ./config/rtems-bsps-tiers.ini to reflect what you removed?
 We should try try to reduce the redundancy in our data sets. Why don't
 we record the tier status in the BSP items?

That's a Chris discussion when the builder is switched to using waf.

The current data is in rtems-tools.git/config. I needed a spot and could not
think of another place that was easy and low impact. I would welcome
alternatives. If this data can be generated and updated or runtime loaded from
another source, ie spec files, I would welcome this.

The current blocker with the spec files is being able to use some shared code to
parse and load the YAML data plus being able to load the data quickly. Waf has
the loading code in the wscript file so that cannot be easily shared and it uses
saved pickled data which I do not think is shareable.


We have a couple of options to re-use the build specification items. In 
general, the Python module to work with these items outside the wscript 
is in rtems-central:


https://git.rtems.org/rtems-central/tree/rtemsspec/items.py

We could add the rtems-tools to the modules:

https://git.rtems.org/rtems-central/tree/modules

We can read the build specification and convert it to pickle or JSON and 
save it completely somewhere in rtems-tools. Another option is to 
generate the *.ini files in rtems-tools/config.


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

Re: Uncrustify

[Joel Sherrill]

On Wed, Oct 14, 2020, 6:03 PM Chris Johns  wrote:

> On 15/10/20 5:04 am, Joel Sherrill wrote:
> > On Wed, Oct 14, 2020 at 12:11 PM Sebastian Huber
> >  sebastian.hu...@embedded-brains.de>>
> > wrote:
> > Hello,
> >
> > I tried to write a configuration file for Uncrustify which is close
> to
> > the RTEMS coding style. This tool has really a lot of options. The
> > configuration file has more than 3000 lines. Apparently this is not
> > enough. I was not able to get function parameters properly aligned.
> For
> > example:
> >
> > -  Thread_queue_Context  queue_context;
> > -  Thread_Control   *the_thread;
> > +  Thread_queue_Context queue_context;
> > +  Thread_Control  *the_thread;
> >
> > It seems Uncrustify interprets the '*' as some sort of white space.
> > Attached is my current configuration file. You can test it for
> example
> > with cpukit/score/src/threadqenqueue.c.
> >
> > I'm not a huge fan of moving the * to after the type rather than against
> > the name but if we accepted that change to the style, would the parameter
> > names line up?
>
> I understand the history with multiple variable declarations per line but
> to me
> the type with the modifier grouped together reads better. In C++ I prefer
> that
> style because there are more type modifiers such as reference and the
> reference
> and address-of is the same character. For example a randomly selected API
> ...
>
> https://en.cppreference.com/w/cpp/container/vector/vector
>
> ... and
>
>  vector& operator=( const vector& other );
>
> I had never noticed the C style until I used C++ heavily many years ago.
>

I don't care as much about the placement as if this let's uncrustify align
the parameter names.

This is definitely in the category of something I'd comprise ob if the tool
gives us an acceptable pattern overall.

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

Re: Uncrustify

[Chris Johns]

On 15/10/20 5:04 am, Joel Sherrill wrote:
> On Wed, Oct 14, 2020 at 12:11 PM Sebastian Huber
>  >
> wrote:
> Hello,
> 
> I tried to write a configuration file for Uncrustify which is close to
> the RTEMS coding style. This tool has really a lot of options. The
> configuration file has more than 3000 lines. Apparently this is not
> enough. I was not able to get function parameters properly aligned. For
> example:
> 
> -  Thread_queue_Context  queue_context;
> -  Thread_Control   *the_thread;
> +  Thread_queue_Context queue_context;
> +  Thread_Control  *the_thread;
> 
> It seems Uncrustify interprets the '*' as some sort of white space.
> Attached is my current configuration file. You can test it for example
> with cpukit/score/src/threadqenqueue.c.
> 
> I'm not a huge fan of moving the * to after the type rather than against
> the name but if we accepted that change to the style, would the parameter
> names line up?

I understand the history with multiple variable declarations per line but to me
the type with the modifier grouped together reads better. In C++ I prefer that
style because there are more type modifiers such as reference and the reference
and address-of is the same character. For example a randomly selected API ...

https://en.cppreference.com/w/cpp/container/vector/vector

... and

 vector& operator=( const vector& other );

I had never noticed the C style until I used C++ heavily many years ago.

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

Re: Fwd: [rtems-bsp-builder] 2020-10-13 09:15:22: Profile(s): everything

[Chris Johns]

On 15/10/20 2:27 am, Joel Sherrill wrote:
> On Wed, Oct 14, 2020 at 10:20 AM Sebastian Huber
>  >
> wrote:
> On 14/10/2020 17:17, Joel Sherrill wrote:
> > On Wed, Oct 14, 2020 at 9:45 AM Sebastian Huber
> >  
> >  >> wrote:
> >     On 14/10/2020 15:35, Joel Sherrill wrote:
> >
> >     > BSP builder has 81 failures. :(
> >     It tried to build BSPs which no longer exist.
> >
> > Well that is an easier thing to fix than my concern that it was related 
> to
> > giving errors when a BSP does not support a feature. I suppose that will
> > show up when the bsp builder switches to waf.
> >
> > Can you patch ./config/rtems-bsps-tiers.ini to reflect what you removed?
> We should try try to reduce the redundancy in our data sets. Why don't
> we record the tier status in the BSP items?
> 
> That's a Chris discussion when the builder is switched to using waf. 

The current data is in rtems-tools.git/config. I needed a spot and could not
think of another place that was easy and low impact. I would welcome
alternatives. If this data can be generated and updated or runtime loaded from
another source, ie spec files, I would welcome this.

The current blocker with the spec files is being able to use some shared code to
parse and load the YAML data plus being able to load the data quickly. Waf has
the loading code in the wscript file so that cannot be easily shared and it uses
saved pickled data which I do not think is shareable.

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

Re: Uncrustify

[Joel Sherrill]

On Wed, Oct 14, 2020 at 12:11 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> I tried to write a configuration file for Uncrustify which is close to
> the RTEMS coding style. This tool has really a lot of options. The
> configuration file has more than 3000 lines. Apparently this is not
> enough. I was not able to get function parameters properly aligned. For
> example:
>
> -  Thread_queue_Context  queue_context;
> -  Thread_Control   *the_thread;
> +  Thread_queue_Context queue_context;
> +  Thread_Control  *the_thread;
>
> It seems Uncrustify interprets the '*' as some sort of white space.
> Attached is my current configuration file. You can test it for example
> with cpukit/score/src/threadqenqueue.c.
>
 v
I'm not a huge fan of moving the * to after the type rather than against
the name but if we accepted that change to the style, would the parameter
names line up?

Just curious. This is an area where giving on one point may make things
better.

>
> ___
> 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: Beagle SPI driver update

[Niteesh G. S.]

Hello,

Update: I got the condition in the while loop wrong. After fixing this it
works now.
I'll try to post a working patch of the SPI driver as soon as possible.

Thanks,
Niteesh

On Wed, Oct 14, 2020 at 12:39 PM Niteesh G. S.  wrote:

> Hello,
>
> First of all really sorry for the long delay, I am preparing for a
> robotics competition
> and it eats up most of my free time.
>
> I finally got a logic analyzer and tested the SPI driver using it. And as
> expected the
> waveforms weren't right. To understand the device better and also to
> narrow down
> the problem I decided to write a simple polled driver. This driver can be
> found
> here
>
> https://github.com/gs-niteesh/rtems/blob/8a75a2f5eb6b4eb852da9563b53b6c021463a8c7/bsps/arm/beagle/spi/simple-spi.c
>
> Commit:
> https://github.com/gs-niteesh/rtems/commit/8a75a2f5eb6b4eb852da9563b53b6c021463a8c7
>
> This way I was able to get my first byte pushed but the succeeding bytes
> time out. I
> added the time out to make sure the pushed data is transferred before
> getting overwritten
> by the succeeding bytes. I also checked other drivers to make sure adding
> a timeout is
> necessary.
> On removing the timeout I was able to get all my bytes pushed successfully.
> This was verified using the logic analyzer. But on using the timeout I
> face the mentioned
> problem. I even tried decreasing the time but still, I face the same issue.
> What could be causing the problem? Is there any other way to debug this?
>
> Thanks,
> Niteesh.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Fwd: [rtems-bsp-builder] 2020-10-13 09:15:22: Profile(s): everything

[Joel Sherrill]

On Wed, Oct 14, 2020, 11:19 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
> On 14/10/2020 18:16, Joel Sherrill wrote:
> >
> > > Can you just fix this for now? It builds with autoconf and there
> > is a
> > > ticket for it.
> >
> > I removed the BSPs a while ago also in the old build system:
> >
> >
> https://git.rtems.org/rtems/log/?qt=range&q=70b803b5549016ab1ca12816e862217b8198e449
> >
> > Why does this work?
> >
> >
> > What do you mean? The bsps are gone but still in the tiers list so
> > attempted. They fail to build as expected. You just missed references
> > to them in the tools
> Ok, I probably misinterpreted your "It builds with autoconf".
>

I was referring to the rtems-bsp-builder has not been converted to test
with waf. There is a ticket.

Also doubt the kernel RSB package has been converted to use waf with RTEMS
yet.

I really want a clean cut over to waf. Tools, packaging, and documentation.
I'm trying to test a lot. :)

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

Re: Fwd: [rtems-bsp-builder] 2020-10-13 09:15:22: Profile(s): everything

[Sebastian Huber]

On 14/10/2020 18:16, Joel Sherrill wrote:


> Can you just fix this for now? It builds with autoconf and there
is a
> ticket for it.

I removed the BSPs a while ago also in the old build system:


https://git.rtems.org/rtems/log/?qt=range&q=70b803b5549016ab1ca12816e862217b8198e449

Why does this work?


What do you mean? The bsps are gone but still in the tiers list so 
attempted. They fail to build as expected. You just missed references 
to them in the tools

Ok, I probably misinterpreted your "It builds with autoconf".
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rtems-bsps-tiers.ini: Delete removed PowerPC BSPs

[Sebastian Huber]

The patch looks good, thanks.

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

Re: Fwd: [rtems-bsp-builder] 2020-10-13 09:15:22: Profile(s): everything

[Joel Sherrill]

On Wed, Oct 14, 2020, 11:13 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
> On 14/10/2020 17:27, Joel Sherrill wrote:
> >
> >
> > On Wed, Oct 14, 2020 at 10:20 AM Sebastian Huber
> >  > > wrote:
> >
> > On 14/10/2020 17:17, Joel Sherrill wrote:
> >
> > > On Wed, Oct 14, 2020 at 9:45 AM Sebastian Huber
> > >  > 
> > >  > >> wrote:
> > >
> > > On 14/10/2020 15:35, Joel Sherrill wrote:
> > >
> > > > BSP builder has 81 failures. :(
> > > It tried to build BSPs which no longer exist.
> > >
> > >
> > > Well that is an easier thing to fix than my concern that it was
> > related to
> > > giving errors when a BSP does not support a feature. I suppose
> > that will
> > > show up when the bsp builder switches to waf.
> > >
> > > Can you patch ./config/rtems-bsps-tiers.ini to reflect what you
> > removed?
> > We should try try to reduce the redundancy in our data sets. Why
> > don't
> > we record the tier status in the BSP items?
> >
> >
> > That's a Chris discussion when the builder is switched to using waf.
> >
> > Can you just fix this for now? It builds with autoconf and there is a
> > ticket for it.
>
> I removed the BSPs a while ago also in the old build system:
>
>
> https://git.rtems.org/rtems/log/?qt=range&q=70b803b5549016ab1ca12816e862217b8198e449
>
> Why does this work?
>

What do you mean? The bsps are gone but still in the tiers list so
attempted. They fail to build as expected. You just missed references to
them in the tools

I just posted a patch.

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

Re: Fwd: [rtems-bsp-builder] 2020-10-13 09:15:22: Profile(s): everything

[Sebastian Huber]

On 14/10/2020 17:27, Joel Sherrill wrote:



On Wed, Oct 14, 2020 at 10:20 AM Sebastian Huber 
> wrote:


On 14/10/2020 17:17, Joel Sherrill wrote:

> On Wed, Oct 14, 2020 at 9:45 AM Sebastian Huber
> mailto:sebastian.hu...@embedded-brains.de>
> >> wrote:
>
>     On 14/10/2020 15:35, Joel Sherrill wrote:
>
>     > BSP builder has 81 failures. :(
>     It tried to build BSPs which no longer exist.
>
>
> Well that is an easier thing to fix than my concern that it was
related to
> giving errors when a BSP does not support a feature. I suppose
that will
> show up when the bsp builder switches to waf.
>
> Can you patch ./config/rtems-bsps-tiers.ini to reflect what you
removed?
We should try try to reduce the redundancy in our data sets. Why
don't
we record the tier status in the BSP items?


That's a Chris discussion when the builder is switched to using waf.

Can you just fix this for now? It builds with autoconf and there is a 
ticket for it.


I removed the BSPs a while ago also in the old build system:

https://git.rtems.org/rtems/log/?qt=range&q=70b803b5549016ab1ca12816e862217b8198e449

Why does this work?

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

[PATCH] rtems-bsps-tiers.ini: Delete removed PowerPC BSPs

[Joel Sherrill]

---
 config/rtems-bsps-tiers.ini | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/config/rtems-bsps-tiers.ini b/config/rtems-bsps-tiers.ini
index 34d7143..e918a6f 100644
--- a/config/rtems-bsps-tiers.ini
+++ b/config/rtems-bsps-tiers.ini
@@ -83,16 +83,15 @@ bsps_moxie = moxiesim
 bsps_nios2 = nios2_iss
 bsps_or1k = generic_or1k
 bsps_powerpc = beatnik,
-br_uid, brs5l, brs6l,
-dp2,
+br_uid,
 gwlcfm,
 haleakala,
 hsc_cm01,
 icecube,
 mcp750,
-mpc5566evb, mpc5566evb_spe, phycore_mpc5554,
-mpc5643l_dpu, mpc5643l_evb, mpc5668g,
-mpc5674f_ecu508_app, mpc5674f_ecu508_boot, mpc5674f_rsm6, mpc5674fevb, 
mpc5674fevb_spe,
+mpc5566evb, phycore_mpc5554,
+mpc5643l_evb, mpc5668g,
+mpc5674fevb,
 mpc8260ads,
 mpc8309som,
 mpc8313erdb,
-- 
2.24.3

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

Re: Fwd: [rtems-bsp-builder] 2020-10-13 09:15:22: Profile(s): everything

[Joel Sherrill]

On Wed, Oct 14, 2020 at 10:20 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 14/10/2020 17:17, Joel Sherrill wrote:
>
> > On Wed, Oct 14, 2020 at 9:45 AM Sebastian Huber
> >  > > wrote:
> >
> > On 14/10/2020 15:35, Joel Sherrill wrote:
> >
> > > BSP builder has 81 failures. :(
> > It tried to build BSPs which no longer exist.
> >
> >
> > Well that is an easier thing to fix than my concern that it was related
> to
> > giving errors when a BSP does not support a feature. I suppose that will
> > show up when the bsp builder switches to waf.
> >
> > Can you patch ./config/rtems-bsps-tiers.ini to reflect what you removed?
> We should try try to reduce the redundancy in our data sets. Why don't
> we record the tier status in the BSP items?
>

That's a Chris discussion when the builder is switched to using waf.

Can you just fix this for now? It builds with autoconf and there is a
ticket for it.

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

Re: Fwd: [rtems-bsp-builder] 2020-10-13 09:15:22: Profile(s): everything

[Sebastian Huber]

On 14/10/2020 17:17, Joel Sherrill wrote:

On Wed, Oct 14, 2020 at 9:45 AM Sebastian Huber 
> wrote:


On 14/10/2020 15:35, Joel Sherrill wrote:

> BSP builder has 81 failures. :(
It tried to build BSPs which no longer exist.


Well that is an easier thing to fix than my concern that it was related to
giving errors when a BSP does not support a feature. I suppose that will
show up when the bsp builder switches to waf.

Can you patch ./config/rtems-bsps-tiers.ini to reflect what you removed?
We should try try to reduce the redundancy in our data sets. Why don't 
we record the tier status in the BSP items?

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

Re: Fwd: [rtems-bsp-builder] 2020-10-13 09:15:22: Profile(s): everything

[Joel Sherrill]

On Wed, Oct 14, 2020 at 9:45 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 14/10/2020 15:35, Joel Sherrill wrote:
>
> > BSP builder has 81 failures. :(
> It tried to build BSPs which no longer exist.
>

Well that is an easier thing to fix than my concern that it was related to
giving errors when a BSP does not support a feature. I suppose that will
show up when the bsp builder switches to waf.

Can you patch ./config/rtems-bsps-tiers.ini to reflect what you removed?

Thanks.

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

Re: Fwd: [rtems-bsp-builder] 2020-10-13 09:15:22: Profile(s): everything

[Sebastian Huber]

On 14/10/2020 15:35, Joel Sherrill wrote:


BSP builder has 81 failures. :(

It tried to build BSPs which no longer exist.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Beagle SPI driver update

[Niteesh G. S.]

Hello,

First of all really sorry for the long delay, I am preparing for a robotics
competition
and it eats up most of my free time.

I finally got a logic analyzer and tested the SPI driver using it. And as
expected the
waveforms weren't right. To understand the device better and also to narrow
down
the problem I decided to write a simple polled driver. This driver can be
found
here
https://github.com/gs-niteesh/rtems/blob/8a75a2f5eb6b4eb852da9563b53b6c021463a8c7/bsps/arm/beagle/spi/simple-spi.c

Commit:
https://github.com/gs-niteesh/rtems/commit/8a75a2f5eb6b4eb852da9563b53b6c021463a8c7

This way I was able to get my first byte pushed but the succeeding bytes
time out. I
added the time out to make sure the pushed data is transferred before
getting overwritten
by the succeeding bytes. I also checked other drivers to make sure adding a
timeout is
necessary.
On removing the timeout I was able to get all my bytes pushed successfully.
This was verified using the logic analyzer. But on using the timeout I face
the mentioned
problem. I even tried decreasing the time but still, I face the same issue.
What could be causing the problem? Is there any other way to debug this?

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