Re: [PATCH] build: Add RTEMS_QUALIFIED

[Chris Johns]

On 6/11/2023 8:27 pm, Sebastian Huber wrote:
> On 06.11.23 01:14, Chris Johns wrote:
>> On 4/11/2023 1:31 am, Sebastian Huber wrote:
>>> On 03.11.23 15:08, Joel Sherrill wrote:
>>>> On Fri, Nov 3, 2023 at 3:58 AM Sebastian Huber
>>>> >>> <mailto:sebastian.hu...@embedded-brains.de>> wrote:
>>>>
>>>>  The goal of the RTEMS pre-qualification activity #3701 is a specified
>>>>  and validated subset of RTEMS.  For users of the pre-qualified subset 
>>>> of
>>>>  RTEMS it is important to not accidentally use not pre-qualified
>>>>  features.  One way to achieve this, is to build only the sources of 
>>>> the
>>>>  pre-qualified feature set. This customized build is enabled by the new
>>>>  build configuration option RTEMS_QUALIFIED.  If it is enabled, then 
>>>> only
>>>>  the pre-qualified subset of RTEMS is built and installed.
>>>>
>>>>  Building with RTEMS_QUALIFIED enable is currently only supported for 
>>>> the
>>>>  sparc/leon3 BSP family.  To support an RTEMS_QUALIFIED enabled build,
>>>>  changes in the CPU port and the BSP are required to only use features 
>>>> of
>>>>  the pre-qualified feature set.
>>>>
>>>>
>>>> Where is this documented?
>>> You mean a documentation of what needs to be done to create pre-qualified 
>>> BSP? I
>>> don't have it available yet. A good place to add this would be the how-to
>>> section in the RTEMS Software Engineering manual.
>>>
>>>> This is a very large patch. Are you assuming that if "not qualified" is
>>>> specified,
>>>> then it is in the qualified set?
>>> No, the logic is reversed. Everything is built by default. Some parts are 
>>> only
>>> enabled if RTEMS_QUALIFIED is not enabled, for example
>>> (spec/build/cpukit/objextra.yml):
>>>
>>> enabled-by:
>>>    not: RTEMS_QUALIFIED
>> It seems counter intuitive to me. I have no idea about qual work but my 
>> limited
>> understanding is everything is controlled yet this is the inverse of that and
>> anything anyone adds will by default be qualified?
> 
> The goal of this patch set is to place each source and header file of RTEMS 
> into
> two buckets, the pre-qualified bucket and the extra bucket. For two buckets 
> you
> need just one option with two values. In the current patch it is 
> RTEMS_QUALIFIED
> enabled or disabled.

I think we should also include in our discussion code contained within this
define (or defines) in shared files and how we manage changes to that code? In
an ideal world we would not have any need for conditional code however I
appreciate this may not be possible or initial achievable. We should however
look for approaches that try to avoid this and understand the constraints the
define brings. For example can I change code in a qualification or FACE define
when I do not know the standards they support?

> Since Joel already brought the FACE profile into play, an alternative could be
> this approach. Lets assume that we pre-qualified the FACE profile interfaces 
> of
> RTEMS. Use RTEMS_EVERYTHING for the I want everything profile. Use
> RTEMS_QUALIFIED for the pre-qualified profile. Use RTEMS_FACE_PROFILE for
> interfaces of the FACE profile.

If these are profiles I suggest RTEMS_PROFILE_EVERYTHING so RTEMS_PROFILE_.* can
find all profiles?

> The objects which are not pre-qualified would use this:
> 
> enabled-by: RTEMS_EVERYTHING

RTEMS_PROFILE_COMMERCIAL ?
RTEMS_PROFILE_INDUSTRIAL ?
RTEMS_PROFILE_RTEMS ?

... or something that reflects what we have always shipped? I borrowed those
labels from the way parts are classed. I tend to keep away from labels like new,
next, everything etc because they quickly date.

> 
> The objects which are pre-qualified would use this:
> 
> enabled-by:
> - RTEMS_EVERYTHING
> - RTEMS_QUALIFIED

Qualified to what? RTEMS_PROFILE_FACE defines something useful and concrete. Is
there an equivalent we could use for the work you have been doing?

I do not like the use of QUALIFIED as mentioned in my other post in this thread
because it implies something the open project should not and that is the code is
qualified. We will only provide pre-qualification data packs from the public
repos unless that has changed?

> The objects which are pre-qualified or in the FACE profile would use this:
> 
> enabled-by:
> - RTEMS_EVERYTHING
> - RTEMS_QUALIFIED
> - RTEMS_FACE_PROFILE

The addition of these defines explodes the builds and testing we need to perform
for each commit. We need to discuss this some more and look for boundaries that
could help limit the builds and testing for each profile.

> Of RTEMS_EVERYTHING, RTEMS_QUALIFIED, and RTEMS_FACE_PROFILE exactly one 
> option
> shall be enabled.

Yes this makes sense. Should a source file not in a profile be considered an 
error?

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

Re: [PATCH] build: Add RTEMS_QUALIFIED

[Chris Johns]

On 4/11/2023 1:31 am, Sebastian Huber wrote:
> On 03.11.23 15:08, Joel Sherrill wrote:
>>
>> On Fri, Nov 3, 2023 at 3:58 AM Sebastian Huber
>> > > wrote:
>>
>>     The goal of the RTEMS pre-qualification activity #3701 is a specified
>>     and validated subset of RTEMS.  For users of the pre-qualified subset of
>>     RTEMS it is important to not accidentally use not pre-qualified
>>     features.  One way to achieve this, is to build only the sources of the
>>     pre-qualified feature set. This customized build is enabled by the new
>>     build configuration option RTEMS_QUALIFIED.  If it is enabled, then only
>>     the pre-qualified subset of RTEMS is built and installed.
>>
>>     Building with RTEMS_QUALIFIED enable is currently only supported for the
>>     sparc/leon3 BSP family.  To support an RTEMS_QUALIFIED enabled build,
>>     changes in the CPU port and the BSP are required to only use features of
>>     the pre-qualified feature set.
>>
>>
>> Where is this documented?
> 
> You mean a documentation of what needs to be done to create pre-qualified 
> BSP? I
> don't have it available yet. A good place to add this would be the how-to
> section in the RTEMS Software Engineering manual.
> 
>>
>> This is a very large patch. Are you assuming that if "not qualified" is
>> specified,
>> then it is in the qualified set?
> 
> No, the logic is reversed. Everything is built by default. Some parts are only
> enabled if RTEMS_QUALIFIED is not enabled, for example
> (spec/build/cpukit/objextra.yml):
> 
> enabled-by:
>   not: RTEMS_QUALIFIED

It seems counter intuitive to me. I have no idea about qual work but my limited
understanding is everything is controlled yet this is the inverse of that and
anything anyone adds will by default be qualified?

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

Re: [PATCH] build: Add RTEMS_QUALIFIED

[Chris Johns]

On 3/11/2023 7:58 pm, Sebastian Huber wrote:
> diff --git a/cpukit/libtest/testbeginend.c b/cpukit/libtest/testbeginend.c
> index d520a45e62..45fd1343fa 100644
> --- a/cpukit/libtest/testbeginend.c
> +++ b/cpukit/libtest/testbeginend.c
> @@ -41,9 +41,15 @@
>  #endif
>  
>  #include 
> -#include 
>  #include 
>  
> +#if defined(RTEMS_QUALIFIED)
> +#include 
> +#include 
> +#else
> +#include 
> +#endif
> +
>  static const char* const test_state_strings[] =
>  {
>"EXPECTED_PASS",
> @@ -55,8 +61,14 @@ static const char* const test_state_strings[] =
>  
>  int rtems_test_begin(const char* name, const RTEMS_TEST_STATE state)
>  {
> +#if defined(RTEMS_QUALIFIED)
> +  return _IO_Printf(
> +rtems_put_char,
> +NULL,
> +#else
>return rtems_printf(
>  _test_printer,
> +#endif

I feel this change and approach needs more discussion publicly before we
determine the path the project follows. I would like to hear from Joel and 
Gedare?

As things stand ...

$ grep -r RTEMS_QUALIFIED .
$

This patch is introducing a new and rather broad category for a single define to
cover. Is the role and bounds of this define documented?

The define is past tense so it implies to me you need to have the code it covers
qualified somewhere before it can be merged? Is there a qualified build of RTEMS
publicly available I can download to compare?

In relation to the build system changes who decided which files are included and
which are not? What if one profile wants a file included and another does not?

Chris

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

Re: [PATCH] build: Let the get-integer action return None

[Chris Johns]

OK

Thanks
Chris

On 20/10/2023 10:16 pm, Sebastian Huber wrote:
> If used with the format-and-define action, this will result in an
> undefined define.
> ---
>  wscript | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/wscript b/wscript
> index c8481d4fde..595dc09efd 100755
> --- a/wscript
> +++ b/wscript
> @@ -1011,6 +1011,8 @@ class OptionItem(Item):
>  value = self.default_value(conf.env.ENABLE)
>  if value is None:
>  return value
> +if not value:
> +return None
>  try:
>  return eval(value)
>  except Exception as e:
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RBW] Re: Best way to arrange 2-cog manual shifting for "single speed" disc braked bicycle

[JohnS]

Hello Patrick,

Did anyone mention the All City Nature Box 853 SSCX disk brake bike? The 
rear disk brake mount is slotted to allow for alignment. No idea how easy 
that would be to adjust on the fly.

JohnS
[image: AllCityNatureBoyRearDropOut.jpg]

On Wednesday, October 18, 2023 at 12:17:34 PM UTC-4 RBW Owners Bunch wrote:

> The updated numbers now corroborate the qualitative claim that it won't 
> fit.  So, have you ordered your new Paul Disc WORD hub yet?
>
> Bill Lindsay
> El Cerrito, CA
>
> On Wednesday, October 18, 2023 at 7:50:30 AM UTC-7 Patrick Moore wrote:
>
>> Sorry, not 5 mm, the usual ~2mm Shimano spacer. Actually I think it's a 9 
>> speed spacer.
>>
>> On Tue, Oct 17, 2023 at 11:09 PM Bill Lindsay  wrote:
>>
>>> Patrick Moore claims to have a 5mm spacer + a 3/32" cog on a hub.  
>>> Assuming his story is accurate, that's a stack up of 7.38mm
>>>
>>> Wesley said "put another cog on there", to which Patrick Moore said 
>>> there would be no room for the chain.  
>>>
>>> 8-speed Shimano cassette cogs are 1.8mm thick, and the right spacer 
>>> between Shimano 8-speed cassette cogs is 3.0mm in thickness.  So, if your 
>>> stack up was COG+SPACER+COG then that would add up to 1.8mm + 3.0mm + 1.8mm 
>>> = 6.6mm.  That's a shorter stack up than what you have, and would have a 
>>> spacing between cogs that you know works.  What's the problem?  Would the 
>>> "inner" cog run up against the spokes or something?  It sounds to me like 
>>> you have ample room to try two cogs plus a spacer and see what you think.  
>>> You frequently describe your box full of all generations of 7, 8, 9, 10 
>>> speed cassette cogs and spacers.  Give it a go!
>>>
>>> Bill Lindsay
>>> El Cerrito, CA
>>>
>>> On Tuesday, October 17, 2023 at 4:09:12 PM UTC-7 Patrick Moore wrote:
>>>
>>>> I could indeed get a second cog into the place of the spacer but  
>>>> there'd be no room for the chain.
>>>>
>>>> No, good thought, but you'd need 5 mm more of space for: big cog + 
>>>> spacer + small cog; then lockring. As it is, the big cog and small cog 
>>>> would have to butt up against each other; no room for chain.
>>>>
>>>> On Tue, Oct 17, 2023 at 4:18 PM Wesley  wrote:
>>>>
>>>>> Ah. Can you not remove the 5mm spacer? That should be enough room for 
>>>>> a second cog, IMO.
>>>>> -W
>>>>>
>>>>> On Tuesday, October 17, 2023 at 3:02:19 PM UTC-7 Patrick Moore wrote:
>>>>>
>>>>>> Not mine, said by seller to be a 2012 model. I have a 5 mm spacer, 
>>>>>> then the 3/32" cog, and then the lockring threads.
>>>>>>
>>>>>> Good to know that the caliper (again, list, almost vertically atop 
>>>>>> the rotor at top dead center, but actually offset a cm or two forward) 
>>>>>> can 
>>>>>> accommodate a bit of fore/aft axle movement.
>>>>>>
>>>>>> On Tue, Oct 17, 2023 at 3:56 PM Wesley  wrote:
>>>>>>
>>>>>>> Hey Patrick,
>>>>>>> My recollection of my monocog was that the freehub had room for 
>>>>>>> three cogs. I think there were spacers on the hub that covered up most 
>>>>>>> of 
>>>>>>> the free hub - remove the locking and you can do adjust the spacers as 
>>>>>>> necessary. If yours is the same, then you could just keep that wheel 
>>>>>>> and 
>>>>>>> put the additional cogs onto it.
>>>>>>>
>>>>>>> And, in case I wasn't clear in my earlier response, I think there is 
>>>>>>> plenty of adjustment room in the disc brakes to accommodate the rear 
>>>>>>> axle 
>>>>>>> being adjusted in the dropout.
>>>>>>> -Wes
>>>>>>>
>>>>>>> On Tuesday, October 17, 2023 at 10:44:19 AM UTC-7 Patrick Moore 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> That's interesting, and after blundering into a few search result 
>>>>>>>> pages about money markets and currency conversion I got:
>>>>>>>>
>>>>>>>> http://www.monebikes.com/read-me/
>>>>>>>>
>>>>>>>> But he says nothing about adjustable chainstays,
>>>

Re: rtems6 master on darwin-x86_64 fails building: arm-rtems6-gcc-814ec21-newlib-fbc5496-x86_64-apple-darwin22.6.0-1

[Chris Johns]

On 18/10/2023 8:48 pm, Sebastian Huber wrote:
> On 18.10.23 12:29, Heinz Junkes wrote:
>> unfortunately also with the GCC 13.2 configuration still the same error:
>> nclude -g -O2 -mthumb -O2
>> -I../../../../gcc-13.2.0/libgcc/../newlib/libc/sys/rtems/include -g -O2
>> -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings
>> -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
>> -isystem ./include -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc
>> -fno-stack-protector -Dinhibit_libc -fno-inline -I. -I. -I../../.././gcc
>> -I../../../../gcc-13.2.0/libgcc -I../../../../gcc-13.2.0/libgcc/.
>> -I../../../../gcc-13.2.0/libgcc/../gcc
>> -I../../../../gcc-13.2.0/libgcc/../include -DHAVE_CC_TLS -o _divtc3.o -MT
>> _divtc3.o -MD -MP -MF _divtc3.dep -DL_divtc3 -c
>> ../../../../gcc-13.2.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
>> ../../../../gcc-13.2.0/libgcc/libgcc2.c: In function '__divdc3':
>> ../../../../gcc-13.2.0/libgcc/libgcc2.c:2063:7: internal compiler error:
>> Segmentation fault: 11 2063 | if (FABS (d) >= RBIG) | ^~ Please submit a full
>> bug report, with preprocessed source (by using -freport-bug). See
>>  for instructions. make[4]: *** [_divdc3.o] Error 
>> 1
> 
> Ok, great. At least it is consistent. Maybe GCC 10 works.
> 
> This bug should be reported to the GCC project.

I have just built the RSB master on a Sonoma (14.0) MacBook M2 Pro 

(r-py3) chris@weka rtems %  /Users/chris/development/rtems/6/bin/arm-rtems6-gcc
--version
arm-rtems6-gcc (GCC) 12.3.1 20231012 (RTEMS 6, RSB
633023de6517998ee3b84e7ed172b1c5f2bf502b, Newlib fbc5496)
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I am only using Xocde tools and related command line bits and pieces and a
python.org installed Python with a virtual env.

I do not have an Intel Mac with me to test on that. I will when I return home.

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

Re: libdl documentation?

[Chris Johns]

On 18/10/2023 7:21 pm, Sebastian Huber wrote:
> I tried to get a bit more familiar with the libdl. Is there some documentation
> available? I tried the user manual, but I see only a work in progress page:
> 
> https://docs.rtems.org/branches/master/user/tools/linker.html

There is this https://git.rtems.org/rtems-tools/tree/linkers/main-page.cpp which
has not been moved across.

> For example, I can use dlopen() to load an object file (ELF). For what do I 
> need
> RAP files?

RAP requires use of the linker. It has some issues that need to be addressed to
be at the same level as the ELF loader. For example I have not looked into TLS
and there is the failure of the tests in the testsuite (dl06).

RAP is an intermediate format where a lot of the required linking can be done on
the host and the file set you need for the target can be collected. This lets
you have a golden base image and a single loadable application.

> Can I load also archives? It seems this can be done through configuration 
> files.
> Are there API calls to do this?

Currently there is no API call available. One could be added if you feel it is
required. I decided you need a valid file system for loading to work so a
configuration file was the simplest method.

Loading from archives is done via the /etc/libdl.conf file:

https://git.rtems.org/rtems/tree/testsuites/libtests/dl10/etc/libdl.conf

The file can be updated at runtime and it is checked on each load for changes.

Note, I did some initial analysis for this at the time the change was made and
if you use runlib on the archives before loading the symbol table for libraries
like libc is manageable.

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

Re: [tools 1/2] linker: Fix typo in symbol table generator

[Chris Johns]

OK

Thanks
Chris

On 16/10/2023 9:47 pm, Sebastian Huber wrote:
> Updates #4920.
> ---
>  linkers/rtems-syms.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/linkers/rtems-syms.cpp b/linkers/rtems-syms.cpp
> index c72ee55..f6b207f 100644
> --- a/linkers/rtems-syms.cpp
> +++ b/linkers/rtems-syms.cpp
> @@ -142,7 +142,7 @@ static const char* c_rtl_call_body[] =
>"{",
>"  rtems_rtl_base_sym_global_add (__rtl_base_globals[0],",
>" rtems__rtl_base_globals_size[0],",
> -  " NULL",
> +  " NULL,",
>" 0);",
>"}",
>0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Windows 11 - Compiling toolchain (5.3 and 6)

[Chris Johns]

On 13/10/2023 1:21 am, Sebastian Huber wrote:
> some of our customers use WSL2 with Ubuntu, they reported no issues with the 
> RSB
> build of RTEMS 6.

I think something in recent Linux versions is causing problems with RTEMS 5.

> If you want to build mingw tools, then I would build them on Linux with a 
> mingw
> cross compiler.

If you do this make sure you collect and handle the DLLs referenced in the
build. Not doing this can leave you with some hidden surprises. The Linux distro
packages and the Windows native DLL may not align.

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

Re: [RSB 1/3] 6/7: Update Newlib

[Chris Johns]

Ok to all patches in the series. Thanks for newlib changes for ARM, they will be
nice to use.

Chris

On 10/10/2023 3:58 am, Sebastian Huber wrote:
> Pick up latest changes from ARM/optimized-routines.
> 
> Close 4510.
> ---
>  rtems/config/tools/rtems-gcc-10-newlib-head.cfg   | 4 ++--
>  rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg | 4 ++--
>  rtems/config/tools/rtems-gcc-12-newlib-head.cfg   | 4 ++--
>  rtems/config/tools/rtems-gcc-13-newlib-head.cfg   | 4 ++--
>  rtems/config/tools/rtems-gcc-head-newlib-head.cfg | 4 ++--
>  5 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> index 1cbb301..06524d4 100644
> --- a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> @@ -17,12 +17,12 @@
>  %patch add newlib -p1 
> https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
>  %hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch 
> 7ca237eabfd5b382713186e1fc290dfc999a353315795ecb8dd0d22fcd1ab7f5bf31f4329954adab91ad04c100dcac0e86d406fdbce8f82cf9dc23842c88caf6
>  
> -%define newlib_version a021448
> +%define newlib_version fe5886a
>  %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 \
> -  
> YiC/BsmRpq8XsN1hx4s2Rvcwys/4DRFB3F6vvd+lEMJWXXpt3knXT4BBZkP11bkEcpDFCV9EaOlTT3HA7C3pCg==
> +  
> w7yxW6iO3ademyF5TTj0pe9zt6WCsYa46+MOY/Rter2loQjJDEnj2AE0YxUhV4fGG+mE/Df3igJH3rzuQYeXwQ==
>  
>  %define with_threads 1
>  %define with_plugin 0
> diff --git a/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> index 99e2a21..e457b75 100644
> --- a/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> @@ -20,12 +20,12 @@
>  %patch add newlib -p1 
> https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
>  %hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch 
> 7ca237eabfd5b382713186e1fc290dfc999a353315795ecb8dd0d22fcd1ab7f5bf31f4329954adab91ad04c100dcac0e86d406fdbce8f82cf9dc23842c88caf6
>  
> -%define newlib_version a021448
> +%define newlib_version fe5886a
>  %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 \
> -  
> YiC/BsmRpq8XsN1hx4s2Rvcwys/4DRFB3F6vvd+lEMJWXXpt3knXT4BBZkP11bkEcpDFCV9EaOlTT3HA7C3pCg==
> +  
> w7yxW6iO3ademyF5TTj0pe9zt6WCsYa46+MOY/Rter2loQjJDEnj2AE0YxUhV4fGG+mE/Df3igJH3rzuQYeXwQ==
>  
>  %define with_threads 1
>  %define with_plugin 0
> diff --git a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> index 04616eb..75dfcb2 100644
> --- a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> @@ -38,13 +38,13 @@
>  
> KEmxHjYOqY4LTXCMZ3I60tbHusbR5GlnP0CLARHPAnhCnovDj9K3U43C1bsMxDDGRqD6fwtrEFoEgqVFX63IuQ==
>  # Comment above related to #4657 and patches ends here
>  
> -%define newlib_version a021448
> +%define newlib_version fe5886a
>  %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 \
> -  
> YiC/BsmRpq8XsN1hx4s2Rvcwys/4DRFB3F6vvd+lEMJWXXpt3knXT4BBZkP11bkEcpDFCV9EaOlTT3HA7C3pCg==
> +  
> w7yxW6iO3ademyF5TTj0pe9zt6WCsYa46+MOY/Rter2loQjJDEnj2AE0YxUhV4fGG+mE/Df3igJH3rzuQYeXwQ==
>  
>  %define with_threads 1
>  %define with_plugin 0
> diff --git a/rtems/config/tools/rtems-gcc-13-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
> index 03b99da..7f7e3e2 100644
> --- a/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-13-newlib-head.cfg
> @@ -8,12 +8,12 @@
>  %hash sha512 %{gcc_expand_name}.tar.gz \
>
> 7uw8yZWdjboqa1k1KPJTsOutVN66EEdrQ+ylaxZCFIwOihRUrct1loZ2Y3LXCYPG9JFso0i+22XEIlx3WMlrTQ==
>  
> -%define newlib_version a021448
> +%define newlib_version fe5886a
>  %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 

Re: rtems6 sb-set-builder gdb enable-tui?

[Chris Johns]

On 7 Oct 2023, at 6:36 pm, Shiro  wrote:Hello, I'd like to build RTEMS' tools from git (rtems 6), but I'd like gdb configured with "--enable-tui".  Any advice on where/how to tweak the scripts would be appreciated.Edit the configure command line here …gdb-common-1.cfg « config « source-builder - rtems-source-builder - RTEMS tools and packages source builder.git.rtems.orgThis could be enabled by default. Chris___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-source-builder] qemu: Adjust cgem interrupt patch

[Chris Johns]

OK

Thanks
Chris

On 7/10/2023 6:05 am, Kinsey Moore wrote:
> This patch is being moved to the 5.2.0-1 QEMU configuration because the
> Xilinx QEMU build uses the 5-1 configuration and this patch does not
> apply to Xilinx's modified tree. This also adds a new patch that applies
> correctly to Xilinx's modified QEMU tree.
> 
> Updates #4919
> ---
>  bare/config/devel/qemu-5.2.0-1.cfg  | 7 +++
>  bare/config/devel/qemu-xilinx-v2020.2-1.cfg | 7 +++
>  source-builder/config/qemu-5-1.cfg  | 4 
>  3 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/bare/config/devel/qemu-5.2.0-1.cfg 
> b/bare/config/devel/qemu-5.2.0-1.cfg
> index 1c1cfeb..3c8186b 100644
> --- a/bare/config/devel/qemu-5.2.0-1.cfg
> +++ b/bare/config/devel/qemu-5.2.0-1.cfg
> @@ -36,6 +36,13 @@
>  %hash sha512 qemu-5.2.0-leon3.patch \
> 
> cQju/ja5SAM+gsXEkzSteeR+7PjG9g2w+yUb4kg1eZoOSm2MmZDjA/auINVdRax8wgtIEWnzq5/hdY7/THnowg==
>  
> +#
> +# Patch to fix cgem priority queue interrupt functionality issue
> +#
> +%patch add qemu --rsb-file=cgem_zynqmp_versal.patch -p1 
> https://devel.rtems.org/raw-attachment/ticket/4919/0001-hw-arm-xlnx-Connect-secondary-CGEM-IRQs.patch
> +%hash sha512 cgem_zynqmp_versal.patch \
> +  
> XIAGD29Qa4uaEKij3TYh1HJUJb7r9ZjZXl19t3Vk+8uleG2O7M1xgqmeA6zoQq+GCrcMRoJxqV4kniRapLgZRQ==
> +
>  #
>  # The Qemu build instructions. We use 5.x.x Release 1.
>  #
> diff --git a/bare/config/devel/qemu-xilinx-v2020.2-1.cfg 
> b/bare/config/devel/qemu-xilinx-v2020.2-1.cfg
> index 2c3fb94..ca70ebd 100644
> --- a/bare/config/devel/qemu-xilinx-v2020.2-1.cfg
> +++ b/bare/config/devel/qemu-xilinx-v2020.2-1.cfg
> @@ -17,6 +17,13 @@
>  #
>  %source set qemu 
> git://github.com/Xilinx/qemu.git?protocol=https?checkout=%{qemu_version}?submodule=dtc?submodule=slirp?submodule=ui/keycodemapdb?submodule=tests/fp/berkeley-softfloat-3?submodule=tests/fp/berkeley-testfloat-3
>  
> +#
> +# Patch to fix cgem priority queue interrupt functionality issue
> +#
> +%patch add qemu --rsb-file=xlnx_cgem_zynqmp_versal.patch -p1 
> https://devel.rtems.org/raw-attachment/ticket/4919/0001-hw-arm-xlnx-Connect-secondary-CGEM-IRQs-xlnx.patch
> +%hash sha512 xlnx_cgem_zynqmp_versal.patch \
> +  
> tGjJn7o8/fQwdC0sgsYmPW6bqDzMkwhKRqBwuuy8sdEKivDj7uGISMj7p8Iwy9fkHiO3Dd3feno+iz5fHYGBkA==
> +
>  #
>  # The Qemu build instructions. We use 5.x.x Release 1.
>  #
> diff --git a/source-builder/config/qemu-5-1.cfg 
> b/source-builder/config/qemu-5-1.cfg
> index 89d203c..7ca58b8 100644
> --- a/source-builder/config/qemu-5-1.cfg
> +++ b/source-builder/config/qemu-5-1.cfg
> @@ -7,7 +7,3 @@
>  %define qemu_disables --disable-nettle
>  
>  %include %{_configdir}/qemu-common-2.cfg
> -
> -%patch add qemu --rsb-file=cgem_zynqmp_versal.patch -p1 
> https://devel.rtems.org/raw-attachment/ticket/4919/0001-hw-arm-xlnx-Connect-secondary-CGEM-IRQs.patch
> -%hash sha512 cgem_zynqmp_versal.patch \
> -  
> XIAGD29Qa4uaEKij3TYh1HJUJb7r9ZjZXl19t3Vk+8uleG2O7M1xgqmeA6zoQq+GCrcMRoJxqV4kniRapLgZRQ==
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs] user/exe: Add MicroBlaze to Dynamic Loader architecture list

[Chris Johns]

OK

Chris

On 6/10/2023 5:40 am, Alex White wrote:
> ---
>  user/exe/loader.rst | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/user/exe/loader.rst b/user/exe/loader.rst
> index be2e78e..fdc54a8 100644
> --- a/user/exe/loader.rst
> +++ b/user/exe/loader.rst
> @@ -844,6 +844,7 @@ The following architectures are supported:
>   - Intel x86 (i386)
>   - LM32
>   - M68K
> + - MicroBlaze
>   - MIPS
>   - Moxie
>   - PowerPC
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

External document links (was Re: Add Formal Verification chapter v4)

[Chris Johns]

On 6/10/2023 1:02 am, Gedare Bloom wrote:
> On Fri, Sep 22, 2023 at 4:50 AM andrew.butterfi...@scss.tcd.ie
>  wrote:
>> Also, I'm not sure the best way to refer to a sub-section of another document
>> I used something like (See Host Tools in the RTEMS User Manual)
>> I guessed the URL might be less robust
> Yes this is basically correct. We don't want explicit links between
> documents. It's a bit challenging at the moment to validate
> cross-document references and we don't have a great solution or
> standard approach for how to do it.

There are a few issues having external links between our documents:

1. The links reference the `master` branch so branching for a release breaks the
documentation in a releases and that is something we cannot have.

2. PDF documents do not know how to link to the other PDF documents. A PDF is
not web resource.

3. Localised builds for internal use, for example on a disk or local server
still link externally back to `master`. If you need to work on a site that does
not have internet access the documentation breaks.

With the current documentation structure these issue are beyond the scope for us
to deal with in sphinx. We develop an RTOS.

A single book of all our documents would resolve this but that would slow the
documentation builds down unless someone knows how to build partial pieces.

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

Re: [PATCH] Avoid StopIteration exception for non-rtems .pc

[Chris Johns]

Hi Martin,

Thanks for posting the patch. I have pushed it. I have pushed an update after
running the change through yapf. I forgot to do that before pushing.

I will also add a new function to the rtems module as a separate patch:

+def arch_bsp(ctx):
+""" Return the list of arch/bsps we are building."""
+return ctx.env.ARCH_BSP
+
+

I think it would be good to update all the submodules.

On 5/10/2023 11:40 pm, Martin Erik Werner wrote:
> _arch_from_arch_bsp() and _bsp_from_arch_bsp() has overly optimistic
> assumptions that the argument must contain a '-'-separated field which
> starts with "rtems". These functions are intended to find the target
> triplet or the bsp parts of strings like "sparc-gaisler-rtems5-leon3"
> and "arm-rtems6-xilinx_zynq_zc702"

Yes the interface around arch/bsp is a bit average and I have wondered about a
change but I think the interface is now set and I think it is too late to 
change.

> But _find_installed_arch_bsps() may call _arch_from_arch_bsp() with the
> name (without file extension) of any file which ends with ".pc",
> including for example "expat". This triggers a StopIteration exception
> when trying to find the next field after the "rtems" field, since no
> "rtems" field exists to start with.
> 
> Rework these function to remove the preconditions, so that they return
> None if no "rtems" field exist or if no field exists before or after the
> "rtems" field.

Nice.

> It could be argued. based on their name, that calling these functions
> with something that is not a triplet-bsp string is incorrect to start
> with, but attempting to address that is not done here.

Yes I agree and I also think we need to accept the string in this case.

Chris

> ---
> 
> This should fix the issue discovered by David Siddons and Frank Kühndel
> described in the "build failed" thread from 2023-07-23 in the
> rtems-users mailing list with message-id:
> <8e6c2841-ae9e-aacf-de84-e6340d204...@embedded-brains.de>
> 
> I have tested this fix when compiling the simple quickstart application
> for the sparc-gaisler-rtems5-leon3 and arm-rtems6-xilinx_zynq_zc702
> targets, but I have not verified execution of the build results, this is
> probably the amount of testing that I will be able to perform at the
> moment.
> 
>  rtems.py | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/rtems.py b/rtems.py
> index c65a7d2..a29d281 100644
> --- a/rtems.py
> +++ b/rtems.py
> @@ -859,15 +859,17 @@ def _check_arch_bsps(req, config, path, archs, version):
>  
>  def _arch_from_arch_bsp(arch_bsp):
>  fields = arch_bsp.split('-')
> -rtems_field_index = next(i for i, field in enumerate(fields) if 
> field.startswith('rtems'))
> -return '-'.join(fields[:(rtems_field_index + 1)])
> -
> +for i, field in enumerate(fields):
> +if field.startswith('rtems') and fields[:(i + 1)] is not None:
> +return '-'.join(fields[:(i + 1)])
> +return None
>  
>  def _bsp_from_arch_bsp(arch_bsp):
>  fields = arch_bsp.split('-')
> -rtems_field_index = next(i for i, field in enumerate(fields) if 
> field.startswith('rtems'))
> -return '-'.join(fields[(rtems_field_index + 1):])
> -
> +for i, field in enumerate(fields):
> +if field.startswith('rtems') and fields[(i + 1):] is not None:
> +return '-'.join(fields[(i + 1):])
> +return None
>  
>  def _pkgconfig_path(path):
>  return os.path.join(path, 'lib', 'pkgconfig')
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] tests: Add header for RTEMS test printer

[Chris Johns]

On 5/10/2023 1:29 am, Heinz Junkes wrote:
> Leads to problems compiling legacy-stack:

Thanks for the report. I have posted a patch to clean up the net-legacy stack.

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

Re: Xilinx MPSoC, programmable logic download

[Chris Johns]

On 5/10/2023 4:56 am, Kinsey Moore wrote:
> If you need dynamic reconfiguration, I believe Chris Johns has been doing some
> work in that vein: https://github.com/kiwichris/rtems-xilinx-xrt
> <https://github.com/kiwichris/rtems-xilinx-xrt>

Yes. This works on the Versal. I have not tested it on the ZynqMP. The rtems/pm
code has a shell command you can use to load bitfiles via the SMC. You need
Xilinx's build of ARM's trusted firmware resident in memory to work.

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

Re: [PATCH rtems] fat_fat_operations.c: Fix incorrect indentation

[Chris Johns]

OK

Chris

On 4/10/2023 2:29 am, Joel Sherrill wrote:
> ---
>  cpukit/libfs/src/dosfs/fat_fat_operations.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/cpukit/libfs/src/dosfs/fat_fat_operations.c 
> b/cpukit/libfs/src/dosfs/fat_fat_operations.c
> index 24a408f9c7..1d94beb26a 100644
> --- a/cpukit/libfs/src/dosfs/fat_fat_operations.c
> +++ b/cpukit/libfs/src/dosfs/fat_fat_operations.c
> @@ -203,9 +203,9 @@ fat_free_fat_clusters_chain(
>  cur_cln = next_cln;
>  }
>  
> -fs_info->vol.next_cl = chain;
> -if (fs_info->vol.free_cls != FAT_UNDEFINED_VALUE)
> -fs_info->vol.free_cls += freed_cls_cnt;
> +fs_info->vol.next_cl = chain;
> +if (fs_info->vol.free_cls != FAT_UNDEFINED_VALUE)
> +fs_info->vol.free_cls += freed_cls_cnt;
>  
>  fat_buf_release(fs_info);
>  if (rc1 != RC_OK)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[RBW] Re: Perfection from the last newsletter

[JohnS]

I was impressed by that bike as well. Looks like it's ready to go anywhere.

JohnS


On Monday, October 2, 2023 at 10:40:12 AM UTC-4 jamin orrall wrote:

> The bike belongs to Masa, more photos and info here:
>
> https://www.rivbike.com/blogs/news/james-japan-pics
>
> On Monday, October 2, 2023 at 10:36:41 AM UTC-4 jamin orrall wrote:
>
>> I love this build so much, Rivendell perfection in my book.  Posting here 
>> in case anyone missed it! 
>>
>> [image: riv all rounder.jpeg]
>>
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/585c3fbb-fef6-4b4b-b1ed-c5f80fcc5816n%40googlegroups.com.

[RBW] Re: Wheel Builder

[JohnS]

Josh,

Your Atlantis looks great with the new wheels. I'm a big fan of WI hubs (I 
have 3 wheelsets with them now). I think you'll be very happy with them. 
The rear hub clicking sound doesn't bother to me either.

JohnS

On Thursday, September 28, 2023 at 8:09:59 PM UTC-4 Josh C wrote:

> Reporting back on the Peter White built cliffhanger set. They look great 
> and the White Ind rear hub sounds great, very quiet IMO. Doesn’t sound any 
> louder than a shimano to be honest. I guess it may get louder with time, we 
> will see
>
> [image: IMG_0669.jpeg][image: IMG_0668.jpeg]
>
> On Friday, September 8, 2023 at 1:06:43 PM UTC-4 Fullylugged wrote:
>
>> Velocity USA builds their wheels in Grand Rapids MI.  I am very happy 
>> with the set I ride on.
>>
>> On Friday, August 11, 2023 at 8:13:50 AM UTC-5 Josh C wrote:
>>
>>> I could use a recommendation for a good wheel builder. I've used 
>>> prowheelbuilder.com in the past and have no complaints. Not sure how I 
>>> landed on them. Just curious if there is another business that I should be 
>>> looking into? I'm located in Indianapolis as well, and would prefer sending 
>>> business to a local or at least midwest company if possible.  
>>>
>>> I'm looking for a set of 700c wheels for my Atlantis. I'm thinking I'll 
>>> do velocity cliffhangers with a SON up front and a nice rear hub. The rear 
>>> is not yet totally decided as I like quiet hubs but there are not many 
>>> options in rim brake, 36-40h hubs these days. I've got an onyx silent hub 
>>> on my crust and love it but they only go up to 32h and I'd prefer 36 or 40 
>>> as I'm a big dude. Which is why I'm thinking about a white industry (loud 
>>> as they come) rear hub in 36 or 40h. 
>>>
>>> Anyway. I'd like to hear about your preferred wheel builders. 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/4ff555f3-c9f2-44b2-b7bb-7f25c590f1f2n%40googlegroups.com.

Re: rsb gdb build on aarch64 (OS-X M2)

[Chris Johns]

On 28/9/2023 6:28 am, Heinz Junkes wrote:
> It was a mess with homebrew and python versions on my system.
> Rsb works well ;-)

Thanks for following this up and good to know. Have you managed to use the gdb
executable? A user has reported on discord the ARM gdb crashing however I do not
see that happening with my build.

I build on my M2 using a python.org install, a virtual environment and X code. I
welcome users using homebrew or macports but I cannot directly support the
efforts because of the amount of work to that would be more than I can handle.

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

Re: [RBW] Re: PSA: New MKS Pretzel pedals coming out next month

[JohnS]

Must be a MKS thing, pretzel, taco... what's next the nacho pedals???

John


On Tuesday, September 26, 2023 at 12:35:10 AM UTC-4 Luke Hendrickson wrote:

> I’ve seen it in-person and … I’ll pass. 
>
> On Monday, September 25, 2023 at 3:50:19 PM UTC-7 krhe...@gmail.com wrote:
>
>> @Bill
>>
>> Thank you for your information. 
>>
>> Kim Hetzel.
>>
>> On Mon, Sep 25, 2023, 2:36 PM Bill Lindsay  wrote:
>>
>>> "Curious as to whether or not they would accept the cage extension that 
>>> currently RBW sells."
>>>
>>> The Pretzel pedal has the cage extension BUILT IN.  You won't need the 
>>> cage extension with the Pretzel.  It's already in there.  
>>>
>>> Bill Lindsay
>>> El Cerrito, CA
>>>
>>> On Monday, September 25, 2023 at 9:45:51 AM UTC-7 krhe...@gmail.com 
>>> wrote:
>>>
>>> I came across  these new MKS Pretzel pedals, while looking for something 
>>> else on the MKS website. They definitely look like they a twist to them, 
>>> like a pretzel.  Curious as to whether or not they would accept the cage 
>>> extension that currently RBW sells.  
>>>
>>> https://www.mkspedal.com/?q=en/news/node/453
>>>
>>> Kim Hetzel.
>>>
>>> -- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "RBW Owners Bunch" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/rbw-owners-bunch/s5cUc3CbjLU/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to 
>>> rbw-owners-bun...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/rbw-owners-bunch/a0c0b38a-af00-4ccf-bab3-e38373e62328n%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/6dc81d1c-c52f-4239-a46c-cbd79ba1ecfdn%40googlegroups.com.

Re: [PATCH 1/1] trace: build with c++17 if building against llvm 16+

[Chris Johns]

On 22/9/2023 2:47 pm, Sebastian Huber wrote:
> On 22.09.23 04:36, Joel Sherrill wrote:
>> Are we doing something that particularly requires C++17? AFAIK we haven't
>> needed it yet and why wouldn't it also be needed with gcc? If the default on
>> recent gcc versions is that, ok but we should be precise in case an older gcc
>> with a different default is used.
> 
> The problem is not that we use features of a particular standard. It is that
> LLVM requires a particular standard for the header files it ships and that we 
> use.
> 
> I already fixed this some time ago:
> 
> https://lists.rtems.org/pipermail/devel/2023-May/075269.html
> 
> However, Chris didn't like the change.

The issue was not specially about that change but the tested hosts. I am fine if
the referenced change builds on a recent MacOS and FreeBSD 13. I am still none
the wiser?

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

Re: [PATCH] tests: Add header for RTEMS test printer

[Chris Johns]

Looks good

Thanks
Chris

On 22/9/2023 10:40 pm, Sebastian Huber wrote:
> The  header file is required for every RTEMS test
> program.  Move the RTEMS test printer support to a dedicated header file
> .  This removes an unnecessary dependency to the
> RTEMS printer support in .
> 
> Tests using the RTEMS Testing Framework no longer depend on the
> .
> ---
>  cpukit/include/rtems/test-info.h  | 18 +
>  cpukit/include/rtems/test-printer.h   | 69 +++
>  cpukit/libtest/testbeginend.c |  1 +
>  cpukit/libtest/testwrappers.c |  2 +-
>  spec/build/cpukit/librtemstest.yml|  1 +
>  testsuites/benchmarks/linpack/linpack-pc.c|  2 +-
>  testsuites/benchmarks/whetstone/whetstone.c   |  2 +-
>  testsuites/fstests/tftpfs/init.c  |  1 +
>  testsuites/libtests/dl01/dl01-o1.c|  2 +-
>  testsuites/libtests/dl02/dl02-o1.c|  2 +-
>  testsuites/libtests/dl02/dl02-o2.c|  2 +-
>  testsuites/libtests/dl05/dl05-o5.cc   |  2 +-
>  testsuites/libtests/dl06/dl06-o1.c|  2 +-
>  testsuites/libtests/dl06/dl06-o2.c|  2 +-
>  testsuites/libtests/dl07/dl07-o1.c|  2 +-
>  testsuites/libtests/dl07/dl07-o2.c|  2 +-
>  testsuites/libtests/dl07/dl07-o3.c|  2 +-
>  testsuites/libtests/dl07/dl07-o4.c|  2 +-
>  testsuites/libtests/dl07/dl07-o5.c|  2 +-
>  testsuites/libtests/dl08/dl08-o1.c|  2 +-
>  testsuites/libtests/dl08/dl08-o2.c|  2 +-
>  testsuites/libtests/dl08/dl08-o3.c|  2 +-
>  testsuites/libtests/dl08/dl08-o4.c|  2 +-
>  testsuites/libtests/dl08/dl08-o5.c|  2 +-
>  .../dl08/dl08-o6-123456789-123456789.c|  2 +-
>  testsuites/libtests/dl09/dl09-o1.c|  2 +-
>  testsuites/libtests/dl09/dl09-o2.c|  2 +-
>  testsuites/libtests/dl09/dl09-o3.c|  2 +-
>  testsuites/libtests/dl09/dl09-o4.c|  2 +-
>  testsuites/libtests/dl09/dl09-o5.c|  2 +-
>  testsuites/libtests/dl10/dl10-o1.c|  2 +-
>  testsuites/libtests/dl10/dl10-o2.c|  2 +-
>  testsuites/libtests/dl10/dl10-o3.c|  2 +-
>  testsuites/libtests/dl10/dl10-o4.c|  2 +-
>  testsuites/libtests/dl10/dl10-o5.c|  2 +-
>  testsuites/libtests/dl10/dl10-o6.c|  1 -
>  testsuites/libtests/dl11/dl11-o1.c|  1 -
>  testsuites/support/include/tmacros.h  |  1 +
>  38 files changed, 105 insertions(+), 48 deletions(-)
>  create mode 100644 cpukit/include/rtems/test-printer.h
> 
> diff --git a/cpukit/include/rtems/test-info.h 
> b/cpukit/include/rtems/test-info.h
> index c1b41ccc6e..a5c00c423a 100644
> --- a/cpukit/include/rtems/test-info.h
> +++ b/cpukit/include/rtems/test-info.h
> @@ -3,10 +3,9 @@
>  /**
>   * @file
>   *
> - * @ingroup RTEMSTestFramework
> + * @ingroup RTEMSTest
>   *
> - * @brief This header file provides interfaces of the
> - *   RTEMS Test Framework.
> + * @brief This header file provides interfaces of the RTEMS Test Support.
>   */
>  
>  /*
> @@ -38,7 +37,6 @@
>  #define _RTEMS_TEST_H
>  
>  #include 
> -#include 
>  #include 
>  #include 
>  
> @@ -61,11 +59,6 @@ extern "C" {
>   */
>  extern const char rtems_test_name[];
>  
> -/**
> - * @brief Each test must define a printer.
> - */
> -extern rtems_printer rtems_test_printer;
> -
>  /**
>   * @brief Fatal extension for tests.
>   */
> @@ -134,13 +127,6 @@ int rtems_test_end(const char* name);
>   */
>  RTEMS_NO_RETURN void rtems_test_exit(int status);
>  
> -/**
> - * @brief Prints via the RTEMS printer.
> - *
> - * @return As specified by printf().
> - */
> -int rtems_test_printf(const char* format, ...) RTEMS_PRINTFLIKE(1, 2);
> -
>  #define RTEMS_TEST_PARALLEL_PROCESSOR_MAX 32
>  
>  typedef struct rtems_test_parallel_job rtems_test_parallel_job;
> diff --git a/cpukit/include/rtems/test-printer.h 
> b/cpukit/include/rtems/test-printer.h
> new file mode 100644
> index 00..901c7c3654
> --- /dev/null
> +++ b/cpukit/include/rtems/test-printer.h
> @@ -0,0 +1,69 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup RTEMSTest
> + *
> + * @brief This header file provides interfaces of the RTEMS Test Support.
> + */
> +
> +/*
> + * Copyright (C) 2014, 2023 embedded brains GmbH & Co. KG
> + *
> + * 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 

[RBW] Re: Riv Road spotted

[JohnS]

Thanks for sharing Paul, that's one clean machine.

JohnS

On Sunday, September 24, 2023 at 1:40:30 PM UTC-4 Ryan wrote:

> Shinier than my 2001 road
>
> On Sunday, September 24, 2023 at 9:45:41 AM UTC-5 Bikie#4646 wrote:
>
>> While eating at one of our favorite coffee shops near Jamestown, Va. (on 
>> the Va. Capital Trail) recently, our group spotted this near-pristine 
>> Rivendell Road (?) parked at the outside deck. 
>> I don't see many of these in my neck of the woods so stopped to ask. The 
>> owner bought it new (maybe late 1990's?). I doesn't seem to have gotten 
>> much use, but maybe he is super-careful with the bike.[image: Inline 
>> image]
>>
>> Paul Germain
>> Midlothian, Va.
>>
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/b2a89bbb-5cbb-4ab3-ac45-bb9c98bc45d1n%40googlegroups.com.

Re: [PATCH 1/2] bsps/xqspipsu: Break out RDID

[Chris Johns]

OK to 1 and 2

Thanks
Chris

On 22/9/2023 7:31 am, Kinsey Moore wrote:
> Expose a function to read the NOR flash chip ID information beyond the
> minimum 3 bytes for the lookup table.
> ---
>  bsps/include/dev/spi/xqspipsu-flash-helper.h | 15 +++
>  bsps/shared/dev/spi/xqspipsu-flash-helper.c  | 45 +---
>  2 files changed, 44 insertions(+), 16 deletions(-)
> 
> diff --git a/bsps/include/dev/spi/xqspipsu-flash-helper.h 
> b/bsps/include/dev/spi/xqspipsu-flash-helper.h
> index 5e4233e64e..1578fe8485 100644
> --- a/bsps/include/dev/spi/xqspipsu-flash-helper.h
> +++ b/bsps/include/dev/spi/xqspipsu-flash-helper.h
> @@ -155,3 +155,18 @@ u32 QspiPsu_NOR_Get_Device_Size(XQspiPsu *QspiPsuPtr);
>   *
>   
> **/
>  u32 QspiPsu_NOR_Get_Sector_Size(XQspiPsu *QspiPsuPtr);
> +
> +/*/
> +/**
> + *
> + * This function performs a read of the RDID configuration space.
> + *
> + * @paramQspiPsuPtr is a pointer to the QSPIPSU driver component to use.
> + * @paramReadBfrPtr is a pointer to a buffer to be filled with
> + *   configuration data.
> + * @paramReadLen is the total length of the configuration space to read.
> + *
> + * @return   XST_SUCCESS if successful, else XST_FAILURE.
> + *
> + 
> **/
> +int QspiPsu_NOR_RDID(XQspiPsu *QspiPsuPtr, u8 *ReadBfrPtr, u32 ReadLen);
> diff --git a/bsps/shared/dev/spi/xqspipsu-flash-helper.c 
> b/bsps/shared/dev/spi/xqspipsu-flash-helper.c
> index c9d8273b87..0dd065f02e 100644
> --- a/bsps/shared/dev/spi/xqspipsu-flash-helper.c
> +++ b/bsps/shared/dev/spi/xqspipsu-flash-helper.c
> @@ -274,22 +274,9 @@ static void QspiPsuHandler(
>}
>  }
>  
> -/*/
> -/**
> - *
> - * Reads the flash ID and identifies the flash in FCT table.
> - *
> - * @paramQspiPsuPtr is a pointer to the QSPIPSU driver component to use.
> - *
> - * @return   XST_SUCCESS if successful, else XST_FAILURE.
> - *
> - * @note None.
> - *
> - 
> */
> -static int FlashReadID(XQspiPsu *QspiPsuPtr)
> +int QspiPsu_NOR_RDID(XQspiPsu *QspiPsuPtr, u8 *ReadBfrPtr, u32 ReadLen)
>  {
>int Status;
> -  u32 ReadId = 0;
>  
>/*
> * Read ID
> @@ -303,7 +290,7 @@ static int FlashReadID(XQspiPsu *QspiPsuPtr)
>  
>FlashMsg[1].TxBfrPtr = NULL;
>FlashMsg[1].RxBfrPtr = ReadBfrPtr;
> -  FlashMsg[1].ByteCount = 3;
> +  FlashMsg[1].ByteCount = ReadLen;
>FlashMsg[1].BusWidth = XQSPIPSU_SELECT_MODE_SPI;
>FlashMsg[1].Flags = XQSPIPSU_MSG_FLAG_RX;
>  
> @@ -314,7 +301,33 @@ static int FlashReadID(XQspiPsu *QspiPsuPtr)
>}
>while (TransferInProgress);
>  
> -  rtems_cache_invalidate_multiple_data_lines(ReadBfrPtr, 3);
> +  rtems_cache_invalidate_multiple_data_lines(ReadBfrPtr, ReadLen);
> +  return XST_SUCCESS;
> +}
> +
> +/*/
> +/**
> + *
> + * Reads the flash ID and identifies the flash in FCT table.
> + *
> + * @paramQspiPsuPtr is a pointer to the QSPIPSU driver component to use.
> + *
> + * @return   XST_SUCCESS if successful, else XST_FAILURE.
> + *
> + * @note None.
> + *
> + 
> */
> +static int FlashReadID(XQspiPsu *QspiPsuPtr)
> +{
> +  u32 ReadId = 0;
> +  u32 ReadLen = 3;
> +  int Status;
> +
> +  Status = QspiPsu_NOR_RDID(QspiPsuPtr, ReadBfrPtr, ReadLen);
> +  if (Status != XST_SUCCESS) {
> +return XST_FAILURE;
> +  }
> +
>/* In case of dual, read both and ensure they are same make/size */
>  
>/*
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsd/ntpq: Use the correct address length

[Chris Johns]

I assume this is in the network services repo?

OK and thanks

Chris

On 22/9/2023 4:38 am, Kinsey Moore wrote:
> lwIP includes more than the bare address structures in its accounting of
> the total addrinfo struct size. Ensure that lwIP gets the correct
> address size.
> ---
>  bsd/freebsd/contrib/ntp/ntpq/ntpq.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/bsd/freebsd/contrib/ntp/ntpq/ntpq.c 
> b/bsd/freebsd/contrib/ntp/ntpq/ntpq.c
> index 1cea922..0ea6c08 100644
> --- a/bsd/freebsd/contrib/ntp/ntpq/ntpq.c
> +++ b/bsd/freebsd/contrib/ntp/ntpq/ntpq.c
> @@ -828,6 +828,14 @@ openhost(
>  #ifdef SYS_VXWORKS
>  (connect(sockfd, (struct sockaddr *),
>   sizeof(hostaddr)) == -1)
> +#elif defined(__rtems__)
> +/*
> + * lwIP's ai_addrlen covers the entire struct which includes
> + * padding for extra data and is not accurate for calls which
> + * validate the size of the address structure. Use sa_len instead
> + */
> +(connect(sockfd, (struct sockaddr *)ai->ai_addr,
> + ai->ai_addr->sa_len) == -1)
>  #else
>  (connect(sockfd, (struct sockaddr *)ai->ai_addr,
>   ai->ai_addrlen) == -1)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RBW] FS ALBATROSS BARS

[JohnS]

The chromoly version is magnetic.

JohnS

On Wednesday, September 20, 2023 at 2:23:39 PM UTC-4 Johnny Alien wrote:

> If its the aluminum version it will have a sticker/band around the bar 
> near the sleeve. Either black or red I think?? I can't remember. If its the 
> chromoly version then not to nitpick but the price is higher than the new 
> price.
>
> On Wednesday, September 20, 2023 at 2:15:13 PM UTC-4 Davey Two Shoes wrote:
>
>> I believe chromoly, I've had them for sometime and forgotten.
>>
>> On Wednesday, September 20, 2023 at 10:32:03 AM UTC-4 Andrew Letton wrote:
>>
>>> Are they ChroMoly or aluminum?
>>> cheers,
>>> Andrew in Sydney
>>>
>>> On Wednesday, September 20, 2023 at 11:50:28 PM GMT+10, Davey Two Shoes <
>>> dgold...@gmail.com> wrote: 
>>>
>>>
>>> Hey Gang,
>>> I've got an albatross for sale $90 plus shipping. Shoot me a PM and I'll 
>>> email pics. I cant seem to upload right now.
>>>
>>> Thanks!
>>> Dave
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "RBW Owners Bunch" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to rbw-owners-bun...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/rbw-owners-bunch/53c71060-e78e-4e75-8200-00045ac48edan%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/rbw-owners-bunch/53c71060-e78e-4e75-8200-00045ac48edan%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/366393a1-abae-4684-8939-7c22d15c9196n%40googlegroups.com.

Re: [PATCH rtems-libbsd] rtemsbsd/libio: Handle invalid descriptors

[Chris Johns]

OK

Thanks
Chris

On 20/9/2023 7:18 am, Kinsey Moore wrote:
> The documentation for this function suggests that it can handle invalid
> descriptors safely. This change allows negative descriptors to be
> handled without a crash.
> ---
>  rtemsbsd/include/machine/rtems-bsd-libio.h | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/rtemsbsd/include/machine/rtems-bsd-libio.h 
> b/rtemsbsd/include/machine/rtems-bsd-libio.h
> index e662a9ec..8cc67ae3 100644
> --- a/rtemsbsd/include/machine/rtems-bsd-libio.h
> +++ b/rtemsbsd/include/machine/rtems-bsd-libio.h
> @@ -228,7 +228,7 @@ rtems_bsd_libio_iop_hold(int fd, rtems_libio_t **iopp)
>   rtems_libio_t *iop = NULL;
>   unsigned int flags = 0;
>   int ffd = -1;
> - if (fd < rtems_libio_number_iops) {
> + if (fd >= 0 && fd < rtems_libio_number_iops) {
>   iop = rtems_libio_iop(fd);
>   flags = rtems_libio_iop_hold(iop);
>   if ((flags & LIBIO_FLAGS_OPEN) != 0) {
> @@ -249,7 +249,9 @@ rtems_bsd_libio_iop_hold(int fd, rtems_libio_t **iopp)
>   if (RTEMS_BSD_DESCRIP_TRACE)
>   flags = iop->flags;
>   } else {
> - *iopp = NULL;
> + if (iopp != NULL) {
> + *iopp = NULL;
> + }
>   }
>   if (RTEMS_BSD_DESCRIP_TRACE)
>   printf("bsd: iop: hold: fd=%d ffd=%d refs=%d iop=%p by %p\n",
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Remove enabled-by special case

[Chris Johns]

Looks good.

Thanks
Chris

On 18/9/2023 8:26 pm, Sebastian Huber wrote:
> Doing the enabled-by processing just for the ldflags and just for the
> link custom commands is confusing.  Use an option instead which is
> intended to be used for such use cases.
> ---
>  spec/build/testsuites/libtests/dl07.yml   |  4 +---
>  spec/build/testsuites/libtests/dl08.yml   |  4 +---
>  spec/build/testsuites/libtests/dl09.yml   |  4 +---
>  spec/build/testsuites/libtests/grp.yml|  2 ++
>  .../testsuites/libtests/optdlldflags.yml  | 22 +++
>  wscript   | 12 +++---
>  6 files changed, 30 insertions(+), 18 deletions(-)
>  create mode 100644 spec/build/testsuites/libtests/optdlldflags.yml
> 
> diff --git a/spec/build/testsuites/libtests/dl07.yml 
> b/spec/build/testsuites/libtests/dl07.yml
> index e443f4ed29..5760f68b87 100644
> --- a/spec/build/testsuites/libtests/dl07.yml
> +++ b/spec/build/testsuites/libtests/dl07.yml
> @@ -33,9 +33,7 @@ enabled-by:
>  includes:
>  - testsuites/libtests/dl07
>  ldflags:
> -- enabled-by:
> -  - microblaze
> -  value: -u__extendsfdf2
> +- ${LIBDL_TESTS_LDFLAGS}
>  links: []
>  prepare-build: null
>  prepare-configure: null
> diff --git a/spec/build/testsuites/libtests/dl08.yml 
> b/spec/build/testsuites/libtests/dl08.yml
> index 8e5eec77f2..ada6caf698 100644
> --- a/spec/build/testsuites/libtests/dl08.yml
> +++ b/spec/build/testsuites/libtests/dl08.yml
> @@ -38,9 +38,7 @@ enabled-by:
>  includes:
>  - testsuites/libtests/dl08
>  ldflags:
> -- enabled-by:
> -  - microblaze
> -  value: -u__extendsfdf2
> +- ${LIBDL_TESTS_LDFLAGS}
>  links: []
>  prepare-build: null
>  prepare-configure: null
> diff --git a/spec/build/testsuites/libtests/dl09.yml 
> b/spec/build/testsuites/libtests/dl09.yml
> index 2d00286c15..ee0be57fb2 100644
> --- a/spec/build/testsuites/libtests/dl09.yml
> +++ b/spec/build/testsuites/libtests/dl09.yml
> @@ -33,9 +33,7 @@ enabled-by:
>  includes:
>  - testsuites/libtests/dl09
>  ldflags:
> -- enabled-by:
> -  - microblaze
> -  value: -u__extendsfdf2
> +- ${LIBDL_TESTS_LDFLAGS}
>  links: []
>  prepare-build: null
>  prepare-configure: null
> diff --git a/spec/build/testsuites/libtests/grp.yml 
> b/spec/build/testsuites/libtests/grp.yml
> index c1a6209e99..eaf21751c4 100644
> --- a/spec/build/testsuites/libtests/grp.yml
> +++ b/spec/build/testsuites/libtests/grp.yml
> @@ -22,6 +22,8 @@ links:
>uid: ../optgzip
>  - role: build-dependency
>uid: ../optxz
> +- role: build-dependency
> +  uid: optdlldflags
>  - role: build-dependency
>uid: optrtemsld
>  - role: build-dependency
> diff --git a/spec/build/testsuites/libtests/optdlldflags.yml 
> b/spec/build/testsuites/libtests/optdlldflags.yml
> new file mode 100644
> index 00..0d754c5270
> --- /dev/null
> +++ b/spec/build/testsuites/libtests/optdlldflags.yml
> @@ -0,0 +1,22 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- get-string: null
> +- split: null
> +- env-assign: null
> +build-type: option
> +copyrights:
> +- Copyright (C) 2023 embedded brains GmbH & Co. KG
> +default:
> +- enabled-by: microblaze
> +  value:
> +  - -u__extendsfdf2
> +- enabled-by: true
> +  value: []
> +description: |
> +  Linker flags used to link libdl tests with a base image.  For example, it 
> may
> +  be used to add undefined symbols which the linker has to resolve to pull in
> +  services required by loaded parts.
> +enabled-by: true
> +links: []
> +name: LIBDL_TESTS_LDFLAGS
> +type: build
> diff --git a/wscript b/wscript
> index 00b81b4874..65f90fc324 100755
> --- a/wscript
> +++ b/wscript
> @@ -360,7 +360,7 @@ class Item(object):
>  def __init__(self, item, bic, cmd, env, ldflags):
>  super(link, self).__init__(self, env=env)
>  self.cmd = cmd
> -self.ldflags = bic.ldflags + ldflags
> +self.ldflags = ldflags
>  self.stlib = item.data["stlib"]
>  self.use = (item.data["use-before"] + bic.use +
>  item.data["use-after"])
> @@ -386,14 +386,8 @@ class Item(object):
>  [],
>  )
>  
> -ldflags = []
> -for ldflag in self.data["ldflags"]:
> -if isinstance(ldflag, dict):
> -if _is_enabled(bld.env.ENABLE, ldflag["enabled-by"]):
> -ldflags.append(ldflag["value"])
> -else:
> -ldflags.append(ldflag)
> -tsk = link(self, bic, cmd, bld.env, ldflags)
> +tsk = link(self, bic, cmd, bld.env,
> +   bic.ldflags + self.substitute(bld, self.data["ldflags"]))
>  tsk.set_inputs([bld.bldnode.make_node(s) for s in source])
>  tsk.set_outputs(bld.bldnode.make_node(target))
>  bld.add_to_group(tsk)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems commit] libdl: Add support to import base image TLS symbols

[Chris Johns]

On 18/9/2023 10:09 pm, Sebastian Huber wrote:
> On 17.09.23 00:58, Chris Johns wrote:
>>> There are also no test cases for this function.
>>> Without test cases it is easy to break something without knowing it.
>> The libdl test cases have been updated to reference TLS newlib variables to 
>> test
>> this. Is that enough? If not what would you like to see?
> 
> These higher level tests are all right, however, it would be nice to have also
> lower level tests which just check a particular function like
> rtems_rtl_tls_get_base(). This would improve the maintainability of this 
> stuff.
> You would not have to debug a tool generated code to figure out what is wrong.

This makes sense. I will think about a suitable test.

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

Re: [PATCH 1/2] score: Add _CPU_Get_TLS_thread_pointer()

[Chris Johns]

Looks good and thank you. I appreciate you handling this for me.

Chris

On 15/9/2023 5:07 pm, Sebastian Huber wrote:
> Add _CPU_Get_TLS_thread_pointer() to get the thread pointer which is
> used to get the address of thread-local storage objects associated with
> a thread.
> 
> Update #4920.
> ---
>  .../cpu/aarch64/include/rtems/score/cpuimpl.h |  7 
>  .../cpu/arm/include/rtems/score/cpuimpl.h |  7 
>  .../cpu/bfin/include/rtems/score/cpuimpl.h|  8 +
>  .../cpu/i386/include/rtems/score/cpuimpl.h|  7 
>  .../cpu/lm32/include/rtems/score/cpuimpl.h|  8 +
>  .../cpu/m68k/include/rtems/score/cpuimpl.h|  7 
>  .../microblaze/include/rtems/score/cpuimpl.h  |  7 
>  .../cpu/mips/include/rtems/score/cpuimpl.h|  8 +
>  .../cpu/moxie/include/rtems/score/cpuimpl.h   |  8 +
>  .../cpu/nios2/include/rtems/score/cpuimpl.h   |  7 
>  .../cpu/no_cpu/include/rtems/score/cpuimpl.h  | 16 +
>  .../cpu/or1k/include/rtems/score/cpuimpl.h|  8 +
>  .../cpu/powerpc/include/rtems/score/cpuimpl.h |  7 
>  .../cpu/riscv/include/rtems/score/cpuimpl.h   |  7 
>  .../cpu/sh/include/rtems/score/cpuimpl.h  |  8 +
>  .../cpu/sparc/include/rtems/score/cpuimpl.h   |  7 
>  .../cpu/sparc64/include/rtems/score/cpuimpl.h |  8 +
>  .../cpu/v850/include/rtems/score/cpuimpl.h|  8 +
>  .../cpu/x86_64/include/rtems/score/cpuimpl.h  |  8 +
>  testsuites/sptests/sptls01/init.c | 33 +++
>  20 files changed, 184 insertions(+)
> 
> diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/cpuimpl.h 
> b/cpukit/score/cpu/aarch64/include/rtems/score/cpuimpl.h
> index b520e8bffb..095c5db5b9 100644
> --- a/cpukit/score/cpu/aarch64/include/rtems/score/cpuimpl.h
> +++ b/cpukit/score/cpu/aarch64/include/rtems/score/cpuimpl.h
> @@ -174,6 +174,13 @@ static inline void _CPU_Use_thread_local_storage(
>);
>  }
>  
> +static inline void *_CPU_Get_TLS_thread_pointer(
> +  const Context_Control *context
> +)
> +{
> +  return (void *) context->thread_id;
> +}
> +
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h 
> b/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
> index f9b40889f5..04d23f0ea7 100644
> --- a/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
> +++ b/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
> @@ -178,6 +178,13 @@ static inline void _CPU_Use_thread_local_storage(
>  #endif
>  }
>  
> +static inline void *_CPU_Get_TLS_thread_pointer(
> +  const Context_Control *context
> +)
> +{
> +  return (void *) context->thread_id;
> +}
> +
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h 
> b/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
> index aaf34a3ce0..5a445d9420 100644
> --- a/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
> +++ b/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
> @@ -72,6 +72,14 @@ static inline void _CPU_Use_thread_local_storage(
>(void) context;
>  }
>  
> +static inline void *_CPU_Get_TLS_thread_pointer(
> +  const Context_Control *context
> +)
> +{
> +  (void) context;
> +  return NULL;
> +}
> +
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h 
> b/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
> index ba5d820016..da38ecacf7 100644
> --- a/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
> +++ b/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
> @@ -112,6 +112,13 @@ static inline void _CPU_Use_thread_local_storage(
>);
>  }
>  
> +static inline void *_CPU_Get_TLS_thread_pointer(
> +  const Context_Control *context
> +)
> +{
> +  return (void *) >gs;
> +}
> +
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h 
> b/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
> index 870640864c..70a1db1d4d 100644
> --- a/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
> +++ b/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
> @@ -71,6 +71,14 @@ static inline void _CPU_Use_thread_local_storage(
>(void) context;
>  }
>  
> +static inline void *_CPU_Get_TLS_thread_pointer(
> +  const Context_Control *context
> +)
> +{
> +  (void) context;
> +  return NULL;
> +}
> +
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/cpukit/score/cpu/m68k/include/rtems/score/cpuimpl.h 
> b/cpukit/score/cpu/m68k/include/rtems/score/cpuimpl.h
> index 4bee157215..521e9fc4c2 100644
> --- a/cpukit/score/cpu/m68k/include/rtems/score/cpuimpl.h
> +++ b/cpukit/score/cpu/m68k/include/rtems/score/cpuimpl.h
> @@ -95,6 +95,13 @@ static inline void _CPU_Use_thread_local_storage(
>(void) context;
>  }
>  
> +static inline void *_CPU_Get_TLS_thread_pointer(
> +  const Context_Control *context
> +)
> +{
> +  return (void *) context->thread_pointer;
> +}
> +
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/cpukit/score/cpu/microblaze/include/rtems/score/cpuimpl.h 
> 

Re: [rtems commit] libdl: Add support to import base image TLS symbols

[Chris Johns]

On 15/9/2023 5:07 pm, Sebastian Huber wrote:
> On 14.09.23 23:56, Chris Johns wrote:
>> On 14/9/2023 7:33 pm, Sebastian Huber wrote:
>>> On 14.09.23 10:51, Chris Johns wrote:
>>>> On 14/9/2023 5:58 pm, Sebastian Huber wrote:
>>>>> On 14.09.23 09:38, Chris Johns wrote:
>>>>>>>> The issue I faced was no score interface to get the TLS base for a
>>>>>>>> thread to
>>>>>>>> determine a symbol's offset. If we had that and something to say if 
>>>>>>>> TLS is
>>>>>>>> supported libdl would be easy to fix.
>>>>>>> Why don't we add this interface if it simplifies things?
>>>>>> Yes please, that would be good. I do not know the TSL support well enough
>>>>>> to do
>>>>>> a decent job of it.
>>>>> Which interface do you need?
>>>> A define that says TLS is support for an arch?
>>>>
>>>> A call that returns the base address for an arch? I have added some in 
>>>> libdl:
>>>>
>>>> https://git.rtems.org/rtems/tree/cpukit/libdl/rtl-tls.c
>>>>
>>>> however having this in score would mean a new arch does not break libdl.
>>> Yes, this should be definitely added to the CPU port. What is the purpose of
>>> rtems_rtl_tls_get_base()? It seems to be unused.
>> It is used by the symbol table loader so is referenced in the symbol table
>> generated code ...
>>
>> https://git.rtems.org/rtems-tools/tree/linkers/rtems-syms.cpp#n66
>> https://git.rtems.org/rtems-tools/tree/linkers/rtems-syms.cpp#n319
>>
>> A TLS symbol is an offset into the TLS area. I encountered two problems. 
>> First I
>> could not find a way to equate a TLS symbol offset to a label in asm or C and
>> second the offsets move with each link phase and with the 2 stage linking the
>> offsets move. As a result the offset needs to be computer at runtime. To do 
>> this
>> the base image TLS symbols each get a small piece of code that determines the
>> offset at runtime. The symbol table in the target contains the TLS area 
>> offset
>> in an arch ABI specific format. The relocs know how to handle the offset the
>> symbol holds.
> 
> It would be really nice to have a Doxygen comment for rtems_rtl_tls_get_base()
> which contains this information.

Good idea. The change is still in development and now you are back and
commenting I am happy to do this.

> There are also no test cases for this function.
> Without test cases it is easy to break something without knowing it.

The libdl test cases have been updated to reference TLS newlib variables to test
this. Is that enough? If not what would you like to see?

Note, TLS variables in loaded modules is not supported. That needs an allocator
and the size of TLS memory used by base image variables. Most of the code is in
libdl (see PowerPC SDATA) so these change may make that be within reach.

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

Re: [rtems commit] libdl: Add support to import base image TLS symbols

[Chris Johns]

On 14/9/2023 7:33 pm, Sebastian Huber wrote:
> On 14.09.23 10:51, Chris Johns wrote:
>> On 14/9/2023 5:58 pm, Sebastian Huber wrote:
>>> On 14.09.23 09:38, Chris Johns wrote:
>>>>>> The issue I faced was no score interface to get the TLS base for a 
>>>>>> thread to
>>>>>> determine a symbol's offset. If we had that and something to say if TLS 
>>>>>> is
>>>>>> supported libdl would be easy to fix.
>>>>> Why don't we add this interface if it simplifies things?
>>>> Yes please, that would be good. I do not know the TSL support well enough 
>>>> to do
>>>> a decent job of it.
>>> Which interface do you need?
>> A define that says TLS is support for an arch?
>>
>> A call that returns the base address for an arch? I have added some in libdl:
>>
>> https://git.rtems.org/rtems/tree/cpukit/libdl/rtl-tls.c
>>
>> however having this in score would mean a new arch does not break libdl.
> 
> Yes, this should be definitely added to the CPU port. What is the purpose of
> rtems_rtl_tls_get_base()? It seems to be unused.

It is used by the symbol table loader so is referenced in the symbol table
generated code ...

https://git.rtems.org/rtems-tools/tree/linkers/rtems-syms.cpp#n66
https://git.rtems.org/rtems-tools/tree/linkers/rtems-syms.cpp#n319

A TLS symbol is an offset into the TLS area. I encountered two problems. First I
could not find a way to equate a TLS symbol offset to a label in asm or C and
second the offsets move with each link phase and with the 2 stage linking the
offsets move. As a result the offset needs to be computer at runtime. To do this
the base image TLS symbols each get a small piece of code that determines the
offset at runtime. The symbol table in the target contains the TLS area offset
in an arch ABI specific format. The relocs know how to handle the offset the
symbol holds.

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

Re: [rtems commit] libdl: Add support to import base image TLS symbols

[Chris Johns]

On 14/9/2023 5:58 pm, Sebastian Huber wrote:
> On 14.09.23 09:38, Chris Johns wrote:
>>>> The issue I faced was no score interface to get the TLS base for a thread 
>>>> to
>>>> determine a symbol's offset. If we had that and something to say if TLS is
>>>> supported libdl would be easy to fix.
>>> Why don't we add this interface if it simplifies things?
>> Yes please, that would be good. I do not know the TSL support well enough to 
>> do
>> a decent job of it.
> 
> Which interface do you need?

A define that says TLS is support for an arch?

A call that returns the base address for an arch? I have added some in libdl:

https://git.rtems.org/rtems/tree/cpukit/libdl/rtl-tls.c

however having this in score would mean a new arch does not break libdl.

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

Re: [rtems commit] libdl: Add support to import base image TLS symbols

[Chris Johns]

On 14/9/2023 5:20 pm, Sebastian Huber wrote:
> On 14.09.23 09:12, Chris Johns wrote:
>> On 14/9/2023 4:55 pm, Sebastian Huber wrote:
>>> On 14.09.23 08:34, Sebastian Huber wrote:
>>>> This seems to break the mips build:
>>>>
>>>> cpukit/libdl/rtl-tls.c:104:2: error: #error unsupported architecture
>>>>     104 | #error unsupported architecture
>>>>     |  ^
>>>>
>>> Also the moxie and 64-bit powerpc (qoriq_e6500_64) no longer build with the
>>> error above.
>> Yes. It was decided this be a hard error so it gets fixed. The newlib TLS 
>> change
>> broke libdl and it is being fixed for the release. I have done what I can and
>> know about but some archs need help from those who know about it.
> 
> An intentionally broken build is not really helpful.

Yes it is not ideal but leaving libdl broken with no one knowing is also not
helpful. We needed a circuit breaker.

> There are also other bugs left to fix, for example:
> 
> https://devel.rtems.org/ticket/4953
> 
> How can I check if my patches break the build if it is already broken?

Like I said it is not a prefect solution and we need to resolve this as a team.
I have done some of the hard work in libdl to get things under way but I need
help in the TLS score area.

>> I am not sure about moxie, if it does not have TLS support it can disabled.
> 
> moxie and mips don't have TLS support.
> 
>>
>> The issue I faced was no score interface to get the TLS base for a thread to
>> determine a symbol's offset. If we had that and something to say if TLS is
>> supported libdl would be easy to fix.
> 
> Why don't we add this interface if it simplifies things?

Yes please, that would be good. I do not know the TSL support well enough to do
a decent job of it.

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

Re: [rtems commit] libdl: Add support to import base image TLS symbols

[Chris Johns]

On 14/9/2023 4:55 pm, Sebastian Huber wrote:
> On 14.09.23 08:34, Sebastian Huber wrote:
>> This seems to break the mips build:
>>
>> cpukit/libdl/rtl-tls.c:104:2: error: #error unsupported architecture
>>    104 | #error unsupported architecture
>>    |  ^
>>
> 
> Also the moxie and 64-bit powerpc (qoriq_e6500_64) no longer build with the
> error above.

Yes. It was decided this be a hard error so it gets fixed. The newlib TLS change
broke libdl and it is being fixed for the release. I have done what I can and
know about but some archs need help from those who know about it.

I am not sure about moxie, if it does not have TLS support it can disabled.

The issue I faced was no score interface to get the TLS base for a thread to
determine a symbol's offset. If we had that and something to say if TLS is
supported libdl would be easy to fix.

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

Re: [PATCH] build: Use build context for custom commands

[Chris Johns]

On 13/9/2023 6:52 pm, Sebastian Huber wrote:
> On 13.09.23 09:20, Chris Johns wrote:
>> On 13/9/2023 4:18 pm, Sebastian Huber wrote:
>>>
>>> On 13.09.23 03:12, Chris Johns wrote:
>>>> On 12/9/2023 5:55 pm, Sebastian Huber wrote:
>>>>> On 12.09.23 09:43, Chris Johns wrote:
>>>>>>>>> Setting OPTIMIZATION_FLAGS and TEST_OPTIMIZATION_FLAGS through the
>>>>>>>>> configuration
>>>>>>>>> file always worked.
>>>>>>>> Great. I am seeing:
>>>>>>>>
>>>>>>>> OPTIMIZATION_FLAGS = -O2 -g -fdata-sections -ffunction-sections
>>>>>>>>
>>>>>>>> and data sections is an optimisation however does it complicates things
>>>>>>>> for the
>>>>>>>> user if they play with with just -O2?
>>>>>>>>
>>>>>>>> 1. -g is debug info and not optimisation
>>>>>>>>
>>>>>>>> 2. we recommend building RTEMS with -fdata-sections -ffunction-sections
>>>>>>>> so I
>>>>>>>> guess removing them would not be good
>>>>>>> We can easily split up the OPTIMIZATION_FLAGS and add more options. For
>>>>>>> example:
>>>>>>>
>>>>>>> DEBUG_FLAGS = -g
>>>>>>>
>>>>>>> OPTIMIZATION_FLAGS = -O2 -fdata-sections -ffunction-sections
>>>>>>>
>>>>>> I think it will help.
>>>>>>
>>>>>> As an idea what about DEBUGGING_OPTIONS and OPTIMIZATION_OPTIONS then
>>>>>> OPTIMIZATION_FLAGS is "${OPTIMIZATION_OPTIONS} ${DEBUGGING_OPTIONS}" so 
>>>>>> it
>>>>>> follows the gcc naming of its option grouping [1] ?
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>> [1]https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html
>>>>> Yes, using OPTIONS instead of FLAGS is more in line with the GCC
>>>>> documentation,
>>>>> however, we currently use FLAGS for this stuff:
>>>>>
>>>>> grep -r -o -h '\w*FLAGS' spec | sort -u
>>>>> ABI_FLAGS
>>>>> ARFLAGS
>>>>> ASFLAGS
>>>>> BSP_CFLAGS
>>>>> BSP_OPTIMIZATION_FLAGS
>>>>> CC_WARNING_FLAGS
>>>>> CFLAGS
>>>>> COVERAGE_COMPILER_FLAGS
>>>>> COVERAGE_LINKER_FLAGS
>>>>> CPPFLAGS
>>>>> CPUKIT_OPTIMIZATION_FLAGS
>>>>> CPU_CFLAGS
>>>>> CXXFLAGS
>>>>> CXX_WARNING_FLAGS
>>>>> LDFLAGS
>>>>> LINKFLAGS
>>>>> MPC55XX_BOOTFLAGS
>>>>> OPTIMIZATION_FLAGS
>>>>> PKGCONFIG_LDFLAGS
>>>>> TEST_DL01_CPPFLAGS
>>>>> TEST_DL02_CPPFLAGS
>>>>> TEST_DL04_CPPFLAGS
>>>>> TEST_DL05_CPPFLAGS
>>>>> TEST_DL06_CPPFLAGS
>>>>> TEST_DL07_CPPFLAGS
>>>>> TEST_DL08_CPPFLAGS
>>>>> TEST_DL09_CPPFLAGS
>>>>> TEST_DL10_CPPFLAGS
>>>>> TEST_DL11_CPPFLAGS
>>>>> TEST_OPTIMIZATION_FLAGS
>>>>> TEST_TAR01_CPPFLAGS
>>>>> TEST_TAR02_CPPFLAGS
>>>>> TEST_psxftw01_CPPFLAGS
>>>>> TMS570_LINKFLAGS
>>>>> WARNING_FLAGS
>>>>> XCFLAGS
>>>>>
>>>>> I guess it is derived from CFLAGS, etc.
>>>> Yes. The thinking is OPTIONS is user focused and can be a set of options 
>>>> from
>>>> that section of the gcc manual while FLAGS are build system focused? We 
>>>> need
>>>> FLAGS like OPTIMIZATION_FLAGS and we make the distinction that user can 
>>>> change
>>>> OPTIONS and if you touch FLAGS you need to be more careful. We keep the ABI
>>>> machine flags away from OPTIONS and in FLAGS.
>>> I think it is too late to introduce a new naming here. There may be already
>>> configuration files which use OPTIMIZATION_FLAGS. I would just split this 
>>> option
>>> into OPTIMIZATION_FLAGS and DEBUGGING_FLAGS.
>> We have not released any of this however after that it is too late if we 
>> want or
>> need to change.
> 
> I am not against a big overhaul of the build options, but then we should
> document the patterns and review all options.

Great and yes. When?

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

Re: [PATCH] build: Use build context for custom commands

[Chris Johns]

On 13/9/2023 4:18 pm, Sebastian Huber wrote:
> 
> 
> On 13.09.23 03:12, Chris Johns wrote:
>> On 12/9/2023 5:55 pm, Sebastian Huber wrote:
>>> On 12.09.23 09:43, Chris Johns wrote:
>>>>>>> Setting OPTIMIZATION_FLAGS and TEST_OPTIMIZATION_FLAGS through the
>>>>>>> configuration
>>>>>>> file always worked.
>>>>>> Great. I am seeing:
>>>>>>
>>>>>> OPTIMIZATION_FLAGS = -O2 -g -fdata-sections -ffunction-sections
>>>>>>
>>>>>> and data sections is an optimisation however does it complicates things
>>>>>> for the
>>>>>> user if they play with with just -O2?
>>>>>>
>>>>>> 1. -g is debug info and not optimisation
>>>>>>
>>>>>> 2. we recommend building RTEMS with -fdata-sections -ffunction-sections 
>>>>>> so I
>>>>>> guess removing them would not be good
>>>>> We can easily split up the OPTIMIZATION_FLAGS and add more options. For
>>>>> example:
>>>>>
>>>>> DEBUG_FLAGS = -g
>>>>>
>>>>> OPTIMIZATION_FLAGS = -O2 -fdata-sections -ffunction-sections
>>>>>
>>>> I think it will help.
>>>>
>>>> As an idea what about DEBUGGING_OPTIONS and OPTIMIZATION_OPTIONS then
>>>> OPTIMIZATION_FLAGS is "${OPTIMIZATION_OPTIONS} ${DEBUGGING_OPTIONS}" so it
>>>> follows the gcc naming of its option grouping [1] ?
>>>>
>>>> Chris
>>>>
>>>> [1]https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html
>>> Yes, using OPTIONS instead of FLAGS is more in line with the GCC 
>>> documentation,
>>> however, we currently use FLAGS for this stuff:
>>>
>>> grep -r -o -h '\w*FLAGS' spec | sort -u
>>> ABI_FLAGS
>>> ARFLAGS
>>> ASFLAGS
>>> BSP_CFLAGS
>>> BSP_OPTIMIZATION_FLAGS
>>> CC_WARNING_FLAGS
>>> CFLAGS
>>> COVERAGE_COMPILER_FLAGS
>>> COVERAGE_LINKER_FLAGS
>>> CPPFLAGS
>>> CPUKIT_OPTIMIZATION_FLAGS
>>> CPU_CFLAGS
>>> CXXFLAGS
>>> CXX_WARNING_FLAGS
>>> LDFLAGS
>>> LINKFLAGS
>>> MPC55XX_BOOTFLAGS
>>> OPTIMIZATION_FLAGS
>>> PKGCONFIG_LDFLAGS
>>> TEST_DL01_CPPFLAGS
>>> TEST_DL02_CPPFLAGS
>>> TEST_DL04_CPPFLAGS
>>> TEST_DL05_CPPFLAGS
>>> TEST_DL06_CPPFLAGS
>>> TEST_DL07_CPPFLAGS
>>> TEST_DL08_CPPFLAGS
>>> TEST_DL09_CPPFLAGS
>>> TEST_DL10_CPPFLAGS
>>> TEST_DL11_CPPFLAGS
>>> TEST_OPTIMIZATION_FLAGS
>>> TEST_TAR01_CPPFLAGS
>>> TEST_TAR02_CPPFLAGS
>>> TEST_psxftw01_CPPFLAGS
>>> TMS570_LINKFLAGS
>>> WARNING_FLAGS
>>> XCFLAGS
>>>
>>> I guess it is derived from CFLAGS, etc.
>> Yes. The thinking is OPTIONS is user focused and can be a set of options from
>> that section of the gcc manual while FLAGS are build system focused? We need
>> FLAGS like OPTIMIZATION_FLAGS and we make the distinction that user can 
>> change
>> OPTIONS and if you touch FLAGS you need to be more careful. We keep the ABI
>> machine flags away from OPTIONS and in FLAGS.
> 
> I think it is too late to introduce a new naming here. There may be already
> configuration files which use OPTIMIZATION_FLAGS. I would just split this 
> option
> into OPTIMIZATION_FLAGS and DEBUGGING_FLAGS.

We have not released any of this however after that it is too late if we want or
need to change.

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

Re: [PATCH 1/2] score: Fix RTEMS_DEFINE_GLOBAL_SYMBOL()

[Chris Johns]

OK

Thanks
Chris

On 13/9/2023 12:44 am, Sebastian Huber wrote:
> The availability of a proper RTEMS_DEFINE_GLOBAL_SYMBOL() implementation
> depends on __asm__() and thus __GNUC__.
> 
> Clarify documentation.
> 
> Update #4953.
> ---
>  cpukit/include/rtems/score/basedefs.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/cpukit/include/rtems/score/basedefs.h 
> b/cpukit/include/rtems/score/basedefs.h
> index 99fda67e8c..0cf7272b5d 100644
> --- a/cpukit/include/rtems/score/basedefs.h
> +++ b/cpukit/include/rtems/score/basedefs.h
> @@ -999,11 +999,12 @@ extern "C" {
>   *
>   * @param _value is the value of the symbol.  On the value a macro expansion 
> is
>   *   performed and afterwards it is stringified.  It shall expand to an 
> integer
> - *   expression understood by the assembler.
> + *   expression understood by the assembler.  The value shall be 
> representable
> + *   in the code model of the target architecture.
>   *
>   * This macro shall be placed at file scope.
>   */
> -#if defined(__USER_LABEL_PREFIX__)
> +#if defined(__GNUC__)
>#define RTEMS_DEFINE_GLOBAL_SYMBOL( _name, _value ) \
>  __asm__( \
>"\t.globl " RTEMS_XSTRING( RTEMS_SYMBOL_NAME( _name ) ) \
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Use build context for custom commands

[Chris Johns]

On 12/9/2023 5:55 pm, Sebastian Huber wrote:
> On 12.09.23 09:43, Chris Johns wrote:
>>>>> Setting OPTIMIZATION_FLAGS and TEST_OPTIMIZATION_FLAGS through the
>>>>> configuration
>>>>> file always worked.
>>>> Great. I am seeing:
>>>>
>>>> OPTIMIZATION_FLAGS = -O2 -g -fdata-sections -ffunction-sections
>>>>
>>>> and data sections is an optimisation however does it complicates things 
>>>> for the
>>>> user if they play with with just -O2?
>>>>
>>>> 1. -g is debug info and not optimisation
>>>>
>>>> 2. we recommend building RTEMS with -fdata-sections -ffunction-sections so 
>>>> I
>>>> guess removing them would not be good
>>> We can easily split up the OPTIMIZATION_FLAGS and add more options. For 
>>> example:
>>>
>>> DEBUG_FLAGS = -g
>>>
>>> OPTIMIZATION_FLAGS = -O2 -fdata-sections -ffunction-sections
>>>
>> I think it will help.
>>
>> As an idea what about DEBUGGING_OPTIONS and OPTIMIZATION_OPTIONS then
>> OPTIMIZATION_FLAGS is "${OPTIMIZATION_OPTIONS} ${DEBUGGING_OPTIONS}" so it
>> follows the gcc naming of its option grouping [1] ?
>>
>> Chris
>>
>> [1]https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html
> 
> Yes, using OPTIONS instead of FLAGS is more in line with the GCC 
> documentation,
> however, we currently use FLAGS for this stuff:
> 
> grep -r -o -h '\w*FLAGS' spec | sort -u
> ABI_FLAGS
> ARFLAGS
> ASFLAGS
> BSP_CFLAGS
> BSP_OPTIMIZATION_FLAGS
> CC_WARNING_FLAGS
> CFLAGS
> COVERAGE_COMPILER_FLAGS
> COVERAGE_LINKER_FLAGS
> CPPFLAGS
> CPUKIT_OPTIMIZATION_FLAGS
> CPU_CFLAGS
> CXXFLAGS
> CXX_WARNING_FLAGS
> LDFLAGS
> LINKFLAGS
> MPC55XX_BOOTFLAGS
> OPTIMIZATION_FLAGS
> PKGCONFIG_LDFLAGS
> TEST_DL01_CPPFLAGS
> TEST_DL02_CPPFLAGS
> TEST_DL04_CPPFLAGS
> TEST_DL05_CPPFLAGS
> TEST_DL06_CPPFLAGS
> TEST_DL07_CPPFLAGS
> TEST_DL08_CPPFLAGS
> TEST_DL09_CPPFLAGS
> TEST_DL10_CPPFLAGS
> TEST_DL11_CPPFLAGS
> TEST_OPTIMIZATION_FLAGS
> TEST_TAR01_CPPFLAGS
> TEST_TAR02_CPPFLAGS
> TEST_psxftw01_CPPFLAGS
> TMS570_LINKFLAGS
> WARNING_FLAGS
> XCFLAGS
> 
> I guess it is derived from CFLAGS, etc.

Yes. The thinking is OPTIONS is user focused and can be a set of options from
that section of the gcc manual while FLAGS are build system focused? We need
FLAGS like OPTIMIZATION_FLAGS and we make the distinction that user can change
OPTIONS and if you touch FLAGS you need to be more careful. We keep the ABI
machine flags away from OPTIONS and in FLAGS.

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

Re: [PATCH] build: Use build context for custom commands

[Chris Johns]

On 12/9/2023 5:32 pm, Sebastian Huber wrote:
> On 12.09.23 08:49, Chris Johns wrote:
>> On 12/9/2023 2:15 pm, Sebastian Huber wrote:
>>> On 12.09.23 03:26, Chris Johns wrote:
>>>> On 11/9/2023 7:37 pm, Sebastian Huber wrote:
>>>>> Revert duplicated listing of TEST_OPTIMIZATION_FLAGS.
>>>> Thank you for picking this up.
>>>>
>>>> Does this change let the user control TEST_OPTIMIZATION_FLAGS and
>>>> OPTIMIZATION_FLAGS via a BSP setting in config.ini?
>>> No, this patch fixes the bld.asm(), bld.cc(), and bld.cxx() functions to 
>>> use the
>>> build item context for the flags.
>> Sure and thanks.
> 
> Ok, good. Is the patch all right to commit?

Yes.

>>> Setting OPTIMIZATION_FLAGS and TEST_OPTIMIZATION_FLAGS through the 
>>> configuration
>>> file always worked.
>> Great. I am seeing:
>>
>> OPTIMIZATION_FLAGS = -O2 -g -fdata-sections -ffunction-sections
>>
>> and data sections is an optimisation however does it complicates things for 
>> the
>> user if they play with with just -O2?
>>
>> 1. -g is debug info and not optimisation
>>
>> 2. we recommend building RTEMS with -fdata-sections -ffunction-sections so I
>> guess removing them would not be good
> 
> We can easily split up the OPTIMIZATION_FLAGS and add more options. For 
> example:
> 
> DEBUG_FLAGS = -g
> 
> OPTIMIZATION_FLAGS = -O2 -fdata-sections -ffunction-sections
> 

I think it will help.

As an idea what about DEBUGGING_OPTIONS and OPTIMIZATION_OPTIONS then
OPTIMIZATION_FLAGS is "${OPTIMIZATION_OPTIONS} ${DEBUGGING_OPTIONS}" so it
follows the gcc naming of its option grouping [1] ?

Chris

[1] https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] 6: Use GCC 13.2

[Chris Johns]

On 12/9/2023 4:43 pm, Sebastian Huber wrote:
> On 12.09.23 08:40, Chris Johns wrote:
>> On 12/9/2023 4:31 pm, Sebastian Huber wrote:
>>> On 27.07.23 13:33, Sebastian Huber wrote:
>>>> Prepare for RTEMS 6.1 release.
>>>>
>>>> Update #4921.
>>> How do we want to proceed with the tools for the RTEMS 6.1 release?
>> I need to move 6 to tar files but other tickets have taken what time I had.
> 
> The patch uses a tar file for GCC. 

Oh sorry then I am fine.

> I guess for Newlib we have to host an archive.

I am more relaxed about newlib because it's release cycle is difficult to line
up for us at a functional level. Long term the key things for gcc is being to
raise bug reports knowing the exact tarfile we have used.

>>
>>> Is GCC 13.2 still the desired GCC release?
>> What is the alternative?
> 
> Do we need one? GCC 13.2 is the best option from my point of view right now.
> 

Sorry I was wondering if you have something else in mind.

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

Re: [PATCH] build: Use build context for custom commands

[Chris Johns]

On 12/9/2023 2:15 pm, Sebastian Huber wrote:
> On 12.09.23 03:26, Chris Johns wrote:
>> On 11/9/2023 7:37 pm, Sebastian Huber wrote:
>>> Revert duplicated listing of TEST_OPTIMIZATION_FLAGS.
>> Thank you for picking this up.
>>
>> Does this change let the user control TEST_OPTIMIZATION_FLAGS and
>> OPTIMIZATION_FLAGS via a BSP setting in config.ini?
> 
> No, this patch fixes the bld.asm(), bld.cc(), and bld.cxx() functions to use 
> the
> build item context for the flags.

Sure and thanks.

> Setting OPTIMIZATION_FLAGS and TEST_OPTIMIZATION_FLAGS through the 
> configuration
> file always worked.

Great. I am seeing:

OPTIMIZATION_FLAGS = -O2 -g -fdata-sections -ffunction-sections

and data sections is an optimisation however does it complicates things for the
user if they play with with just -O2?

1. -g is debug info and not optimisation

2. we recommend building RTEMS with -fdata-sections -ffunction-sections so I
guess removing them would not be good

Chris

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

Re: [PATCH] microblaze: Fix relocation targets

[Chris Johns]

OK to push

Thanks
Chris

On 12/9/2023 5:41 am, Alex White wrote:
> Previously the addend was only used in 64 bit relocations. This
> behavior was incorrect but did not cause the RTEMS libdl tests to
> fail.
> ---
>  cpukit/libdl/rtl-mdreloc-microblaze.c | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/cpukit/libdl/rtl-mdreloc-microblaze.c 
> b/cpukit/libdl/rtl-mdreloc-microblaze.c
> index 0daba19a47..0956e22bc7 100644
> --- a/cpukit/libdl/rtl-mdreloc-microblaze.c
> +++ b/cpukit/libdl/rtl-mdreloc-microblaze.c
> @@ -141,8 +141,10 @@ rtems_rtl_elf_reloc_rela (rtems_rtl_obj*obj,
>  
>where = (Elf_Addr *)(sect->base + rela->r_offset);
>  
> +  /* Target value */
> +  target = (Elf_Addr)symvalue + addend;
>/* Final PCREL value */
> -  Elf_Word pcrel_val = symvalue - ((Elf_Word)where);
> +  Elf_Word pcrel_val = target - ((Elf_Word)where);
>  
>if (parsing) {
>  return rtems_rtl_elf_rel_no_error;
> @@ -153,7 +155,6 @@ rtems_rtl_elf_reloc_rela (rtems_rtl_obj*obj,
>  break;
>  
>case R_TYPE(64):
> -target = (Elf_Addr)symvalue + addend;
>  /* Set the lower 16 bits of where to the upper 16 bits of target */
>  write16le(where,
>(read16le(where) & 0x) | (target >> 16));
> @@ -180,18 +181,18 @@ rtems_rtl_elf_reloc_rela (rtems_rtl_obj*obj,
>  unsigned offset = addr & 3;
>  
>  /*
> - * Combine `symvalue` with `value_down` and `value_up` to form the 
> new
> + * Combine `target` with `value_down` and `value_up` to form the new
>   * values to write.
>   */
>  uint32_t new_value_down = (value_down & ((1 << (offset * 8)) - 1)) |
> -  (symvalue << (offset * 8));
> +  (target << (offset * 8));
>  uint32_t new_value_up = (value_up & ~((1 << (offset * 8)) - 1)) |
> -  (symvalue >> ((4 - offset) * 8));
> +  (target >> ((4 - offset) * 8));
>  
>  write32le((void*)addr_down, new_value_down);
>  write32le((void*)addr_up, new_value_up);
>} else {
> -write32le(where, symvalue);
> +write32le(where, target);
>}
>  }
>  break;
> @@ -208,13 +209,13 @@ rtems_rtl_elf_reloc_rela (rtems_rtl_obj*obj,
>  /*
>   * Compensate for the fact that the PC is 4 bytes ahead of the 
> instruction
>   */
> -target = pcrel_val - 4;
> +pcrel_val -= 4;
>  /* Set the lower 16 bits of where to the upper 16 bits of target */
>  write16le(where,
> -  (read16le(where) & 0x) | (target >> 16));
> +  (read16le(where) & 0x) | (pcrel_val >> 16));
>  /* Set the lower 16 bits of where + 4 to the lower 16 bits of target */
>  write16le(where + 1,
> -  (read16le(where + 1) & 0x) | (target & 0x));
> +  (read16le(where + 1) & 0x) | (pcrel_val & 0x));
>  
>  if (rtems_rtl_trace (RTEMS_RTL_TRACE_RELOC))
>printf ("rtl: R_MICROBLAZE_64_PCREL %p @ %p in %s\n",
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Use build context for custom commands

[Chris Johns]

On 11/9/2023 7:37 pm, Sebastian Huber wrote:
> Revert duplicated listing of TEST_OPTIMIZATION_FLAGS.

Thank you for picking this up.

Does this change let the user control TEST_OPTIMIZATION_FLAGS and
OPTIMIZATION_FLAGS via a BSP setting in config.ini?

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

Re: [RBW] Paul Racer Brake Noise/Vibration

[JohnS]

Hello Ben, maybe it would help the group if you were to post a picture or 
two of your current set up.

Thanks,
JohnS


On Friday, September 8, 2023 at 10:56:34 AM UTC-4 bjmi...@gmail.com wrote:

> Good to know...but if my brake is mounted on the fork, I'm not sure where 
> I'd mount a fork-mounted cable hanger. 
>
> Ben
>
> On Friday, September 8, 2023 at 9:50:52 AM UTC-5 Jay Lonner wrote:
>
>> This is a common complaint with headset-mounted cable hangers. Changing 
>> to a fork-mounted hanger usually alleviates the problem. Shovel Research 
>> just released a nice one: 
>> https://shovelresearch.com/fork-mounted-brake-cable-hanger
>>
>> Jay Lonner
>> Bellingham, WA
>>
>> Sent from my Atari 400
>>
>> On Sep 8, 2023, at 5:54 AM, Ben Mihovk  wrote:
>>
>> Good morning,
>>
>> I just got a new set of Racer (regular) brakes for my sidepull Hillborne. 
>> Everything's set up, the brakes are grabbing/stopping, but I'm getting the 
>> most horrific noises from the pads on the front brakes. I'm using the Kool 
>> Stop Thinlines that Paul sends with the brakes. I set them up following the 
>> instructions from Paul initially (no toe-in), and the brakes squealed on 
>> the first test ride. So I toed them in and now I'm getting this awful 
>> vibration when the pads touch the rims that gets louder/more intense with 
>> speed. The vibration can be felt in the saddle...all through the frame. 
>> Truly harrowing stuff here. When I full pull the brake levers, the 
>> vibration kind of goes away but I get a light squeal (even with brakes toed 
>> in). 
>>
>> I've never set up centerpull brakes or any brakes with a straddle 
>> wire/hanger. I can't see how the problem could be from anything but how the 
>> pads are hitting. I've double checked to see that the unit is centered when 
>> I tighten it. The one goofy thing I'm noticing is that the right arm of the 
>> brake seems lower because I have the pad set higher in the arm than on the 
>> left side...but I've taken the pads off completely and recentered the brake 
>> unit and I'm getting the same results.
>>
>> I've read a little about how big frames (this is a 62cm Sam) can have the 
>> vibrations because of the length of cable and how tension varies through 
>> the pull (or something like that). I've also read that this kind issue 
>> could be from cheap/flimsly brakes...but I would hope that Paul brakes 
>> would be above suspicion here. I've also heard that if something is loose 
>> on the brake assembly, the vibrations can happen.
>>
>> However...I'm convinced it's in how I have the pads set...I don't get 
>> vibrations when the pads are not toed-in...toeing in almost seems to bring 
>> about the vibrations. 
>>
>> Any ideas anyone has would be very helpful. I'm at the end of my rope and 
>> considering removing the Pauls and going back to the squisy and not very 
>> good Tektros Riv put on it originally.
>>
>> Thanks!
>> Ben in Omaha
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "RBW Owners Bunch" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to rbw-owners-bun...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/rbw-owners-bunch/4f5914bb-774a-43b7-b5b9-c943686493e9n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/rbw-owners-bunch/4f5914bb-774a-43b7-b5b9-c943686493e9n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/fee51709-7c49-4aa3-844d-441044df3b80n%40googlegroups.com.

Re: [rtems-tools]rtems-ld issue?

[Chris Johns]

On 4/9/2023 4:50 pm, zhengxiaojun wrote:
> 
> 
> 在 2023/8/31 13:39, Chris Johns 写道:
>> On 31/8/2023 3:12 pm, zhengxiaojun wrote:
>>>
>>>
>>> 在 2023/8/31 6:05, Chris Johns 写道:
>>>> On 31/8/2023 12:48 am, zhengxiaojun wrote:
>>>>> Hi,
>>>>>  I use the latest rtems-tools to generate RAP file, I found the object
>>>>> file
>>>>> become too small(elf,2184bytes==>rap,736bytes) and the file loaded failed,
>>>>> error
>>>>> message like this "load app.out error:offset past end of file: offset=736
>>>>> size=736 error."
>>>>
>>>> What arch and BSP?
>>>>
>>>>>  I reverted the rtl-rap.cpp commit(
>>>>> 0ad4aaafc20afcb5aacb7a82b0b3a8150b638975
>>>>> linker/rap: Ignore relocation records with no section), the rap file can 
>>>>> be
>>>>> loaded.
>>>>
>>>> I think the commit has the wrong ticket id, it should be 4069 ...
>>>>
>>>> https://devel.rtems.org/ticket/4069
>>>>
>>>> My guess is the length includes the relocs that have been dropped because 
>>>> they
>>>> do not have a symbol section. A reloc without a symbol section cannot be
>>>> located
>>>> because you do not know the section to locate it against.
>>>>
>>>> Are you able to review the rtems-ld code for the issue?
>>>>
>>> I found something suspicious, get_relocations(s) return all the count of
>>> relocation and write to rap file, but actual count is less, because ignore 
>>> the
>>> reloc with section=0.
>>
>> Right, this aligns with my guess. That value should the number written out 
>> and
>> it should not assume all are written.
>>
>>> This issue is similar to ticket #4781, maybe the same.
>>
>> Yeah it could. It would be nice if it is.
>>
>>> reduce count or write all relocs in rap ? I do not know which is the right
>>> solution.
>>
>> I am not sure. If relocs are needed then we have to have them and the patch 
>> you
>> isolated is wrong or needs more understanding to know why it is there. I 
>> suspect
>> an arch had an issue and this was the solution but that is guess on my part.
> 
> I tried to make the length fit the relocs write to rap file, the file can not 
> be
> loaded, it crashed. So the relocs(reloc.symsect == 0) can not be ignored, at
> least in arm.

Can you please open a ticket and can you please add the code to build into the
RAP with the commands you are using? A script would help.

> In addition, I saw a loader complaint "rtl: unsupported section:..." about
> .ARM.attributes， the arm linkcmds always keep it.
> Should it be dealt with?

The RTL may need to be taught to ignore the section.

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

[RBW] Re: Source for headset locking/key'd spacer

[JohnS]

This is what you're looking for and at a $1.00, you'll probably pay more in 
shipping.

https://www.thebicyclechain.com/product/sunlite-keyed-lock-headset-washer-394262-1.htm

I've not dealt with them, they were the cheapest I could fined.

JohnS

On Thursday, August 31, 2023 at 5:01:34 PM UTC-4 Johnny Alien wrote:

> My Roadini frame came this week (exciting) but the headset is missing the 
> locking spacing. The thin guy with the tiny nipple thing. I don't have a 
> great local shop to check with so I was going to just buy one because they 
> have to be cheap but the only one I can find it a sunlite black one. No 
> silver. Anyone know where to find one of these things? 

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/3f728760-8b09-4811-bd23-e796dfba8b43n%40googlegroups.com.

Re: [rtems-tools]rtems-ld issue?

[Chris Johns]

On 31/8/2023 3:12 pm, zhengxiaojun wrote:
> 
> 
> 在 2023/8/31 6:05, Chris Johns 写道:
>> On 31/8/2023 12:48 am, zhengxiaojun wrote:
>>> Hi,
>>>     I use the latest rtems-tools to generate RAP file, I found the object 
>>> file
>>> become too small(elf,2184bytes==>rap,736bytes) and the file loaded failed, 
>>> error
>>> message like this "load app.out error:offset past end of file: offset=736
>>> size=736 error."
>>
>> What arch and BSP?
>>
>>>     I reverted the rtl-rap.cpp commit( 
>>> 0ad4aaafc20afcb5aacb7a82b0b3a8150b638975
>>> linker/rap: Ignore relocation records with no section), the rap file can be
>>> loaded.
>>
>> I think the commit has the wrong ticket id, it should be 4069 ...
>>
>> https://devel.rtems.org/ticket/4069
>>
>> My guess is the length includes the relocs that have been dropped because 
>> they
>> do not have a symbol section. A reloc without a symbol section cannot be 
>> located
>> because you do not know the section to locate it against.
>>
>> Are you able to review the rtems-ld code for the issue?
>>
> I found something suspicious, get_relocations(s) return all the count of
> relocation and write to rap file, but actual count is less, because ignore the
> reloc with section=0.

Right, this aligns with my guess. That value should the number written out and
it should not assume all are written.

> This issue is similar to ticket #4781, maybe the same.

Yeah it could. It would be nice if it is.

> reduce count or write all relocs in rap ? I do not know which is the right
> solution.

I am not sure. If relocs are needed then we have to have them and the patch you
isolated is wrong or needs more understanding to know why it is there. I suspect
an arch had an issue and this was the solution but that is guess on my part.

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

Re: [rtems-tools]rtems-ld issue?

[Chris Johns]

On 31/8/2023 1:51 pm, zhengxiaojun wrote:
> 在 2023/8/31 6:05, Chris Johns 写道:
>> On 31/8/2023 12:48 am, zhengxiaojun wrote:
>>> Hi,
>>>     I use the latest rtems-tools to generate RAP file, I found the object 
>>> file
>>> become too small(elf,2184bytes==>rap,736bytes) and the file loaded failed, 
>>> error
>>> message like this "load app.out error:offset past end of file: offset=736
>>> size=736 error."
>>
>> What arch and BSP?
> ARM, imx6ull
> 
>>
>>>     I reverted the rtl-rap.cpp commit( 
>>> 0ad4aaafc20afcb5aacb7a82b0b3a8150b638975
>>> linker/rap: Ignore relocation records with no section), the rap file can be
>>> loaded.
>>
>> I think the commit has the wrong ticket id, it should be 4069 ...
>>
>> https://devel.rtems.org/ticket/4069
>>
>> My guess is the length includes the relocs that have been dropped because 
>> they
>> do not have a symbol section. A reloc without a symbol section cannot be 
>> located
>> because you do not know the section to locate it against.
>>
>> Are you able to review the rtems-ld code for the issue?
> I am trying to find something, but I do not know elf/rap format well. I found
> when ignore synsect==0, the GLOBAL symbol will be ignore too.
> Should the GLOBAL symbol be dealt with?
> 
> Here is part of ELF:
> Symbol table (.symtab)
> [  Nr ] Value    Size Type    Bind  Sect Name
> [    0]   NOTYPE  LOCAL    0
> [    1]   NOTYPE  LOCAL    4 $d
> [    2] 0001 011e FUNC    LOCAL    1 task_test
> [    3]   NOTYPE  LOCAL    1 $t
> [    4]   NOTYPE  LOCAL    3 $d
> [    5]   NOTYPE  LOCAL    4 .LC0
> [    6] 0030  NOTYPE  LOCAL    4 .LC3
> [    7]   NOTYPE  LOCAL    3 .LANCHOR0
> [    8] 000c  NOTYPE  LOCAL    4 .LC1
> [    9] 0038  NOTYPE  LOCAL    4 .LC4
> [   10]   NOTYPE  GLOBAL   0 putchar
> [   11]   NOTYPE  GLOBAL   0 printf
> [   12]   NOTYPE  GLOBAL   0 rtems_task_wake_after
> [   13]   NOTYPE  GLOBAL   0 puts
> [   14]   NOTYPE  GLOBAL   0 tcflush
> [   15] 0121 0054 FUNC    GLOBAL   1 appmain
> [   16]   NOTYPE  GLOBAL   0 rtems_task_start
> [   17]   NOTYPE  GLOBAL   0 cfsetispeed
> [   18]   NOTYPE  GLOBAL   0 write
> [   19]   NOTYPE  GLOBAL   0 cfsetospeed
> [   20]   NOTYPE  GLOBAL   0 read
> [   21]   NOTYPE  GLOBAL   0 tcgetattr
> [   22]   NOTYPE  GLOBAL   0 open
> [   23]   NOTYPE  GLOBAL   0 tcsetattr
> [   24]   NOTYPE  GLOBAL   0 rtems_task_create

Looking at this the change does not seem right. I cannot remember why it was
added. It may require building the supported archs without the patch to see what
happens, specifically RISCV.

Chris

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

Re: [rtems-tools] Fix shlex.join on python 3.8 and earlier

[Chris Johns]

On 31/8/2023 4:14 am, Frank Kühndel wrote:
> Hello Chris,
> 
> if I did not make any mistake, this patch works fine on OpenSUSE 15.5.

Thanks, I have pushed the change.

> I had some headaches because the source-builder tries to download the
> rtems-tools as tar.bz2 and the version with the patch is not yet on that 
> server.
> I fumbled your patch into the cached tar.bz2. That seemed to work in the end.

Ah, a clone of rtems-tools and then a `distclean configure` showed the issue :)

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

Re: [rtems-tools]rtems-ld issue?

[Chris Johns]

On 31/8/2023 12:48 am, zhengxiaojun wrote:
> Hi,
>    I use the latest rtems-tools to generate RAP file, I found the object file
> become too small(elf,2184bytes==>rap,736bytes) and the file loaded failed, 
> error
> message like this "load app.out error:offset past end of file: offset=736
> size=736 error."

What arch and BSP?

>    I reverted the rtl-rap.cpp commit( 0ad4aaafc20afcb5aacb7a82b0b3a8150b638975
> linker/rap: Ignore relocation records with no section), the rap file can be 
> loaded.

I think the commit has the wrong ticket id, it should be 4069 ...

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

My guess is the length includes the relocs that have been dropped because they
do not have a symbol section. A reloc without a symbol section cannot be located
because you do not know the section to locate it against.

Are you able to review the rtems-ld code for the issue?

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

Re: [PATCH v2 0/6] Add libdl support to MicroBlaze

[Chris Johns]

Hi Alex,

The libdl parts are OK to push.

I am fine with the `wscript` change however Sebastian is away at the moment. I
will leave that part of change with you and Joel to decide what to do. :)

Chris

On 30/8/2023 12:05 pm, Alex White wrote:
> Hi,
> 
> This patch set adds libdl support to MicroBlaze. All tests pass except for 
> dl05
> and dl06. To get dl07, dl08, and dl09 to pass, I added `-u__extendsfdf2` to 
> the
> link options.
> 
> v2:
> - Remove changes to dl07, dl08, and dl09 source code
> - Add link options to dl07, dl08, and dl09
> 
> Alex
> 
> Alex White (6):
>   microblaze: Add libdl support
>   microblaze: Align exception-related sections
>   microblaze: Add dl06 to expected failures
>   microblaze: Add dl05 to expected failures
>   build: Allow enabled-by in ldflags for link_cc and link_cxx
>   microblaze: Add link options to dl07, dl08, and dl09
> 
>  cpukit/libdl/rtl-mdreloc-microblaze.c | 297 ++
>  cpukit/libdl/rtl-tls.c|   2 +-
>  .../microblaze/include/machine/elf_machdep.h  |  83 +
>  .../microblaze/microblaze_fpga/linkcmds.yml   |   8 +-
>  .../microblaze_fpga/tstkcu105_qemu.yml|  10 +-
>  spec/build/cpukit/cpumicroblaze.yml   |   3 +
>  spec/build/cpukit/objdl.yml   |   2 +
>  spec/build/cpukit/objdlmicroblaze.yml |  15 +
>  spec/build/cpukit/optlibdl.yml|   1 +
>  spec/build/testsuites/libtests/dl07.yml   |   5 +-
>  spec/build/testsuites/libtests/dl08.yml   |   5 +-
>  spec/build/testsuites/libtests/dl09.yml   |   5 +-
>  wscript   |  13 +-
>  13 files changed, 437 insertions(+), 12 deletions(-)
>  create mode 100644 cpukit/libdl/rtl-mdreloc-microblaze.c
>  create mode 100644 cpukit/score/cpu/microblaze/include/machine/elf_machdep.h
>  create mode 100644 spec/build/cpukit/objdlmicroblaze.yml
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-tools PATCH] rtemstoolkit: Fix shell execution

[Chris Johns]

On 30/8/2023 5:44 am, Joel Sherrill wrote:
> A bit more feedback. I got this failure on CentOS 7 building sparc-rtems6 
> tools.
> 
> + cd rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8
> + ./waf distclean configure --prefix=/home/joel/rtems-work/tools/6
> 'distclean' finished successfully (0.001s)
> Setting top to                           :
> /home/joel/rtems-work/rtems-source-builder/rtems/build/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8-1/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8
> Setting out to                           :
> /home/joel/rtems-work/rtems-source-builder/rtems/build/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8-1/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8/build
> invalid version file: 'module' object has no attribute 'join'
> (complete log in
> /home/joel/rtems-work/rtems-source-builder/rtems/build/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8-1/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8/build/config.log)
> shell cmd failed: /bin/sh -ex
>  
> /home/joel/rtems-work/rtems-source-builder/rtems/build/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8-1/do-build
> error: building rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8-1
> 
> I tried the same target on Rocky 9 and did not get this error.
> 
> I loaded the software collection for Python 3.6 on CentOS 7 and got this:
> 
> + ./waf distclean configure --prefix=/home/joel/rtems-work/tools/6
> 'distclean' finished successfully (0.001s)
> Setting top to                           :
> /home/joel/rtems-work/rtems-source-builder/rtems/build/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8-1/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8
> Setting out to                           :
> /home/joel/rtems-work/rtems-source-builder/rtems/build/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8-1/rtems-tools-3ea0c249346fda427bf0d3c169aa3e7c2a521df8/build
> invalid version file: module 'shlex' has no attribute 'join'
> 
> Not sure what the common factor on all this is.

The `.join()` is documented with [1]:

  New in version 3.8.

I did not notice this.

Chris

[1] https://docs.python.org/3/library/shlex.html#shlex.join
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-tools PATCH] rtemstoolkit: Fix shell execution

[Chris Johns]

> On 29 Aug 2023, at 6:24 pm, Frank Kühndel  
> wrote:
> 
> Hello Chris,
> 
> our continuous integration server found an issues with this patch
> ("module 'shlex' has no attribute 'join'"):

Frank, thanks for the post and the insight. I saw the build break in Joel’s 
build but I could not see the reason. This will help. 

I will look into this tomorrow. Sorry for the breakage. 

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

[RBW] Re: Riv Ride: Chicago Lakefront Trail Recap

[JohnS]

Thank you for sharing Leah, looks like it was a great ride!

JohnS

On Sunday, August 27, 2023 at 10:19:35 PM UTC-4 Bicycle Belle Ding Ding! 
wrote:

> We had 10 riders join us for our Chicago ride yesterday! 
> In attendance: 
> 1 silver Appaloosa (fun fact: it belonged to Will Keating) 
> 1 green Hunq
> 1 A. Homer Hilsen
> 2 blue Sam Hillbornes
> 1 lime olive Clem L
> 1 yellow Legolas
> 1 blue Rivendell road custum
> 1 red Erickson
> 1 raspberry Platypus
>
> We began at Mack’s Bike and Goods in Evanston, where we were greeted 
> warmly by Sam and Kelly Mack. They graciously set out coffee and 
> refreshments, took photos and talked all the bike talk with our riders as 
> we shopped their excellent store. If you are in the area, please go and see 
> them; they carry all of our favorite things. We took photos and belatedly 
> hit the road.
>
> We had several miles to ride before connecting with Chicago’s famous 
> Lakefront Trail. The clouds were thick and the winds were high. We dodged 
> triathletes, throngs of people, and later, the Chicago Bears fans. We were 
> treated to gorgeous scenery and the sounds of crashing waves on the shores 
> of Lake Michigan as we pedaled along our path. The rain held off and we 
> arrived intact (minus one Legolas front cantilever brake) and upright, 
> ready for lunch. We at the famous Billy Goat Tavern and then some of us 
> peeled off for other destinations. The Lone Wolf and I were fortunate to 
> keep 2 of our guides, Sean and Davey, who graciously offered to ride us 
> back to the trail that would lead us to Evanston. But first, they escorted 
> us through the heart of Chicago, where we enjoyed fabulous bike 
> infrastructure (including an elevated bike path!) and viewings of the 
> city’s historical buildings. Marc and I had over 40 miles when we arrived 
> back at the shop.
>
> Thank you to everyone who joined us! Below are a few photos, but even 
> better, a link to the Post Ride Video on my Instagram. I’ll be changing the 
> privacy back to “private” in a week or so, so try to view it before then.
>
> Leah
>
> Instagram: 
> https://www.instagram.com/reel/CweJZD5gkCE/?igshid=NzZhOTFlYzFmZQ==
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/68575573-5287-4ddc-b18e-3ab37bd6c53cn%40googlegroups.com.

Re: [PATCH 2/5] testsuites/libtests: Remove floats from libdl tests

[Chris Johns]

On 28/8/2023 2:12 pm, Alex White wrote:
> On Sun, Aug 27, 2023 at 8:38 PM Chris Johns  wrote:
>> The floats need to stay to make sure there are no issues with this type. I 
>> see
>> the tests with floats as valid.
>>
>> Is the only missing function `__extendsfdf2`?
> 
> Yes, that is the only missing function. If I change the floats to doubles, the
> need for `__extendsfdf2` goes away and the tests pass. Is that an acceptable
> solution?

I would happy with doubles being added so they are tested as well but that is
also outside the scope of your effort :)

Is it easier to add a Microblaze conditional for the use of a double to the base
image and to forced the symbol to be linked in?

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

Re: [PATCH 1/5] microblaze: Add libdl support

[Chris Johns]

On 28/8/2023 11:30 am, Alex White wrote:
> ---
>  cpukit/libdl/rtl-mdreloc-microblaze.c | 291 ++
>  cpukit/libdl/rtl-tls.c|   2 +-
>  .../microblaze/include/machine/elf_machdep.h  |  83 +
>  spec/build/cpukit/cpumicroblaze.yml   |   3 +
>  spec/build/cpukit/objdl.yml   |   2 +
>  spec/build/cpukit/objdlmicroblaze.yml |  15 +
>  spec/build/cpukit/optlibdl.yml|   1 +
>  7 files changed, 396 insertions(+), 1 deletion(-)
>  create mode 100644 cpukit/libdl/rtl-mdreloc-microblaze.c

There is an additional call in my changes to fix trampolines I have posted for
review. You will need to add that for the microblaze.

My trampoline fixes change the allocation order of the sections and that has
exposed an issue on powerpc that I am looking into. That issue will be a
separate patch.

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

Re: [PATCH 2/5] testsuites/libtests: Remove floats from libdl tests

[Chris Johns]

On 28/8/2023 11:30 am, Alex White wrote:
> This patch addresses an issue seen with MicroBlaze in the dl07, dl08,
> and dl09 tests by removing the use of floats. The issue relates to the
> fact that the MicroBlaze BSPs use software floating point routines. Any
> float passed to `printf` is converted to a double automatically because
> of default argument promotion with variadic functions. This conversion
> is handled by the `__extendsfdf2` libgcc function. The problem is that
> the main test executable does not use floating point code, so the
> `__extendsfdf2` function is not linked in. This causes a problem when
> loading the test objects.
> 
> This patch removes the use of floats so that BSPs that use software
> floating point routines can still run the tests.

The floats need to stay to make sure there are no issues with this type. I see
the tests with floats as valid.

Is the only missing function `__extendsfdf2`?

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

[RBW] Re: 26” MTB Tire Advice

[JohnS]

Hello Bones,

I built up a Specialized M2 Stumpjumper with Panaracer Gravel King SK tires 
that are 26 x 2.1. I use it as a gravel bike. The tires are for best for 
gravel and light duty single track, not as supple as RH Rat Trap Pass, 
which are better suited for road and hard packed cinder/gravel rail trails. 
I got the SK from e-bay for $107 for the pair. I got the Rat Trap Pass 
tires used from a list member.

https://www.ebay.com/itm/303917075015

JohnS




On Friday, August 25, 2023 at 12:34:32 PM UTC-4 Edwin W wrote:

> I find Schwalbe usually has some good offerings. You can search by "inch" 
> to find 26x2,2.1,2.25...
>
> Edwin
>
> On Friday, August 25, 2023 at 11:22:45 AM UTC-5 Bill Lindsay wrote:
>
>> Do you know ANYBODY who used to ride?  26" tires accumulate in any garage 
>> that hosts riders.  Find some for free!  Or is it so late that everybody 
>> has already thrown everything away?  
>>
>> BL in EC
>>
>> On Friday, August 25, 2023 at 8:59:55 AM UTC-7 Bones wrote:
>>
>>> I recently pulled my wife’s old Cannondale F5 hardtail out of 
>>> hibernation with the intention of moving it along, but she now has a 
>>> renewed interest in it. It cleaned up nicely, but the tires are falling 
>>> apart. It looks like it can comfortably fit a 26x2.25, but I haven’t used a 
>>> 26” tire since the early 90’s so I don’t know where to start. If anyone can 
>>> point me to to a decent all around trail tire that doesn’t break the bank, 
>>> I’d greatly appreciate it.
>>>
>>> Bones
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/94a06456-3598-4dd2-a56f-2cb43049788bn%40googlegroups.com.

[RBW] Re: FS: QuickBeam 58 cm

[JohnS]

Hello Bill,

FWIW, my orange QB has the same "frenchie mid fork tabs". The work fine and 
they seem to be original to the bike.

JohnS


On Thursday, August 24, 2023 at 1:46:22 PM UTC-4 Bill Lindsay wrote:

> Your OP claimed that all the details were on the Crust site.  That listing 
> has been deleted, and the one that is now "active" doesn't have an explicit 
> build list.  It looks like there's a dynamo hub, but in some of the photos 
> there's a headlamp, and others not.  Your buyer may want an enumerated list 
> of what they are actually buying.  An entrepreneurial type may see that 
> list as a project to sell down parts and end up with a super cheap QB 
> frameset!  
>
> Also, what's the story with the fork braze ons.  Were those factory?  Or 
> did you have that changed?  I'm not used to seeing frenchie mid fork tabs 
> like that on a Rivendell.
>
> Bill Lindsay
> El Cerrito, CA
>
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/e7694a6b-6d26-4146-b48f-dd3ef271a568n%40googlegroups.com.

Re: (libdl) Fwd: New Defects reported by Coverity Scan for RTEMS

[Chris Johns]

On 22/8/2023 10:02 am, Gedare Bloom wrote:
> flag it as a false positive.

I agree.

> g7 is a global register that is reserved for system / compiler use in
> the sparc ABI

The reigster is set up by the operating system out of the view of Coverity. I
took the code from:

https://git.rtems.org/rtems/tree/cpukit/score/cpu/sparc/include/rtems/score/cpuimpl.h#n242

Chris


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

Re: Networking examples

[Chris Johns]

On 18/8/2023 12:54 am, Gedare Bloom wrote:
> I don't think that "--with-rtems" is a valid command line option to
> use. I guess RSB should be a little more noisy about unknown command
> line options.

The --with-* and --without-* options align to the autoconf type options where
users can override some defaults. The reason the RSB cannot say anything is it
does not know what is needed or used.

The --with-*/--without-* options define a specific type of macro the config
scripts can use to key specific functionality around. The RSB python code which
handles the command line and reports any errors does not know all the config
logic paths in advance so it cannot say if a value is needed or right. This is
also the reason a generic approach is being used rather than being able to
specify specific options for specific purposes.

Resolving the issue might be possible with a lot of work and it would require a
number of changes in a few places based around some form of a config definition
of the with and without options.

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

Re: [PATCH rtems-tools] tester/report: Apply test excludes to fatal-error

[Chris Johns]

On 18/8/2023 11:51 pm, Kinsey Moore wrote:
> On Thu, Aug 17, 2023 at 7:25 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
> On 17/8/2023 10:43 pm, Kinsey Moore wrote:
> > On Wed, Aug 16, 2023 at 9:47 PM Chris Johns  <mailto:chr...@rtems.org>
> > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> wrote:
> >
> >     On 17/8/2023 7:36 am, Kinsey Moore wrote:
> >     > Before the fatal-error test result type was introduced, 
> minimum.exe was
> >     > classified as an invalid test since it lacked a proper test 
> header and
> >     > trailer. This applies the test exclusions to all test states to 
> avoid
> >     > this happening again in the future.
> >
> >     I do not think this right. What state are you seeing?
> >
> >
> > The minimum test fails with a fatal error:
> >     "*** FATAL ***",
> >     "fatal source: 0 (INTERNAL_ERROR_CORE)",
> >     "fatal code: 5 (INTERNAL_ERROR_THREAD_EXITTED)",
> >     "RTEMS version: 6.0.0.c76c98c344d803fa80361884c4cc79f0b3607ec8",
> >     "RTEMS tools: 12.3.1 20230626 (RTEMS 6, RSB
> > 8e568b2ca3489d6bfa48e1d29618ea9b48a5b408, Newlib 4c7d0df)",
> >     "executing thread ID: 0x09010001",
> >
> > As far as I'm aware, this is a normal exit for minimum since it does 
> nothing
> > which includes not properly exiting the test by allowing Init() to 
> return.
> >
> >
> >     While we cannot determine the pass state because there is no end
> message we can
> >     determine if the test has timed out or is too long and they should 
> be
> a fail.
> >
> >
> > This is not timing out or taking too long as per the above. I could 
> move the
> > check to cover just the invalid/fatal-error checks instead of all of 
> them
> if you
> > prefer.
> 
> This looks to me like an issue in minimum and it looks to me like minimal 
> has
> some other issue. What is printing out the message? If there is code in 
> minimal
> to print this error then why not print a normal test start and end banner?
> 
> My understanding is minimal has not means to output anything.
> 
> 
> It seems to be intentional:
> static void *Init( uintptr_t ignored )
> {
>   /* initialize application */
> 
>   /* Real application would call idle loop functionality */
> 
>   /* but in this case, just return and fall into a fatal error */
> 
>   return NULL;
> }
> 
> Even if no console is requested (not even simple console), BSP_output_char is
> still available.

Is this happening for all BSPs and all archs?

When the original filter for minimal was made minimal never reported anything so
what has changed to make this happen?

I think what we have is right because it does not suppress real issues minimal
could have if there is a regression. I think there is more to this we need to
understand before we decide to change the tester filtering.

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

[RBW] Re: New Build Day! Two Speed Road Bike

[JohnS]

Very cool build Bill, should be fun ride. I can see the value in a two 
speed, I think I'll do one sometime.

JohnS


On Saturday, August 19, 2023 at 1:06:29 PM UTC-4 Bill Lindsay wrote:

> I pounced on a local 59cm Romulus.  That bike has long been on my list of 
> "I'd ride THAT" bikes, but it wasn't a terribly high priority.  This 
> opportunity presented itself and got to work.  
>
> Cutting to the chase: here's the album  
> https://www.flickr.com/photos/45758191@N04/albums/72177720310604809
>
> The bike was a mostly original Riv complete Rom build.  It had a mustache 
> bar cockpit, and Silver bar con shifters, but otherwise was pretty much 
> stock.  It's got nicks and scratches beau-sage but was in mechanically fine 
> shape.  
>
> This is going to be a versatile road platform upon which I could implement 
> a number of different build concepts.  The one that had been sticking in my 
> mind, though, was a front-derailleur only road two speed.  The forthcoming 
> Roaduno is allegedly going to have both a rear der hanger as well as the 
> braze on bits to do a FRONT shifter.  Some listers vocally proclaimed that 
> "silly", but it seems pretty sensible to me.  I had not executed a build of 
> that kind, and this was my shot.  
>
> From "inventory" I pulled together a nice two speed road bike kit:
>
> The wheelset was "inherited" from my Crust Florida Man., which lives in 
> Michigan.  When I built that bike, I used stuff I had on-hand, including a 
> pair of HED Belgium rims.  Those are almost impossible to get anymore, so I 
> built a new set of wheels around cheaper and wider rims to bring that 
> wheelset back to California.  I just grabbed them off the hook.  I put a 
> pair of used Compass Steilacoom 700x38 knobbier on there (with latex 
> tubes!) and grabbed a 16/18 DOS ENO freewheel.  The rear hub is Surly Ultra 
> New.  The front is a Phil Track hub.  I tossed on a pair of Shimano 
> "CLICKR" SPD pedals.  
>
> The drivetrain centers on a Campy Centaur 172.5mm square taper cranks
> Origin8 sealed BB (110.5)
> blue chain guard
> 39T tripleizer ring
> 24T ring from the original Rom build
>
> The front derailleur is a heavily modified FSA that I had from earlier 
> experiments.  The shift lever is a Shimano Ultegra "triple-color" model 
> from he 1990s with an awesome return spring inside to make it really light 
> action.  The tensioner is a modified XT rapid rise.  There's no return 
> spring inside, from a desmodromic exploration.  I was able to adjust one 
> limit screw so it hits the 16T cog.  The other limit screw was too short, 
> so I replaced it with a long socket head M4x0.7mm bolt.  I can turn that 
> one with my fingers.  Dialed out the RD "falls" to the 18T cog.  Dialed in 
> I can push it to the 16.  
>
> The cockpit includes other parts box items.  I got the Salsa stem really 
> cheap only to find it's like 25.8mm in clamp diameter.  I was waiting for a 
> working-class build to force it to 26.0mm.  I spread it wide and got a 
> 420mm Nitto Noodle in there.  I used the stock brake levers and some orange 
> Newbaums.  I kept the original Nitto 65 seat post and installed the Brooks 
> Pro saddle reclaimed from "Shawn's Hetchins".  
>
> Now it's ready to ride (after the shellac dries).  Maybe this will inspire 
> some of the Roaduno builds later this year.  Enjoy
>
> Bill Lindsay
> El Cerrito, CA
>
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/05041a9c-753f-4bd6-b5d8-e45999a94a41n%40googlegroups.com.

[RBW] Re: Rivendell In Paris

[JohnS]

Thank Eric!

La chouette = "the owl" or "very useful word you can use to describe 
something that you like or you think is nice or cool." Seems most 
appropriate.

JohnS

On Friday, August 18, 2023 at 4:19:36 AM UTC-4 campyo...@me.com wrote:

> Guess what I found in Paris! A local Rivendell dealer! 20 Boulevard 
> Magenta in the 10th.
>
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/a92eb76f-be03-4158-8b16-ef81ab8d221bn%40googlegroups.com.

Re: [PATCH rtems-tools] tester/report: Apply test excludes to fatal-error

[Chris Johns]

On 17/8/2023 10:43 pm, Kinsey Moore wrote:
> On Wed, Aug 16, 2023 at 9:47 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
> On 17/8/2023 7:36 am, Kinsey Moore wrote:
> > Before the fatal-error test result type was introduced, minimum.exe was
> > classified as an invalid test since it lacked a proper test header and
> > trailer. This applies the test exclusions to all test states to avoid
> > this happening again in the future.
> 
> I do not think this right. What state are you seeing?
> 
> 
> The minimum test fails with a fatal error:
>     "*** FATAL ***",
>     "fatal source: 0 (INTERNAL_ERROR_CORE)",
>     "fatal code: 5 (INTERNAL_ERROR_THREAD_EXITTED)",
>     "RTEMS version: 6.0.0.c76c98c344d803fa80361884c4cc79f0b3607ec8",
>     "RTEMS tools: 12.3.1 20230626 (RTEMS 6, RSB
> 8e568b2ca3489d6bfa48e1d29618ea9b48a5b408, Newlib 4c7d0df)",
>     "executing thread ID: 0x09010001",
> 
> As far as I'm aware, this is a normal exit for minimum since it does nothing
> which includes not properly exiting the test by allowing Init() to return.
> 
> 
> While we cannot determine the pass state because there is no end message 
> we can
> determine if the test has timed out or is too long and they should be a 
> fail.
> 
> 
> This is not timing out or taking too long as per the above. I could move the
> check to cover just the invalid/fatal-error checks instead of all of them if 
> you
> prefer.

This looks to me like an issue in minimum and it looks to me like minimal has
some other issue. What is printing out the message? If there is code in minimal
to print this error then why not print a normal test start and end banner?

My understanding is minimal has not means to output anything.

Chris

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

Re: [PATCH] spec/cpukit: Omit Cortex-M from libdebugger build

[Chris Johns]

On 18/8/2023 7:01 am, Kinsey Moore wrote:
> On Thu, Aug 17, 2023 at 7:11 AM Kinsey Moore  <mailto:kinsey.mo...@oarcorp.com>> wrote:
> 
> On Wed, Aug 16, 2023 at 9:42 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
> On 17/8/2023 6:30 am, Kinsey Moore wrote:
> > The current ARM support in libdebugger does not cover Cortex-M 
> series
> > cores since it requires support for CP14 system register accessor
> > instructions. Cortex-M series cores support debug monitor mode, but 
> its
> > configuration is accessed by memory mapped registers instead of 
> using
> > CP14. This omits building libdebugger from BSPs that use a cortex-m 
> ABI
> > flag.
> 
> The ARM libdebugger has support to use memory mapped registers. It is
> determined
>  by the ROM and then rtems_debugger_arm_debug_registers. I think the 
> code
> currently assume CP14 instructions but I think that could be made
> conditional
> where needed?
> 
> Are these builds of Cortex-M processors able to support libdebugger?
> 
> I have been rejecting changes like this unless there is a reason it
> cannot be
> made to work. Are there reasons it cannot be made to work?
> 
> 
> As to my current understanding, I believe that the Cortex-M3/4/7 cores can
> support libdebugger via their exclusive monitor mode. I'll see if I can 
> work
> around the CP14 issues instead.
> 
> 
> Reading into the relevant Architecture and Technical reference manuals, the 
> ROM
> tables in the Cortex-M cores do not expose information about the debug and 
> data
> watchpoint blocks. It looks like all the breakpoint (0xE0002000) and 
> watchpoint
> (0xE0001000) controls are the same IP at the same address across the Cortex-M
> line, but are in no way compatible with the CP14-based breakpoint and 
> watchpoint
> blocks in the Cortex-A/R lines of cores. The Cortex-M cores require a nearly
> unrelated libdebugger implementation.

Thanks for this and looking into it. I am fine with the change now we understand
it is not compatible. It sounds like a new back end would be cleaner for both
types of devices.

The patch is approved.

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

Re: [PATCH rtems-tools] tester/report: Apply test excludes to fatal-error

[Chris Johns]

On 17/8/2023 7:36 am, Kinsey Moore wrote:
> Before the fatal-error test result type was introduced, minimum.exe was
> classified as an invalid test since it lacked a proper test header and
> trailer. This applies the test exclusions to all test states to avoid
> this happening again in the future.

I do not think this right. What state are you seeing?

While we cannot determine the pass state because there is no end message we can
determine if the test has timed out or is too long and they should be a fail.

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

Re: [PATCH] spec/cpukit: Omit Cortex-M from libdebugger build

[Chris Johns]

On 17/8/2023 6:30 am, Kinsey Moore wrote:
> The current ARM support in libdebugger does not cover Cortex-M series
> cores since it requires support for CP14 system register accessor
> instructions. Cortex-M series cores support debug monitor mode, but its
> configuration is accessed by memory mapped registers instead of using
> CP14. This omits building libdebugger from BSPs that use a cortex-m ABI
> flag.

The ARM libdebugger has support to use memory mapped registers. It is determined
 by the ROM and then rtems_debugger_arm_debug_registers. I think the code
currently assume CP14 instructions but I think that could be made conditional
where needed?

Are these builds of Cortex-M processors able to support libdebugger?

I have been rejecting changes like this unless there is a reason it cannot be
made to work. Are there reasons it cannot be made to work?

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

Re: libdl support for base image TLS variables

[Chris Johns]

On 17/8/2023 11:57 am, Joel Sherrill wrote:
> On Wed, Aug 16, 2023, 8:30 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
> On 17/8/2023 6:34 am, Gedare Bloom wrote:
> > On Mon, Aug 14, 2023 at 10:05 PM  <mailto:chr...@rtems.org>> wrote:
> >>
> >> These patches add support to rtems.git and rtems-tools.git to
> >> provide access to TLS variables in the base from loaded code.
> >> The changes contain the ground work to resolving #4920 which is
> >> a blocker for the release of 6.
> >>
> >> This change is required due to the regression in libdl due to the
> >> change in newlib to use TLS variables for reneterant data.
> >>
> >> The rtems.git patch can be applied before the rtems-tools.git
> >> patch. If the tools are updated and the libdl code is not present
> >> the tests fail with linker errors. If the tools change is
> >> not present the test will link but it will continue to fail.
> >>
> >> The currently supported archs that build are:
> >>
> >>  - aarch64
> >>  - arm
> >>  - powerpc
> >>  - sparc
> >>
> >> The follow are to be completed and do not build:
> >>
> >>  - bfin
> >>  - i386
> >>  - lm32
> >>  - m68k
> >>  - mips
> >>  - moxie
> >>  - riscv
> >>  - v850
> >>
> >> We need to add support for these architectures if they support TLS.
> >>
> > We are deprecating v850. It might be worth considering whether some of
> > these other architectures should also be deprecated, especially if no
> > one is able/willing to add TLS for them.
> 
> From Joel's comments on #4920 some have TLS but the newlib support has 
> not been
> updated. Newlib TLS support for reent is a nice and welcomed feature but 
> not
> having newlib TLS support means the arch is performing as before.
> 
> Is TLS off on some architectures?

I do not know.

> Is that a column missing in the table I added?

I suggest that becomes a different thread so the topic is not lost here.

> The other TSL issue is gdb is broken. If you attempt to print errno you 
> will be
> told TLS is not supported by gdb for this OS.
> 
> That seems harder. 

I do not know how this fixed. It only showed up after the newlib switch
happened. That was July 2022 so we have to fix gdb to have it resolved as
winding back the newlib change is now not possible.

> A review of archs should happen before 6 is released so we can indicate 
> which we
> will remove for 7. What have we indicated is to be removed in 7?
> 
>  SH, v850, and sparc64.
> 

I suggest new thread so this is not lost in this one.

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

Re: libdl support for base image TLS variables

[Chris Johns]

On 17/8/2023 6:34 am, Gedare Bloom wrote:
> On Mon, Aug 14, 2023 at 10:05 PM  wrote:
>>
>> These patches add support to rtems.git and rtems-tools.git to
>> provide access to TLS variables in the base from loaded code.
>> The changes contain the ground work to resolving #4920 which is
>> a blocker for the release of 6.
>>
>> This change is required due to the regression in libdl due to the
>> change in newlib to use TLS variables for reneterant data.
>>
>> The rtems.git patch can be applied before the rtems-tools.git
>> patch. If the tools are updated and the libdl code is not present
>> the tests fail with linker errors. If the tools change is
>> not present the test will link but it will continue to fail.
>>
>> The currently supported archs that build are:
>>
>>  - aarch64
>>  - arm
>>  - powerpc
>>  - sparc
>>
>> The follow are to be completed and do not build:
>>
>>  - bfin
>>  - i386
>>  - lm32
>>  - m68k
>>  - mips
>>  - moxie
>>  - riscv
>>  - v850
>>
>> We need to add support for these architectures if they support TLS.
>>
> We are deprecating v850. It might be worth considering whether some of
> these other architectures should also be deprecated, especially if no
> one is able/willing to add TLS for them.

From Joel's comments on #4920 some have TLS but the newlib support has not been
updated. Newlib TLS support for reent is a nice and welcomed feature but not
having newlib TLS support means the arch is performing as before.

The other TSL issue is gdb is broken. If you attempt to print errno you will be
told TLS is not supported by gdb for this OS.

A review of archs should happen before 6 is released so we can indicate which we
will remove for 7. What have we indicated is to be removed in 7?

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

Re: [PATCH] libdl: Add support to import base image TLS symbols

[Chris Johns]

Thanks for the detailed review. It is so nice to have this happen.

I will post v2 soon.

On 17/8/2023 6:55 am, Gedare Bloom wrote:
> On Mon, Aug 14, 2023 at 10:05 PM  wrote:
>>
>> From: Chris Johns 
>>
>> This change requires an rtems-tools update for symbol generation.
>>
>> Working architectures:
>>  - aarch64
>>  - arm
>>  - powerpc
>>  - sparc
>>
>> Updates #4920
>> ---
>>  cpukit/include/rtems/rtl/rtl-sym.h |  23 -
>>  cpukit/include/rtems/rtl/rtl.h |   6 +-
>>  cpukit/libdl/rtl-elf.c |  20 +++-
>>  cpukit/libdl/rtl-mdreloc-aarch64.c |   6 +-
>>  cpukit/libdl/rtl-mdreloc-arm.c |   3 +-
>>  cpukit/libdl/rtl-mdreloc-powerpc.c |  18 +++-
>>  cpukit/libdl/rtl-mdreloc-sparc.c   | 152 -
>>  cpukit/libdl/rtl-sym.c |  36 ++-
>>  cpukit/libdl/rtl-tls.c | 111 +
>>  cpukit/libdl/rtl-tls.h |  51 ++
>>  cpukit/libdl/rtl.c |   6 +-
>>  spec/build/cpukit/objdl.yml|   1 +
>>  testsuites/libtests/dl11/dl-load.c |  27 -
>>  13 files changed, 408 insertions(+), 52 deletions(-)
>>  create mode 100644 cpukit/libdl/rtl-tls.c
>>  create mode 100644 cpukit/libdl/rtl-tls.h
>>
>> diff --git a/cpukit/include/rtems/rtl/rtl-sym.h 
>> b/cpukit/include/rtems/rtl/rtl-sym.h
>> index 0d29a6ae40..9eef9a1b7b 100644
>> --- a/cpukit/include/rtems/rtl/rtl-sym.h
>> +++ b/cpukit/include/rtems/rtl/rtl-sym.h
>> @@ -62,6 +62,22 @@ typedef struct rtems_rtl_symbols
>>size_t   nbuckets;
>>  } rtems_rtl_symbols;
>>
>> +/**
>> + * A TLS variable offset call. There is one per base image TLS
>> + * variable.
>> + */
>> +typedef size_t (*rtems_tls_offset_func)(void);
>> +
> rtems_tls_xxx is a new naming prefix. Is this stuff only specific to
> rtl? should be rtems_rtl_tls_...?
> 
> or, do we need to add a new tls header file and interface for this
> stuff, in case it would be needed outside of the rtl?

I will change the function call to rtems_rtl_tls_.

Yes an score way to provide the base would be welcome but that is out of scope
for this change. I am sorry but I have no time to invest in adding something new
the score like this.

>> +/**
>> + * A TLS symbol offset entry. It is used with an exported symbol table
>> + * to find a TSL table offset for a variable at runtime.
> s/TSL/TLS
> 
>> + */
>> +typedef struct rtems_tls_offset

I have fixed this as well.

>> +{
>> +  size_tindex;  /** exported symbol table index */
>> +  rtems_tls_offset_func offset; /** TLS offset function */
>> +} rtems_tls_offset;
>> +
>>  /**
>>   * Open a symbol table with the specified number of buckets.
>>   *
>> @@ -101,10 +117,15 @@ void rtems_rtl_symbol_table_close (rtems_rtl_symbols* 
>> symbols);
>>   * @param obj The object table the symbols are for.
>>   * @param esyms The exported symbol table.
>>   * @param size The size of the table in bytes.
>> + * @param tls_offsets The TLS offsets table. If NULL none provided.
>> + * @param tls_size The number TLS offset entries in the table..
> two periods, "number of"

Fixed

> 
>> +
> extra blank line

Fixed

> 
>>   */
>>  bool rtems_rtl_symbol_global_add (rtems_rtl_obj*   obj,
>>const unsigned char* esyms,
>> -  unsigned int size);
>> +  unsigned int size,
>> +  rtems_tls_offset*tls_offsets,
>> +  unsigned int tls_size);
>>
>>  /**
>>   * Find a symbol given the symbol label in the global symbol table.
>> diff --git a/cpukit/include/rtems/rtl/rtl.h b/cpukit/include/rtems/rtl/rtl.h
>> index 0fd4e74cdf..aaaeb7b592 100644
>> --- a/cpukit/include/rtems/rtl/rtl.h
>> +++ b/cpukit/include/rtems/rtl/rtl.h
>> @@ -393,9 +393,13 @@ bool rtems_rtl_path_prepend (const char* path);
>>   *
>>   * @param esyms The exported symbol table.
>>   * @param count The size of the exported symbol table.
>> + * @param tls_offsets The TLS offsets table. If NULL none provided.
>> + * @param tls_size The number TLS offset entries in the table..
> two periods

Fixed

> 
>>   */
>>  void rtems_rtl_base_sym_global_add (const unsigned char* esyms,
>> -unsigned int count);
>> +unsigned int count,
>> +

[RBW] Re: Broken shifters

[JohnS]

If that doesn't help, you could repurpose them as key chains. I did that 
with some old Campy down tube shifters recently.

JohnS

On Wednesday, August 16, 2023 at 9:05:13 AM UTC-4 JohnS wrote:

> Hello Pam,
>
> I had a problem with Suntour power shifters (ratchet mechanism just like 
> the Silvers) which caused the ratchet to not work, sounded like it was 
> grinding or slipping. I found that by taking the shifter apart, cleaning 
> the washers and applying a thin coat of light oil helped. Worth a try. Not 
> sure if the oil is recommended or not, maybe someone else can chime in.
>
> Good luck,
> JohnS
>
> On Tuesday, August 15, 2023 at 4:29:08 PM UTC-4 Pam Bikes wrote:
>
>> I have several broken Silver shifters.  The power ratchet doesn't work 
>> any more.  My question is if I can get a part to fix the ratchet.  If not, 
>> should I throw them in the metal recycling or is there anything I can use 
>> later?  I'm not a mechanical person.  I just know the ratchet wouldn't hold 
>> after I replaced the plastic washer and when I put a new shifter on, it 
>> worked.  
>
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/84497d87-d98b-4dbc-a2e4-e5cbbe9c2c3en%40googlegroups.com.

[RBW] Re: Broken shifters

[JohnS]

Hello Pam,

I had a problem with Suntour power shifters (ratchet mechanism just like 
the Silvers) which caused the ratchet to not work, sounded like it was 
grinding or slipping. I found that by taking the shifter apart, cleaning 
the washers and applying a thin coat of light oil helped. Worth a try. Not 
sure if the oil is recommended or not, maybe someone else can chime in.

Good luck,
JohnS

On Tuesday, August 15, 2023 at 4:29:08 PM UTC-4 Pam Bikes wrote:

> I have several broken Silver shifters.  The power ratchet doesn't work any 
> more.  My question is if I can get a part to fix the ratchet.  If not, 
> should I throw them in the metal recycling or is there anything I can use 
> later?  I'm not a mechanical person.  I just know the ratchet wouldn't hold 
> after I replaced the plastic washer and when I put a new shifter on, it 
> worked.  

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/14af-fb80-4dfb-a65f-419cb208393an%40googlegroups.com.

Re: [PATCH] build: Make gzip archives reproducible

[Chris Johns]

On 14/8/2023 4:24 pm, Sebastian Huber wrote:
> On 12.08.23 18:29, Joel Sherrill wrote:
>> Piling on Chris' comments about where is the requirement for this. This is a
>> topic which must be addressed in the Software Engineering Guide and accepted
>> before it can be put into practices. A software development process of any
>> quality cannot be changed on a whim without discussion and modifying all the
>> artifacts necessary.
> 
> Sorry, it was not my intention to open another can of worms. This reproducible
> builds stuff appeared to be some small thing to do.

I think it would be good to understand what you intend and why? At the moment we
are wondering or guessing based on some patches and that is never good. Our main
focus is the long term liability change have for us. Anything you can add to
explain things helps.

I think reproducible builds is a great thing to attempt but in the past there
have been issues. For example at one point the register allocator in gcc for the
m68k used the libc sort and Windows and Linux differed when sorting "all the
elements are the same" so the code built on Windows did not match the code built
on Linux even though it was equivalent code, ie register ordering for push and
pops differed.

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

Re: [PATCH RTEMS] spec: Add -mstrict-align to mvme2100 default build

[Chris Johns]

On 11/8/2023 1:17 pm, Vijay Kumar Banerjee wrote:
> On Wed, Aug 9, 2023 at 8:04 PM Chris Johns  wrote:
>>
>> On 10/8/2023 2:41 am, Joel Sherrill wrote:
>>> Reading the EPICS discussion, I wonder if this should be added for all
>>> motorola_powerpc BSP variants.
>>>
>>> Gedare/Chris/anyone with another board in the family? What do you think?
>>
>> Michael asked if the setting is present when building libc, libm etc in the
>> EPICS core devs meeting today and I could not answer the question?
> 
> I just built the tools for powerpc and it looks like libc, libm are
> not built with the -mstrict-align flag.

Is it a problem to not have option? I am do not know enough about this area of
the PowerPC to know.

>> Is it
>> exported in the .pc or Makefile.inc flags?
>>
> This flag is exported in ${RTEMS_BSP}.cfg file in RTEMS, which gets
> included by EPICS though CONFIG.Common.RTEMS:
> https://github.com/epics-base/epics-base/blob/7.0/configure/os/CONFIG.Common.RTEMS#L38
> 
> The `RTEMS_CUSTOM` variable is defined in Makefile.inc, and it points
> to the ${RTEMS_BSP}.cfg file

RTEMS has not needed this flag and libc and libm do not have it on so I am
confused why code in EPICS has triggering something that needs this option? I
would have thought it is needed everywhere or not at all?

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

Re: [PATCH] build: Create deterministic tar archives

[Chris Johns]

On 11/8/2023 3:43 pm, Sebastian Huber wrote:
> On 11.08.23 07:39, Chris Johns wrote:
>> On 11/8/2023 3:37 pm, Sebastian Huber wrote:
>>> On 11.08.23 02:22, Chris Johns wrote:
>>>> On 10/8/2023 8:19 pm, Sebastian Huber wrote:
>>>>> This helps to make the build reproducible.
>>>>> ---
>>>>>    wscript | 11 ++-
>>>>>    1 file changed, 10 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/wscript b/wscript
>>>>> index a8fca88dcb..4baf701c27 100755
>>>>> --- a/wscript
>>>>> +++ b/wscript
>>>>> @@ -188,6 +188,15 @@ def process_start_files(self):
>>>>>    self.link_task.dep_nodes.extend(self.bld.start_files)
>>>>>      +def deterministic_tar_info(info):
>>>> I suggest `tar_user_info` as the name.
>>> The function changes also the mtime. What about reproducible_tar_info()?
>> That is the out come and not the data itself. What about tar_metadata()?
> 
> What about make_tar_info_reproducible()?
> 

Sure

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

Re: [PATCH] build: Add target to build scripts

[Chris Johns]

On 11/8/2023 3:33 pm, Sebastian Huber wrote:
> On 11.08.23 02:21, Chris Johns wrote:
>> On 10/8/2023 7:02 pm, Sebastian Huber wrote:
>>> Document that the build scripts in the testsuites produce a test program.
>> I am sorry but I do not understand this change and why we need it. Is the
>> addition of the target line purely cosmetic?
> 
> This information can be used to associate test executables with build items 
> and
> vice versa.

We just these tests?

I am struggling to see a need. If you have a need it may help to outline it.

Also I cannot see anything we have to make sure the path is valid.

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

Re: [PATCH] build: Create deterministic tar archives

[Chris Johns]

On 11/8/2023 3:37 pm, Sebastian Huber wrote:
> On 11.08.23 02:22, Chris Johns wrote:
>> On 10/8/2023 8:19 pm, Sebastian Huber wrote:
>>> This helps to make the build reproducible.
>>> ---
>>>   wscript | 11 ++-
>>>   1 file changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/wscript b/wscript
>>> index a8fca88dcb..4baf701c27 100755
>>> --- a/wscript
>>> +++ b/wscript
>>> @@ -188,6 +188,15 @@ def process_start_files(self):
>>>   self.link_task.dep_nodes.extend(self.bld.start_files)
>>>     +def deterministic_tar_info(info):
>> I suggest `tar_user_info` as the name.
> 
> The function changes also the mtime. What about reproducible_tar_info()?

That is the out come and not the data itself. What about tar_metadata()?

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

Re: [PATCH] build: Create deterministic tar archives

[Chris Johns]

On 10/8/2023 8:19 pm, Sebastian Huber wrote:
> This helps to make the build reproducible.
> ---
>  wscript | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/wscript b/wscript
> index a8fca88dcb..4baf701c27 100755
> --- a/wscript
> +++ b/wscript
> @@ -188,6 +188,15 @@ def process_start_files(self):
>  self.link_task.dep_nodes.extend(self.bld.start_files)
>  
>  
> +def deterministic_tar_info(info):

I suggest `tar_user_info` as the name.

Chris

> +info.uid = 0
> +info.gid = 0
> +info.mtime = 0
> +info.uname = "root"
> +info.gname = "root"
> +return info
> +
> +
>  class Item(object):
>  
>  def __init__(self, uid, data):
> @@ -479,7 +488,7 @@ class Item(object):
>  dst = src
>  for r in remove:
>  dst = src.replace(srcpath + r, "").replace(bldpath + r, 
> "")
> -tar.add(src, dst)
> +tar.add(src, dst, filter=deterministic_tar_info)
>  tar.close()
>  return 0
>  
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [tools] tester: Use shorter SHA512 encoding

[Chris Johns]

OK to push

Thanks
Chris

On 10/8/2023 11:52 pm, Sebastian Huber wrote:
> Encode the SHA512 digest in base64urlsafe instead of a hex string to
> reduce the report size.
> ---
>  tester/rt/test.py | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tester/rt/test.py b/tester/rt/test.py
> index 2b5ad85..0e22002 100644
> --- a/tester/rt/test.py
> +++ b/tester/rt/test.py
> @@ -329,13 +329,14 @@ def generate_yaml_report(args, reports, start_time, 
> end_time,
>  
>  def get_hash512(exe):
>  """ returns SHA512 hash string of a given binary file passed as argument 
> """
> +import base64
>  import hashlib
>  
>  hash = hashlib.sha512()
>  with open(exe, "rb") as f:
>  for byte_block in iter(lambda: f.read(4096), b""):
>  hash.update(byte_block)
> -return hash.hexdigest()
> +return base64.urlsafe_b64encode(hash.digest()).decode("ascii")
>  
>  
>  report_formatters = {
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Add target to build scripts

[Chris Johns]

On 10/8/2023 7:02 pm, Sebastian Huber wrote:
> Document that the build scripts in the testsuites produce a test program.

I am sorry but I do not understand this change and why we need it. Is the
addition of the target line purely cosmetic?

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

Re: [PATCH] build: Make BUILD_LIBDL configurable

[Chris Johns]

On 10/8/2023 11:44 pm, Sebastian Huber wrote:
> On 10.08.23 15:28, Joel Sherrill wrote:
>> It looks ok but why? It isn't built if not supported. It isn't a lot of code
>> even if it is built. And it will not be in a user executable if they don't
>> call it.
>>
>> I just don't see the point.
> 
> Yes, good question. Actually, I wanted to add an option to disable the libdl
> tests as a workaround for
> 
> http://devel.rtems.org/ticket/4941
> 
> and the use of vendor tools or clang. I will make this more explicit with a
> BUILD_LIBDL_TESTS option.

Please do not add a work around.

Thanks
Chris

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

Re: [PATCH rtems v3 1/1] Add the Regulator Interface and test

[Chris Johns]

On 11/8/2023 8:14 am, Joel Sherrill wrote:
> I should have asked if you want another round of patches or just go ahead and
> merge. This set of changes was pretty minor.

I am fine with the changes being pushed.

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

Re: [PATCH] build: Add PROGRAM_PREFIX option

[Chris Johns]

On 10/8/2023 3:06 pm, Sebastian Huber wrote:
> On 10.08.23 03:13, Chris Johns wrote:
>>
>> On 9/8/2023 7:12 pm, Sebastian Huber wrote:
>>> On 09.08.23 11:10, Cedric Berger wrote:
>>>> On 09.08.23 10:51, Sebastian Huber wrote:
>>>>> We could add some text to the option description:
>>>>>
>>>>> # Defines the program prefix of tools (compiler, assembler, linker).
>>>>> # This option may be used to build RTEMS with a vendor tool suite.
>>>>> # Please note that using tool suites not provided by the RTEMS Project
>>>>> # may not work as expected.
>>>> If the goal of that comment it to prevent "fielding support related
>>>> questions", I doubt that writing "may not work as expected" will have the
>>>> desired effect...
>>> I am open for alternative wordings.
>>>
>> # Defines the program prefix of tools (compiler, assembler, linker) used
>> # to build RTEMS. This option may be used to build RTEMS with a vendor
>> # tool suite. Please note, support issues related to using this option with
>> # vendor tool suites should be directed to the vendor of the tools.
> 
> Sounds good, do you check it in?

I have not. Are you able to? If so please feel free to push the change as 
approved.

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

Re: [PATCH rtems v3 1/1] Add the Regulator Interface and test

[Chris Johns]

Hi Joel,

This looks good.

A minor nit relates to pointer checks. We have:

https://docs.rtems.org/branches/master/eng/coding-conventions.html#language-and-compiler

I do not know how well enforced the pointer check for NULL in `if` is?

Chris

On 10/8/2023 1:42 am, Joel Sherrill wrote:
> Updates #4924.
> 
> The Regulator is an application support class which is used to
> deal with the scenario where there is a bursty input source
> which needs to be metered out to a destination sink. The maximum
> size of bursts needs to be known and the delivery method must
> be configured to deliver messages at a rate that allows the
> traffic to not overflow.
> ---
>  cpukit/include/rtems/regulator.h  |  499 +++
>  cpukit/include/rtems/regulatorimpl.h  |  135 ++
>  cpukit/libmisc/regulator/regulator.c  |  683 +
>  spec/build/cpukit/librtemscpu.yml |2 +
>  spec/build/cpukit/objregulator.yml|   18 +
>  spec/build/testsuites/libtests/grp.yml|2 +
>  .../build/testsuites/libtests/regulator01.yml |   21 +
>  testsuites/libtests/regulator01/regulator01.c | 1310 +
>  .../libtests/regulator01/regulator01.doc  |   67 +
>  .../libtests/regulator01/rtems_config.c   |   59 +
>  10 files changed, 2796 insertions(+)
>  create mode 100644 cpukit/include/rtems/regulator.h
>  create mode 100644 cpukit/include/rtems/regulatorimpl.h
>  create mode 100644 cpukit/libmisc/regulator/regulator.c
>  create mode 100644 spec/build/cpukit/objregulator.yml
>  create mode 100644 spec/build/testsuites/libtests/regulator01.yml
>  create mode 100644 testsuites/libtests/regulator01/regulator01.c
>  create mode 100644 testsuites/libtests/regulator01/regulator01.doc
>  create mode 100644 testsuites/libtests/regulator01/rtems_config.c
> 
> diff --git a/cpukit/include/rtems/regulator.h 
> b/cpukit/include/rtems/regulator.h
> new file mode 100644
> index 00..362a99f6bc
> --- /dev/null
> +++ b/cpukit/include/rtems/regulator.h
> @@ -0,0 +1,499 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @defgroup RegulatorAPI Regulator API
> + *
> + * @brief Regulator APIs
> + *
> + * The Regulator provides a set of APIs to manage input sources which 
> + * produces bursts of message traffic.
> + */
> +
> +/**
> + * @mainpage
> + *
> + * The regulator is designed to sit logically between two entities -- a
> + * source and a destination, where it limits the traffic sent to the
> + * destination to prevent it from being flooded with messages from the
> + * source. This can be used to accommodate bursts of input from a source
> + * and meter it out to a destination.  The maximum number of messages
> + * which can be buffered in the regulator is specified by the
> + * @a maximum_messages field in the @a rtems_regulator_attributes
> + * structure passed as an argument to @a rtems_regulator_create().
> + *
> + * The regulator library accepts an input stream of messages from a
> + * source and delivers them to a destination. The regulator assumes that the
> + * input stream from the source contains sporadic bursts of data which can
> + * exceed the acceptable rate of the destination. By limiting the message 
> rate,
> + * the regulator prevents an overflow of messages.
> + *
> + * The regulator can be configured for the input buffering required to manage
> + * the maximum burst and for the metering rate for the output. The output 
> rate
> + * is in messages per second. If the sender produces data too fast, the
> + * regulator will buffer the configured number of messages.
> + *
> + * A configuration capability is provided to allow for adaptation to 
> different
> + * message streams. The regulator can also support running multiple 
> instances,
> + * which could be used on independent message streams.
> + *
> + * The regulator provides a simple interface to the application for avoiding
> + * bursts of input from a fast source overflowing a slower destination.
> + *
> + * It is assumed that the application has a design limit on the number of
> + * messages which may be buffered. All messages accepted by the regulator,
> + * assuming no overflow on input, will eventually be output by the Delivery
> + * thread.
> + *
> + * A regulator instance is used as follows from the producer/source side:
> + *
> + * @code
> + *   while (1)
> + * use rtems_regulator_obtain_buffer to obtain a buffer
> + * input operation to fetch data into the buffer
> + * rtems_regulator_send(buffer, size of message)
> + * @endcode
> + *
> + * The delivery of message buffers to the Destination and subsequent
> + * release is performed in the context of the delivery thread by either
> + * the delivery function or delivery thread. Details are below.
> + *
> + * The sequence diagram below shows the interaction between a message Source,
> + * a Regulator instance, and RTEMS, given the usage described in the above
> + * paragraphs.
> + *
> + * \startuml "Regulator 

Re: [PATCH] build: Add PROGRAM_PREFIX option

[Chris Johns]

On 9/8/2023 7:12 pm, Sebastian Huber wrote:
> On 09.08.23 11:10, Cedric Berger wrote:
>> On 09.08.23 10:51, Sebastian Huber wrote:
>>> We could add some text to the option description:
>>>
>>> # Defines the program prefix of tools (compiler, assembler, linker).
>>> # This option may be used to build RTEMS with a vendor tool suite.
>>> # Please note that using tool suites not provided by the RTEMS Project
>>> # may not work as expected.
>>
>> If the goal of that comment it to prevent "fielding support related
>> questions", I doubt that writing "may not work as expected" will have the
>> desired effect...
> 
> I am open for alternative wordings.
> 

# Defines the program prefix of tools (compiler, assembler, linker) used
# to build RTEMS. This option may be used to build RTEMS with a vendor
# tool suite. Please note, support issues related to using this option with
# vendor tool suites should be directed to the vendor of the tools.

?

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

Re: [PATCH RTEMS] spec: Add -mstrict-align to mvme2100 default build

[Chris Johns]

On 10/8/2023 2:41 am, Joel Sherrill wrote:
> Reading the EPICS discussion, I wonder if this should be added for all
> motorola_powerpc BSP variants.
> 
> Gedare/Chris/anyone with another board in the family? What do you think?

Michael asked if the setting is present when building libc, libm etc in the
EPICS core devs meeting today and I could not answer the question? Is it
exported in the .pc or Makefile.inc flags?

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

Re: [PATCH] build: Add PROGRAM_PREFIX option

[Chris Johns]

On 8/8/2023 11:14 pm, Sebastian Huber wrote:
> On 08.08.23 08:06, Chris Johns wrote:
>> n 7/8/2023 4:06 pm, Sebastian Huber wrote:
>>> On 07.08.23 00:25, Chris Johns wrote:
>>>> On 4/8/2023 4:39 pm, Sebastian Huber wrote:
>>>>> On 04.08.23 08:22, Chris Johns wrote:
>>>>>> On 4/8/2023 3:16 pm, Sebastian Huber wrote:
>>>>>>> On 04.08.23 00:27, Chris Johns wrote:
>>>>>>>> On 2/8/2023 6:49 pm, Chris Johns wrote:
>>>>>>>>  > I am concerned about the compatibility to the ecosystem we have.
>>>>>>>> Have you
>>>>>>>> built
>>>>>>>>> all the tests in the testsuite with this value set to something that 
>>>>>>>>> is
>>>>>>>>> not
>>>>>>>>> RTEMS default? I think a few things will break because of hard coding 
>>>>>>>>> in
>>>>>>>>> them.
>>>>>>>> I have asked for test results and I have not seen any yet the patch has
>>>>>>>> been
>>>>>>>> merged? The change was not approved my me and is still not approved.
>>>>>>> Sorry I thought it was fine after answering your questions.
>>>>>> All good, I would like to finish the discusion. 
>>>>>>
>>>>>>> Yes, I have tested this with the rtems7 tools. It was possible to build 
>>>>>>> with
>>>>>>> the rtems7 tools
>>>>>>> before, however, the PROGRAM_PREFIX approach is better, since it allows
>>>>>>> also the
>>>>>>> build using vendor tools. We had some fixes for this recently:
>>>>>>>
>>>>>>> https://lists.rtems.org/pipermail/devel/2023-May/075321.html
>>>>>>>
>>>>>>> This is something the user need.
>>>>>> What if a user adds or uses a prefix that does not conform to the 
>>>>>> standard
>>>>>> format? I am assuming this is possible to do this, eg Gaisler's special
>>>>>> prefix?
>>>>>>
>>>>>> Possible breakage is
>>>>>> https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-cc.cpp#n457   ?
>>>>>>
>>>>>> Do we need to document any constraints around this option?
>>>>> There will be always problems left to fix.
>>>> I do not see this as a problem, I see an incomplete change pushed without 
>>>> the
>>>> review being completed.
>>> Sometimes it is not 100% clear when a review is finished.
>> Yes it is all a bit fragile and there is lots of guess work.
>>
>>>>> A basic build and the normal tests
>>>>> work fine with non-standard tools. For the Gaisler tools, you would need:
>>>>>
>>>>> PROGRAM_PREFIX = sparc-gaisler-rtems5-
>>>>>
>>>>> I guess the rld-cc.cpp will also have issues with a clang build.
>>>> Yes it would and libdl is a part of RTEMS and breaking it again is 
>>>> something I
>>>> would like to avoid. I consider the change incomplete because one part 
>>>> says use
>>>> PROGRAM_PREFIX to change the tools prefix however doing so may break other
>>>> parts. There is nothing to warn the user PROGRAM_PREFIX may not work as
>>>> expected.
>>> I don't use vendor tool chains, but it seems that some users would like to 
>>> use
>>> them. They were supported by the old build system, so a lacking support in 
>>> the
>>> new build system would be a regression. But if you don't like this change, 
>>> then
>>> we can also revert the patch.
>> I think the change is fine and I am not suggesting it is reverted. It is not
>> clear to me if more work is needed to complete what this has started because 
>> I
>> do not know where we stand with vendor tools.
>>
>> I think supporting vendor tools is something we should consider and either
>> accept it and sort out what is needed or we clearly state vendors are on 
>> their
>> own.
>>
>> Supporting vendor tools add something else we need to test and handle but it
>> lets vendors own the tools they create and it is clear to us when a user 
>> raises
>> a problem when using them.
> 
> The vendor tools support works now as good or bad as in RTEMS 5. If someone
> wants better support, then he/she should work on it. We can't make everything
> perfect, there are other things left to do for the RTEMS 6 release.

Should we document the extent of what we do support and what is missing?

And yes I agree with your comments however users are often not aware of this and
we end up fielding support related questions. I also do not think we need to do
much to make it work but I am not sure. How do you build gcc with a different
tools prefix?

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

Re: [PATCH 1/3] gitignore: Ignore clangd and clang-format files

[Chris Johns]

On 8/8/2023 4:07 pm, Chris Johns wrote:
> On 8/8/2023 1:05 pm, Utkarsh Verma wrote:
>> ---
>>  .gitignore | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/.gitignore b/.gitignore
>> index 8b28b186e1..d0144f6737 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -12,3 +12,7 @@ Makefile.in
>>  /testsuites/build/build
>>  /testsuites/build/wscript
>>  .waf*
>> +.clangd
>> +.clang-format
>> +compile_commands.json
>> +.cache/
> 
> What are these from?
> 
> Why add them to your $HOME/.gitignore?

Sorry ... that should be

Why not add them to your $HOME/.gitignore?

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

Re: [PATCH 1/3] gitignore: Ignore clangd and clang-format files

[Chris Johns]

On 8/8/2023 1:05 pm, Utkarsh Verma wrote:
> ---
>  .gitignore | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/.gitignore b/.gitignore
> index 8b28b186e1..d0144f6737 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -12,3 +12,7 @@ Makefile.in
>  /testsuites/build/build
>  /testsuites/build/wscript
>  .waf*
> +.clangd
> +.clang-format
> +compile_commands.json
> +.cache/

What are these from?

Why add them to your $HOME/.gitignore?

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

Re: [PATCH] build: Add PROGRAM_PREFIX option

[Chris Johns]

On 7/8/2023 4:06 pm, Sebastian Huber wrote:
> On 07.08.23 00:25, Chris Johns wrote:
>> On 4/8/2023 4:39 pm, Sebastian Huber wrote:
>>> On 04.08.23 08:22, Chris Johns wrote:
>>>> On 4/8/2023 3:16 pm, Sebastian Huber wrote:
>>>>> On 04.08.23 00:27, Chris Johns wrote:
>>>>>> On 2/8/2023 6:49 pm, Chris Johns wrote:
>>>>>>     > I am concerned about the compatibility to the ecosystem we have.
>>>>>> Have you
>>>>>> built
>>>>>>> all the tests in the testsuite with this value set to something that is 
>>>>>>> not
>>>>>>> RTEMS default? I think a few things will break because of hard coding in
>>>>>>> them.
>>>>>> I have asked for test results and I have not seen any yet the patch has 
>>>>>> been
>>>>>> merged? The change was not approved my me and is still not approved.
>>>>> Sorry I thought it was fine after answering your questions.
>>>> All good, I would like to finish the discusion. 
>>>>
>>>>> Yes, I have tested this with the rtems7 tools. It was possible to build 
>>>>> with
>>>>> the rtems7 tools
>>>>> before, however, the PROGRAM_PREFIX approach is better, since it allows
>>>>> also the
>>>>> build using vendor tools. We had some fixes for this recently:
>>>>>
>>>>> https://lists.rtems.org/pipermail/devel/2023-May/075321.html
>>>>>
>>>>> This is something the user need.
>>>> What if a user adds or uses a prefix that does not conform to the standard
>>>> format? I am assuming this is possible to do this, eg Gaisler's special 
>>>> prefix?
>>>>
>>>> Possible breakage is
>>>> https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-cc.cpp#n457  ?
>>>>
>>>> Do we need to document any constraints around this option?
>>> There will be always problems left to fix.
>> I do not see this as a problem, I see an incomplete change pushed without the
>> review being completed.
> 
> Sometimes it is not 100% clear when a review is finished.

Yes it is all a bit fragile and there is lots of guess work.

>>> A basic build and the normal tests
>>> work fine with non-standard tools. For the Gaisler tools, you would need:
>>>
>>> PROGRAM_PREFIX = sparc-gaisler-rtems5-
>>>
>>> I guess the rld-cc.cpp will also have issues with a clang build.
>> Yes it would and libdl is a part of RTEMS and breaking it again is something 
>> I
>> would like to avoid. I consider the change incomplete because one part says 
>> use
>> PROGRAM_PREFIX to change the tools prefix however doing so may break other
>> parts. There is nothing to warn the user PROGRAM_PREFIX may not work as 
>> expected.
> 
> I don't use vendor tool chains, but it seems that some users would like to use
> them. They were supported by the old build system, so a lacking support in the
> new build system would be a regression. But if you don't like this change, 
> then
> we can also revert the patch.

I think the change is fine and I am not suggesting it is reverted. It is not
clear to me if more work is needed to complete what this has started because I
do not know where we stand with vendor tools.

I think supporting vendor tools is something we should consider and either
accept it and sort out what is needed or we clearly state vendors are on their 
own.

Supporting vendor tools add something else we need to test and handle but it
lets vendors own the tools they create and it is clear to us when a user raises
a problem when using them.

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

Re: [PATCH] build: Add PROGRAM_PREFIX option

[Chris Johns]

On 4/8/2023 4:39 pm, Sebastian Huber wrote:
> On 04.08.23 08:22, Chris Johns wrote:
>> On 4/8/2023 3:16 pm, Sebastian Huber wrote:
>>> On 04.08.23 00:27, Chris Johns wrote:
>>>> On 2/8/2023 6:49 pm, Chris Johns wrote:
>>>>    > I am concerned about the compatibility to the ecosystem we have. Have 
>>>> you
>>>> built
>>>>> all the tests in the testsuite with this value set to something that is 
>>>>> not
>>>>> RTEMS default? I think a few things will break because of hard coding in 
>>>>> them.
>>>> I have asked for test results and I have not seen any yet the patch has 
>>>> been
>>>> merged? The change was not approved my me and is still not approved.
>>>
>>> Sorry I thought it was fine after answering your questions.
>>
>> All good, I would like to finish the discusion. :)
>>
>>> Yes, I have tested this with the rtems7 tools. It was possible to build with
>>> the rtems7 tools
>>> before, however, the PROGRAM_PREFIX approach is better, since it allows 
>>> also the
>>> build using vendor tools. We had some fixes for this recently:
>>>
>>> https://lists.rtems.org/pipermail/devel/2023-May/075321.html
>>>
>>> This is something the user need.
>>
>> What if a user adds or uses a prefix that does not conform to the standard
>> format? I am assuming this is possible to do this, eg Gaisler's special 
>> prefix?
>>
>> Possible breakage is
>> https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-cc.cpp#n457 ?
>>
>> Do we need to document any constraints around this option?
> 
> There will be always problems left to fix. 

I do not see this as a problem, I see an incomplete change pushed without the
review being completed.

> A basic build and the normal tests
> work fine with non-standard tools. For the Gaisler tools, you would need:
> 
> PROGRAM_PREFIX = sparc-gaisler-rtems5-
> 
> I guess the rld-cc.cpp will also have issues with a clang build.

Yes it would and libdl is a part of RTEMS and breaking it again is something I
would like to avoid. I consider the change incomplete because one part says use
PROGRAM_PREFIX to change the tools prefix however doing so may break other
parts. There is nothing to warn the user PROGRAM_PREFIX may not work as 
expected.

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

Re: [RBW] Re: Tried and liked: Suntour Cyclone pretzel

[JohnS]

Awesome news Eric, glad to hear you're Hillborne is back on the road!

JohnS


On Saturday, August 5, 2023 at 5:17:41 PM UTC-4 eric...@gmail.com wrote:

> After twenty miles today with no chain jumping I'm calling this solved. 
>
> [image: sh.jpg]
>
> On Friday, August 4, 2023 at 11:42:39 AM UTC-4 Stephen wrote:
>
>> huzzah!
>>
>> On Friday, August 4, 2023 at 10:12:15 AM UTC-4 ride2almo...@gmail.com 
>> wrote:
>>
>>> What a great outcome 
>>>
>>> On Fri, Aug 4, 2023 at 10:09 AM Eric Marth  wrote:
>>>
>>>> Thanks, Ryan and Danny. Just rode another 3 miles on a quick bank 
>>>> errand, no skips. Will have to try a longer ride when it dries out. 
>>>>
>>>> Also installed a Brooks Pro I purchased from Two Wheeled Texan's Grand 
>>>> Relocation Parts Blowout and I liked it! 
>>>>
>>>> On Thursday, August 3, 2023 at 10:15:42 PM UTC-4 Ryan wrote:
>>>>
>>>>> Glad this saga had a happy ending!I bet you're relieved
>>>>>
>>>>> On Thursday, August 3, 2023 at 8:20:22 PM UTC-5 Danny wrote:
>>>>>
>>>>>> Ooops, didn't see your update just before I posted. Glad you got it 
>>>>>> worked out!
>>>>>>
>>>>>> On Thursday, August 3, 2023 at 8:16:54 PM UTC-5 Danny wrote:
>>>>>>
>>>>>>> I'm curious to hear what ends up resolving the issue. I hope it's as 
>>>>>>> easy as a new cassette, but I'm most intrigued by it being related to 
>>>>>>> the 
>>>>>>> elongated hole.
>>>>>>>
>>>>>>> Re: alignment tools, after borrowing my friend's Park DAG a handful 
>>>>>>> of times over a few months, I decided to buy my own tool. Ended up with 
>>>>>>> the 
>>>>>>> Wolf Tooth one that Stephen linked to. Have only used it once so far, 
>>>>>>> but I 
>>>>>>> found it to work quite well. Doesn't take up much room in the drawer, 
>>>>>>> and I 
>>>>>>> don't have to endure the frequent screeching of metal sliding on metal 
>>>>>>> that 
>>>>>>> I experienced with the Park tool.
>>>>>>>
>>>>>>> -Danny
>>>>>>>
>>>>>>> On Thu, Aug 3, 2023 at 7:52 PM Eric Marth  wrote:
>>>>>>>
>>>>>>>> George: Thanks for reading along! Yes, the Helicoil seems like a 
>>>>>>>> more robust solution, I agree. 
>>>>>>>>
>>>>>>>> Jason: Noted! If only Riv would bring back those beefy headset 
>>>>>>>> presses they got a super limited run of a few years ago. Never need 
>>>>>>>> one 
>>>>>>>> but... they seemed awesome. 
>>>>>>>>
>>>>>>>> On Thursday, August 3, 2023 at 8:21:45 PM UTC-4 Jason Fuller wrote:
>>>>>>>>
>>>>>>>>> Eric, you've *got* to get a DAG alignment tool!  The heavy steel 
>>>>>>>>> one, avoid the new lighter one. It's a must have for the home 
>>>>>>>>> mechanic of 
>>>>>>>>> fine steel frames that do not have replaceable hangers.  I use it 
>>>>>>>>> every 
>>>>>>>>> time the derailleur is pulled off for any reason, or if I'm having 
>>>>>>>>> any 
>>>>>>>>> stubborn shifting issue - it's amazing how often it's just because 
>>>>>>>>> the 
>>>>>>>>> alignment was out slightly. 
>>>>>>>>>
>>>>>>>>> On Thursday, 3 August 2023 at 12:17:13 UTC-7 George Schick wrote:
>>>>>>>>>
>>>>>>>>>> This is one of the more interesting posts/threads having to do 
>>>>>>>>>> with bike repairs that has come along in awhile (with no intention 
>>>>>>>>>> to 
>>>>>>>>>> downplay the unfortunate accident!).  I like the final post about a 
>>>>>>>>>> Helicoil or dropout saver recommendation.  My own preference would 
>>>>>>>>>> likely 
>>>>>>>>>> be the Helicoil because you have to tap in new larger diameter 
>>>>>>>>>> thre

Re: [PATCH] trace/wscript: Improve C++ standard selection

[Chris Johns]

On 4/8/2023 4:47 pm, Sebastian Huber wrote:
> On 04.08.23 08:30, Chris Johns wrote:
>>> Please understand there is a limited number people reviewing and it takes 
>>> time.
>>>> I am blocked on the other changes you have recently posted. Adding which 
>>>> hosts
>>>> you have built and tested this change on would help?
>>> Sorry, Joel is rushing for the RTEMS 6 release. The patch is from 19.05.23. 
>>> A CI
>>> system and pull requests would also help.
>> Ah yes and I have raised an 7 related RSB sources fetch that need to be fix 
>> as
>> well. My concern is release testing on hosts like MacOS M etc tend to find
>> issues if it has not been tested.
> 
> GitHub offers runners for macOS:
> 
> https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners
> 
> I don't understand why we don't use the GitHub services for the project. It is
> just a matter of adding a couple for text files to the repositories. You can
> still run your own GitLab stuff in parallel. It is not one or another. You can
> have both.

It is not a technical issue. Who legally owns the github account? It cannot be a
single person and it cannot be a company. It could be a foundation but ours is
not functioning enough to do this.

Individuals can always set up builders and post to the builds list and that is
no different to a private build server in a company but these is not part of the
project or under its control.

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

Re: [PATCH] trace/wscript: Improve C++ standard selection

[Chris Johns]

On 4/8/2023 3:02 pm, Sebastian Huber wrote:
> On 04.08.23 00:53, Chris Johns wrote:
>> On 3/8/2023 5:36 pm, Sebastian Huber wrote:
>>> Ping.
>>
>> Which repo? Is this in the rtems-tools repo?
> 
> Yes, the rtems-tools.
> 

Thanks

> Please understand there is a limited number people reviewing and it takes 
> time.
>> I am blocked on the other changes you have recently posted. Adding which 
>> hosts
>> you have built and tested this change on would help?
> 
> Sorry, Joel is rushing for the RTEMS 6 release. The patch is from 19.05.23. A 
> CI
> system and pull requests would also help.

Ah yes and I have raised an 7 related RSB sources fetch that need to be fix as
well. My concern is release testing on hosts like MacOS M etc tend to find
issues if it has not been tested.

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

Re: [PATCH] libdebugger: Restrict ARM architecture support

[Chris Johns]

On 4/8/2023 3:07 pm, Sebastian Huber wrote:
> On 04.08.23 00:43, Chris Johns wrote:
>> On 3/8/2023 10:17 pm, Sebastian Huber wrote:
>>> Build the arm libdebugger support only for supported ARM architectures.
>> What ARM archs are not supported?
> 
> At least ARMv7-M and everything with Thumb 1.
> 

Does the rtems_debugger_target_configure fail in this patch for this arch?

>>> This fixes assembler errors at -O0.
>> How does it fix the assembler errors?
> 
> The unsupported assembly instructions are not issued by the compiler so that 
> the
> assembler is happy. This issue is open since 2020:
> 
> https://lists.rtems.org/pipermail/devel/2020-March/058432.html

Yes.

> 
> Since the gcov code coverage is generated using -O0, this is now a bigger 
> issue.
> 

Why is RPi showing issues? That is confusing me.

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

Re: [PATCH] build: Add PROGRAM_PREFIX option

[Chris Johns]

On 4/8/2023 3:16 pm, Sebastian Huber wrote:
> On 04.08.23 00:27, Chris Johns wrote:
>> On 2/8/2023 6:49 pm, Chris Johns wrote:
>>   > I am concerned about the compatibility to the ecosystem we have. Have you
>> built
>>> all the tests in the testsuite with this value set to something that is not
>>> RTEMS default? I think a few things will break because of hard coding in 
>>> them.
>> I have asked for test results and I have not seen any yet the patch has been
>> merged? The change was not approved my me and is still not approved.
> 
> Sorry I thought it was fine after answering your questions. 

All good, I would like to finish the discusion. :)

> Yes, I have tested this with the rtems7 tools. It was possible to build with 
> the rtems7 tools
> before, however, the PROGRAM_PREFIX approach is better, since it allows also 
> the
> build using vendor tools. We had some fixes for this recently:
> 
> https://lists.rtems.org/pipermail/devel/2023-May/075321.html
> 
> This is something the user need.

What if a user adds or uses a prefix that does not conform to the standard
format? I am assuming this is possible to do this, eg Gaisler's special prefix?

Possible breakage is
https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-cc.cpp#n457 ?

Do we need to document any constraints around this option?

> I have problems to send test reports by e-mail:

Anything Amar or I can help with?

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