Re: [rtems-libbsd commit] sys/kern: Add VFS support

[Chris Johns]

On 9/2/22 7:43 pm, Sebastian Huber wrote:
> On 09/02/2022 09:41, Sebastian Huber wrote:
>> On 08/02/2022 11:07, Chris Johns wrote:
>>>> It seems that the commit is not present in the master branch. This means 
>>>> all
>>>> the
>>>> work will be lost when we update to a newer FreeBSD baseline.
>>> Yes. It is an out standing task that I need to get funding for.
>>>
>>> What are your plans and if you are looking to update, timeline?
>>
>> The last update was in 2019, so we ship a pretty outdated FreeBSD in libbsd. 
>> I
>> currently estimate the work to do an update, but I don't have a timeline.
> 
> Actually the last update was "Update to FreeBSD stable/12 2020-02-10".
> 

Which branch or branches are you referring too?

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

Re: [rtems-libbsd commit] sys/kern: Add VFS support

[Chris Johns]

On 8/2/22 12:48 am, Sebastian Huber wrote:
> Hello Chris,
> 
> sorry, this slipped through may review list.

Thanks for the review.

> 
> On 02/09/2021 04:43, Chris Johns wrote:
>> @@ -1232,9 +993,6 @@ osendmsg(struct thread *td, struct osendmsg_args *uap)
>>   #endif
>>   #endif /* __rtems__ */
>>   -#ifdef __rtems__
>> -static
>> -#endif /* __rtems__ */
>>   int
>>   sys_sendmsg(struct thread *td, struct sendmsg_args *uap)
>>   {
>> @@ -1257,35 +1015,7 @@ sys_sendmsg(struct thread *td, struct sendmsg_args 
>> *uap)
>>   free(iov, M_IOV);
>>   return (error);
>>   }
>> -#ifdef __rtems__
>> -ssize_t
>> -sendmsg(int socket, const struct msghdr *message, int flags)
>> -{
>> -    struct thread *td = rtems_bsd_get_curthread_or_null();
>> -    struct sendmsg_args ua = {
>> -    .s = socket,
>> -    .msg = message,
>> -    .flags = flags
>> -    };
>> -    int error;
>> -
>> -    if (td != NULL) {
>> -    error = sys_sendmsg(td, );
>> -    } else {
>> -    error = ENOMEM;
>> -    }
>> -
>> -    if (error == 0) {
>> -    return td->td_retval[0];
>> -    } else {
>> -    rtems_set_errno_and_return_minus_one(error);
>> -    }
>> -}
>> -#endif /* __rtems__ */
> 
> Why did you move all these system call implementations for RTEMS into a 
> separate
> file? The sys_sendmsg() was a static function so the compiler was able to
> optimize the use of struct sendmsg_args away and there was no function call
> overhead.  In the successful case the return value was determined by
> td->td_retval[0]. I don't think this now the case?
> 
> ssize_t
> sendmsg(int socket, const struct msghdr *message, int flags)
> {
> struct thread *td = rtems_bsd_get_curthread_or_null();
> struct sendmsg_args ua;
> int ffd;
> int error;
> if (RTEMS_BSD_SYSCALL_TRACE) {
>     printf("bsd: sys: sendmsg: %d\n", socket);
> }
> if (td == NULL) {
>     return rtems_bsd_error_to_status_and_errno(ENOMEM);
> }
> ffd = rtems_bsd_libio_iop_hold(socket, NULL);
> if (ffd < 0) {
>     return rtems_bsd_error_to_status_and_errno(EBADF);
> }
> ua.s = ffd;
> ua.msg = message;
> ua.flags = flags;
> error = sys_sendmsg(td, );
> rtems_bsd_libio_iop_drop(socket);
> return rtems_bsd_error_to_status_and_errno(error);> }
> 
> Unfortunately syscalls01 only tests error conditions and not a good case.

It looks like a bug. I think there should be a check of `error` after the drop
and the call's result returned.

> It seems that the commit is not present in the master branch. This means all 
> the
> work will be lost when we update to a newer FreeBSD baseline.

Yes. It is an out standing task that I need to get funding for.

What are your plans and if you are looking to update, timeline?

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

Re: RISC-V BSP Build Failures on Ubuntu

[Chris Johns]

On 30/1/22 7:19 am, Joel Sherrill wrote:
> Hi
> https://lists.rtems.org/pipermail/build/2022-January/031425.html
> 
> bsp-builder is reporting this. Help appreciated. Looks like it could
> be a tooling issue
> 
> Failures Report
> ===
>1 posix-debug riscv/frdme310arty build:
>   configure: /home/tester/rtems-cron-6/rtems/waf configure\
>   --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
>   /rtems-cron-6/rtems --rtems-config=config-riscv-frdme310arty-posix-\
>   debug.ini
>  error: ld/collect2:0 error: no error message found!

Could you please check the detailed and log and see what the actual error
message is? There is code in the bsp builder to handle these linker errors and
it seems it may need an update.

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

Re: New validation test suites

[Chris Johns]

On 27/1/22 6:09 pm, Sebastian Huber wrote:
> On 27/01/2022 03:24, Chris Johns wrote:
>> On 25/1/22 5:37 pm, Sebastian Huber wrote:
>>> On 25/01/2022 01:09, Chris Johns wrote:
>>>> On 25/1/22 1:39 am, Sebastian Huber wrote:
>>>>> how do we want to proceed with the integration of the new validation test
>>>>> suite?
>>>>> At the moment it is not clear to me what issues are left to resolve and 
>>>>> what I
>>>>> can do to address them?
>>>>
>>>> I believe I have been clear about what I see as being needed:
>>>>
>>>> https://lists.rtems.org/pipermail/devel/2022-January/070323.html
>>>
>>> Sorry, I don't know what I have to do next.
>>
>> Sure and I am sorry if this was not clear.
>>
>>> The release process for rtems-central is quite clear from my point of view.
>>
>> I would not have raised this if I was in the same position. You are the only
>> person I know who understand rtems-central. I only have an overview of it 
>> and I
>> I am sorry but I have no spare time in invest in learning more about it. I do
>> have the responsibility of releasing RTEMS and if I accept these changes 
>> without
>> any of the needed support in place history has taught me I am left to provide
>> it. Tools and scripts that shows how a process is to work would go a long 
>> long
>> way to resolving this issue.
>>
>> The RTEMS Release repo is a series of FreeBSD scripts I use to release ...
>>
>> https://git.rtems.org/rtems-release/
>>
>> I have not touched it in a while and it needs work to change it to support 
>> waf.
> 
> Ok, I will update
> 
> https://docs.rtems.org/branches/master/eng/release-process.html
> 
> to account for rtems-central.git.
> 
> It seems that there is some work to do to make an RTEMS 6.1 release happen in
> general (this issue is independent of the new validation tests). We should
> figure out which core developers can contribute what.

Yes and I would welcome that.

> 
>>
>>> We just have to create a
>>> release branch for RTEMS 6 and reference release branch commits in the
>>> submodules.
>>
>> How do you validate the generated sources in the sub-modules match those in 
>> the
>> branched submodules? I think this should be done as part of the release
>> procedure to catch any mistakes.
> 
> I will write something about this in the release procedure documentation.

Thank you, I appreciate this. This is a big help.

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

Re: [rtems commit] cpukit: Add description of release version numbers

[Chris Johns]

On 29/1/22 2:36 am, Sebastian Huber wrote:
> On 28/01/2022 15:28, Christian MAUDERER wrote:
>> So I think at the moment, the engineering manual is wrong. The release branch
>> will always have the number N.0.0 as long as we don't change the release 
>> process.
> 
> I think the manual is right and the version on the RTEMS 5 release branch is
> wrong. It should be 5.1.1. Right after the 5.2.0 release it should be 5.2.1.

I will need to take a look and resolve this for an RTEMS 6 release.

A brief review, without examining the detail, would lead me to believe the
manual may need updating but I am not sure.

I think a unified method for controlling version numbers would be good.

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

Re: [PATCH] rtems-tools-6.cfg: Bump hash

[Chris Johns]

OK

On 28/1/22 12:48 am, Ryan Long wrote:
> ---
>  rtems/config/tools/rtems-tools-6.cfg | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/rtems/config/tools/rtems-tools-6.cfg 
> b/rtems/config/tools/rtems-tools-6.cfg
> index d493955..f7a766e 100644
> --- a/rtems/config/tools/rtems-tools-6.cfg
> +++ b/rtems/config/tools/rtems-tools-6.cfg
> @@ -10,14 +10,14 @@
>   %define rtems_tools_source rtems-tools-%{rtems_tools_version}
>   %define rtems_tools_ext xz
>  %else
> - %define rtems_tools_version 6736c738baee94a31ec4f8bc4484582eb7839556
> + %define rtems_tools_version 756897818360a6c110886fb5740303563c92f7a4
>   %define rtems_tools_ext bz2
>  %endif
>  
>  %define rtems_tools_source rtems-tools-%{rtems_tools_version}
>  %source set rtems-tools 
> https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
>  %hash   sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
> - 
> DK6eZJJTXeO3g7PJrB+CsqUU/aYgb3/46MjUP8OqSLYTEOCStoIAm9NjHkWZCIPpJyqQIeEpX8Aerd3RfFiuYA==
> + 
> PBGJPJX2E9g3JCmaijG/FsyAokN/9mjAeEd8NzLejDE0TbVxEHuPpnrhKRkpUeYHi7ljG76OX61p3GgVD06vgg==
>  
>  #
>  # Optionally enable/disable building the RTEMS Tools via the command line.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New validation test suites

[Chris Johns]

On 25/1/22 5:37 pm, Sebastian Huber wrote:
> On 25/01/2022 01:09, Chris Johns wrote:
>> On 25/1/22 1:39 am, Sebastian Huber wrote:
>>> how do we want to proceed with the integration of the new validation test 
>>> suite?
>>> At the moment it is not clear to me what issues are left to resolve and 
>>> what I
>>> can do to address them?
>>
>> I believe I have been clear about what I see as being needed:
>>
>> https://lists.rtems.org/pipermail/devel/2022-January/070323.html
> 
> Sorry, I don't know what I have to do next.

Sure and I am sorry if this was not clear.

> The release process for rtems-central is quite clear from my point of view. 

I would not have raised this if I was in the same position. You are the only
person I know who understand rtems-central. I only have an overview of it and I
I am sorry but I have no spare time in invest in learning more about it. I do
have the responsibility of releasing RTEMS and if I accept these changes without
any of the needed support in place history has taught me I am left to provide
it. Tools and scripts that shows how a process is to work would go a long long
way to resolving this issue.

The RTEMS Release repo is a series of FreeBSD scripts I use to release ...

https://git.rtems.org/rtems-release/

I have not touched it in a while and it needs work to change it to support waf.

> We just have to create a
> release branch for RTEMS 6 and reference release branch commits in the 
> submodules.

How do you validate the generated sources in the sub-modules match those in the
branched submodules? I think this should be done as part of the release
procedure to catch any mistakes.

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

Re: New validation test suites

[Chris Johns]

On 25/1/22 1:39 am, Sebastian Huber wrote:
> how do we want to proceed with the integration of the new validation test 
> suite?
> At the moment it is not clear to me what issues are left to resolve and what I
> can do to address them?

I believe I have been clear about what I see as being needed:

https://lists.rtems.org/pipermail/devel/2022-January/070323.html

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

Re: [PATCH] rtems-tools-6.cfg: Bump hash to get new INI files

[Chris Johns]

On 21/1/22 1:32 am, Joel Sherrill wrote:
> This looks good to me. If no one objects, I will push it.

Ok to push. Thanks

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

Re: [PATCH] sb/linux.py: Simplify "distro" determination

[Chris Johns]

I do not use Linux enough to know if this is OK.

I have no problem with this being pushed if other Linux users are happy.

Chtis

On 20/1/22 11:03 pm, Sebastian Huber wrote:
> This fixes an issue on Debian 11 which contains "Debian" in /etc/issue
> (captital D).
> ---
>  source-builder/sb/linux.py | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/source-builder/sb/linux.py b/source-builder/sb/linux.py
> index d89377b..d71ac39 100644
> --- a/source-builder/sb/linux.py
> +++ b/source-builder/sb/linux.py
> @@ -76,20 +76,16 @@ def load():
>  except:
>  pass
>  
> +distro = distro.lower()
> +
>  # Manage distro aliases
>  if distro in ['centos']:
>  distro = 'redhat'
>  elif distro in ['fedora']:
>  if distro_ver < 17:
>  distro = 'redhat'
> -elif distro in ['centos', 'fedora']:
> -distro = 'redhat'
> -elif distro in ['Ubuntu', 'ubuntu', 'MX', 'LinuxMint', 'linuxmint']:
> +elif distro in ['ubuntu', 'mx', 'linuxmint']:
>  distro = 'debian'
> -elif distro in ['Arch']:
> -distro = 'arch'
> -elif distro in ['SuSE']:
> -distro = 'suse'
>  
>  variations = {
>  'debian' : { '__bzip2':('exe', 'required', '/bin/bzip2'),
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/5] rtems-bsp-builder Configuration Cleanup

[Chris Johns]

OK to push.

Thank you for taking the time to get this sorted.

Chris

On 22/1/22 2:26 am, Joel Sherrill wrote:
> As part of adding aarch64 BSPs to tier 1, it become obvious that
> these config files had not received attention lately. Multiple
> architectures and BSPs needed to be added. Some BSPs that had
> been removed needed to be removed here as well.
> 
> With the legacy TCP/IP stack no longer in rtems.git, it made 
> sense to eliminate the build variance on network. This will
> have a huge impact on the execution time of the build sweeps.
> 
> Build results for everything, tier-1, tier-2, and tier-3 are
> posted to build@.
> 
> Hopefully not controversial since it wasn't in the best shape
> when I started.
> 
> --joel
> 
> Joel Sherrill (5):
>   rtems-bsps-tiers.ini: Add missing architectures and BSPs as tier 3
>   rtems-bsps-tiers.ini: Update comment to use tier 2 definitiion in docs
>   rtems-bsps-arm.ini, config/rtems-bsps.ini: Remove build variance on
> network
>   rtems-bsps.ini: Add missing architectures and BSPs
>   rtems-bsps-tiers.ini: Move appropriate aarch64 BSPs to Tier 1 and 2
> 
>  config/rtems-bsps-arm.ini   |  1 -
>  config/rtems-bsps-tiers.ini | 36 ++--
>  config/rtems-bsps.ini   | 31 +--
>  3 files changed, 43 insertions(+), 25 deletions(-)
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd 1/2] microblaze: Add AXI Ethernet support

[Chris Johns]

On 21/1/22 8:18 am, Alex White wrote:
> On Thu, Jan 20, 2022 at 12:30 AM Chris Johns  wrote:
>>
>> On 20/1/22 2:54 pm, Alex White wrote:
>>> From: Jennifer Averett 
>>>  rtemsbsd/rtems/rtems-kernel-vmem.c|   17 +
>>> diff --git a/rtemsbsd/rtems/rtems-kernel-vmem.c 
>>> b/rtemsbsd/rtems/rtems-kernel-vmem.c
>>> index f64fbd17..70708902 100644
>>> --- a/rtemsbsd/rtems/rtems-kernel-vmem.c
>>> +++ b/rtemsbsd/rtems/rtems-kernel-vmem.c
>>> @@ -41,6 +41,11 @@
>>>
>>>  static MALLOC_DEFINE(M_VMEM, "vmem", "VMEM buffers");
>>>
>>> +int vmem_add(vmem_t *vm, vmem_addr_t addr, vmem_size_t size, int flags)
>>> +{
>>> + return 0;
>>> +}
>>> +
>>>  int
>>>  vmem_alloc(vmem_t *vm, vmem_size_t size, int flags, vmem_addr_t *addrp)
>>>  {
>>> @@ -48,6 +53,18 @@ vmem_alloc(vmem_t *vm, vmem_size_t size, int flags, 
>>> vmem_addr_t *addrp)
>>>   return 0;
>>>  }
>>>
>>> +static int dummy_vmem;
>>> +
>>> +vmem_t *vmem_create(const char *name, vmem_addr_t base,
>>> +vmem_size_t size, vmem_size_t quantum, vmem_size_t qcache_max, int 
>>> flags)
>>> +{
>>> + return _vmem;
>>> +}
>>> +
>>> +void vmem_destroy(vmem_t *vm)
>>> +{
>>> +}
>>> +
>>>  void
>>>  vmem_free(vmem_t *vm, vmem_addr_t addr, vmem_size_t size)
>>>  {
>>
>> What is pulling this interface in?
> 
> The added vmem functions are pulled in by freebsd/sys/dev/xdma/xdma.c

So how can it be an empty stub and the XDMA driver operate? Is the allocator
being called?

>>
>> Why have they been stubbed out?
> 
> They were stubbed out to provide the minimal implementation needed to get 
> xdma working, and xdma is ultimately used by the AXI Ethernet subsystem.
> 
> The alternatives we saw were to pull in the full FreeBSD vmem implementation 
> (overkill) or modify
> freebsd/sys/dev/xdma/xdma.c to not use vmem functions.

What sort of memory does this allocator allocate? Can some heap memory be used?

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

Re: [PATCH rtems-tools] tiers: Add AArch64 to tier 1

[Chris Johns]

On 20/1/22 9:04 am, Joel Sherrill wrote:
> On Wed, Jan 19, 2022 at 2:56 PM Chris Johns  wrote:
>>
>> On 20/1/22 5:08 am, Joel Sherrill wrote:
>>> Are the Tier 1 architectures/BSPs documented anywhere besides an INI file?
>>
>> I do not think they are.
> 
> Me either. I vaguely recall we have had this conversation before.
> 
> Where should they be? Sebastian says we have 5 now.

I am not sure. The user manual or a wiki page with a link in the user manual?

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

Re: [PATCH rtems-libbsd 1/2] microblaze: Add AXI Ethernet support

[Chris Johns]

On 20/1/22 2:54 pm, Alex White wrote:
> From: Jennifer Averett 
>  rtemsbsd/rtems/rtems-kernel-vmem.c|   17 +
> diff --git a/rtemsbsd/rtems/rtems-kernel-vmem.c 
> b/rtemsbsd/rtems/rtems-kernel-vmem.c
> index f64fbd17..70708902 100644
> --- a/rtemsbsd/rtems/rtems-kernel-vmem.c
> +++ b/rtemsbsd/rtems/rtems-kernel-vmem.c
> @@ -41,6 +41,11 @@
>  
>  static MALLOC_DEFINE(M_VMEM, "vmem", "VMEM buffers");
>  
> +int vmem_add(vmem_t *vm, vmem_addr_t addr, vmem_size_t size, int flags)
> +{
> + return 0;
> +}
> +
>  int
>  vmem_alloc(vmem_t *vm, vmem_size_t size, int flags, vmem_addr_t *addrp)
>  {
> @@ -48,6 +53,18 @@ vmem_alloc(vmem_t *vm, vmem_size_t size, int flags, 
> vmem_addr_t *addrp)
>   return 0;
>  }
>  
> +static int dummy_vmem;
> +
> +vmem_t *vmem_create(const char *name, vmem_addr_t base,
> +vmem_size_t size, vmem_size_t quantum, vmem_size_t qcache_max, int flags)
> +{
> + return _vmem;
> +}
> +
> +void vmem_destroy(vmem_t *vm)
> +{
> +}
> +
>  void
>  vmem_free(vmem_t *vm, vmem_addr_t addr, vmem_size_t size)
>  {

What is pulling this interface in?

Why have they been stubbed out?

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

Re: Older gcc for MacOS

[Chris Johns]

On 8/1/22 9:34 am, Joel Sherrill wrote:
> On Fri, Jan 7, 2022 at 4:17 PM Chris Johns  wrote:
>>
>> On 8/1/22 8:28 am, Ryan Long wrote:
>>> Hi,
>>>
>>> Our MacOS VM is failing to build several of the tools on the RTEMS 5 
>>> branch. We
>>> think that using an older version of gcc should get all of the tools to 
>>> build. I
>>> tried build gcc-4.8 with the RSB, but I get the following error.
>>>
>>>
>>> tester@VM-MacOS bare % ../source-builder/sb-set-builder
>>> --prefix=${HOME}/rtems-cron-5/tools/gcc-48 gnu-tools-4.8.2
>>> RTEMS Source Builder - Set Builder, 5 (6225eadda1de modified)
>>> Build Set: gnu-tools-4.8.2
>>> error: gnu-tools-4.8.2:24: cannot find file: devel/gcc-4.8.2-newlib-cvs-1
>>> Build Set: Time 0:00:00.000607
>>> Build FAILED
>>>
>>>
>>> Does anyone know how to get these tools to build?
>>>
>>
>> It looks like the recipe has rotted.
> 
> Was there a native gcc recipe? The name includes newlib which would
> imply it is intended for use with RTEMS.

The `bare/config` tree had recipes to build bare metal tool chains.

> Also clearly old with cvs in the name.
> 
> Having the ability to build an older gcc would ease the burden of
> using 5 on newer FreeBSD, Linux, etc with stricter compilers. As
> with everything, doing it with the RSB gives us control.

Yes but do we want to head down that path?

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

Re: [PATCH 0/5] Update rtems-bsp-builder to match RTEMS master

[Chris Johns]

Looks great and thank you for taking care of this.

Chris

On 20/1/22 5:04 am, Joel Sherrill wrote:
> The set of ini files for rtems-bsp-builder was out of sync
> with the set of architectures and BSPs currently in RTEMS.
> This patch set adds three architectures and a handful of BSPs.
> 
> Build results with these patches are at:
> 
> https://lists.rtems.org/pipermail/build/2022-January/031032.html
> 
> --joel
> 
> Joel Sherrill (5):
>   rtems-bsps-arm.ini: Add missing BSPs
>   rtems-bsps-riscv.ini: Add missing BSPs
>   rtems-bsps-aarch64.ini: New file
>   rtems-bsps-microblaze.ini: New file
>   rtems-bsps-x86_64.ini: New file
> 
>  config/rtems-bsps-aarch64.ini| 31 +++
>  config/rtems-bsps-arm.ini| 16 +---
>  config/rtems-bsps-microblaze.ini | 25 +
>  config/rtems-bsps-riscv.ini  |  4 +++-
>  config/rtems-bsps-x86_64.ini | 25 +
>  5 files changed, 97 insertions(+), 4 deletions(-)
>  create mode 100644 config/rtems-bsps-aarch64.ini
>  create mode 100644 config/rtems-bsps-microblaze.ini
>  create mode 100644 config/rtems-bsps-x86_64.ini
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-tools] tiers: Add AArch64 to tier 1

[Chris Johns]

On 20/1/22 5:08 am, Joel Sherrill wrote:
> Are the Tier 1 architectures/BSPs documented anywhere besides an INI file?

I do not think they are.

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

Re: [PATCH rtems-tools] rtems-bsps-powerpc.ini: Remove powerpc/halekala

[Chris Johns]

OK

Thanks
Chris

On 19/1/22 5:17 am, Joel Sherrill wrote:
> Updates #4302.
> ---
>  config/rtems-bsps-powerpc.ini | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/config/rtems-bsps-powerpc.ini b/config/rtems-bsps-powerpc.ini
> index b4dc02c..fc69827 100644
> --- a/config/rtems-bsps-powerpc.ini
> +++ b/config/rtems-bsps-powerpc.ini
> @@ -24,7 +24,6 @@
>  bsps = beatnik,
> br_uid,
> gwlcfm,
> -   haleakala,
> hsc_cm01,
> icecube,
> mcp750,
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-tools] tiers: Add AArch64 to tier 1

[Chris Johns]

Ok to push.

Thank you
Chris

On 19/1/22 3:19 am, Kinsey Moore wrote:
> Hardware test results have recently been posted for AArch64.
> 
> Closes #4581
> ---
>  config/rtems-bsps-tiers.ini | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/config/rtems-bsps-tiers.ini b/config/rtems-bsps-tiers.ini
> index 875c5df..ba9e6b5 100644
> --- a/config/rtems-bsps-tiers.ini
> +++ b/config/rtems-bsps-tiers.ini
> @@ -21,10 +21,11 @@
>  # Tier 1: no build errors and no unexpected tests failures on hardware.
>  #
>  [tier-1]
> -archs = arm, i386, powerpc
> +archs = arm, i386, powerpc, aarch64
>  bsps_arm = beagleboneblack, imx7, xilinx_zynq_zedboard
>  bsps_i386 = pc686
>  bsps_powerpc = qoriq_e500
> +bsps_aarch64 = xilinx_zynqmp_lp64_zu3eg, xilinx_zynqmp_ilp32_zu3eg
>  
>  #
>  # Tier 2: no build errors and no unexpected tests failures on hardware and
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New validation test suites

[Chris Johns]

On 17/1/22 8:51 pm, Sebastian Huber wrote:
> On 17/01/2022 09:47, Chris Johns wrote:
>> On 17/1/22 7:04 pm, Sebastian Huber wrote:
>>> On 17/01/2022 08:52, Chris Johns wrote:
>>>> My understanding of the status of these patches is the remaining topic is 
>>>> the
>>>> release dependencies. I have not had time to give this any consideration
>>>> however
>>>> I have a feeling it will not be easy or simple because of the 
>>>> inter-dependency
>>>> of the repos and sub-module relationship. I hope I am wrong about this.
>>>
>>> In order to work with the generated test programs you have to use the
>>> specification items which are in rtems-central.  Most of the validation 
>>> tests
>>> are defined through transitions from pre-conditions to post-conditions. 
>>> Working
>>> directly with the generated sources is too complicated. I don't know what
>>> complicates a release here, the rtems-central is just another repository 
>>> which
>>> needs a release branch. In the release branch, the submodules track the
>>> corresponding release branch of the referenced repository.
>>
>> A release has tarballs of sources and not git repos so I am not sure how
>> branches help? How does the submodules in rtems-central get captured? The
>> current release scripts expand sub-modules which means they need to 
>> reconcile or
>> we will have different copies of the code in the release.
>>
>> At the point of release how does the release manager know the rtems-central
>> scripts match the generated sources in the down stream repos that are 
>> released?
> 
> The rtems-central contains nothing relevant to an user of RTEMS. There is no
> need to provide a release archive. The purpose of the branch is the 
> maintenance
> of an RTEMS release branch.

This thread indicates my position about releases needing to be solved to move
forwards. This patch set is the first export from rtems-central that we cannot
maintain outside of rtems-central. It has been a requirement of the qual effort
that we can cleanly separate the two parts and accepting these patches changes
that. I still have real reservations about that happening.

>>> Please note, that the RTEMS sources used by rtems-central are currently not
>>> one-to-one a commit of the RTEMS master branch. There are about 90 
>>> additional
>>> patches. The patch set with the new validation sets is a part of it.
>>
>> Which is a concern and why a release needs to check and make sure everything 
>> is
>> in sync.
>>
>> Ideally the rtems-central submodule hashes match the release tarball sources 
>> for
>> each repo. This is the task as I see it.
>>
>> I am sure this can be resolved and I prefer it happens before being pushed 
>> so it
>> is not left as a task for the release manager.
> 
> The only way to reduce the gap between the RTEMS version referenced by
> rtems-central and the RTEMS master is to integrate patch sets step by step. 
> Some
> patch sets are specific to the sparc/leon3 BSPs and the build system. 

If rtems.git is a submodule where are the changes being held?

And please understand, I think these tests are important and I would like to see
them merged.

> I am not sure if this should delay the RTEMS 6 release.

You could be right, I am not sure. I am still digging myself out of a pile of
things.

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

Re: New validation test suites

[Chris Johns]

On 17/1/22 7:04 pm, Sebastian Huber wrote:
> On 17/01/2022 08:52, Chris Johns wrote:
>> My understanding of the status of these patches is the remaining topic is the
>> release dependencies. I have not had time to give this any consideration 
>> however
>> I have a feeling it will not be easy or simple because of the 
>> inter-dependency
>> of the repos and sub-module relationship. I hope I am wrong about this.
> 
> In order to work with the generated test programs you have to use the
> specification items which are in rtems-central.  Most of the validation tests
> are defined through transitions from pre-conditions to post-conditions. 
> Working
> directly with the generated sources is too complicated. I don't know what
> complicates a release here, the rtems-central is just another repository which
> needs a release branch. In the release branch, the submodules track the
> corresponding release branch of the referenced repository.

A release has tarballs of sources and not git repos so I am not sure how
branches help? How does the submodules in rtems-central get captured? The
current release scripts expand sub-modules which means they need to reconcile or
we will have different copies of the code in the release.

At the point of release how does the release manager know the rtems-central
scripts match the generated sources in the down stream repos that are released?

> Please note, that the RTEMS sources used by rtems-central are currently not
> one-to-one a commit of the RTEMS master branch. There are about 90 additional
> patches. The patch set with the new validation sets is a part of it.

Which is a concern and why a release needs to check and make sure everything is
in sync.

Ideally the rtems-central submodule hashes match the release tarball sources for
each repo. This is the task as I see it.

I am sure this can be resolved and I prefer it happens before being pushed so it
is not left as a task for the release manager.

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

Re: New validation test suites

[Chris Johns]

On 15/1/22 2:02 am, Sebastian Huber wrote:
> On 11/01/2022 17:09, Sebastian Huber wrote:
>>
>> I will do a test run on a arm/imx7 board tomorrow. The new validation tests
>> already passed some time ago on this board.
> 
> Running the complete new validation test suite revealed a bug in the arm
> interrupt handling:

Nice.

> https://devel.rtems.org/ticket/4579
> 
> With the proposed fix I get now the following results for the arm/imx7 BSP on 
> a
> TQMa7x module
> (https://www.tq-group.com/en/products/tq-embedded/arm-architecture/tqma7x/):
> 
> Passed:    674
> Failed:  2
> User Input:  6
> Expected Fail:   0
> Indeterminate:   0
> Benchmark:   3
> Timeout: 0
> Test too long:   0
> Invalid: 0
> Wrong Version:   0
> Wrong Build: 0
> Wrong Tools: 0
> Wrong Header:    0
> --
> Total: 685
> Failures:
>  dl06.exe.img
>  minimum.exe.img
> User Input:
>  dl10.exe.img
>  termios.exe.img
>  fileio.exe.img
>  monitor.exe.img
>  top.exe.img
>  capture.exe.img
> Benchmark:
>  dhrystone.exe.img
>  linpack.exe.img
>  whetstone.exe.img
> Average test time: 0:00:09.704139
> Testing time : 1:50:47.335244
> 
> The dl06 failure is expected, I will update the build configuration 
> accordingly.
> 

Thanks

My understanding of the status of these patches is the remaining topic is the
release dependencies. I have not had time to give this any consideration however
I have a feeling it will not be easy or simple because of the inter-dependency
of the repos and sub-module relationship. I hope I am wrong about this.

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

Re: Older gcc for MacOS

[Chris Johns]

On 8/1/22 8:28 am, Ryan Long wrote:
> Hi,
> 
> Our MacOS VM is failing to build several of the tools on the RTEMS 5 branch. 
> We
> think that using an older version of gcc should get all of the tools to 
> build. I
> tried build gcc-4.8 with the RSB, but I get the following error.
> 
> 
> tester@VM-MacOS bare % ../source-builder/sb-set-builder
> --prefix=${HOME}/rtems-cron-5/tools/gcc-48 gnu-tools-4.8.2
> RTEMS Source Builder - Set Builder, 5 (6225eadda1de modified)
> Build Set: gnu-tools-4.8.2
> error: gnu-tools-4.8.2:24: cannot find file: devel/gcc-4.8.2-newlib-cvs-1
> Build Set: Time 0:00:00.000607
> Build FAILED
> 
> 
> Does anyone know how to get these tools to build?
> 

It looks like the recipe has rotted.

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

Re: [PATCH 1/2] microblaze: Add support for libbsd.

[Chris Johns]

On 5/1/22 5:10 am, Alex White wrote:
> From: Jennifer Averett 
> 
> ---
>  .../microblaze_fpga/dts/microblaze-dtb.c  | 962 ++
>  .../microblaze/microblaze_fpga/dts/system.dts | 452 
>  bsps/microblaze/microblaze_fpga/fdt/bsp_fdt.c |  21 +
>  bsps/microblaze/microblaze_fpga/include/bsp.h |   4 +
>  .../bsps/microblaze/microblaze_fpga/obj.yml   |   2 +
>  5 files changed, 1441 insertions(+)
>  create mode 100644 bsps/microblaze/microblaze_fpga/dts/microblaze-dtb.c
>  create mode 100644 bsps/microblaze/microblaze_fpga/dts/system.dts
>  create mode 100644 bsps/microblaze/microblaze_fpga/fdt/bsp_fdt.c

How does a user with an FPGA microblaze implementation provide there own FDT? I
see the clock speed is a setting.

Is there a means to add such support available?

I am OK with a specific implementation keyed into a specific BSP being in our
source but that must be limited to a specific piece of hardware and FPGA is too
general given this is a soft processor. I think there needs to a workflow that
allows users to customize these settings for their own build.

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

Re: [PATCH 0/2] microblaze: libbsd support

[Chris Johns]

Which repo is this for?

On 5/1/22 5:10 am, Alex White wrote:
> This patch set adds support for libbsd to the MicroBlaze BSPs and contains 
> fixes
> for issues found while debugging the rtems-libbsd telnetd01 test in QEMU and 
> on
> the Xilinx KCU105 board.
> 
> Alex White (1):
>   microblaze: Add support for libbsd networking
> 
> Jennifer Averett (1):
>   microblaze: Add support for libbsd.
> 
>  .../microblaze_fpga/dts/microblaze-dtb.c  | 963 ++
>  .../microblaze/microblaze_fpga/dts/system.dts | 452 
>  bsps/microblaze/microblaze_fpga/fdt/bsp_fdt.c |  22 +
>  bsps/microblaze/microblaze_fpga/include/bsp.h |   9 +
>  bsps/microblaze/microblaze_fpga/irq/irq.c |   2 +-
>  .../microblaze_fpga/start/bspstart.c  |   6 +
>  .../start/microblaze_enable_dcache.S  |  20 +
>  .../start/microblaze_enable_icache.S  |  20 +
>  .../start/microblaze_invalidate_dcache.S  |  29 +
>  .../start/microblaze_invalidate_icache.S  |  28 +
>  cpukit/score/cpu/microblaze/cpu.c |   1 -
>  cpukit/score/cpu/microblaze/cpu_asm.S |   4 +-
>  .../bsps/microblaze/microblaze_fpga/grp.yml   |  12 +
>  .../bsps/microblaze/microblaze_fpga/obj.yml   |   6 +
>  .../microblaze_fpga/optdcachebaseaddress.yml  |  18 +
>  .../microblaze_fpga/optdcachelinelen.yml  |  17 +
>  .../microblaze_fpga/optdcachesize.yml |  17 +
>  .../microblaze_fpga/opticachebaseaddress.yml  |  18 +
>  .../microblaze_fpga/opticachelinelen.yml  |  17 +
>  .../microblaze_fpga/opticachesize.yml |  17 +
>  20 files changed, 1673 insertions(+), 5 deletions(-)
>  create mode 100644 bsps/microblaze/microblaze_fpga/dts/microblaze-dtb.c
>  create mode 100644 bsps/microblaze/microblaze_fpga/dts/system.dts
>  create mode 100644 bsps/microblaze/microblaze_fpga/fdt/bsp_fdt.c
>  create mode 100644 
> bsps/microblaze/microblaze_fpga/start/microblaze_enable_dcache.S
>  create mode 100644 
> bsps/microblaze/microblaze_fpga/start/microblaze_enable_icache.S
>  create mode 100644 
> bsps/microblaze/microblaze_fpga/start/microblaze_invalidate_dcache.S
>  create mode 100644 
> bsps/microblaze/microblaze_fpga/start/microblaze_invalidate_icache.S
>  create mode 100644 
> spec/build/bsps/microblaze/microblaze_fpga/optdcachebaseaddress.yml
>  create mode 100644 
> spec/build/bsps/microblaze/microblaze_fpga/optdcachelinelen.yml
>  create mode 100644 
> spec/build/bsps/microblaze/microblaze_fpga/optdcachesize.yml
>  create mode 100644 
> spec/build/bsps/microblaze/microblaze_fpga/opticachebaseaddress.yml
>  create mode 100644 
> spec/build/bsps/microblaze/microblaze_fpga/opticachelinelen.yml
>  create mode 100644 
> spec/build/bsps/microblaze/microblaze_fpga/opticachesize.yml
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Alternative download paths for RSB?

[Chris Johns]

On 22/12/21 6:37 am, Joel Sherrill wrote:
> On Tue, Dec 21, 2021, 12:45 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> > How can we ensure that all mirrors listed work?
> 
> They would need to be tested and that means more code in the RSB to do it.
> 
> And another thing to check. Worries me.

Yes. What about fetching all the packages on each git commit to a spot on our
ftp server the RSB checks? The hashes will make sure things are OK to use and it
will avoid download when is present.

Chris


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

Re: [PATCH v2] ReportsBase: Change raw pointer to unique_ptr

[Chris Johns]

OK

Thanks
Chris

On 22/12/21 7:49 am, Ryan Long wrote:
> Replaced raw pointer used with ReportsBase-derived classes to make code
> cleaner and make it to where pointers do not have to be manually
> deleted.
> 
> Closes #4376
> ---
>  tester/covoar/ReportsBase.cc | 77 
> +---
>  1 file changed, 36 insertions(+), 41 deletions(-)
> 
> diff --git a/tester/covoar/ReportsBase.cc b/tester/covoar/ReportsBase.cc
> index 219e5af..0fb9ce0 100644
> --- a/tester/covoar/ReportsBase.cc
> +++ b/tester/covoar/ReportsBase.cc
> @@ -591,80 +591,75 @@ void GenerateReports(
>boolbranchInfoAvailable
>  )
>  {
> -  typedef std::list reportList_t;
> +  using reportList_ptr = std::unique_ptr;
> +  using reportList = std::vector;
>  
> -  reportList_t   reportList;
> -  reportList_t::iterator ritr;
> +  reportList reports;
>std::stringreportName;
> -  ReportsBase*   reports;
>time_t timestamp;
>  
>  
>timestamp = time( NULL ); /* get current cal time */
> -  reports = new ReportsText(
> -timestamp,
> -symbolSetName,
> -allExplanations,
> -projectName,
> -outputDirectory,
> -symbolsToAnalyze,
> -branchInfoAvailable
> +  reports.emplace_back(
> +new ReportsText(
> +  timestamp,
> +  symbolSetName,
> +  allExplanations,
> +  projectName,
> +  outputDirectory,
> +  symbolsToAnalyze,
> +  branchInfoAvailable
> +)
>);
> -  reportList.push_back( reports );
> -  reports = new ReportsHtml(
> -timestamp,
> -symbolSetName,
> -allExplanations,
> -projectName,
> -outputDirectory,
> -symbolsToAnalyze,
> -branchInfoAvailable
> +  reports.emplace_back(
> +new ReportsHtml(
> +  timestamp,
> +  symbolSetName,
> +  allExplanations,
> +  projectName,
> +  outputDirectory,
> +  symbolsToAnalyze,
> +  branchInfoAvailable
> +)
>);
> -  reportList.push_back( reports );
>  
> -  for ( ritr = reportList.begin(); ritr != reportList.end(); ritr++ ) {
> -reports = *ritr;
> +  for ( auto& report: reports ) {
>  
> -reportName = "index" + reports->ReportExtension();
> +reportName = "index" + report->ReportExtension();
>  if ( verbose ) {
>std::cerr << "Generate " << reportName << std::endl;
>  }
> -reports->WriteIndex( reportName );
> +report->WriteIndex( reportName );
>  
> -reportName = "annotated" + reports->ReportExtension();
> +reportName = "annotated" + report->ReportExtension();
>  if ( verbose ) {
>std::cerr << "Generate " << reportName << std::endl;
>  }
> -reports->WriteAnnotatedReport( reportName );
> +report->WriteAnnotatedReport( reportName );
>  
> -reportName = "branch" + reports->ReportExtension();
> +reportName = "branch" + report->ReportExtension();
>  if ( verbose ) {
>std::cerr << "Generate " << reportName << std::endl;
>  }
> -reports->WriteBranchReport( reportName );
> +report->WriteBranchReport( reportName );
>  
> -reportName = "uncovered" + reports->ReportExtension();
> +reportName = "uncovered" + report->ReportExtension();
>  if ( verbose ) {
>std::cerr << "Generate " << reportName << std::endl;
>  }
> -reports->WriteCoverageReport( reportName );
> +report->WriteCoverageReport( reportName );
>  
> -reportName = "sizes" + reports->ReportExtension();
> +reportName = "sizes" + report->ReportExtension();
>  if ( verbose ) {
>std::cerr << "Generate " << reportName << std::endl;
>  }
> -reports->WriteSizeReport( reportName );
> +report->WriteSizeReport( reportName );
>  
> -reportName = "symbolSummary" + reports->ReportExtension();
> +reportName = "symbolSummary" + report->ReportExtension();
>  if ( verbose ) {
>std::cerr << "Generate " << reportName << std::endl;
>  }
> -reports->WriteSymbolSummaryReport( reportName, symbolsToAnalyze );
> -  }
> -
> -  for ( ritr = reportList.begin(); ritr != reportList.end(); ritr++ ) {
> -reports = *ritr;
> -delete reports;
> +report->WriteSymbolSummaryReport( reportName, symbolsToAnalyze );
>}
>  
>ReportsBase::WriteSummaryReport(
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Alternative download paths for RSB?

[Chris Johns]

On 22/12/21 1:45 am, Joel Sherrill wrote:
> On Tue, Dec 21, 2021 at 12:33 AM Sebastian Huber
>  wrote:
>>
>> On 20/12/2021 22:52, Chris Johns wrote:
>>> On 21/12/21 2:33 am, Joel Sherrill wrote:
>>>> On Mon, Dec 20, 2021 at 8:54 AM Joel Sherrill  wrote:
>>>>>
>>>>> On Mon, Dec 20, 2021 at 6:59 AM Sebastian Huber
>>>>>  wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> it seems the GNU web server is down:
>>>>>
>>>>> Yep. Still down.
>>>>>
>>>>> i reached out to the sourceware admins to see if they knew who to
>>>>> contact. I couldn't find a gnu.org address.
>>>>
>>>> Social media post from FSF forwarded by one of the sourceware admins
>>>> about a general outage at the FSF:
>>>> https://hostux.social/@fsfstatus/107479476196064925
>>>>
>>>> Looks to be up now. RSB handling mirrors would be good. Although
>>>> it would seem to be complex to ensure that all entries and mirrors are
>>>> correct.
>>>>
>>>>>
>>>>>>
>>>>>> download: https://ftp.gnu.org/gnu/mpfr/mpfr-3.1.4.tar.bz2 ->
>>>>>> sources/mpfr-3.1.4.tar.bz2
>>>>>> download: https://ftp.gnu.org/gnu/mpfr/mpfr-3.1.4.tar.bz2: error:
>>>>>> 
>>>>>> error: downloading https://ftp.gnu.org/gnu/mpfr/mpfr-3.1.4.tar.bz2: all
>>>>>> paths have failed, giving up
>>>>>> Build FAILED
>>>>>> error: downloading https://ftp.gnu.org/gnu/mpfr/mpfr-3.1.4.tar.bz2: all
>>>>>> paths have failed, giving up
>>>>>> Build Set: Time 0:04:23.318509
>>>>>> Build FAILED
>>>>>>
>>>>>> The error message suggests that it is possible to add alternative
>>>>>> download sources. How can I do this? This didn't work:
>>>>>>
>>>>>> diff --git a/source-builder/config/gcc-9.cfg
>>>>>> b/source-builder/config/gcc-9.cfg
>>>>>> index f8cf69b..1d7c716 100644
>>>>>> --- a/source-builder/config/gcc-9.cfg
>>>>>> +++ b/source-builder/config/gcc-9.cfg
>>>>>> @@ -21,4 +21,8 @@
>>>>>>%source set gmp https://ftp.gnu.org/gnu/gmp/gmp-%{gmp_version}.tar.bz2
>>>>>>%source set mpfr 
>>>>>> https://ftp.gnu.org/gnu/mpfr/mpfr-%{mpfr_version}.tar.bz2
>>>>>>
>>>>>> +%source set mpc
>>>>>> https://ftp.mpi-inf.mpg.de/pub/mirrors/gnu/mirror/gcc.gnu.org/pub/gcc/infrastructure/mpc-%{mpc_version}.tar.gz
>>>>>> +%source set gmp
>>>>>> https://ftp.mpi-inf.mpg.de/pub/mirrors/gnu/mirror/gcc.gnu.org/pub/gcc/infrastructure/gmp-%{gmp_version}.tar.bz2
>>>>>> +%source set mpfr
>>>>>> https://ftp.mpi-inf.mpg.de/pub/mirrors/gnu/mirror/gcc.gnu.org/pub/gcc/infrastructure/mpfr-%{mpfr_version}.tar.bz2
>>>>>> +
>>>>>>%include %{_configdir}/gcc-common-1.cfg
>>>>>
>>>>> This would be Chris' department. Sorry
>>>
>>> I would update the `%source` keyword to accept:
>>>
>>> %source mirror mpc 1 https://ftp.mpi-inf.mpg.de/../mpc-%{mpc_version}.tar.gz
>>>
>>> where `1` is an integer priority and 1 is highest. The code is here:
>>>
>>> https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/sources.py#n55
>>>
>>> There is no such thing as a list in the macros so I suspect you would need 
>>> to
>>> dereference the source where the results of `_make_key` would reference 
>>> another
>>> series of macro keys that are the mirrors.
>>>
>>> Do we want to start maintaining lists of mirrors in RSB configurations? I am
>>> undecided. As developers we do not notice the online status due to the RSB
>>> cache. For sites and users would deployment be a better long term solution?
>>
>> Thanks for the hints. I added a ticket for this:
>>
>> https://devel.rtems.org/ticket/4573
> 
> How can we ensure that all mirrors listed work?

They would need to be tested and that means more code in the RSB to do it.

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

Re: [PATCH rtems-tools v1] ReportsBase: Change raw pointer to unique_ptr

[Chris Johns]

On 21/12/21 10:08 am, Ryan Long wrote:
> On 12/20/2021 5:03 PM, Chris Johns wrote:
>> On 21/12/21 7:24 am, Ryan Long wrote:
>>
>>>     reportList_t   reportList;
>> Then make this `reports`.
>>
>>>     reportList_t::iterator ritr;
>>>     std::string    reportName;
>>> -  ReportsBase*   reports;
>>>     time_t timestamp;
>>>         timestamp = time( NULL ); /* get current cal time */
>>> -  reports = new ReportsText(
>>> +  reportList.emplace_back(new ReportsText(
>> Should `std::make_unique(...)` be used?
> I was going to use this, but it was added in c++14.

Ak OK and thanks. I am using c++14 these days and had not noticed. I will leave
this with you.

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

Re: [PATCH rtems-tools v1] ReportsBase: Change raw pointer to unique_ptr

[Chris Johns]

On 21/12/21 7:24 am, Ryan Long wrote:
> Replaced raw pointer used with ReportsBase-derived classes to make code
> cleaner and make it to where pointers do not have to be manually
> deleted.
> 
> Closes #4376
> ---
>  tester/covoar/ReportsBase.cc | 21 ++---
>  1 file changed, 6 insertions(+), 15 deletions(-)
> 
> diff --git a/tester/covoar/ReportsBase.cc b/tester/covoar/ReportsBase.cc
> index 219e5af..8ec65c0 100644
> --- a/tester/covoar/ReportsBase.cc
> +++ b/tester/covoar/ReportsBase.cc
> @@ -591,17 +591,16 @@ void GenerateReports(
>boolbranchInfoAvailable
>  )
>  {
> -  typedef std::list reportList_t;
> +  typedef std::vector> reportList_t;

Are we OK to use `*_t` in types?

Plus I have moved to ...

using reportList = std::vector>

so I would use the following to avoid '>>':

using reportList_ptr = std::unique_ptr;
using reportLists = std::vector;

The vector is a container of report lists and not a container of report list
singular.

A minor point, I do not embed the container type into the type alias because
someone may decide to change this to `std::deque` or `std::forward_list` and the
name becomes misleading.

>reportList_t   reportList;

Then make this `reports`.

>reportList_t::iterator ritr;
>std::stringreportName;
> -  ReportsBase*   reports;
>time_t timestamp;
>  
>  
>timestamp = time( NULL ); /* get current cal time */
> -  reports = new ReportsText(
> +  reportList.emplace_back(new ReportsText(

Should `std::make_unique(...)` be used?

Thanks
Chris

>  timestamp,
>  symbolSetName,
>  allExplanations,
> @@ -609,9 +608,8 @@ void GenerateReports(
>  outputDirectory,
>  symbolsToAnalyze,
>  branchInfoAvailable
> -  );
> -  reportList.push_back( reports );
> -  reports = new ReportsHtml(
> +  ));
> +  reportList.emplace_back(new ReportsHtml(
>  timestamp,
>  symbolSetName,
>  allExplanations,
> @@ -619,11 +617,9 @@ void GenerateReports(
>  outputDirectory,
>  symbolsToAnalyze,
>  branchInfoAvailable
> -  );
> -  reportList.push_back( reports );
> +  ));
>  
> -  for ( ritr = reportList.begin(); ritr != reportList.end(); ritr++ ) {
> -reports = *ritr;
> +  for ( auto& reports: reportList ) {
>  
>  reportName = "index" + reports->ReportExtension();
>  if ( verbose ) {
> @@ -662,11 +658,6 @@ void GenerateReports(
>  reports->WriteSymbolSummaryReport( reportName, symbolsToAnalyze );
>}
>  
> -  for ( ritr = reportList.begin(); ritr != reportList.end(); ritr++ ) {
> -reports = *ritr;
> -delete reports;
> -  }
> -
>ReportsBase::WriteSummaryReport(
>  "summary.txt",
>  symbolSetName,
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Alternative download paths for RSB?

[Chris Johns]

On 21/12/21 2:33 am, Joel Sherrill wrote:
> On Mon, Dec 20, 2021 at 8:54 AM Joel Sherrill  wrote:
>>
>> On Mon, Dec 20, 2021 at 6:59 AM Sebastian Huber
>>  wrote:
>>>
>>> Hello,
>>>
>>> it seems the GNU web server is down:
>>
>> Yep. Still down.
>>
>> i reached out to the sourceware admins to see if they knew who to
>> contact. I couldn't find a gnu.org address.
> 
> Social media post from FSF forwarded by one of the sourceware admins
> about a general outage at the FSF:
> https://hostux.social/@fsfstatus/107479476196064925
> 
> Looks to be up now. RSB handling mirrors would be good. Although
> it would seem to be complex to ensure that all entries and mirrors are
> correct.
> 
>>
>>>
>>> download: https://ftp.gnu.org/gnu/mpfr/mpfr-3.1.4.tar.bz2 ->
>>> sources/mpfr-3.1.4.tar.bz2
>>> download: https://ftp.gnu.org/gnu/mpfr/mpfr-3.1.4.tar.bz2: error:
>>> 
>>> error: downloading https://ftp.gnu.org/gnu/mpfr/mpfr-3.1.4.tar.bz2: all
>>> paths have failed, giving up
>>> Build FAILED
>>> error: downloading https://ftp.gnu.org/gnu/mpfr/mpfr-3.1.4.tar.bz2: all
>>> paths have failed, giving up
>>> Build Set: Time 0:04:23.318509
>>> Build FAILED
>>>
>>> The error message suggests that it is possible to add alternative
>>> download sources. How can I do this? This didn't work:
>>>
>>> diff --git a/source-builder/config/gcc-9.cfg
>>> b/source-builder/config/gcc-9.cfg
>>> index f8cf69b..1d7c716 100644
>>> --- a/source-builder/config/gcc-9.cfg
>>> +++ b/source-builder/config/gcc-9.cfg
>>> @@ -21,4 +21,8 @@
>>>   %source set gmp https://ftp.gnu.org/gnu/gmp/gmp-%{gmp_version}.tar.bz2
>>>   %source set mpfr https://ftp.gnu.org/gnu/mpfr/mpfr-%{mpfr_version}.tar.bz2
>>>
>>> +%source set mpc
>>> https://ftp.mpi-inf.mpg.de/pub/mirrors/gnu/mirror/gcc.gnu.org/pub/gcc/infrastructure/mpc-%{mpc_version}.tar.gz
>>> +%source set gmp
>>> https://ftp.mpi-inf.mpg.de/pub/mirrors/gnu/mirror/gcc.gnu.org/pub/gcc/infrastructure/gmp-%{gmp_version}.tar.bz2
>>> +%source set mpfr
>>> https://ftp.mpi-inf.mpg.de/pub/mirrors/gnu/mirror/gcc.gnu.org/pub/gcc/infrastructure/mpfr-%{mpfr_version}.tar.bz2
>>> +
>>>   %include %{_configdir}/gcc-common-1.cfg
>>
>> This would be Chris' department. Sorry

I would update the `%source` keyword to accept:

%source mirror mpc 1 https://ftp.mpi-inf.mpg.de/../mpc-%{mpc_version}.tar.gz

where `1` is an integer priority and 1 is highest. The code is here:

https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/sources.py#n55

There is no such thing as a list in the macros so I suspect you would need to
dereference the source where the results of `_make_key` would reference another
series of macro keys that are the mirrors.

Do we want to start maintaining lists of mirrors in RSB configurations? I am
undecided. As developers we do not notice the online status due to the RSB
cache. For sites and users would deployment be a better long term solution?

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

Re: New validation test suites

[Chris Johns]

On 16/12/21 6:36 pm, Sebastian Huber wrote:
> On 16/12/2021 04:51, Chris Johns wrote:
>> On 16/12/21 3:27 am, Sebastian Huber wrote:
>>> On 15/12/2021 06:46, Chris Johns wrote:
>>>> On 14/12/21 6:24 pm, Sebastian Huber wrote:
>>>>> Hello Chris,
>>>>>
>>>>> On 13/12/2021 22:01, Chris Johns wrote:
>>>>>> On 14/12/21 1:53 am, Sebastian Huber wrote:
>>> [...]
>>>>>>> We finished the specification of the pre-qualified RTEMS feature set. 
>>>>>>> The
>>>>>>> specification is available in an RTEMS Project repository:
>>>>>>>
>>>>>>> https://git.rtems.org/rtems-central/tree/spec
>>>>>>
>>>>>> I had a quick look. Is there a more user friendly view of this data?
>>>>>>
>>>>>> I think the term "specification" is a little bit misleading because the 
>>>>>> data
>>>>>> files are not easily read by a person. I understand this is the 
>>>>>> specification
>>>>>> data set however it is not what I am traditionally use to seeing.
>>>>>
>>>>> You can use the "./specview.py" script to get views of the specification. 
>>>>>  For
>>>>> example, this command displays the transition map for the 
>>>>> rtems_signal_send()
>>>>> directive:
>>>>
>>>> Is specview.py part of rtems.git?
>>>
>>> No, this script is in rtems-central.  This is also the location of the
>>> specification items.
>>
>> I am not sure linking a script from that repo like this is helpful.
>>
>>>> If not part of rtems.git how much data is there for all the output? That 
>>>> is it
>>>> is generated and held in the repo with the tests?
>>>
>>> In rtems.git, there are only the generated sources.
>>>
>>> [...]
>>
>> There should be no reach back to the upstream specs, scripts etc and for good
>> reasons. The information you posted is nice and useful and I do not wish to
>> release manage rtems-central to accommodate these tests in a release.
>>
>> Would capturing that information with the tests be something worth doing?
> 
> I don't think it would be useful. If you want to modify the tests you should
> work with the specification items and the corresponding scripts.

This is not about modifying the tests. As I previously stated the tests provide
little detail on the verification matrix being solved.

In relation to where is best to make changes, rtems-central may be the best
place however we will accept patches to the tests as they are in rtems.git. How
that is pushed back to rtems-central is not a focus here.

> Adding the
> tables as comments would blow up the sources considerably. Some tests have 
> about
> 5 table entries and the table entries depend on C preprocessor defines.

Ah yes I agree and what I was wanting to understand.

I think we need to understand what a release will contain because the specs used
are not captured with a release. I appreciate the efforts to make this available
as a workflow for development and for the pre-qual process but I am now
critically examining what this means for a release. For example lets say years
after a release someone questions a test, they will only have the test source
code in the release package and I think this is a short coming. Adding the
rtems-central repo as a package to the releases source may be a solution however
this creates further issues. How do I know the master of the rtems-central and
the committed sources match when creating the release as separate pieces of
rtems.git may have been updated at different commit points in rtems-central?

I suggest we get together when we can. Contact me off-line and lets see if we
can arrange a time :)

> 
> [...]
>>>>> In an earlier version of the header, we had a link which you didn't like:
>>>>
>>>> If I need to look at the formatting rules the heading "Software Development
>>>> Management" is easy to see and then a click on "Coding Standards" gives me 
>>>> what
>>>> I am looking for.
>>>>
>>>> To generate these headers I click on "Software Requirements Engineering" 
>>>> and
>>>> then do I just guess until I find it in the "How To" section? I am actually
>>>> asking this be sorted out so it is not left hanging and we are not left
>>>> guessing
>>>> what to do. If it can be rearrange into something meaningful it 

Re: [PATCH rtems-libbsd] Import arm64 in_cksum.h correctly

[Chris Johns]

OK

Thanks
Chris

On 16/12/21 3:05 am, Kinsey Moore wrote:
> When this file was brought in, it came from the wrong location or
> freebsd-org hash. This corrects the file such that freebsd-to-rtems.py
> runs cleanly.
> ---
>  freebsd/sys/arm64/include/machine/in_cksum.h | 43 +++-
>  1 file changed, 6 insertions(+), 37 deletions(-)
> 
> diff --git a/freebsd/sys/arm64/include/machine/in_cksum.h 
> b/freebsd/sys/arm64/include/machine/in_cksum.h
> index d55b838b..522ba005 100644
> --- a/freebsd/sys/arm64/include/machine/in_cksum.h
> +++ b/freebsd/sys/arm64/include/machine/in_cksum.h
> @@ -1,6 +1,4 @@
>  /*-
> - * SPDX-License-Identifier: BSD-3-Clause
> - *
>   * Copyright (c) 1990 The Regents of the University of California.
>   * All rights reserved.
>   *
> @@ -31,7 +29,6 @@
>   *   from tahoe: in_cksum.c  1.2 86/01/05
>   *   from:   @(#)in_cksum.c  1.3 (Berkeley) 1/19/91
>   *   from: Id: in_cksum.c,v 1.8 1995/12/03 18:35:19 bde Exp
> - *   from: src/sys/alpha/include/in_cksum.h,v 1.7 2005/03/02 21:33:20 joerg
>   * $FreeBSD$
>   */
>  
> @@ -40,44 +37,16 @@
>  
>  #include 
>  
> +#ifdef _KERNEL
>  #define  in_cksum(m, len)in_cksum_skip(m, len, 0)
> -
> +u_short in_addword(u_short sum, u_short b);
> +u_short in_cksum_skip(struct mbuf *m, int len, int skip);
> +u_int do_cksum(const void *, int);
>  #if defined(IPVERSION) && (IPVERSION == 4)
> -/*
> - * It it useful to have an Internet checksum routine which is inlineable
> - * and optimized specifically for the task of computing IP header checksums
> - * in the normal case (where there are no options and the header length is
> - * therefore always exactly five 32-bit words.
> - */
> -#ifdef __CC_SUPPORTS___INLINE
> -
> -static __inline void
> -in_cksum_update(struct ip *ip)
> -{
> - int __tmpsum;
> - __tmpsum = (int)ntohs(ip->ip_sum) + 256;
> - ip->ip_sum = htons(__tmpsum + (__tmpsum >> 16));
> -}
> -
> -#else
> -
> -#define  in_cksum_update(ip) 
> \
> - do {\
> - int __tmpsum;   \
> - __tmpsum = (int)ntohs(ip->ip_sum) + 256;\
> - ip->ip_sum = htons(__tmpsum + (__tmpsum >> 16));\
> - } while(0)
> -
> -#endif
> +u_int in_cksum_hdr(const struct ip *);
>  #endif
>  
> -#ifdef _KERNEL
> -#if defined(IPVERSION) && (IPVERSION == 4)
> -u_int in_cksum_hdr(const struct ip *ip);
> -#endif
> -u_short in_addword(u_short sum, u_short b);
>  u_short in_pseudo(u_int sum, u_int b, u_int c);
> -u_short in_cksum_skip(struct mbuf *m, int len, int skip);
> -#endif
>  
> +#endif /* _KERNEL */
>  #endif /* _MACHINE_IN_CKSUM_H_ */
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH RSB 5] sb: Merge mailer changes from rtems-tools

[Chris Johns]

OK

Thanks
Chris

On 16/12/21 8:38 am, Alex White wrote:
> This adds the improved mailer.py script from rtems-tools.
> 
> Closes #4554
> ---
>  source-builder/sb/mailer.py | 194 
> +---
>  source-builder/sb/options.py|  26 +-
>  source-builder/sb/setbuilder.py |   2 +
>  3 files changed, 189 insertions(+), 33 deletions(-)
> 
> diff --git a/source-builder/sb/mailer.py b/source-builder/sb/mailer.py
> index 42b4fa6..1d3cbb5 100644
> --- a/source-builder/sb/mailer.py
> +++ b/source-builder/sb/mailer.py
> @@ -1,21 +1,33 @@
>  #
>  # RTEMS Tools Project (http://www.rtems.org/)
> -# Copyright 2013 Chris Johns (chr...@rtems.org)
> +# Copyright 2013-2016 Chris Johns (chr...@rtems.org)
> +# Copyright (C) 2021 On-Line Applications Research Corporation (OAR)
>  # All rights reserved.
>  #
>  # This file is part of the RTEMS Tools package in 'rtems-tools'.
>  #
> -# Permission to use, copy, modify, and/or distribute this software for any
> -# purpose with or without fee is hereby granted, provided that the above
> -# copyright notice and this permission notice appear in all copies.
> +# Redistribution and use in source and binary forms, with or without
> +# modification, are permitted provided that the following conditions are met:
> +#
> +# 1. Redistributions of source code must retain the above copyright notice,
> +# this list of conditions and the following disclaimer.
> +#
> +# 2. Redistributions in binary form must reproduce the above copyright 
> notice,
> +# this list of conditions and the following disclaimer in the documentation
> +# and/or other materials provided with the distribution.
> +#
> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> +# POSSIBILITY OF SUCH DAMAGE.
>  #
> -# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> -# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> -# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> -# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> -# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> -# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> -# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>  
>  #
>  # Manage emailing results or reports.
> @@ -28,18 +40,72 @@ import smtplib
>  import socket
>  
>  import error
> +import execute
>  import options
>  import path
>  
> +_options = {
> +'--mail' : 'Send email report or results.',
> +'--use-gitconfig': 'Use mail configuration from git config.',
> +'--mail-to'  : 'Email address to send the email to.',
> +'--mail-from': 'Email address the report is from.',
> +'--smtp-host': 'SMTP host to send via.',
> +'--smtp-port': 'SMTP port to send via.',
> +'--smtp-user': 'User for SMTP authentication.',
> +'--smtp-password': 'Password for SMTP authentication.'
> +}
> +
>  def append_options(opts):
> -opts['--mail'] = 'Send email report or results.'
> -opts['--smtp-host'] = 'SMTP host to send via.'
> -opts['--mail-to'] = 'Email address to send the email too.'
> -opts['--mail-from'] = 'Email address the report is from.'
> +for o in _options:
> +opts[o] = _options[o]
> +
> +def add_arguments(argsp):
> +argsp.add_argument('--mail', help = _options['--mail'], action = 
> 'store_true')
> +argsp.add_argument('--use-gitconfig', help = 
> _options['--use-gitconfig'], action = 'store_true')
> +no_add = ['--mail', '--use-gitconfig']
> +for o in [opt for opt in list(_options) if opt not in no_add]:
> +argsp.add_argument(o, help = _options[o], type = str)
>  
>  class mail:
>  def __init__(self, opts):
>  self.opts = opts
> +self.gitconfig_lines = None
> +if opts.find_arg('--use-gitconfig') is not None:
> +# Read the output of `git config --

Re: [PATCH rtems-tools 5 0/5] Port mailer.py fixes to rtems-tools 5 branch

[Chris Johns]

OK

Thanks
Chris

On 16/12/21 8:32 am, Alex White wrote:
> Hi,
> 
> This patch set adds the changes related to report mailing to rtems-tools 5.
> 
> See #4553
> 
> Thanks,
> 
> Alex White
> 
> Alex White (5):
>   rtemstoolkit/mailer.py: Return full smtp-host arg value
>   rtemstoolkit: Filter mail options from log output
>   rtemstoolkit/mailer.py: Add SMTP login options
>   rtemstoolkit/mailer.py: Add --use-gitconfig option
>   rtems-bsp-builder: Fix mail support
> 
>  rtemstoolkit/mailer.py  | 86 +
>  rtemstoolkit/options.py | 17 +++-
>  tester/rt/check.py  | 17 +++-
>  3 files changed, 111 insertions(+), 9 deletions(-)
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New validation test suites

[Chris Johns]

On 16/12/21 3:27 am, Sebastian Huber wrote:
> On 15/12/2021 06:46, Chris Johns wrote:
>> On 14/12/21 6:24 pm, Sebastian Huber wrote:
>>> Hello Chris,
>>>
>>> On 13/12/2021 22:01, Chris Johns wrote:
>>>> On 14/12/21 1:53 am, Sebastian Huber wrote:
> [...]
>>>>> We finished the specification of the pre-qualified RTEMS feature set. The
>>>>> specification is available in an RTEMS Project repository:
>>>>>
>>>>> https://git.rtems.org/rtems-central/tree/spec
>>>>
>>>> I had a quick look. Is there a more user friendly view of this data?
>>>>
>>>> I think the term "specification" is a little bit misleading because the 
>>>> data
>>>> files are not easily read by a person. I understand this is the 
>>>> specification
>>>> data set however it is not what I am traditionally use to seeing.
>>>
>>> You can use the "./specview.py" script to get views of the specification.  
>>> For
>>> example, this command displays the transition map for the 
>>> rtems_signal_send()
>>> directive:
>>
>> Is specview.py part of rtems.git?
> 
> No, this script is in rtems-central.  This is also the location of the
> specification items.

I am not sure linking a script from that repo like this is helpful.

>> If not part of rtems.git how much data is there for all the output? That is 
>> it
>> is generated and held in the repo with the tests?
> 
> In rtems.git, there are only the generated sources.
> 
> [...]

There should be no reach back to the upstream specs, scripts etc and for good
reasons. The information you posted is nice and useful and I do not wish to
release manage rtems-central to accommodate these tests in a release.

Would capturing that information with the tests be something worth doing?

>>>>> The validation tests are generated from the specification using the
>>>>> "./spec2modules.py" script and end up in the RTEMS sources of a Git
>>>>> submodule. I
>>>>> think the specification and the generation tool is now sufficiently 
>>>>> stable so
>>>>> that the validation test code can be integrated in the RTEMS master 
>>>>> branch.
>>>>> The
>>>>> patch set is too big for the mailing list, so you can review it here:
>>>>>
>>>>> https://git.rtems.org/sebh/rtems.git/log/?h=validation
>>>>
>>>> The link failed.
>>>
>>> Yes, viewing my personal repository no longer works.  I am not sure if this 
>>> is a
>>> temporary issue.  This is why I added the github link.
>>
>> It seems to have been temporary. It is back again.
>>
>>>
>>>>
>>>>> https://github.com/sebhub/rtems/tree/validation
>>>>
>>>> The header in a test says the regeneration instructions are in the 
>>>> engineering
>>>> manual but I could not quickly find them?
>>>
>>> https://docs.rtems.org/branches/master/eng/req/howto.html#generate-content-after-changes
>>>
>>>
>>>
>>> In an earlier version of the header, we had a link which you didn't like:
>>
>> If I need to look at the formatting rules the heading "Software Development
>> Management" is easy to see and then a click on "Coding Standards" gives me 
>> what
>> I am looking for.
>>
>> To generate these headers I click on "Software Requirements Engineering" and
>> then do I just guess until I find it in the "How To" section? I am actually
>> asking this be sorted out so it is not left hanging and we are not left 
>> guessing
>> what to do. If it can be rearrange into something meaningful it would help. 
>> :)
> 
> Well, if you read the text in the header:
> 
>  * For information on updating and regenerating please refer to the How-To
>  * section in the Software Requirements Engineering chapter of the
>  * RTEMS Software Engineering manual.  The manual is provided as a part of
>  * a release.  For development sources please refer to the online
>  * documentation at:
>  *
>  * https://docs.rtems.org
> 
> You should read the How-to section or not?

Yes I should have and thanks for pointing this out but I did not see this and
the manual as it stands did not help. I think it should change. It can be
performed post this patch set but I think the documentation would read better if
changed.

>>>> What hardware have the validation tests been run 

Re: New validation test suites

[Chris Johns]

On 14/12/21 6:24 pm, Sebastian Huber wrote:
> Hello Chris,
> 
> On 13/12/2021 22:01, Chris Johns wrote:
>> On 14/12/21 1:53 am, Sebastian Huber wrote:
>>> Hello,
>>>
>>> the ESA activity to pre-qualify parts of RTEMS according to ECSS 
>>> requirements is
>>> nearly complete. There is a short presentation available here:
>>>
>>> https://indico.esa.int/event/374/timetable/
>>
>> Was the change in memory usage for 4.8 of 23812 bytes to 68896 explained?
> 
> The foot print increase has mainly five reasons:
> 
> * General GCC code generation
> 
> * Chip errata workarounds done by GCC
> 
> * More features used from RTEMS (for example uniprocessor synchronization done
> via task priorities vs. mutex synchronization)
> 
> * SMP support of RTEMS
> 
> * New RTEMS features such as transitive priority inheritance
> 

Thanks.

>>> We finished the specification of the pre-qualified RTEMS feature set. The
>>> specification is available in an RTEMS Project repository:
>>>
>>> https://git.rtems.org/rtems-central/tree/spec
>>
>> I had a quick look. Is there a more user friendly view of this data?
>>
>> I think the term "specification" is a little bit misleading because the data
>> files are not easily read by a person. I understand this is the specification
>> data set however it is not what I am traditionally use to seeing.
> 
> You can use the "./specview.py" script to get views of the specification.  For
> example, this command displays the transition map for the rtems_signal_send()
> directive:

Is specview.py part of rtems.git?

If not part of rtems.git how much data is there for all the output? That is it
is generated and held in the repo with the tests?

> 
> ./specview.py --filter=action-table /rtems/signal/req/send
> .. table::
>     :class: longtable
> 
>     = == = === ===  == == 
> =
> =
>     Entry Descriptor Task  Set Handler ASR  Nested Status Handler 
>  
> Recursive
>     = == = === ===  == == 
> =
> =
>     0 0  NoObj Zero    Invalid Enabled  Yes    InvNum NoCall  
>   No
>     1 0  NoObj Zero    Invalid Enabled  No InvNum NoCall  
>   No
>     2 0  NoObj Zero    Invalid Disabled Yes    InvNum NoCall  
>   No
>     3 0  NoObj Zero    Invalid Disabled No InvNum NoCall  
>   No
>     4 0  NoObj Zero    Valid   Enabled  Yes    InvNum NoCall  
>   No
>     5 0  NoObj Zero    Valid   Enabled  No InvNum NoCall  
>   No
>     6 0  NoObj Zero    Valid   Disabled Yes    InvNum NoCall  
>   No
>     7 0  NoObj Zero    Valid   Disabled No InvNum NoCall  
>   No
>     8 1  NoObj NonZero Invalid Enabled  Yes    InvId NoCall   
>  No
>     9 1  NoObj NonZero Invalid Enabled  No InvId NoCall   
>  No
>     10    1  NoObj NonZero Invalid Disabled Yes    InvId NoCall   
>  No
>     11    1  NoObj NonZero Invalid Disabled No InvId NoCall   
>  No
>     12    1  NoObj NonZero Valid   Enabled  Yes    InvId NoCall   
>  No
>     13    1  NoObj NonZero Valid   Enabled  No InvId NoCall   
>  No
>     14    1  NoObj NonZero Valid   Disabled Yes    InvId NoCall   
>  No
>     15    1  NoObj NonZero Valid   Disabled No InvId NoCall   
>  No
>     16    0  Self  Zero    Invalid Enabled  Yes    InvNum NoCall  
>   No
>     17    0  Self  Zero    Invalid Enabled  No InvNum NoCall  
>   No
>     18    0  Self  Zero    Invalid Disabled Yes    InvNum NoCall  
>   No
>     19    0  Self  Zero    Invalid Disabled No InvNum NoCall  
>   No
>     20    0  Self  Zero    Valid   Enabled  Yes    InvNum NoCall  
>   No
>     21    0  Self  Zero    Valid   Enabled  No InvNum NoCall  
>   No
>     22    0  Self  Zero    Valid   Disabled Yes    InvNum NoCall  
>   No
>     23    0  Self  Zero    Valid   Disabled No InvNum NoCall  
>   No
>     24    2  Self  NonZero Invalid Enabled  Yes    NotDef NoCall  
>   No
>     25    2  Self  NonZero Invalid Enabled  No NotDef NoCall  
>   No
>     26    2  Self  NonZero Invalid Disabled Yes    NotDef NoCall  
>   No
>     27    2  Self  NonZero Invalid Disabled No NotDef NoCall  
>   No
>     28    6  

Re: [PATCH] TraceConverter.cc: Fix Uncaught exception issue

[Chris Johns]

OK

On 14/12/21 12:47 am, Ryan Long wrote:
> CID 1471639: Uncaught exception
> 
> Closes #4501
> ---
>  tester/covoar/TraceConverter.cc | 20 ++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/tester/covoar/TraceConverter.cc b/tester/covoar/TraceConverter.cc
> index 8e30ae5..2c5330a 100644
> --- a/tester/covoar/TraceConverter.cc
> +++ b/tester/covoar/TraceConverter.cc
> @@ -87,14 +87,30 @@ int main(
>std::string tracefile;
>std::string logname = "/tmp/qemu.log";
>Coverage::ExecutableInfo*   executableInfo;
> -  rld::process::tempfile  objdumpFile( ".dmp" );
> -  rld::process::tempfile  err( ".err" );
>Coverage::DesiredSymbolssymbolsToAnalyze;
>boolverbose = false;
>std::string dynamicLibrary;
>int ec = 0;
>std::shared_ptr targetInfo;
>  
> +  try
> +  {
> +rld::process::tempfile objdumpFile( ".dmp" );
> +  }
> +  catch ( rld::error re )
> +  {
> +std::cerr << "Failed to make .dmp tempfile " << std::endl;
> +  }
> +
> +  try
> +  {
> +rld::process::tempfile err( ".err" );
> +  }
> +  catch ( rld::error re )
> +  {
> +std::cerr << "Failed to make .err tempfile " << std::endl;
> +  }
> +
>setup_signals();
>  
> //
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New validation test suites

[Chris Johns]

On 14/12/21 1:53 am, Sebastian Huber wrote:
> Hello,
> 
> the ESA activity to pre-qualify parts of RTEMS according to ECSS requirements 
> is
> nearly complete. There is a short presentation available here:
> 
> https://indico.esa.int/event/374/timetable/

Was the change in memory usage for 4.8 of 23812 bytes to 68896 explained?
> We finished the specification of the pre-qualified RTEMS feature set. The
> specification is available in an RTEMS Project repository:
> 
> https://git.rtems.org/rtems-central/tree/spec

I had a quick look. Is there a more user friendly view of this data?

I think the term "specification" is a little bit misleading because the data
files are not easily read by a person. I understand this is the specification
data set however it is not what I am traditionally use to seeing.

> The validation tests are generated from the specification using the
> "./spec2modules.py" script and end up in the RTEMS sources of a Git 
> submodule. I
> think the specification and the generation tool is now sufficiently stable so
> that the validation test code can be integrated in the RTEMS master branch. 
> The
> patch set is too big for the mailing list, so you can review it here:
> 
> https://git.rtems.org/sebh/rtems.git/log/?h=validation

The link failed.

> https://github.com/sebhub/rtems/tree/validation

The header in a test says the regeneration instructions are in the engineering
manual but I could not quickly find them?

> The patch set is organized so that general support code for the validation 
> tests
> is added first and then there are commits for each pre-qualified Classic API
> Manager or subsystem.
> 
> I did build all BSPs with the patch set. The validation tests use only
> statically allocated resources. 

Are the validation tests compatible with rtems-test?

How many test executables does this add to the testsuite?

What hardware have the validation tests been run on? Any tier 1 archs?

Is there anything that interprets the new test output format? It looks like lots
of great info but a little difficult to read.

> Some low memory targets are not able to link all test suites.

Are these excluded in the normal way?

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

Re: [PATCH rtems-tools 0/6] Fix formatting patches

[Chris Johns]

OK and thanks for the split.

Thanks
Chris

On 14/12/21 3:09 am, Ryan Long wrote:
> Hi,
> 
> For this patchset I made the formatting more consistent.
> 
> This included:
> 
> - adding whitespace
> - adding curly braces to if statements or loops
> - fixing the layout of long lists of function parameters
> 
> Thanks,
> Ryan
> 
> Ryan Long (6):
>   ObjdumpProcessor.cc: Fix formatting
>   TargetFactory.cc: Fix formatting
>   ConfigFile: Fix formatting
>   ObjdumpProcessor.cc: Fix formatting
>   ObjdumpProcessor.h: Fix formatting
>   SymbolTable.cc: Fix formatting
> 
>  tester/covoar/ConfigFile.cc   |  66 +-
>  tester/covoar/ConfigFile.h|   8 +-
>  tester/covoar/ObjdumpProcessor.cc | 261 
> +-
>  tester/covoar/ObjdumpProcessor.h  |  22 ++--
>  tester/covoar/SymbolTable.cc  |  70 +-
>  tester/covoar/TargetFactory.cc|  20 ++-
>  6 files changed, 241 insertions(+), 206 deletions(-)
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems commit] untar: Make behavior similar to GNU or BSD tar

[Chris Johns]

On 10/12/21 6:20 pm, Christian MAUDERER wrote:
> Am 09.12.21 um 22:09 schrieb Chris Johns:
>> On 9/12/21 6:47 pm, Christian MAUDERER wrote:
>>
>> Given it is in maybe we let it sit and it there is feedback we come back and
>> take another look?
> 
> No problem with that. I will try to be extra sensitive for problems with Untar
> that appear on the list in the next months.
> 

Thanks. There is no easy or clear guideline with this as a number of factors
effect this.

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

Re: [PATCH rtems-tools v2 0/4] Convert to C++ patches

[Chris Johns]

On 10/12/21 10:00 am, Ryan Long wrote:
> For this round of changes, I made some revisions that were recommended
> in ConfigFile.cc
> 
> - deleted a library include
> - changed a function call from sscanf to std::sscanf
> - consolidated some error messages into a function

OK to push.

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

Re: [rtems commit] untar: Make behavior similar to GNU or BSD tar

[Chris Johns]

On 9/12/21 6:47 pm, Christian MAUDERER wrote:
> Hello Chris,
> 
> sorry that I haven't been clear enough.
> 
> 1. The ticket #4552 that I created before sending the patch to the list and 
> that
> was closed by the patch was for 5.
> 
> 2. I asked as an answer to Joels review and I understood him that he is OK 
> with
> that change:
> 
>   https://lists.rtems.org/pipermail/devel/2021-December/070092.html
> 
> and
> 
>   https://lists.rtems.org/pipermail/devel/2021-December/070093.html

Again sorry I missed this when I brushed over the emails.

> 
> Do you want me to revert that patch on 5?
> 

It does change the expected functionality and we should be careful about doing
that. It is not clear if someone has relied on it working this way as a cheap
way to detect an overwrite. I am fine on RTEMS 6 because of the upgrade and a
ticket in the release notes covering the change however if it breaks in a dot
release then that is a different issue.

Given it is in maybe we let it sit and it there is feedback we come back and
take another look?

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

Re: [rtems commit] untar: Make behavior similar to GNU or BSD tar

[Chris Johns]

Hi Christian,

I did not know this was for the 5 branch. Where was this discussed?

Functional changes to a release branch need to be treated carefully and in this
case I would not approve it. I am sorry if I did not pick up it was for 5 as 
well.

Thanks
Chris

On 9/12/21 6:21 pm, Christian Mauderer wrote:
> Module:rtems
> Branch:5
> Commit:ff3f3490df7120c9ec039b5acd1935265c3f9262
> Changeset: 
> http://git.rtems.org/rtems/commit/?id=ff3f3490df7120c9ec039b5acd1935265c3f9262
> 
> Author:Christian Mauderer 
> Date:  Wed Dec  1 16:39:46 2021 +0100
> 
> untar: Make behavior similar to GNU or BSD tar
> 
> RTEMS untar implementation had problems with overwriting or integrating
> archives into existing directory structures. This patch adapts the
> behavior to mimic that of a GNU tar or BSD tar and extends the tar01
> test to check for the behavior. That is:
> 
> * If a directory structure exists, the files from the archive will be
>   integrated. Existing files are overwritten.
> 
> * If a file exists and the archive contains a directory with the same
>   name, the file is removed and a directory is created. In the above
>   example: if l1/l2 is a file it will be overwritten with a new
>   directory.
> 
> * If a directory exists and the archive contains a file with the same
>   name, the directory will be replaced if it is empty. If it contains
>   files, the result is an error.
> 
> * An archive also can contain only a file without the parent
>   directories. If in that case one of the parent directories exists as a
>   file extracting the archive results in an error. In the example: if
>   l1/l2 is a file and the archive doesn't contain the directories but
>   only the file l1/l2/x.txt that would be an error.
> 
> * In case of an error, it is possible that the archive has been
>   partially extracted.
> 
> Closes #4552
> 
> ---
> 
>  cpukit/libmisc/untar/untar.c|  57 +++
>  testsuites/libtests/tar01/init.c| 199 
> +++-
>  testsuites/libtests/tar01/tar01.doc |   1 +
>  testsuites/libtests/tar01/tar01.scn |  54 --
>  testsuites/libtests/tar01/tar01.tar | Bin 10240 -> 10240 bytes
>  5 files changed, 282 insertions(+), 29 deletions(-)
> 
> diff --git a/cpukit/libmisc/untar/untar.c b/cpukit/libmisc/untar/untar.c
> index a2f09fb..ab2 100644
> --- a/cpukit/libmisc/untar/untar.c
> +++ b/cpukit/libmisc/untar/untar.c
> @@ -126,30 +126,25 @@ Make_Path(const rtems_printer *printer, char *path)
>  
>  *p = '\0';
>  if (p[1] == '\0') {
> -  /* Speculatively unlink the last component so that it can be 
> re-created */
> -  unlink(path);
>return 0;
>  }
>  
>  if (mkdir(path, S_IRWXU | S_IRWXG | S_IRWXO) != 0) {
> -  if (errno == EEXIST || errno == EISDIR) {
> +  if (errno == EEXIST) {
> +/* If it exists already: Check whether it is a directory */
>  struct stat sb;
> -
> -if (stat(path, ) != 0) {
> +if (lstat(path, ) != 0) {
> +  Print_Error(printer, "lstat", path);
> +  return -1;
> +} else if (!S_ISDIR(sb.st_mode)) {
> +  rtems_printf(printer,
> +   "untar: mkdir: %s: exists but is not a directory\n",
> +   path);
>return -1;
>  }
> -
> -if (!S_ISDIR(sb.st_mode)) {
> -  if (unlink(path) != 0) {
> -Print_Error(printer, "unlink", path);
> -return -1;
> -  }
> -
> -  if (mkdir(path, S_IRWXU | S_IRWXG | S_IRWXO) != 0) {
> -Print_Error(printer, "mkdir (unlink)", path);
> -return -1;
> -  }
> -}
> +  } else {
> +Print_Error(printer, "mkdir", path);
> +return -1;
>}
>  }
>  
> @@ -206,6 +201,12 @@ Untar_ProcessHeader(
>  
>if (Make_Path(ctx->printer, ctx->file_path) != 0) {
>  retval = UNTAR_FAIL;
> +  } else {
> +/*
> + * Speculatively unlink. This should unlink everything but non-empty
> + * directories or write protected stuff.
> + */
> +unlink(ctx->file_path);
>}
>  
>if (ctx->linkflag == SYMTYPE) {
> @@ -225,8 +226,22 @@ Untar_ProcessHeader(
>  rtems_printf(ctx->printer, "untar: dir: %s\n", ctx->file_path);
>  r = mkdir(ctx->file_path, ctx->mode);
>  if (r != 0) {
> -  Print_Error(ctx->printer, "mkdir", ctx->file_path);
> -  retval = UNTAR_FAIL;
> +  if (errno == EEXIST) {
> +/* If it exists already: Check whether it is a directory */
> +struct stat sb;
> +if (lstat(ctx->file_path, ) != 0) {
> +  Print_Error(ctx->printer, "lstat", ctx->file_path);
> +  retval = UNTAR_FAIL;
> +} else if (!S_ISDIR(sb.st_mode)) {
> +  rtems_printf(ctx->printer,
> +   "untar: mkdir: %s: exists but is not a directory\n",
> +   ctx->file_path);
> +  retval = UNTAR_FAIL;
> +}
> +  } else {
> +

Re: [PATCH v1 3/4] ConfigFile: Convert to C++

[Chris Johns]

On 9/12/21 2:15 am, Ryan Long wrote:
> ---
>  tester/covoar/ConfigFile.cc | 79 
> +
>  tester/covoar/ConfigFile.h  |  2 +-
>  2 files changed, 31 insertions(+), 50 deletions(-)
> 
> diff --git a/tester/covoar/ConfigFile.cc b/tester/covoar/ConfigFile.cc
> index c16b64a..5c8949e 100644
> --- a/tester/covoar/ConfigFile.cc
> +++ b/tester/covoar/ConfigFile.cc
> @@ -10,6 +10,10 @@
>  #include 

Is this needed? I think reducing the C interfaces included would help the long
maintenance.

>  #include 
>  
> +#include 
> +#include 
> +#include 
> +
>  namespace Configuration {
>  
>FileReader::FileReader(
> @@ -24,43 +28,40 @@ namespace Configuration {
>}
>  
>bool FileReader::processFile(
> -const char* const file
> +const std::string& file
>)
>{
>  #define METHOD "FileReader::processFile - "
> -FILE *  in;
> -charline[256];
> -charoption[256];
> -charvalue[256];
> +#define MAX_LENGTH 256
> +std::ifstream in;
> +std::string line;
> +char option[MAX_LENGTH];
> +char value[MAX_LENGTH];
>  int line_no;
>  int i;
>  int j;
>  
> -if ( file == NULL ) {
> -  fprintf( stderr, METHOD "NULL filename\n" );
> +if ( file.empty() ) {
> +  std::cerr << METHOD << "Empty filename" << std::endl;
>return false;
>  }
>  
> -in = fopen( file, "r" );
> -if ( !in ) {
> -  fprintf( stderr, METHOD "unable to open %s\n", file );
> +in.open( file );
> +if ( !in.is_open() ) {
> +  std::cerr << METHOD << "unable to open " << file << std::endl;
>return false;
>  }
>  
>  line_no = 0;
> -while (fgets(line, sizeof(line), in) != NULL) {
> +while ( std::getline( line, MAX_LENGTH ) ) {
>int length;
>  
>line_no++;
>  
> -  length = (int) strlen( line );
> -  if ( line[length - 1] != '\n' ) {
> -fprintf(
> -  stderr,
> -  "%s: line %d is too long",
> -  file,
> -  line_no
> -);
> +  length = (int) line.length();
> +  if ( length > MAX_LENGTH ) {
> +std::cerr << file << ": line " << line_no << " is too long"
> +  << std::endl;
>  continue;
>}
>  
> @@ -96,14 +97,9 @@ namespace Configuration {
>if (line[0] == '\0')
>  continue;
>  
> -  if (sscanf(line, "%s", option) != 1) {
> -fprintf(
> -  stderr,
> -  "%s: line %d is invalid: %s\n",
> -  file,
> -  line_no,
> -  line
> -);
> +  if (sscanf(line.c_str(), "%s", option) != 1) {

I suggest you use the C++ interface ..

https://en.cppreference.com/w/cpp/io/c/fscanf

> +std::cerr << file << ": line" << line_no << " is invalid: " << line
> +  << std::endl;

Please make the repeated code a helper function with line number and line as 
args.

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

Re: [PATCH] spec: Update location of cadence I2C

[Chris Johns]

OK and thanks

Chris

On 9/12/21 12:08 pm, Kinsey Moore wrote:
> When the cadence I2C code was moved to a shared directory, the
> references were updated but the install locations weren't. This updates
> the install locations to match what out-of-tree applications expect.
> ---
>  spec/build/bsps/aarch64/xilinx-zynqmp/objcadencei2c.yml | 4 +++-
>  spec/build/bsps/arm/xilinx-zynq/obj.yml | 6 --
>  2 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/objcadencei2c.yml 
> b/spec/build/bsps/aarch64/xilinx-zynqmp/objcadencei2c.yml
> index fd9d51dfa9..fa269d61ad 100644
> --- a/spec/build/bsps/aarch64/xilinx-zynqmp/objcadencei2c.yml
> +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/objcadencei2c.yml
> @@ -9,10 +9,12 @@ enabled-by: true
>  includes: []
>  install:
>  - destination: ${BSP_INCLUDEDIR}/bsp
> +  source:
> +  - bsps/aarch64/xilinx-zynqmp/include/bsp/i2c.h
> +- destination: ${BSP_INCLUDEDIR}/dev/i2c
>source:
>- bsps/include/dev/i2c/cadence-i2c-regs.h
>- bsps/include/dev/i2c/cadence-i2c.h
> -  - bsps/aarch64/xilinx-zynqmp/include/bsp/i2c.h
>  links: []
>  source:
>  - bsps/shared/dev/i2c/cadence-i2c.c
> diff --git a/spec/build/bsps/arm/xilinx-zynq/obj.yml 
> b/spec/build/bsps/arm/xilinx-zynq/obj.yml
> index bc675cd38c..dcac09126b 100644
> --- a/spec/build/bsps/arm/xilinx-zynq/obj.yml
> +++ b/spec/build/bsps/arm/xilinx-zynq/obj.yml
> @@ -14,10 +14,12 @@ install:
>- bsps/arm/xilinx-zynq/include/tm27.h
>  - destination: ${BSP_INCLUDEDIR}/bsp
>source:
> -  - bsps/include/dev/i2c/cadence-i2c-regs.h
> -  - bsps/include/dev/i2c/cadence-i2c.h
>- bsps/arm/xilinx-zynq/include/bsp/i2c.h
>- bsps/arm/xilinx-zynq/include/bsp/irq.h
> +- destination: ${BSP_INCLUDEDIR}/dev/i2c
> +  source:
> +  - bsps/include/dev/i2c/cadence-i2c-regs.h
> +  - bsps/include/dev/i2c/cadence-i2c.h
>  links: []
>  source:
>  - bsps/arm/shared/cache/cache-l2c-310.c
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-tools 0/8] Convert and reformat pt. 4

[Chris Johns]

On 8/12/21 1:09 am, Ryan Long wrote:
> On 12/6/2021 10:09 PM, Chris Johns wrote:
>> On 4/12/21 1:47 am, Ryan Long wrote:
>>> Hi,
>>>
>>> For this series of patches, I followed this series of steps:
>>>
>>> 1. Convert a file from the C way of doing things to C++.
>>> 2. Go through all the files that had to do with the converted file and
>>> make the formatting consistent.
>> OK to push.
>>
>> It would be helpful in future to separate the white space changes from any 
>> code
>> changes.
> 
> I guess removing "void" from an empty parameter list and adding curly brackets
> around if statements counts as code changes? 

Yes.

> I didn't see any whitespace changes in the code changes.

The following is an example:

-debug.begin(executable.elf());
+debug.begin( executable.elf() );

It takes time for me to check and see if this is the same code with whitespace
changes or whitespace and code changes.

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

Re: [PATCH] untar: Make behavior similar to GNU or BSD tar

[Chris Johns]

On 3/12/21 11:50 pm, Christian Mauderer wrote:
> RTEMS untar implementation had problems with overwriting or integrating
> archives into existing directory structures. This patch adapts the
> behavior to mimic that of a GNU tar or BSD tar and extends the tar01
> test to check for the behavior. That is:
> 
> * If a directory structure exists, the files from the archive will be
>   integrated. Existing files are overwritten.

What currently happens?

> * If a file exists and the archive contains a directory with the same
>   name, the file is removed and a directory is created. In the above
>   example: if l1/l2 is a file it will be overwritten with a new
>   directory.

OK

> * If a directory exists and the archive contains a file with the same
>   name, the directory will be replaced if it is empty. If it contains
>   files, the result is an error.
> 
> * An archive also can contain only a file without the parent
>   directories. If in that case one of the parent directories exists as a
>   file extracting the archive results in an error. In the example: if
>   l1/l2 is a file and the archive doesn't contain the directories but
>   only the file l1/l2/x.txt that would be an error.
> 
> * In case of an error, it is possible that the archive has been
>   partially extracted.

And what was there is not recoverable.

Functionally this is not a big change and so I am left wondering why the
original developer(s) did not do this?

I think the changes make sense and I do not think it will break any applications
I know of that use this code.

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

Re: [PATCH rtems-tools 0/8] Convert and reformat pt. 4

[Chris Johns]

On 4/12/21 1:47 am, Ryan Long wrote:
> Hi,
> 
> For this series of patches, I followed this series of steps:
> 
> 1. Convert a file from the C way of doing things to C++.
> 2. Go through all the files that had to do with the converted file and
> make the formatting consistent.

OK to push.

It would be helpful in future to separate the white space changes from any code
changes.

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

Re: [PATCH 1/1] Update rtems-notes-5.md

[Chris Johns]

On 3/12/21 8:26 pm, jan.som...@dlr.de wrote:
>> -Original Message-
>> From: Chris Johns 
>> Sent: Thursday, December 2, 2021 10:11 PM
>> To: Sommer, Jan ; Moyano Heredia, Victor Gabriel
>> ; devel@rtems.org
>> Subject: Re: [PATCH 1/1] Update rtems-notes-5.md
>>
>> On 2/12/21 7:27 pm, jan.som...@dlr.de wrote:
>>>> -----Original Message-
>>>> From: devel  On Behalf Of Chris Johns
>>>> Sent: Thursday, December 2, 2021 2:06 AM
>>>> To: Moyano Heredia, Victor Gabriel ;
>>>> devel@rtems.org
>>>> Subject: Re: [PATCH 1/1] Update rtems-notes-5.md
>>>>
>>>> OK to push.
>>>
>>> Should I push the addition to master, 5, or both branches?
>>
>> Good question, I think both.
>>
> 
> One more question: 
> Adding the 5.2 Release notes below the ones from 5.1 is correct?
> Or do you prefer to have the newest release notes on top?

I think top.

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

Re: [PATCH 1/1] Update rtems-notes-5.md

[Chris Johns]

On 2/12/21 7:27 pm, jan.som...@dlr.de wrote:
>> -Original Message-
>> From: devel  On Behalf Of Chris Johns
>> Sent: Thursday, December 2, 2021 2:06 AM
>> To: Moyano Heredia, Victor Gabriel ;
>> devel@rtems.org
>> Subject: Re: [PATCH 1/1] Update rtems-notes-5.md
>>
>> OK to push.
> 
> Should I push the addition to master, 5, or both branches?

Good question, I think both.

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

Re: [PATCH 1/1] Update rtems-notes-5.md

[Chris Johns]

OK to push.

Thanks
Chris

On 1/12/21 2:03 am, Moyano, Gabriel wrote:
> ---
>  rtems-notes-5.md | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/rtems-notes-5.md b/rtems-notes-5.md
> index 3737199..7697980 100644
> --- a/rtems-notes-5.md
> +++ b/rtems-notes-5.md
> @@ -374,3 +374,12 @@ Obsoleted architectures:
>  * RTEMS Trace addition of a new trace record support for target tracing.
>  
>  * RTEMS Bootimage, a tool to portably create SD card images.
> +
> +## RTEMS 5.2 Release Notes
> +
> +### API Changes
> +
> + API Additions
> +
> +* NTP support
> + * Addition of NTP update second handler via 
> _Timecounter_Set_NTP_update_second() from 
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 4/5] score: Optimize Workspace Handler initialization

[Chris Johns]

On 29/11/21 9:29 pm, Sebastian Huber wrote:
> The BSPs provide memory for the workspace initialization via
> _Memory_Get().  Most BSPs provide exactly one memory area.  Only two
> BSPs provide more than one memory area (arm/altera-cyclone-v and
> bsps/powerpc/mpc55xxevb).  Only if more than one memory area is
> provided, there is a need to use _Heap_Extend().  Provide two
> implementations to initialize the workspace handler and let the BSP
> select one of the implementations based on the number of provided memory
> areas.  This gets rid of a dependency on _Heap_Extend().  It also avoids
> dead code sections for most BSPs.
> ---
>  bsps/shared/start/wkspaceinitmany.c   |  46 +++
>  bsps/shared/start/wkspaceinitone.c|  46 +++
>  cpukit/include/rtems/score/wkspace.h  |  12 +-
>  cpukit/include/rtems/score/wkspaceinitmany.h  | 129 ++
>  cpukit/include/rtems/score/wkspaceinitone.h   | 113 +++
>  cpukit/score/src/wkspace.c|  85 +---
>  .../altera-cyclone-v/bspalteracyclonev.yml|   1 +
>  spec/build/bsps/i386/pc386/obj.yml|   1 +
>  spec/build/bsps/objmem.yml|   1 +
>  spec/build/bsps/powerpc/mpc55xxevb/obj.yml|   1 +
>  spec/build/bsps/powerpc/objmem.yml|   1 +
>  spec/build/bsps/powerpc/tqm8xx/obj.yml|   1 +
>  spec/build/bsps/sparc/objmem.yml  |   1 +
>  13 files changed, 347 insertions(+), 91 deletions(-)
>  create mode 100644 bsps/shared/start/wkspaceinitmany.c
>  create mode 100644 bsps/shared/start/wkspaceinitone.c
>  create mode 100644 cpukit/include/rtems/score/wkspaceinitmany.h
>  create mode 100644 cpukit/include/rtems/score/wkspaceinitone.h
> 
> diff --git a/bsps/shared/start/wkspaceinitmany.c 
> b/bsps/shared/start/wkspaceinitmany.c
> new file mode 100644
> index 00..30335d63c9
> --- /dev/null
> +++ b/bsps/shared/start/wkspaceinitmany.c
> @@ -0,0 +1,46 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreWorkspace
> + *
> + * @brief This source file contains the _Workspace_Handler_initialization()
> + *   implementation which supports more than one memory area.
> + */
> +
> +/*
> + * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#include 
> +
> +void _Workspace_Handler_initialization( void )
> +{
> +  _Workspace_Initialize_for_many_areas();

_Workspace_Initialize_for_multiple_areas() ?

And then also for _Malloc_Initialize_for_many_areas() ?

> diff --git a/cpukit/include/rtems/score/wkspaceinitmany.h 
> b/cpukit/include/rtems/score/wkspaceinitmany.h
> new file mode 100644
> index 00..0277c6ee1e
> --- /dev/null
> +++ b/cpukit/include/rtems/score/wkspaceinitmany.h
> @@ -0,0 +1,129 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreWorkspace
> + *
> + * @brief This header file provides the implementation of
> + *   _Workspace_Initialize_for_many_areas().
> + */
> +
> +/*
> + * Copyright (C) 2012, 2020 embedded brains GmbH 
> (http://www.embedded-brains.de)
> + *
> + * 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 

Re: AW: AW: AW: [PATCH 00/27] Update kern_tc in rtems 5 for ntp support

[Chris Johns]

On 29/11/21 11:24 pm, Sebastian Huber wrote:
> On 24/11/2021 10:57, gabriel.moy...@dlr.de wrote:
>>> I am fine with this change being pushed to the 5 branch but I think it
>>> needs to built with the tier 1 archs (i386, powerpc, arm).
>> I could compile them for the BSPs of those archs.
> Thanks.
>
>> Does it make sense to run some test in qemu?
> Test results are always welcome.
>
 I've run the following tests:
 - sptimecounter02, 03 and 04 are pass on pc686 and Xilinx_zynq_a9.
 - sptimecounter01 doesn't print something since everything happens inside 
 of
 boot_card(). How the result of this test is verified?
>>> Re-run the test using rtems-test.
>>> - sptimecounter01, 02, 03 and 04 are marked as pass on Xilinx_zynq_a9 and 
>>> psim
>>> - sptimecounter02, 03 and 04 are marked as pass on pc686
>>> - sptimecounter01 is marked as invalid on pc686. This result is with and
>>> without the patch set. I guess it is because nothing is printed
>>> out.
>>>
 Are there any other tests that can be interested to run?
>>> If there isn't any other test to run, I would say that the patch set is 
>>> ready.
>> After running the whole testsuite for pc686, xilinx_zynq_a9 and psim; there
>> are no new failures introduced.
> 
> For me this is fine, what do you think Chris?

Sorry about the delay and being distracted .. a few deadlines.

Yes this looks fine.

I think Jan has commit access so if he could push this to the 5 branch it would
be appreciated.

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

Re: grub2 on old Linux Distributions (at least CentOS 7)

[Chris Johns]

On 21/11/21 12:21 pm, Joel Sherrill wrote:
> On Sat, Nov 20, 2021, 6:50 PM Karel Gardas  wrote:
>> indeed, centos 7 is bundled with gcc 4.8.5. Now, the question is, is
>> centos 7 still supported by RTEMS? If so, then we will need to invent
>> some machinery to check not only for commands but also for versions in
>> cfg files? Also if we're doing this we need to check firmly we're really
>> on old centos IMHO.
> 
> You can't build the documentation without using a Python 3 software
> collection, Texlive, and some pip magic. For rtems6, I might be ok with
> recommending a newer GCC.

Is this to be checked and enforced or does it just fail to build?

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

Re: AW: AW: [PATCH 00/27] Update kern_tc in rtems 5 for ntp support

[Chris Johns]

On 19/11/21 9:32 pm, gabriel.moy...@dlr.de wrote:
>> I am fine with this change being pushed to the 5 branch but I think it needs 
>> to built with the tier 1 archs (i386, powerpc, arm).
> 
> I could compile them for the BSPs of those archs. 

Thanks.

> Does it make sense to run some test in qemu?

Test results are always welcome.

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

Re: Testing rtems 7 using rtems-test

[Chris Johns]

On 20/11/21 5:14 am, Joel Sherrill wrote:
> Looks like another place that needs version help. rtems-test has a 6
> in it somewhere that needs to be overridden.

It is located here:

https://git.rtems.org/rtems-tools/tree/tester/rtems/version.cfg

> Notice that it is
> invoking sparc-rtems6-sis when I really want sparc-rtems7-sis.
> Hopefully there is an existing way to override this easily enough.
> Otherwise, we are missing a small but essential piece of really
> testing rtems7.

Yes it needs to have the `--rtems-version` option added. I will need to play a
bit to figure out how to add this.

Could you please raise a ticket and assign it to me?

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

Re: AW: [PATCH 00/27] Update kern_tc in rtems 5 for ntp support

[Chris Johns]

On 17/11/21 11:03 pm, Sebastian Huber wrote:
> On 17/11/2021 11:42, gabriel.moy...@dlr.de wrote:
>>> The patch set should have no API/ABI impact on applications.
>> Sorry I didn't verified if the ABI is broken. We are checking this with my 
>> team.
> 
> I think, the patch set should have no API/ABI impact on applications. The
> changes are all in kern_tc.c.

I am fine with this change being pushed to the 5 branch but I think it needs to
built with the tier 1 archs (i386, powerpc, arm).

Once pushed I would appreciate an update to:

https://git.rtems.org/rtems-release/tree/rtems-notes-5.md

under "## RTEMS 5.2 Release Notes".

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

Re: [rtems commit] rtems: Add new clock manager directives

[Chris Johns]

On 18/11/21 3:39 am, Sebastian Huber wrote:
> On 17/11/2021 09:11, Sebastian Huber wrote:
>> Module:    rtems
>> Branch:    master
>> Commit:    ccbcfb679da0a6c07878d3ae4ff0f91cb1c3caee
>> Changeset:http://git.rtems.org/rtems/commit/?id=ccbcfb679da0a6c07878d3ae4ff0f91cb1c3caee
>>
>>
>> Author:    Sebastian Huber
>> Date:  Mon Oct 11 17:07:50 2021 +0200
>>
>> rtems: Add new clock manager directives
>>
>> Update #4527.
> 
> Sorry, I accidentally committed this patch along with the build system patch
> set. I will revert it if needed.

Thank you for raising this. I saw them go by. Lets leave them, all good.

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

Re: [PATCH v2] c-user: Document new clock manager directives

[Chris Johns]

On 16/11/21 4:27 am, Sebastian Huber wrote:
> On 11/11/2021 08:02, Sebastian Huber wrote:> On 09/11/2021 13:06, Sebastian
> Huber wrote:
>>> On 09/11/2021 08:50, Sebastian Huber wrote:
>>>> On 09/11/2021 08:41, Chris Johns wrote:
>>>>>> We could also use something like this:
>>>>>>
>>>>>> static inline struct timespec rtems_clock_get_realtime(void)
>>>>>> {
>>>>>>    struct timespec time_snapshot;
>>>>>>
>>>>>>    _Timecounter_Nanotime( _snapshot );
>>>>>>
>>>>>>    return time_snapshot;
>>>>>> }
>>>>>>
>>>>>> Unfortunately GCC is not able to optimize this.
>>>>>>
>>>>> Ah OK. This can be fixed and the performance improved but once the API is
>>>>> set it
>>>>> cannot change or do you think we can add a check later and not break the 
>>>>> API?
>>>>
>>>> I filed a GCC bug for this:
>>>>
>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103150
>>>>
>>>> It seems I was not the only one noticing issues related to structure 
>>>> returns:
>>>>
>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926
>>>>
>>>> However, if we want a foolproof API, then I would prefer the structure
>>>> return over the return status and pointer argument. Compilers may get 
>>>> better
>>>> in the future. clang has similar issues, so this is not only a GCC problem.
>>>
>>> We have at least three options for the API:
>>>
>>> 1. Use the existing FreeBSD implementation as is:
>>>
>>> void rtems_clock_get_realtime(struct timespec *);
>>>
>>> This is the easiest and most efficient approach.
>>>
>>> 2. Check for NULL and return a status:
>>>
>>> rtems_status_code rtems_clock_get_realtime(struct timespec *);
>>>
>>> This requires a wrapper function which is a bit less efficient and needs 
>>> more
>>> code/testing:
>>>
>>> rtems_status_code
>>> rtems_clock_get_realtime(struct timespec *time_snapshot)
>>> {
>>>    if ( time_snapshot == NULL ) {
>>>  return RTEMS_INVALID_ADDRESS;
>>>    }
>>>
>>>    _Timecounter_Nanotime( time_snapshot );
>>>    return RTEMS_SUCCESSFUL;
>>> }
>>>
>>> 3. Return the structure and use the existing implementation:
>>>
>>> static inline struct timespec rtems_clock_get_realtime(void)
>>> {
>>>    struct timespec time_snapshot;
>>>
>>>    _Timecounter_Nanotime( _snapshot );
>>>
>>>    return time_snapshot;
>>> }
>>>
>>> This is currently not well supported by existing compilers:
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103150
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926
>>>
>>
>> 4. Do nothing for a NULL pointer:
>>
>> void rtems_clock_get_realtime(struct timespec *);
>>
>> This requires a wrapper function which can use a tail call optimization:
>>
>> void
>> rtems_clock_get_realtime(struct timespec *time_snapshot)
>> {
>>    if ( time_snapshot == NULL ) {
>>  return;
>>    }
>>
>>    _Timecounter_Nanotime( time_snapshot );
>> }
> 
> How do we want to proceed with this? We ship the high performance and very
> useful clock routines from FreeBSD since 2015. I just would like to add an 
> RTEMS
> signature for them and document them in the Clock Manager. Currently, these
> routines are the most efficient way to get clock values in RTEMS. Developers
> afraid of unchecked NULL pointers may use existing RTEMS directives or
> clock_get(). It would be nice if we can decide on a way forward.

I will leave this for Joel to decide.

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

Re: [PATCH] config: CONFIGURE_DISABLE_BSP_SETTINGS

[Chris Johns]

OK

Chris

On 16/11/21 5:18 am, Sebastian Huber wrote:
> Evaluate CONFIGURE_DISABLE_BSP_SETTINGS for each affected application
> configuration option.  This makes the code easier to review since the 
> influence
> of CONFIGURE_DISABLE_BSP_SETTINGS is locally visible in the code.
> ---
>  cpukit/include/rtems/confdefs/bsp.h| 15 ++-
>  cpukit/include/rtems/confdefs/extensions.h |  3 ++-
>  cpukit/include/rtems/confdefs/iodrivers.h  |  3 ++-
>  cpukit/include/rtems/confdefs/malloc.h | 10 +++---
>  cpukit/include/rtems/confdefs/percpu.h |  9 ++---
>  5 files changed, 19 insertions(+), 21 deletions(-)
> 
> diff --git a/cpukit/include/rtems/confdefs/bsp.h 
> b/cpukit/include/rtems/confdefs/bsp.h
> index 03ad9bf55f..bc96713765 100644
> --- a/cpukit/include/rtems/confdefs/bsp.h
> +++ b/cpukit/include/rtems/confdefs/bsp.h
> @@ -41,19 +41,8 @@
>  #error "Do not include this file directly, use  instead"
>  #endif
>  
> -#ifdef CONFIGURE_INIT
> -
> -#ifdef CONFIGURE_DISABLE_BSP_SETTINGS
> -  #undef BSP_IDLE_TASK_BODY
> -  #undef BSP_IDLE_TASK_STACK_SIZE
> -  #undef BSP_INITIAL_EXTENSION
> -  #undef BSP_INTERRUPT_STACK_SIZE
> -  #undef CONFIGURE_BSP_PREREQUISITE_DRIVERS
> -  #undef CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK
> -#else
> -  #include 
> +#if defined(CONFIGURE_INIT) && !defined(CONFIGURE_DISABLE_BSP_SETTINGS)
> +#include 
>  #endif
>  
> -#endif /* CONFIGURE_INIT */
> -
>  #endif /* _RTEMS_CONFDEFS_BSP_H */
> diff --git a/cpukit/include/rtems/confdefs/extensions.h 
> b/cpukit/include/rtems/confdefs/extensions.h
> index 6492407934..118ad29484 100644
> --- a/cpukit/include/rtems/confdefs/extensions.h
> +++ b/cpukit/include/rtems/confdefs/extensions.h
> @@ -146,7 +146,8 @@ extern "C" {
>  #ifdef CONFIGURE_INITIAL_EXTENSIONS
>CONFIGURE_INITIAL_EXTENSIONS,
>  #endif
> -#ifdef BSP_INITIAL_EXTENSION
> +#if !defined(CONFIGURE_DISABLE_BSP_SETTINGS) && \
> +  defined(BSP_INITIAL_EXTENSION)
>BSP_INITIAL_EXTENSION
>  #endif
>};
> diff --git a/cpukit/include/rtems/confdefs/iodrivers.h 
> b/cpukit/include/rtems/confdefs/iodrivers.h
> index a7de77a8c3..8c102197eb 100644
> --- a/cpukit/include/rtems/confdefs/iodrivers.h
> +++ b/cpukit/include/rtems/confdefs/iodrivers.h
> @@ -110,7 +110,8 @@ extern "C" {
>  
>  rtems_driver_address_table
>  _IO_Driver_address_table[ CONFIGURE_MAXIMUM_DRIVERS ] = {
> -  #ifdef CONFIGURE_BSP_PREREQUISITE_DRIVERS
> +  #if !defined(CONFIGURE_DISABLE_BSP_SETTINGS) && \
> +defined(CONFIGURE_BSP_PREREQUISITE_DRIVERS)
>  CONFIGURE_BSP_PREREQUISITE_DRIVERS,
>#endif
>#ifdef CONFIGURE_APPLICATION_PREREQUISITE_DRIVERS
> diff --git a/cpukit/include/rtems/confdefs/malloc.h 
> b/cpukit/include/rtems/confdefs/malloc.h
> index d864a98270..a8dae6e739 100644
> --- a/cpukit/include/rtems/confdefs/malloc.h
> +++ b/cpukit/include/rtems/confdefs/malloc.h
> @@ -45,8 +45,12 @@
>  
>  #include 
>  
> -#if defined(CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK) \
> -  || defined(CONFIGURE_MALLOC_DIRTY)
> +#if !defined(CONFIGURE_DISABLE_BSP_SETTINGS) && \
> +  defined(CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK)
> +#define _CONFIGURE_HEAP_EXTEND_VIA_SBRK
> +#endif
> +
> +#if defined(_CONFIGURE_HEAP_EXTEND_VIA_SBRK) || 
> defined(CONFIGURE_MALLOC_DIRTY)
>  #include 
>  #endif
>  
> @@ -54,7 +58,7 @@
>  extern "C" {
>  #endif
>  
> -#ifdef CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK
> +#ifdef _CONFIGURE_HEAP_EXTEND_VIA_SBRK
>  const rtems_heap_extend_handler rtems_malloc_extend_handler =
>rtems_heap_extend_via_sbrk;
>  #endif
> diff --git a/cpukit/include/rtems/confdefs/percpu.h 
> b/cpukit/include/rtems/confdefs/percpu.h
> index 3bea8340cb..b91590bfd9 100644
> --- a/cpukit/include/rtems/confdefs/percpu.h
> +++ b/cpukit/include/rtems/confdefs/percpu.h
> @@ -78,7 +78,8 @@ extern "C" {
>  /* Interrupt stack configuration */
>  
>  #ifndef CONFIGURE_INTERRUPT_STACK_SIZE
> -  #ifdef BSP_INTERRUPT_STACK_SIZE
> +  #if !defined(CONFIGURE_DISABLE_BSP_SETTINGS) && \
> +defined(BSP_INTERRUPT_STACK_SIZE)
>  #define CONFIGURE_INTERRUPT_STACK_SIZE BSP_INTERRUPT_STACK_SIZE
>#else
>  #define CONFIGURE_INTERRUPT_STACK_SIZE CPU_STACK_MINIMUM_SIZE
> @@ -121,7 +122,8 @@ RTEMS_DEFINE_GLOBAL_SYMBOL(
>  /* Idle thread configuration */
>  
>  #ifndef CONFIGURE_IDLE_TASK_STACK_SIZE
> -  #ifdef BSP_IDLE_TASK_STACK_SIZE
> +  #if !defined(CONFIGURE_DISABLE_BSP_SETTINGS) && \
> +defined(BSP_IDLE_TASK_STACK_SIZE)
>  #define CONFIGURE_IDLE_TASK_STACK_SIZE BSP_IDLE_TASK_STACK_SIZE
>#else
>  #define CONFIGURE_IDLE_TASK_STACK_SIZE CONFIGURE_MINIMUM_TASK_STACK_SIZE
> @@ -153,7 +155,8 @@ const size_t _Thread_Idle_stack_size = 
> CONFIGURE_IDLE_TASK_STACK_SIZE;
>#error "If you define CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION, then 
> you must define CONFIGURE_IDLE_TASK_BODY as well"
>  #endif
>  
> -#if !defined(CONFIGURE_IDLE_TASK_BODY) && defined(BSP_IDLE_TASK_BODY)
> +#if !defined(CONFIGURE_IDLE_TASK_BODY) && \
> +  

Re: [PATCH] c-user: Use rubric for configuration options

[Chris Johns]

OK to push. This is a sensible change to make.

Thanks
Chris

On 16/11/21 6:27 pm, Sebastian Huber wrote:
> Use a rubric instead of a definition list for the application
> configuration options similar to the directive documentation pages.  For
> direcives and application configuration options use the same rubric
> order.
> 
> Generalize value constraints to constraints.
> 
> This patch does not change hand written content.
> ---
> 
> The generated PDF can be reviewed here:
> 
> https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf
> 
>  c-user/config/bdbuf.rst |  457 +--
>  c-user/config/bsp-related.rst   |  304 
>  c-user/config/classic-api.rst   |  676 
>  c-user/config/classic-init-task.rst |  355 +
>  c-user/config/device-driver.rst |  792 ++-
>  c-user/config/event-record.rst  |  160 ++--
>  c-user/config/filesystem.rst|  844 ++--
>  c-user/config/general.rst   | 1103 +++
>  c-user/config/idle-task.rst |  147 ++--
>  c-user/config/mpci.rst  |  315 
>  c-user/config/posix-api.rst |  539 +++--
>  c-user/config/posix-init-thread.rst |  115 +--
>  c-user/config/scheduler-general.rst |  669 
>  c-user/config/task-stack-alloc.rst  |  244 +++---
>  14 files changed, 3691 insertions(+), 3029 deletions(-)
> 
> diff --git a/c-user/config/bdbuf.rst b/c-user/config/bdbuf.rst
> index c5381e1..d36c2bd 100644
> --- a/c-user/config/bdbuf.rst
> +++ b/c-user/config/bdbuf.rst
> @@ -35,24 +35,29 @@ This section describes configuration options related to 
> the Block Device Cache
>  CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
>  
>  
> -CONSTANT:
> -``CONFIGURE_APPLICATION_NEEDS_LIBBLOCK``
> +.. rubric:: CONSTANT:
>  
> -OPTION TYPE:
> -This configuration option is a boolean feature define.
> +``CONFIGURE_APPLICATION_NEEDS_LIBBLOCK``
>  
> -DEFAULT CONFIGURATION:
> -If this configuration option is undefined, then the described feature is 
> not
> -enabled.
> +.. rubric:: OPTION TYPE:
>  
> -DESCRIPTION:
> -In case this configuration option is defined, then the Block Device 
> Cache is
> -initialized during system initialization.
> +This configuration option is a boolean feature define.
>  
> -NOTES:
> -Each option of the Block Device Cache (bdbuf) configuration can be 
> explicitly
> -set by the user with the configuration options below.  The Block Device 
> Cache
> -is used for example by the RFS and DOSFS filesystems.
> +.. rubric:: DEFAULT CONFIGURATION:
> +
> +If this configuration option is undefined, then the described feature is not
> +enabled.
> +
> +.. rubric:: DESCRIPTION:
> +
> +In case this configuration option is defined, then the Block Device Cache is
> +initialized during system initialization.
> +
> +.. rubric:: NOTES:
> +
> +Each option of the Block Device Cache (bdbuf) configuration can be explicitly
> +set by the user with the configuration options below.  The Block Device Cache
> +is used for example by the RFS and DOSFS filesystems.
>  
>  .. Generated from spec:/acfg/if/bdbuf-buffer-max-size
>  
> @@ -63,30 +68,31 @@ NOTES:
>  CONFIGURE_BDBUF_BUFFER_MAX_SIZE
>  ---
>  
> -CONSTANT:
> -``CONFIGURE_BDBUF_BUFFER_MAX_SIZE``
> +.. rubric:: CONSTANT:
> +
> +``CONFIGURE_BDBUF_BUFFER_MAX_SIZE``
> +
> +.. rubric:: OPTION TYPE:
>  
> -OPTION TYPE:
> -This configuration option is an integer define.
> +This configuration option is an integer define.
>  
> -DEFAULT VALUE:
> -The default value is 4096.
> +.. rubric:: DEFAULT VALUE:
>  
> -VALUE CONSTRAINTS:
> -The value of this configuration option shall satisfy all of the following
> -constraints:
> +The default value is 4096.
>  
> -* It shall be greater than or equal to zero.
> +.. rubric:: DESCRIPTION:
>  
> -* It shall be an integral multiple of
> -  :ref:`CONFIGURE_BDBUF_BUFFER_MIN_SIZE`.
> +The value of this configuration option defines the maximum size of a buffer
> +in bytes.
>  
> -DESCRIPTION:
> -The value of this configuration option defines the maximum size of a 
> buffer
> -in bytes.
> +.. rubric:: CONSTRAINTS:
>  
> -NOTES:
> -None.
> +The following constraints apply to this configuration option:
> +
> +* The value of the configuration option shall be greater than or equal to 
> zero.
> +
> +* The value of the configuration option shall be an integral multiple of
> +  :ref:`CONFIGURE_BDBUF_BUFFER_MIN_SIZE`.
>  
>  .. Generated from spec:/acfg/if/bdbuf-buffer-min-size
>  
> @@ -97,30 +103,31 @@ NOTES:
>  CONFIGURE_BDBUF_BUFFER_MIN_SIZE
>  ---
>  
> -CONSTANT:
> -``CONFIGURE_BDBUF_BUFFER_MIN_SIZE``
> +.. rubric:: CONSTANT:
> +
> +``CONFIGURE_BDBUF_BUFFER_MIN_SIZE``
> +
> +.. rubric:: OPTION TYPE:
>  
> -OPTION TYPE:
> -This configuration option is an integer define.
> +This 

Re: [PATCH v2 1/4] Revert "optvermaj.yml: Allow __RTEMS_MAJOR__ to be overridden so RTEMS 7 tools can be tested"

[Chris Johns]

OK and thank you

Chris

On 16/11/21 5:47 pm, Sebastian Huber wrote:
> This reverts commit d1bbfbea5f60f552b2b3138bb1df35c3372f2461.
> ---
>  spec/build/cpukit/optvermaj.yml | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/spec/build/cpukit/optvermaj.yml b/spec/build/cpukit/optvermaj.yml
> index e1a5eae5b3..2596e6ef6a 100644
> --- a/spec/build/cpukit/optvermaj.yml
> +++ b/spec/build/cpukit/optvermaj.yml
> @@ -1,16 +1,14 @@
>  SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>  actions:
> -- get-string: null
> +- set-value: '6'
>  - env-assign: null
>  build-type: option
>  copyrights:
>  - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> -default: 6
> +default: null
>  default-by-variant: []
> -description: |
> -  Major Component of the RTEMS Version Number
> +description: ''
>  enabled-by: true
> -format: '{}' 
>  links: []
>  name: __RTEMS_MAJOR__
>  type: build
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] waf: Add --rtems-version as a configure option

[Chris Johns]

On 15/11/21 7:09 pm, Sebastian Huber wrote:
> On 14/11/2021 23:42, Chris Johns wrote:
>>> With this approach you don't give the user the ability to change everything.
>>> However, what can be change is defined by the build specification and not 
>>> the
>>> wscript.
>> I understand the reason however you would need to implement it to show how 
>> it is
>> done? Can we internally do:
>>
>>   set_value("__RTEMS_MAJOR__", ctx.options.rtems_version)
>>
>> ? I do not understand the how to make the change and then manage the sequence
>> via the actions.
> 
> Please have a look at for a proof of concept:
> 
> https://lists.rtems.org/pipermail/devel/2021-November/069889.html

Really nice and I like the idea of `get-string-command-line`. Having this in the
spec files is important if you want to know what can be changed. The prepare
step is a nice way to sequence the steps and the bit I was not sure about.

> We can also add --rtems-version=X and map it to __RTEMS_MAJOR=X in the wscipt.

Is adding this something specific? I would like to see the option directly
supported.

Thank you for the patch and the prompt response.

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

Re: [PATCH] waf: Add --rtems-version as a configure option

[Chris Johns]

> On 14 Nov 2021, at 11:15 pm, Sebastian Huber
>  wrote:
>
> On 14/11/2021 04:07, chr...@rtems.org wrote:
>> From: Chris Johns 
>> - Provide the option `--rtems-version` to set the major version
>>   number
>> - Add a method to handle setting action values
>> - Return the spec YAML file back to it's original values
>>   as it does not allow a user to change the version.
>> Closes #4548
>
> I would simply revert the optvermaj.yml patch with "git revert".

Ok. 

> I don't like the special case approach which violates one design principle of
> the build system that the wcript should know the absolute minimum of the
> layout of the build specification.

This alternative moves that knowledge out into all sorts of support tools. Is
that what you want?

I think the same command line interface (--rtems-version) used else where for
this option would be good.

> My preferred solution would be that the build item defines that it can be
> modified by a command line option, for example:
>
> ./waf configure --rtems-set-value=__RTEMS_MAJOR__=7

Does this option as stated here contradict the idea of the build system being
specified? I see strength in the spec files and I am not sure about a generic
approach. I think the less that can change the better. And if you need change
the spec files to use the value what does it offer?

We need to change the version and a specific option exposes as narrow an
interface as possible.

> In spec/build/cpukit/optvermaj.yml:
>
> actions:
> - get-string-option: '6'
> - env-assign
>
> With this approach you don't give the user the ability to change everything.
> However, what can be change is defined by the build specification and not the
> wscript.

I understand the reason however you would need to implement it to show how it is
done? Can we internally do:

 set_value("__RTEMS_MAJOR__", ctx.options.rtems_version)

? I do not understand the how to make the change and then manage the sequence
via the actions. 

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

Re: [RTEMS v2] optvermaj.yml: Allow __RTEMS_MAJOR__ to be overridden so RTEMS 7 tools can be tested

[Chris Johns]

On 13/11/21 10:00 am, Joel Sherrill wrote:
> On Fri, Nov 12, 2021 at 4:52 PM Chris Johns  wrote:
>>
>> Let me take a look at a configure option. I prefer it over spec files as this
>> creates another thing to change after a release.
> 
> Happy to see an alternative way to do this. At this point, there was no way
> to build RTEMS or any subsequent software with the rtems7 tools. That
> seemed like a glaring hole in the testing.

I see it is applied. It is a bit rough to post then push 45 minutes later a
patch when someone is asleep.

I now need to see what was there and figure it all out.

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

Re: [PATCH RSB] rtems-tools-6.cfg: Bump hash to get fix for rtems-test

[Chris Johns]

OK

On 13/11/21 1:54 am, Joel Sherrill wrote:
> ---
>  rtems/config/tools/rtems-tools-6.cfg | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/rtems/config/tools/rtems-tools-6.cfg 
> b/rtems/config/tools/rtems-tools-6.cfg
> index 6d05d12..cf895d6 100644
> --- a/rtems/config/tools/rtems-tools-6.cfg
> +++ b/rtems/config/tools/rtems-tools-6.cfg
> @@ -10,14 +10,14 @@
>   %define rtems_tools_source rtems-tools-%{rtems_tools_version}
>   %define rtems_tools_ext xz
>  %else
> - %define rtems_tools_version d1df4f6e02fe22d2cb542adbd6ba4248ee077892
> + %define rtems_tools_version 6b31bb03aaf98232a21813c471d0298c170dde60
>   %define rtems_tools_ext bz2
>  %endif
>  
>  %define rtems_tools_source rtems-tools-%{rtems_tools_version}
>  %source set rtems-tools 
> https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
>  %hash   sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
> - 
> zhSEMRbpLdeDTg6RI5U1e/TU9FsN09cS/NPQrXCMU6QJsCdDWIzA0HwTq54/apM7RW38uQkmaW9cPk5RVU3e1A==
> + 
> +TKPQxx2HdnSBW7QcgfzFZCjRw7mssXHaJSxDd0v1KJ/VLeWcdus/MELH7oq0WyEMpqAyd1+1HpMVuFrMFyvcw==
>  
>  #
>  # Optionally enable/disable building the RTEMS Tools via the command line.
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RTEMS v2] optvermaj.yml: Allow __RTEMS_MAJOR__ to be overridden so RTEMS 7 tools can be tested

[Chris Johns]

Let me take a look at a configure option. I prefer it over spec files as this
creates another thing to change after a release.

Thanks
Chris

On 13/11/21 3:03 am, Joel Sherrill wrote:
> ---
>  spec/build/cpukit/optvermaj.yml | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/spec/build/cpukit/optvermaj.yml b/spec/build/cpukit/optvermaj.yml
> index 2596e6ef6a..e1a5eae5b3 100644
> --- a/spec/build/cpukit/optvermaj.yml
> +++ b/spec/build/cpukit/optvermaj.yml
> @@ -1,14 +1,16 @@
>  SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>  actions:
> -- set-value: '6'
> +- get-string: null
>  - env-assign: null
>  build-type: option
>  copyrights:
>  - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> -default: null
> +default: 6
>  default-by-variant: []
> -description: ''
> +description: |
> +  Major Component of the RTEMS Version Number
>  enabled-by: true
> +format: '{}' 
>  links: []
>  name: __RTEMS_MAJOR__
>  type: build
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Building a BSP for rtems7

[Chris Johns]

On 13/11/21 9:08 am, Joel Sherrill wrote:
> On Fri, Nov 12, 2021 at 3:50 PM Chris Johns  wrote:
>>
>> On 13/11/21 12:46 am, Sebastian Huber wrote:
>>> On 11/11/2021 22:31, Joel Sherrill wrote:
>>>> On Thu, Nov 11, 2021 at 12:56 PM Sebastian Huber
>>>>   wrote:
>>>>>
>>>>>
>>>>> On 11/11/2021 17:47, Joel Sherrill wrote:
>>>>>> Hi
>>>>>>
>>>>>> I was looking at the logs for building the rtems7 tools and it seems
>>>>>> that I am missing something on the waf configure for rtems to build
>>>>>> for rtems7. Assuming it is possible. My command was:
>>>>>>
>>>>>> ./waf configure --rtems-tools=/home/joel/rtems-cron-7/tools/7
>>>>>> --rtems-bsps=sparc/leon3 --out=b-leon3
>>>>>> --prefix=/home/joel/rtems-cron-7/tools/7/bsp-install
>>>>>> --rtems-config=config-sparc-leon3.ini
>>>>>>
>>>>>> And it still tried to find sparc-rtems6-gcc.  Is there an argument i am 
>>>>>> mising?
>>>>> Try to add
>>>>>
>>>>> __RTEMS_MAJOR__ = 7
>>>>>
>>>>> to the config.ini.
>>>> That isn't in the set dumped by bsp_defaults and using it didn't
>>>> appear to change anything.
>>>
>>> Ok, I seem to remember a discussion about this some time ago. Options with
>>>
>>> default: null
>>>
>>> cannot be changed by the user. I think for the RTEMS version the reason was 
>>> that
>>> users should be forced to use the right tool chain.
>>>
>>> We could change the RTEMS version options to
>>>
>>> default: 6
>>>
>>> for example.
>>>
>>> At the moment you have to patch spec/build/cpukit/optvermaj.yml to build 
>>> with a
>>> tool chain of the wrong version.
>>
>> I think the major version is important enough and needed for development 
>> that a
>> top level waf option should be considered. I am not in favour of settings or 
>> INI
>> files because these can be archived in user projects. A user should be able 
>> to
>> move a config from 6 to 7 to 8 etc without changing it. An option can be 
>> used to
>> force the change.
> 
> OK. Patch? :)
> 

Please?

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

Re: Building a BSP for rtems7

[Chris Johns]

On 13/11/21 12:46 am, Sebastian Huber wrote:
> On 11/11/2021 22:31, Joel Sherrill wrote:
>> On Thu, Nov 11, 2021 at 12:56 PM Sebastian Huber
>>   wrote:
>>>
>>>
>>> On 11/11/2021 17:47, Joel Sherrill wrote:
 Hi

 I was looking at the logs for building the rtems7 tools and it seems
 that I am missing something on the waf configure for rtems to build
 for rtems7. Assuming it is possible. My command was:

 ./waf configure --rtems-tools=/home/joel/rtems-cron-7/tools/7
 --rtems-bsps=sparc/leon3 --out=b-leon3
 --prefix=/home/joel/rtems-cron-7/tools/7/bsp-install
 --rtems-config=config-sparc-leon3.ini

 And it still tried to find sparc-rtems6-gcc.  Is there an argument i am 
 mising?
>>> Try to add
>>>
>>> __RTEMS_MAJOR__ = 7
>>>
>>> to the config.ini.
>> That isn't in the set dumped by bsp_defaults and using it didn't
>> appear to change anything.
> 
> Ok, I seem to remember a discussion about this some time ago. Options with
> 
> default: null
> 
> cannot be changed by the user. I think for the RTEMS version the reason was 
> that
> users should be forced to use the right tool chain.
> 
> We could change the RTEMS version options to
> 
> default: 6
> 
> for example.
> 
> At the moment you have to patch spec/build/cpukit/optvermaj.yml to build with 
> a
> tool chain of the wrong version.

I think the major version is important enough and needed for development that a
top level waf option should be considered. I am not in favour of settings or INI
files because these can be archived in user projects. A user should be able to
move a config from 6 to 7 to 8 etc without changing it. An option can be used to
force the change.

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

Re: RSB: add GRUB2 to the tools.

[Chris Johns]

On 11/11/21 9:15 am, Karel Gardas wrote:
> On 11/10/21 11:04 PM, Chris Johns wrote:
>> On 11/11/21 5:32 am, Karel Gardas wrote:
>>> the attach patch adds GRUB2 into the RSB RTEMS tools. Idea is to use
>>> that on amd64 BSP for building bootable images. That's also the reason
>>> why it is used only on 6/rtems-x86_64 bset only.
>>
>> Thank you for adding this and posting it here.
>>
>> Does grub build on all supported hosts, ie Windows, MacOS, FreeBSD and Linux?
> 
> Wow! I've tested only build on Ubuntu 20.04. I'll see what I can do
> about others. FreeBSD (13) is most easy to do here actually.

It may not be possible to build on Windows and MacOS and that may be fine. Maybe
an error is raised if the host type is not supported?

This is a really useful package and it is good we add it.

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

Re: RSB: add GRUB2 to the tools.

[Chris Johns]

On 11/11/21 5:32 am, Karel Gardas wrote:
> the attach patch adds GRUB2 into the RSB RTEMS tools. Idea is to use
> that on amd64 BSP for building bootable images. That's also the reason
> why it is used only on 6/rtems-x86_64 bset only.

Thank you for adding this and posting it here.

Does grub build on all supported hosts, ie Windows, MacOS, FreeBSD and Linux?

Chris

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

Re: [PATCH v2] c-user: Document new clock manager directives

[Chris Johns]

On 9/11/21 5:57 pm, Sebastian Huber wrote:
> On 09/11/2021 03:46, Chris Johns wrote:
>>
>> On 20/10/21 2:25 am, Sebastian Huber wrote:
>>> Add new clock manager directives to get all times provided by the
>>> timehands.
>>>
>>> Update #4527.
>>> ---
>>> For an updated document to review see:
>>>
>>> https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf
>>>
>>> v2: Clarify boot time.
>>>
>>>   c-user/clock/directives.rst   | 835 ++
>>>   c-user/clock/introduction.rst |  81 
>>>   2 files changed, 916 insertions(+)
>>>
>>> diff --git a/c-user/clock/directives.rst b/c-user/clock/directives.rst
>>> index bdb7680..8f2d7ea 100644
>>> --- a/c-user/clock/directives.rst
>>> +++ b/c-user/clock/directives.rst
>>> @@ -224,6 +224,841 @@ The following constraints apply to this directive:
>>>     Applications which are restricted to only use interfaces of the
>>> pre-qualified
>>>     feature set of RTEMS shall not use the directive.
>>>   +.. Generated from spec:/rtems/clock/if/get-realtime
>>> +
>>> +.. raw:: latex
>>> +
>>> +    \clearpage
>>> +
>>> +.. index:: rtems_clock_get_realtime()
>>> +
>>> +.. _InterfaceRtemsClockGetRealtime:
>>> +
>>> +rtems_clock_get_realtime()
>>> +--
>>> +
>>> +Gets the time elapsed since the :term:`Unix epoch` measured using
>>> +:term:`CLOCK_REALTIME` in seconds and nanoseconds format.
>>> +
>>> +.. rubric:: CALLING SEQUENCE:
>>> +
>>> +.. code-block:: c
>>> +
>>> +    void rtems_clock_get_realtime( struct timespec *time_snapshot );
>>> +
>>> +.. rubric:: PARAMETERS:
>>> +
>>> +``time_snapshot``
>>> +    This parameter is the pointer to a `struct timespec
>>> +<https://en.cppreference.com/w/c/chrono/timespec>`_ object. The time> +   
>>> elapsed since the :term:`Unix epoch` measured using the
>>> +    :term:`CLOCK_REALTIME` at some time point during the directive call 
>>> will be
>>> +    stored in this object.  Calling the directive with a pointer equal to 
>>> `NULL
>>> +<https://en.cppreference.com/w/c/types/NULL>`_ is undefined behaviour.
>> Why not return an invalid error status? Same question for the same thing 
>> below.
> 
> I just documented the existing implementation. If you want an error status and
> NULL pointer checks, then we have to add a wrapper function around the FreeBSD
> interface. We still have to export the FreeBSD interface since it is used by
> libbsd.

Sure. I was only comparing this against the other APIs we have and a NULL is
checked.

> 
> The functions just have a single parameter and no return value currently. Why
> would someone pass a NULL pointer to such functions?
> 
> We could also change
> 
> RTEMS_ALIAS(_Timecounter_Nanotime)
> void rtems_clock_get_realtime(struct timespec *);
> 
> to
> 
> rtems_status_code
> rtems_clock_get_realtime(struct timespec *time_snapshot)
> {
>   if ( time_snapshot == NULL ) {
>     return RTEMS_INVALID_ADDRESS;
>   }
> 
>   _Timecounter_Nanotime( time_snapshot );
>   return RTEMS_SUCCESSFUL;
> }
> 
> However, this is less efficient. You need an extra comparison, a branch, a 
> stack
> frame, push/pop of the return address, and an extra function call.
> 
> We could also use something like this:
> 
> static inline struct timespec rtems_clock_get_realtime(void)
> {
>   struct timespec time_snapshot;
> 
>   _Timecounter_Nanotime( _snapshot );
> 
>   return time_snapshot;
> }
> 
> Unfortunately GCC is not able to optimize this.
> 

Ah OK. This can be fixed and the performance improved but once the API is set it
cannot change or do you think we can add a check later and not break the API?

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

Re: [PATCH v2] c-user: Document new clock manager directives

[Chris Johns]

On 20/10/21 2:25 am, Sebastian Huber wrote:
> Add new clock manager directives to get all times provided by the
> timehands.
> 
> Update #4527.
> ---
> For an updated document to review see:
> 
> https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf
> 
> v2: Clarify boot time.
> 
>  c-user/clock/directives.rst   | 835 ++
>  c-user/clock/introduction.rst |  81 
>  2 files changed, 916 insertions(+)
> 
> diff --git a/c-user/clock/directives.rst b/c-user/clock/directives.rst
> index bdb7680..8f2d7ea 100644
> --- a/c-user/clock/directives.rst
> +++ b/c-user/clock/directives.rst
> @@ -224,6 +224,841 @@ The following constraints apply to this directive:
>Applications which are restricted to only use interfaces of the 
> pre-qualified
>feature set of RTEMS shall not use the directive.
>  
> +.. Generated from spec:/rtems/clock/if/get-realtime
> +
> +.. raw:: latex
> +
> +\clearpage
> +
> +.. index:: rtems_clock_get_realtime()
> +
> +.. _InterfaceRtemsClockGetRealtime:
> +
> +rtems_clock_get_realtime()
> +--
> +
> +Gets the time elapsed since the :term:`Unix epoch` measured using
> +:term:`CLOCK_REALTIME` in seconds and nanoseconds format.
> +
> +.. rubric:: CALLING SEQUENCE:
> +
> +.. code-block:: c
> +
> +void rtems_clock_get_realtime( struct timespec *time_snapshot );
> +
> +.. rubric:: PARAMETERS:
> +
> +``time_snapshot``
> +This parameter is the pointer to a `struct timespec
> +`_ object. The time> +  
>   elapsed since the :term:`Unix epoch` measured using the
> +:term:`CLOCK_REALTIME` at some time point during the directive call will 
> be
> +stored in this object.  Calling the directive with a pointer equal to 
> `NULL
> +`_ is undefined behaviour.

Why not return an invalid error status? Same question for the same thing below.

Chris

> +
> +.. rubric:: NOTES:
> +
> +The directive accesses a device provided by the :term:`Clock Driver` to get 
> the
> +time in the highest precision available to the system.  Alternatively, the
> +:ref:`InterfaceRtemsClockGetRealtimeCoarse` directive may be used to get the
> +time with less precision and less runtime overhead.
> +
> +See :ref:`InterfaceRtemsClockGetRealtimeBintime` and
> +:ref:`InterfaceRtemsClockGetRealtimeTimeval` to get the time in alternative
> +formats.
> +
> +.. rubric:: CONSTRAINTS:
> +
> +The following constraints apply to this directive:
> +
> +* The directive may be called from within any runtime context.
> +
> +* The directive will not cause the calling task to be preempted.
> +
> +* The directive requires a :term:`Clock Driver`.
> +
> +.. Generated from spec:/rtems/clock/if/get-realtime-bintime
> +
> +.. raw:: latex
> +
> +\clearpage
> +
> +.. index:: rtems_clock_get_realtime_bintime()
> +
> +.. _InterfaceRtemsClockGetRealtimeBintime:
> +
> +rtems_clock_get_realtime_bintime()
> +--
> +
> +Gets the time elapsed since the :term:`Unix epoch` measured using
> +:term:`CLOCK_REALTIME` in binary time format.
> +
> +.. rubric:: CALLING SEQUENCE:
> +
> +.. code-block:: c
> +
> +void rtems_clock_get_realtime_bintime( struct bintime *time_snapshot );
> +
> +.. rubric:: PARAMETERS:
> +
> +``time_snapshot``
> +This parameter is the pointer to a :c:type:`bintime` object.  The time
> +elapsed since the :term:`Unix epoch` measured using the
> +:term:`CLOCK_REALTIME` at some time point during the directive call will 
> be
> +stored in this object.  Calling the directive with a pointer equal to 
> `NULL
> +`_ is undefined behaviour.
> +
> +.. rubric:: NOTES:
> +
> +The directive accesses a device provided by the :term:`Clock Driver` to get 
> the
> +time in the highest precision available to the system.  Alternatively, the
> +:ref:`InterfaceRtemsClockGetRealtimeCoarseBintime` directive may be used to 
> get
> +the time with less precision and less runtime overhead.
> +
> +See :ref:`InterfaceRtemsClockGetRealtime` and
> +:ref:`InterfaceRtemsClockGetRealtimeTimeval` to get the time in alternative
> +formats.
> +
> +.. rubric:: CONSTRAINTS:
> +
> +The following constraints apply to this directive:
> +
> +* The directive may be called from within any runtime context.
> +
> +* The directive will not cause the calling task to be preempted.
> +
> +* The directive requires a :term:`Clock Driver`.
> +
> +.. Generated from spec:/rtems/clock/if/get-realtime-timeval
> +
> +.. raw:: latex
> +
> +\clearpage
> +
> +.. index:: rtems_clock_get_realtime_timeval()
> +
> +.. _InterfaceRtemsClockGetRealtimeTimeval:
> +
> +rtems_clock_get_realtime_timeval()
> +--
> +
> +Gets the time elapsed since the :term:`Unix epoch` measured using
> +:term:`CLOCK_REALTIME` in seconds and microseconds format.
> +
> +.. rubric:: CALLING SEQUENCE:
> +
> +.. code-block:: c
> 

Re: [PATCH v2] c-user: Document new clock manager directives

[Chris Johns]

On 9/11/21 9:08 am, Joel Sherrill wrote:
> 
> 
> On Mon, Nov 8, 2021, 5:04 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
> On 8/11/21 5:29 pm, Sebastian Huber wrote:
> > On 25/10/2021 19:50, Sebastian Huber wrote:
> >> On 19/10/2021 17:25, Sebastian Huber wrote:
> >>> Add new clock manager directives to get all times provided by the
> >>> timehands.
> >>>
> >>> Update #4527.
> >>> ---
> >>> For an updated document to review see:
> >>>
> >>> https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf
> <https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf>
> >>>
> >>> v2: Clarify boot time.
> >>
> >> Any comments with respect to the new clock manager directives?
> >
> > If I get no objections, I will commit this on Wednesday.
> 
> We need to discuss and resolve the use of external links to specific 
> pages in
> our documentation.
> 
> I have just seen the links to opengroup.org <http://opengroup.org> and
> cppreference.com <http://cppreference.com> in the patch
> and was going to comment however a check of the existing documentation 
> shows:
> 
> $ grep -r cppreference `find . -name \*.rst` | wc -l
>      164
> 
> $ grep -r opengroup.org <http://opengroup.org> `find . -name \*.rst` | wc 
> -l
>       11
> 
> It looks like I have missed this happening in the past. I think we need to
> handle what happens with these external links because it now blocks a 6 
> release.
> 
> Deep linking into pages on an external site is at best fragile. I prefer 
> we do
> not do this because they are:
> 
> 1. Nice but not critical
> 
> 2. Create additional maintenance because someone needs to maintain the 
> links to
> make sure they are valid for each release. I have no idea how that can be 
> done
> and as the person handling releases I have no interest in doing this 
> however I
> have an interest in providing clean and stable releases
> 
> 3. Archived in a release and the referenced web site can and will change 
> their
> internal structure breaking a long life release. The referenced websites 
> have
> done this a number of times in the past
> 
> I am sorry to have to raise this. I did consider us holding an offline 
> copy of
> cppreference.com <http://cppreference.com> on ftp.rtems.org
> <http://ftp.rtems.org> however the open group site makes that hard
> because it is an exception. I am happy to hear about alternative solution?
> 
> 
> The Open Group has perma-links to specific POSIX versions and pages. If we 
> just
> want the latest version of a standard page, that's different.

That would work but in looking at the documentation and the links I still
question the value given the issues it raises. Is the overhead and work worth
what it gives us? Check `clock_settime()` in ...

https://docs.rtems.org/branches/master/c-user/clock/directives.html#rtems-clock-set

I normally just use `man` but I suspect that is just me.

> Give me an example and the goal and I will get some guidance for those.

https://docs.rtems.org/branches/master/c-user/message/directives.html#rtems-message-queue-broadcast

Then a `NULL`. Looking at this the `NULL` is a link but `buffer` is not and that
is confusing but that is the style. If the `NULL` link is broken that would be
frustrating.

Also why not also link `size_t`, `uint32_t` etc?

The fact the link jumps you out to an external site may not be liked by some.
What about those users who are required to be offline?

> Cppreference.com may have a similar permanence but I don't know. We could ask.

Asking would be great.

A halfway point maybe a glossary entry that shows the link and users can see the
jump is external?

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

Re: [PATCH v2] c-user: Document new clock manager directives

[Chris Johns]

On 8/11/21 5:29 pm, Sebastian Huber wrote:
> On 25/10/2021 19:50, Sebastian Huber wrote:
>> On 19/10/2021 17:25, Sebastian Huber wrote:
>>> Add new clock manager directives to get all times provided by the
>>> timehands.
>>>
>>> Update #4527.
>>> ---
>>> For an updated document to review see:
>>>
>>> https://ftp.rtems.org/pub/rtems/people/sebh/c-user.pdf
>>>
>>> v2: Clarify boot time.
>>
>> Any comments with respect to the new clock manager directives?
> 
> If I get no objections, I will commit this on Wednesday.

We need to discuss and resolve the use of external links to specific pages in
our documentation.

I have just seen the links to opengroup.org and cppreference.com in the patch
and was going to comment however a check of the existing documentation shows:

$ grep -r cppreference `find . -name \*.rst` | wc -l
 164

$ grep -r opengroup.org `find . -name \*.rst` | wc -l
  11

It looks like I have missed this happening in the past. I think we need to
handle what happens with these external links because it now blocks a 6 release.

Deep linking into pages on an external site is at best fragile. I prefer we do
not do this because they are:

1. Nice but not critical

2. Create additional maintenance because someone needs to maintain the links to
make sure they are valid for each release. I have no idea how that can be done
and as the person handling releases I have no interest in doing this however I
have an interest in providing clean and stable releases

3. Archived in a release and the referenced web site can and will change their
internal structure breaking a long life release. The referenced websites have
done this a number of times in the past

I am sorry to have to raise this. I did consider us holding an offline copy of
cppreference.com on ftp.rtems.org however the open group site makes that hard
because it is an exception. I am happy to hear about alternative solution?

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

Re: [PATCH RSB v3] rtems-kernel: Implement kernel recipe using waf

[Chris Johns]

OK and thanks

Chris

On 5/11/21 1:31 am, Ryan Long wrote:
> Closes #4145
> ---
>  rtems/config/tools/rtems-kernel-6.cfg   |   6 +-
>  rtems/config/tools/rtems-kernel-common.cfg  | 125 +++
>  source-builder/sb/rtems-kernel-config-check | 147 
> 
>  3 files changed, 215 insertions(+), 63 deletions(-)
>  create mode 100755 source-builder/sb/rtems-kernel-config-check
> 
> diff --git a/rtems/config/tools/rtems-kernel-6.cfg 
> b/rtems/config/tools/rtems-kernel-6.cfg
> index f1d0990..9120862 100644
> --- a/rtems/config/tools/rtems-kernel-6.cfg
> +++ b/rtems/config/tools/rtems-kernel-6.cfg
> @@ -2,10 +2,10 @@
>  # RTEMS 5
>  #
>  
> -%define rtems_kernel_version 3ec5f20484cc4201e1d7b87844505644533b6148
> -%hash sha512 rtems-kernel-%{rtems_kernel_version}.tar.bz2 \
> -  
> BjMKrf5n1YR6IpiZrY5TUEzKATPRJxA2/6m6f833DdRu+RyLxccXqA4gHRdVUqFelFNQ3o0XdG4o1naBKYfhkQ==
> +%define rtems_kernel_version 3bb97a30b17b6c138dead3e3a6b329c3b301cdb3
>  
> +%hash sha512 rtems-kernel-%{rtems_kernel_version}.tar.gz \
> +  
> m/ogwrJj4X60ewDIbV6WRj1MJa/22gQHQd56XiNMfvCr0nsvcXdkXKAObLIGYIGYfUyEwlVk3SRjjRFkFalDGQ==
>  #
>  # The RTEMS build instructions.
>  #
> diff --git a/rtems/config/tools/rtems-kernel-common.cfg 
> b/rtems/config/tools/rtems-kernel-common.cfg
> index 157c7a4..431fc1d 100644
> --- a/rtems/config/tools/rtems-kernel-common.cfg
> +++ b/rtems/config/tools/rtems-kernel-common.cfg
> @@ -9,7 +9,7 @@
>  # and BSPs. Only after the source to download.
>  #
>  %if %{_dry_run} && %{defined with_download}
> - %log Kenrel configuration errors ignored
> + %log Kernel configuration errors ignored
>   %define rtems_kernel_error 0
>  %else
>   %define rtems_kernel_error 1
> @@ -19,10 +19,15 @@
>   %define rtems_kernel_version %{rsb_version}
>  %endif
>  
> +%if %{defined with_rtems_bsp_config}
> + %define _target %(%{_sbdir}/sb/rtems-kernel-config-check -v 
> %{rtems_version} -t %{with_rtems_bsp_config})
> + %define rtems_bsp %(%{_sbdir}/sb/rtems-kernel-config-check -b 
> %{with_rtems_bsp_config})
> +%endif
> +
>  #
>  # The target. It could be set in rtems_target.
>  #
> -%if %{defined rtems_target}
> +%if %{defined rtems_target} && !%{defined with_rtems_bsp_config}
>   %define _target %{rtems_target}
>  %endif
>  %if %{_target} == %{nil} && %{rtems_kernel_error}
> @@ -32,10 +37,21 @@
>  #
>  # The BSP.
>  #
> -%if !%{defined with_rtems_bsp} && %{rtems_kernel_error}
> +%if !%{defined with_rtems_bsp} && %{rtems_kernel_error} && !%{defined 
> with_rtems_bsp_config}
>   %error No RTEMS BSP specified: --with-rtems-bsp=bsp
>  %endif
> -%define rtems_bsp %{with_rtems_bsp}
> +%if !%{defined with_rtems_bsp_config}
> + %define rtems_bsp %{with_rtems_bsp}
> +%endif
> +
> +#
> +# Configuration file used with waf
> +#
> +%ifn %{defined with_rtems_bsp_config}
> + %define config_file config-%{_target}-%{rtems_bsp}.ini
> +%else
> + %define config_file %{with_rtems_bsp_config}
> +%endif
>  
>  #
>  # If no tools are provided use the prefix.
> @@ -98,14 +114,6 @@ URL:   https://www.rtems.org/
>   %define rtems_posix 0
>  %endif
>  
> -%if %{defined with_rtems_legacy_network}
> - %define rtems_networking 1
> -%endif
> -
> -%if %{defined with_rtems_cxx}
> - %define rtems_cxx 1
> -%endif
> -
>  %if %{defined with_rtems_bspopts}
>   %define bspopts %{with_rtems_bspopts}
>  %endif
> @@ -143,43 +151,43 @@ URL: https://www.rtems.org/
>  # --without-rtems-tests  : Supported, forced to no
>  # --with-rtems-smp   : Supported
>  # --without-rtems-smp: Don't care
> -# --with-rtems-legacy-network: Supported
> +# --with-rtems-legacy-network: Unsupported
>  # --without-rtems-legacy-network : Don't care
> -# --with-rtems-bspopts   : Supported, quote for a list
> -# --without-rtems-bspopts: Don't care
> -#
>  %if %{defined without_rtemsbsp}
>   %error Option --without-rtemsbsp is not supported.
>  %endif
> +%if %{defined with_rtems_legacy_network}
> + echo "RTEMS legacy network has been removed."
> + echo "Please review and update your configuration."
> + exit 1
> +%endif
> +%if %{defined enable_cxx}
> + echo CXX has been removed."
> + echo "Please review and update your configuration."
> + exit 1
> +%endif
> +
>  %if %{defined without_rtems_tests}
> - %define with_rtems_tests no
> + %define rtems_tests False
> + %define rtems_sample_tests False
>  %endif
>  %if %{defined with_rtems_tests}
>   %if %{with_rtems_tests} == 1
> -  %define with_rtems_tests yes
> +   %define rtems_tests True
> +   %define rtems_sample_tests True
>   %endif
> - %if %{with_rtems_tests} == yes || \
> - %{with_rtems_tests} == no || \
> - %{with_rtems_tests} == samples
> -  %define rtems_tests %{with_rtems_tests}
> +  %if %{with_rtems_tests} == samples
> +  %define rtems_tests False
> +  %define rtems_sample_tests True
>   %endif
>  %endif
>  %if %{defined with_rtems_smp}
>   %define rtems_smp 1
>  %endif
> -%if %{defined 

Re: [PATCH RSB v2] rtems-kernel: Implement kernel recipe using waf

[Chris Johns]

On 4/11/21 12:37 am, Ryan Long wrote:
> -Original Message-
> From: Chris Johns  
> Sent: Tuesday, November 2, 2021 5:14 PM
> To: Ryan Long ; devel@rtems.org
> Subject: Re: [PATCH RSB v2] rtems-kernel: Implement kernel recipe using waf
> 
> On 3/11/21 4:13 am, Ryan Long wrote:
>>
>> -----Original Message-
>> From: Chris Johns 
>> Sent: Monday, November 1, 2021 8:48 PM
>> To: Ryan Long ; devel@rtems.org
>> Subject: Re: [PATCH RSB v2] rtems-kernel: Implement kernel recipe 
>> using waf On 28/10/21 2:09 am, Ryan Long wrote:
>>> + %define rtems_bsp
>>> + %(%{_topdir}/../source-builder/rtems-kernel-config-check -b
>>> + %{with_rtems_bsp_config})
>>
>> How are config file errors handled? I normally return `ERROR` or something 
>> that can be checked.
>> [Ryan Long] Right now the script is handling all the errors. I'll add some 
>> error checking to rtems-kernel-common.cfg.
> 
> And if the helper script finds and error what happens to the RSB build?
> [Ryan Long] The build fails when an error is found on in the INI file by the 
> helper script. The error is printed out, so does error checking still need to 
> be added to rtems-kernel-common.cfg?

This founds fine to me. I was just checking this is being handled.

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

Re: [PATCH RSB v2] rtems-kernel: Implement kernel recipe using waf

[Chris Johns]

On 3/11/21 4:13 am, Ryan Long wrote:
> 
> -Original Message-
> From: Chris Johns  
> Sent: Monday, November 1, 2021 8:48 PM
> To: Ryan Long ; devel@rtems.org
> Subject: Re: [PATCH RSB v2] rtems-kernel: Implement kernel recipe using waf
> On 28/10/21 2:09 am, Ryan Long wrote:
>> + %define rtems_bsp 
>> + %(%{_topdir}/../source-builder/rtems-kernel-config-check -b 
>> + %{with_rtems_bsp_config})
> 
> How are config file errors handled? I normally return `ERROR` or something 
> that can be checked.
> [Ryan Long] Right now the script is handling all the errors. I'll add some 
> error checking to rtems-kernel-common.cfg.

And if the helper script finds and error what happens to the RSB build?

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

Re: [PATCH RSB v2] rtems-kernel: Implement kernel recipe using waf

[Chris Johns]

True,  None,  False),
> +'--topdir': ('_topdir',   self._lo_path, 
> True,  None,  False),
> +'--configdir' : ('_configdir',self._lo_path, 
> True,  None,  False),
> +'--builddir'  : ('_builddir', self._lo_path, 
> True,  None,  False),
> +'--sourcedir' : ('_sourcedir',self._lo_path, 
> True,  None,  False),
> +'--patchdir'  : ('_patchdir', self._lo_path, 
> True,  None,  False),
> +'--tmppath'   : ('_tmppath',  self._lo_path, 
> True,  None,  False),
> +'--jobs'  : ('_jobs', self._lo_jobs, 
> True,  'max', True),
> +'--log'   : ('_logfile',  
> self._lo_string,   True,  None,  False),
> +'--url'   : ('_url_base', 
> self._lo_string,   True,  None,  False),
> +'--no-download'   : ('_disable_download', self._lo_bool, 
> False, '0',   True),
> +'--macros': ('_macros',   
> self._lo_string,   True,  None,  False),
> +'--source-only-download'  : ('_source_download',  self._lo_bool, 
> False, '0',   True),
> +'--targetcflags'  : ('_targetcflags', 
> self._lo_string,   True,  None,  False),
> +'--targetcxxflags': ('_targetcxxflags',   
> self._lo_string,   True,  None,  False),
> +'--libstdcxxflags': ('_libstdcxxflags',   
> self._lo_string,   True,  None,  False),
> +'--force' : ('_force',self._lo_bool, 
> False, '0',   True),
> +'--quiet' : ('_quiet',self._lo_bool, 
> False, '0',   True),
> +'--trace' : ('_trace',self._lo_bool, 
> False, '0',   True),
> +    '--dry-run'   : ('_dry_run',  self._lo_bool, 
> False, '0',   True),
> +'--warn-all'  : ('_warn_all', self._lo_bool, 
> False, '0',   True),
> +'--no-clean'  : ('_no_clean', self._lo_bool, 
> False, '0',   True),
> +'--keep-going': ('_keep_going',   self._lo_bool, 
> False, '0',   True),
> +'--always-clean'  : ('_always_clean', self._lo_bool, 
> False, '0',   True),
> +'--no-install': ('_no_install',   self._lo_bool, 
> False, '0',   True),
> +'--regression': ('_regression',   self._lo_bool, 
> False, '0',   True),
> +'--host'  : ('_host', 
> self._lo_triplets, True,  None,  False),
> +'--build' : ('_build',
> self._lo_triplets, True,  None,  False),
> +'--target': ('_target',   
> self._lo_triplets, True,  None,  False),
> +'--rtems-tools'   : ('_rtems_tools',  
> self._lo_string,   True,  None,  False),
> +'--rtems-bsp' : ('_rtems_bsp',
> self._lo_string,   True,  None,  False),

The documented method uses `--with-rtems-bsp=erc32 --with-rtems-tests=yes` ...

https://docs.rtems.org/branches/master/user/start/bsp-build.html#rsb-bsp-build

I prefer we do not changes this. See `--with-`:

https://docs.rtems.org/branches/master/user/rsb/commands.html#set-builder-sb-set-builder

The --with-* method avoids creating a dependency between package configs and the
commandline options, ie this source file.

Chris

> +'--rtems-version' : ('_rtems_version',
> self._lo_string,   True,  None,  False),
> +'--help'  : (None,self._lo_help, 
> False, None,  False)
>  }
>  
>  self.command_path = command_path
> @@ -203,40 +203,41 @@ class command_line:
>  print('%s: [options] [args]' % (self.command_name))
>  print('RTEMS Source Builder, an RTEMS Tools Project (c) 2012-2019 
> Chris Johns')
>  print('Options and arguments:')
> -print('--force: Force the build to proceed')
> -print('--quiet: Quiet output (not used)')
> -print('--trace: Trace the execution')
> -print('--dry-run  : Do everything but actually run the 
> build')
> -print('--warn-all : Generate warnings')
> -print('--no-clean : Do not clean up the build tree')
> -print('--always-clean : Always clean the build tree, even 
> with 

Re: [PATCH v1 0/8] Add AArch64 libdebugger support

[Chris Johns]

On 30/10/21 8:17 am, Kinsey Moore wrote:
> This patch set adds libdebugger support to AArch64 and resolves several
> bugs found along the way.

Looks good and OK to push.

Kinsey. really nice work :)

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

Re: [PATCH RSB] Update to dtc 1.6.1

[Chris Johns]

On 29/10/21 6:26 am, Joel Sherrill wrote:
> On Thu, Oct 28, 2021 at 12:20 PM Hesham Almatary
>  wrote:
>>
>> Does RISC-V need that too?
> 
> Not based on the current bsets.
> 
> $ grep -r dtc *
> 6/rtems-moxie.bset:devel/dtc-1.6.0-1
> 6/rtems-microblaze.bset:devel/dtc-1.6.0-1
> 7/rtems-moxie.bset:devel/dtc-1.6.0-1
> 
> Alex.. the grep shows that 7/microblaze is out of sync. Please address that.
> 
> Hesham.. if riscv needs dtc, it should be added to its bset for 6 and 7.

Should we add DTC to the default package set and avoid the need to manage what
needs it?

The rational is the growing use of FDT in RTEMS and this lets us control what we
need on a per release basis. For example 5 years from now DTC has changed and
RTEMS today does not work with it.

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

Re: [PATCH rtems-tools] rtems-bsp-builder: Fix mail support

[Chris Johns]

OK

Thanks
Chris

On 29/10/21 7:01 am, Alex White wrote:
> This fixes a problem with mailer options support that occurred because
> check.py uses argparse.ArgumentParser instead of tester.rt.options.
> ---
>  rtemstoolkit/mailer.py |  2 +-
>  tester/rt/check.py | 17 -
>  2 files changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/rtemstoolkit/mailer.py b/rtemstoolkit/mailer.py
> index 085a2ce..32cbc23 100644
> --- a/rtemstoolkit/mailer.py
> +++ b/rtemstoolkit/mailer.py
> @@ -70,7 +70,7 @@ class mail:
>  def __init__(self, opts):
>  self.opts = opts
>  self.gitconfig_lines = None
> -if opts.find_arg('--use-gitconfig') is not None:
> +if self._get_arg('--use-gitconfig'):
>  # Read the output of `git config --list` instead of reading the
>  # .gitconfig file directly because Python 2 ConfigParser does not
>  # accept tabs at the beginning of lines.
> diff --git a/tester/rt/check.py b/tester/rt/check.py
> index c01c25d..ec92e7e 100755
> --- a/tester/rt/check.py
> +++ b/tester/rt/check.py
> @@ -105,7 +105,22 @@ def title():
>  return 'RTEMS Tools Project - RTEMS Kernel BSP Builder, %s' % 
> (version.string())
>  
>  def command_line():
> -return wrap(('command: ', ' '.join(sys.argv)), lineend = '\\')
> +# Filter potentially sensitive mail options out.
> +filtered_args = [
> +arg for arg in sys.argv
> +if all(
> +smtp_opt not in arg
> +for smtp_opt in [
> +'--smtp-host',
> +'--mail-to',
> +'--mail-from',
> +'--smtp-user',
> +'--smtp-password',
> +'--smtp-port'
> +]
> +)
> +]
> +return wrap(('command: ', ' '.join(filtered_args)), lineend = '\\')
>  
>  def jobs_option_parse(jobs_option):
>  try:
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] spec/libdebugger: Only enable for supported architectures

[Chris Johns]

On 22/10/21 1:21 am, Sebastian Huber wrote:
> On 21/10/2021 10:36, Chris Johns wrote:
>> Could you please answer the other parts of the email you cut because it would
>> help understand this stuff?
>>
>> Specifically the opt* and user options. When is an option optional and when 
>> is
>> an option an option but not optional?
> 
> The option item files are used for both user options and internal options.
> 

OK I think this now makes sense. An option can be a user controlled with a
default or a variant dependent on the build characteristics, for example
architecture?

>> On 21/10/21 7:09 pm, Sebastian Huber wrote:
>>> On 21/10/2021 10:06, Chris Johns wrote:
>>>> KeyError: '/cpukit/optlibddebugger'
>>>>
>>>> You have to admit this is a horrible error message. It provides no insight 
>>>> into
>>>> problem or the solution.
>>>
>>> Looks like a typo. Maybe use optlibdebugger?
>>
>> Yes it was. Thanks. However I am still confused.
>>
>> If I add optlibdebugger to cpuopts.yml which is:
>>
>>   build-type: config-header
>>
>> I would expect libdl and libdebugger to appear in cpuopts.h as enable 
>> variables
>> but they do not?
> 
> What the option items to is defined by the actions attribute, for example
> (spec/build/cpukit/optlibdl.yml):
> 
> actions:
> - set-value: true
> - env-enable: null
> 
> This adds the option name to the enabled set.

Thanks. And `name` is the name field?

>> Why are they in this YAML file?
> 
> This is to order the build properly.

OK. Is it fair to say cpuopts is a convenient way to centralise this?

>>
>> The the libdebugger YAML file I need:
>>
>>   enabled-by: BUILD_LIBDEBUGGER
>>
>> or:
>>
>>   enabled-by:
>>    - arm
>>    - i386
> 
> If the option file adding BUILD_LIBDEBUGGER to the enabled set is processed
> before the libdebugger.yml and it uses the same enabled-by expression, then 
> you
> can use both.

Both of what?

How would I add a define to the actual cpuopts.h file?

I wonder if adding libdl and libdebugger would be useful given they are not
universally supported?

>> however `enabled-by` is not in:
>>
>> https://docs.rtems.org/branches/master/eng/req/items.html#spectypebuildlibraryitemtype
>>
>>
>> Is it OK to do this?
> 
> Yes, just follow the "refines" link to the root type.
> 
>>
>> It is great this is working but it is confusing understanding why and that 
>> means
>> it is hard to know what you can do and not do?
> 
> The items have a fixed set of top-level attributes which are all documented.
> What you should definitely not do is adding new attributes to existing files.
> This is an absolute no go.

Would it make sense to capture the constraints of each `build-type`? It would
have helped me here if an error was generated when I added `name` to the
`build-type` library. I can see `constraints.yml` as a top level file that is
read in and to used to monitor what is present in each built-type.

> We should gradually improve the documentation. Maybe the enabled-by attribute
> needs more explanations.

Agreed. And the options and what they are used for? I considered their use was
literal and user facing.

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

Re: [PATCH] spec/libdebugger: Only enable for supported architectures

[Chris Johns]

Could you please answer the other parts of the email you cut because it would
help understand this stuff?

Specifically the opt* and user options. When is an option optional and when is
an option an option but not optional?

On 21/10/21 7:09 pm, Sebastian Huber wrote:
> On 21/10/2021 10:06, Chris Johns wrote:
>> KeyError: '/cpukit/optlibddebugger'
>>
>> You have to admit this is a horrible error message. It provides no insight 
>> into
>> problem or the solution.
> 
> Looks like a typo. Maybe use optlibdebugger?

Yes it was. Thanks. However I am still confused.

If I add optlibdebugger to cpuopts.yml which is:

 build-type: config-header

I would expect libdl and libdebugger to appear in cpuopts.h as enable variables
but they do not? Why are they in this YAML file?

The the libdebugger YAML file I need:

 enabled-by: BUILD_LIBDEBUGGER

or:

 enabled-by:
  - arm
  - i386

however `enabled-by` is not in:

https://docs.rtems.org/branches/master/eng/req/items.html#spectypebuildlibraryitemtype

Is it OK to do this?

It is great this is working but it is confusing understanding why and that means
it is hard to know what you can do and not do?

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

Re: [PATCH] spec/libdebugger: Only enable for supported architectures

[Chris Johns]

On 21/10/21 4:30 pm, Sebastian Huber wrote:
> On 21/10/2021 04:09, chr...@rtems.org wrote:
>> From: Chris Johns
>>
>> ---
>>   spec/build/cpukit/libdebugger.yml | 5 -
>>   spec/build/testsuites/libtests/debugger01.yml | 4 +---
>>   2 files changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/spec/build/cpukit/libdebugger.yml
>> b/spec/build/cpukit/libdebugger.yml
>> index f316cc18e8..4e689044e7 100644
>> --- a/spec/build/cpukit/libdebugger.yml
>> +++ b/spec/build/cpukit/libdebugger.yml
>> @@ -5,7 +5,9 @@ copyrights:
>>   - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
>>   cppflags: []
>>   cxxflags: []
>> -enabled-by: true
>> +enabled-by:
>> +- arm
>> +- i386
>>   includes: []
>>   install: []
>>   install-path: ${BSP_LIBDIR}
>> @@ -24,4 +26,5 @@ source:
>>   - cpukit/libdebugger/rtems-debugger-target.c
>>   - cpukit/libdebugger/rtems-debugger-threads.c
>>   target: debugger
>> +name: BUILD_LIBDEBUGGER
>>   type: build
> 
> Library items cannot have a name. You need an option item for this.

An option implies it is user configurable and it is not. How would you pass the
enable-it state to the tests?

If there is another approach could be please explain how this is to handled?

The waf build for libdebugger is broken. The library should only be built for
the archs that have a backend. As it currently is the library is created and
installed and this is hidden by the fact the test is conditional on the archs
and not the library being built. This is now exposed by Kinsey's patch to
libbsd. LibBSD does not build.

I based adding the name on libdl. It seems libdl is done differently and I have
no idea why and how it works.

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

Re: [PATCH v2] rtems-kernel: Implement kernel recipe using waf

[Chris Johns]

._lo_bool,  
>False, '0',   True),
> -'--no-clean' : ('_no_clean', self._lo_bool,  
>False, '0',   True),
> -'--keep-going'   : ('_keep_going',   self._lo_bool,  
>False, '0',   True),
> -'--always-clean' : ('_always_clean', self._lo_bool,  
>False, '0',   True),
> -'--no-install'   : ('_no_install',   self._lo_bool,  
>False, '0',   True),
> -'--regression'   : ('_regression',   self._lo_bool,  
>False, '0',   True),
> -'--host' : ('_host', 
> self._lo_triplets, True,  None,  False),
> -'--build': ('_build',
> self._lo_triplets, True,  None,  False),
> -'--target'   : ('_target',   
> self._lo_triplets, True,  None,  False),
> -'--rtems-tools'  : ('_rtems_tools',  
> self._lo_string,   True,  None,  False),
> -'--rtems-bsp': ('_rtems_bsp',
> self._lo_string,   True,  None,  False),
> -'--rtems-version': ('_rtems_version',
> self._lo_string,   True,  None,  False),
> -'--help' : (None,self._lo_help,  
>False, None,  False)
> +'--prefix': ('_prefix',   self._lo_path, 
> True,  None,  False),
> +'--topdir': ('_topdir',   self._lo_path, 
> True,  None,  False),
> +'--configdir' : ('_configdir',self._lo_path, 
> True,  None,  False),
> +'--builddir'  : ('_builddir', self._lo_path, 
> True,  None,  False),
> +'--sourcedir' : ('_sourcedir',self._lo_path, 
> True,  None,  False),
> +'--patchdir'  : ('_patchdir', self._lo_path, 
> True,  None,  False),
> +'--tmppath'   : ('_tmppath',  self._lo_path, 
> True,  None,  False),
> +'--jobs'  : ('_jobs', self._lo_jobs, 
> True,  'max', True),
> +'--log'   : ('_logfile',  
> self._lo_string,   True,  None,  False),
> +'--with-rtems-bsp-config' : ('_bspconfig',self._lo_path, 
> True,  None,  False),

--with-* and --without- has special handling. This is not needed.

Chris

> +'--url'   : ('_url_base', 
> self._lo_string,   True,  None,  False),
> +'--no-download'   : ('_disable_download', self._lo_bool, 
> False, '0',   True),
> +'--macros': ('_macros',   
> self._lo_string,   True,  None,  False),
> +'--source-only-download'  : ('_source_download',  self._lo_bool, 
> False, '0',   True),
> +'--targetcflags'  : ('_targetcflags', 
> self._lo_string,   True,  None,  False),
> +'--targetcxxflags': ('_targetcxxflags',   
> self._lo_string,   True,  None,  False),
> +'--libstdcxxflags': ('_libstdcxxflags',   
> self._lo_string,   True,  None,  False),
> +'--force' : ('_force',self._lo_bool, 
> False, '0',   True),
> +'--quiet' : ('_quiet',self._lo_bool, 
> False, '0',   True),
> +'--trace' : ('_trace',self._lo_bool, 
> False, '0',   True),
> +'--dry-run'   : ('_dry_run',  self._lo_bool, 
> False, '0',   True),
> +'--warn-all'  : ('_warn_all', self._lo_bool, 
> False, '0',   True),
> +'--no-clean'  : ('_no_clean', self._lo_bool, 
> False, '0',   True),
> +'--keep-going': ('_keep_going',   self._lo_bool, 
> False, '0',   True),
> +'--always-clean'  : ('_always_clean', self._lo_bool, 
> False, '0',   True),
> +'--no-install': ('_no_install',   self._lo_bool, 
> False, '0',   True),
> +    '--regression': ('_regression',   self._lo_bool, 
> False, '0',   True),
> +'--host'  : ('_host', 
> self._lo_triplets, True,  None,  False),
> +'--build' : ('_build',
> self._lo_triplets, True,  None,  False),
> +'--target': ('_target',   
> self._lo_triplets, True,  None,  False),
> +'--rtems-tools'   : ('_rtems_tools',  
> self._lo_

Re: [PATCH 3/4] rtemsbsd/nfsclient: Fix the error code return value

[Chris Johns]

On 21/10/21 9:59 am, Joel Sherrill wrote:
> On Wed, Oct 20, 2021, 12:49 AM Sebastian Huber
>  >
> wrote:
> On 20/10/2021 05:16, chr...@rtems.org  wrote:
> > +     errno = 0;
> > +     return 0;
> 
> I think setting errno if no error occurred is not allowed.
> Right. Convention is that errno should not be touched by implementation or 
> read
> by application unless -1 is returned.
> 

Fantastic and thank you for the review and feedback.

I will remove this and push the patches.

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

Re: [PATCH 3/4] rtemsbsd/nfsclient: Fix the error code return value

[Chris Johns]

On 20/10/21 4:49 pm, Sebastian Huber wrote:
> On 20/10/2021 05:16, chr...@rtems.org wrote:
>> +    errno = 0;
>> +    return 0;
> 
> I think setting errno if no error occurred is not allowed.
> 

I suspect you are right. Joel?

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

Re: [PATCH] testsuite/spcache01: Clear allocated coherent cache memory

[Chris Johns]

On 20/10/21 2:46 am, Christian MAUDERER wrote:
> Am 19.10.21 um 16:48 schrieb Sebastian Huber:
>>
>>
>> On 18/10/2021 23:08, Chris Johns wrote:
>>> On 18/10/21 8:37 pm, Sebastian Huber wrote:
>>>> On 18/10/2021 09:53, Chris Johns wrote:
>>>>> On 18/10/21 4:50 pm, Sebastian Huber wrote:
>>>>>> On 18/10/2021 07:19,chr...@rtems.org   wrote:
>>>>>>> From: Chris Johns
>>>>>>>
>>>>>>> - Coherent cache memory is used in libbsd for things like descriptors
>>>>>>>  and it optionally clears the memory on allocation. Test is works.
>>>>>> There is no guarantee that memset() and memcpy() work with cache coherent
>>>>>> memory. Such memory areas may disallow misaligned access for example.
>>>>> That seems reasonable however this change about testing the implicit
>>>>> requirements we have that memset works. LibBSD requires memset works ...
>>>>>
>>>>> https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/rtems/rtems-kernel-bus-dma.c?h=6-freebsd-12#n260
>>>>>
>>>>>
>>>> Using memset() here could be a bug in libbsd.
>>> Yes, I also think so.
>>>
>>> But what is a suitable mechanism to make sure the arch or BSP handle it
>>> correctly? Maybe a clear routine in libbsd using the bus space API? That
>>> interface has to work or the drivers will not work.
>>
>> I think we had similar issues on another BSP. Christian, do you remember how
>> we solved this?
>>
> 
> I remember mainly problems with copying memory. I think the last time it
> resulted in an ugly "copy_from/to_io" function on the atsam:
> 
>   https://git.rtems.org/rtems/tree/bsps/arm/atsam/start/iocopy.c
> 

Thanks.

> The bus_space_* functions should work. Only problem is that a valid
> bus_space_tag is missing in this context. I think x86 uses it. I think for all
> other platforms it is unused.

I used the direct methods because it is internal and I think it is safe to
assume this is a linear address being returned from the allocator?

I have posted a patch which is working on the Versal. It is not optimized and
does not attempt to detect alignments to use larger word sizes for faster
clears. The amount of memory being allocated is not large.

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

Re: [PATCH] rtems/6: Update binutils to 2.37

[Chris Johns]

On 19/10/21 9:23 am, Joel Sherrill wrote:
> Was there something wrong with Ryan's patch to do this? He also bumped RTEMS 7
> tools. 

No not at all.

> You reviewed it. :)

I thought I had reviewed it and I checked the repo today and could not see
anything. Is it pushed?

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

Re: ZynqMP and Versal crash clearing coherent cache memory with memset

[Chris Johns]

On 19/10/21 8:59 am, Joel Sherrill wrote:
> On Mon, Oct 18, 2021 at 4:28 PM Chris Johns  wrote:
>>
>> On 19/10/21 3:53 am, Kinsey Moore wrote:
>>> On 10/18/2021 00:44, Chris Johns wrote:
>>>> Hi,
>>>>
>>>> I cannot run libbsd on real hardware because the cadence rx descriptor 
>>>> cache
>>>> coherent allocation crashes in `memset`. It is used to clear the memory.
>>>>
>>>> The rtemsbsd allocator call optionally clears the memory and it seems the 
>>>> newlib
>>>> aarch64 memset code crashes when doing this. A basic loop with 8bit or 
>>>> 32bit
>>>> writes does not crash. The memset call happily clears an array in cached 
>>>> memory
>>>> with different offsets.
>>>>
>>>> I have posted a patch to spcache01 that generates the crash on Versal and 
>>>> ZynqMP
>>>> hardware. The crash dump is:
>>>>
>>>> test cache coherent allocation
>>>> clear cache coherent with memset: 0x1fe00050
>>>>
>>>>
>>>> *** FATAL ***
>>>> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
>>>>
>>>>
>>>> X0   = 0x1fe00050 X17  = 0x000c
>>>> X1   = 0x X18  = 0x17b0
>>>> X2   = 0x0110 X19  = 0x1fe00050
>>>> X3   = 0x1fe000c0 X20  = 0x1fdfff80
>>>> X4   = 0x1fe00250 X21  = 0x10013ab0
>>>> X5   = 0x0004 X22  = 0x
>>>> X6   = 0x0001 X23  = 0x
>>>> X7   = 0x X24  = 0x10103140
>>>> X8   = 0x X25  = 0x
>>>> X9   = 0xff80ffc8 X26  = 0x
>>>> X10  = 0x X27  = 0x
>>>> X11  = 0x1010ca78 X28  = 0x
>>>> X12  = 0x0001 FP   = 0x1010cc30
>>>> X13  = 0x1fe00050 LR   = 0x10001f94
>>>> X14  = 0x SP   = 0x1010cc30
>>>> X15  = 0x0004 PC   = 0x100125c0
>>>> X16  = 0x1000f700 DAIF = 0x03c0
>>>> VEC  = 0x0004 CPSR = 0x6005
>>>> ESR  = EC: 0b100101 IL: 0b1 ISS: 0b00111
>>>> Data Abort taken without a change in Exception level
>>>> FAR  = 0x1fe000c0
>>>> FPCR = 0x FPSR = 0x0010
>>>>
>>>> The Versal (A72) fails in exactly the same way. The allocated address is
>>>> 0x1fe00050 and the FAR is 0x1fe000c0 so I am not sure if the "0xc0 - 0x50"
>>>> section is aligning the pointer to a larger word size for better 
>>>> performance and
>>>> that first part is OK but the different word size breaks.
>>>
>>> I'm running with a toolchain that was built with
>>> --targetcflags="-DPREFER_SIZE_OVER_SPEED" which affects the content of the
>>> memset function, so my memset is just loops of writes and seems to work 
>>> fine.
>>
>> Oh. Maybe the eng manual needs a piece on this. Using flags on tool chains 
>> like
>> this is fine for a user because it is use at your own peril however I believe
>> patches need to be tested with the defaults for all tools. It is way to hard 
>> to
>> baseline a BSP if tweaks are needed here and there.
> 
> We did try to merge this to the RSB as a temporary workaround for ilp32 
> issues.
> Kinsey may have realized it had this impact also but I don't recall
> being aware of it.

Sure and we need to accommodate this but I think as a policy we need to make
sure patches are tested with default tool sets. I cannot see how we can make
things work without having this happen?

> We didn't want it to be a local hack. :)

It may have to be just that. It seem to me we have an IPL32 BSP that needs a
special set of tools and that constrains any other aarch64 BSPs if it became the
default. Do we want that? If the cached memory gets a performance boost from a
better memset, memcpy etc then I hope that is available to me by default.

>>> Just out of curiousity, what instruction was at that PC address? If it was 
>>> "dc
>>> zva", then I had seen this a while back during initial AArch64 bringup and 
>>> had
>>> assumed it was fixed since the addition of the MMU code since that 
>>> instruction
>>> doesn't work on device memory.
>>
>> It this that instruction ...
>>
>> 100125c0:   d50b7423dc  zva, x3
>>
>> Looks like it is not fixed.
> 
> I think your suggestion that FreeBSD should not use memset for device memory
> is the right path though. But that could be in a lot of places. :(

I do not know. The allocation is under the bus space DMA allocator and that
interface is complicated. Maybe memset is not suitable?

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

Re: [PATCH RSB] rtems-tools-6.cfg: Bump hash to include MicroBlaze

[Chris Johns]

OK and thanks

Chris

On 19/10/21 2:09 am, Alex White wrote:
> Hash: 323007a6b520140a20b2e268c90b78ff67afaf45
> ---
>  rtems/config/tools/rtems-tools-6.cfg | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/rtems/config/tools/rtems-tools-6.cfg 
> b/rtems/config/tools/rtems-tools-6.cfg
> index cfb..4158753 100644
> --- a/rtems/config/tools/rtems-tools-6.cfg
> +++ b/rtems/config/tools/rtems-tools-6.cfg
> @@ -10,14 +10,14 @@
>   %define rtems_tools_source rtems-tools-%{rtems_tools_version}
>   %define rtems_tools_ext xz
>  %else
> - %define rtems_tools_version 40a7058bd4d7681ca6be7a14f09a1275ea4fbde4
> + %define rtems_tools_version 323007a6b520140a20b2e268c90b78ff67afaf45
>   %define rtems_tools_ext bz2
>  %endif
>  
>  %define rtems_tools_source rtems-tools-%{rtems_tools_version}
>  %source set rtems-tools 
> https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
>  %hash   sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
> - 
> nlwNKLP2UXRMRfK0SU0Bpd+9sOvRoRaXRRTj0lzx9jkqGMwwU4lB19uLhTnH88u1jGOrhVSkNunIHvbi9SayAg==
> + 
> yo5i1HEaYyOOX8JJGr+kok0vIEZGpXjeZmA44gqTow101PhtlwhebvgTS0SeMe8L68wTDqdjZe5QVnsjKgYOhw==
>  
>  #
>  # Optionally enable/disable building the RTEMS Tools via the command line.
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: ZynqMP and Versal crash clearing coherent cache memory with memset

[Chris Johns]

On 19/10/21 3:53 am, Kinsey Moore wrote:
> On 10/18/2021 00:44, Chris Johns wrote:
>> Hi,
>>
>> I cannot run libbsd on real hardware because the cadence rx descriptor cache
>> coherent allocation crashes in `memset`. It is used to clear the memory.
>>
>> The rtemsbsd allocator call optionally clears the memory and it seems the 
>> newlib
>> aarch64 memset code crashes when doing this. A basic loop with 8bit or 32bit
>> writes does not crash. The memset call happily clears an array in cached 
>> memory
>> with different offsets.
>>
>> I have posted a patch to spcache01 that generates the crash on Versal and 
>> ZynqMP
>> hardware. The crash dump is:
>>
>> test cache coherent allocation
>> clear cache coherent with memset: 0x1fe00050
>>
>>
>> *** FATAL ***
>> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
>>
>>
>> X0   = 0x1fe00050 X17  = 0x000c
>> X1   = 0x X18  = 0x17b0
>> X2   = 0x0110 X19  = 0x1fe00050
>> X3   = 0x1fe000c0 X20  = 0x1fdfff80
>> X4   = 0x1fe00250 X21  = 0x10013ab0
>> X5   = 0x0004 X22  = 0x
>> X6   = 0x0001 X23  = 0x
>> X7   = 0x X24  = 0x10103140
>> X8   = 0x X25  = 0x
>> X9   = 0xff80ffc8 X26  = 0x
>> X10  = 0x X27  = 0x
>> X11  = 0x1010ca78 X28  = 0x
>> X12  = 0x0001 FP   = 0x1010cc30
>> X13  = 0x1fe00050 LR   = 0x10001f94
>> X14  = 0x SP   = 0x1010cc30
>> X15  = 0x0004 PC   = 0x100125c0
>> X16  = 0x1000f700 DAIF = 0x03c0
>> VEC  = 0x0004 CPSR = 0x6005
>> ESR  = EC: 0b100101 IL: 0b1 ISS: 0b00111
>>     Data Abort taken without a change in Exception level
>> FAR  = 0x1fe000c0
>> FPCR = 0x FPSR = 0x0010
>>
>> The Versal (A72) fails in exactly the same way. The allocated address is
>> 0x1fe00050 and the FAR is 0x1fe000c0 so I am not sure if the "0xc0 - 0x50"
>> section is aligning the pointer to a larger word size for better performance 
>> and
>> that first part is OK but the different word size breaks.
> 
> I'm running with a toolchain that was built with
> --targetcflags="-DPREFER_SIZE_OVER_SPEED" which affects the content of the
> memset function, so my memset is just loops of writes and seems to work fine.

Oh. Maybe the eng manual needs a piece on this. Using flags on tool chains like
this is fine for a user because it is use at your own peril however I believe
patches need to be tested with the defaults for all tools. It is way to hard to
baseline a BSP if tweaks are needed here and there.

> Just out of curiousity, what instruction was at that PC address? If it was "dc
> zva", then I had seen this a while back during initial AArch64 bringup and had
> assumed it was fixed since the addition of the MMU code since that instruction
> doesn't work on device memory.

It this that instruction ...

100125c0:   d50b7423dc  zva, x3

Looks like it is not fixed.

> It looks like bsp_section_nocacheheap sits inside bsp_section_nocachenoload
> which is mapped as device memory which wouldn't play nicely with the "dc zva"
> instruction.
Cache coherent memory is mapped as device memory. The descriptors are mapped
into it so checks of bits and updates are effected by caches.

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

Re: [PATCH] testsuite/spcache01: Clear allocated coherent cache memory

[Chris Johns]

On 18/10/21 8:37 pm, Sebastian Huber wrote:
> On 18/10/2021 09:53, Chris Johns wrote:
>> On 18/10/21 4:50 pm, Sebastian Huber wrote:
>>> On 18/10/2021 07:19,chr...@rtems.org  wrote:
>>>> From: Chris Johns
>>>>
>>>> - Coherent cache memory is used in libbsd for things like descriptors
>>>>     and it optionally clears the memory on allocation. Test is works.
>>> There is no guarantee that memset() and memcpy() work with cache coherent
>>> memory. Such memory areas may disallow misaligned access for example.
>> That seems reasonable however this change about testing the implicit
>> requirements we have that memset works. LibBSD requires memset works ...
>>
>> https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/rtems/rtems-kernel-bus-dma.c?h=6-freebsd-12#n260
>>
> 
> Using memset() here could be a bug in libbsd.

Yes, I also think so.

But what is a suitable mechanism to make sure the arch or BSP handle it
correctly? Maybe a clear routine in libbsd using the bus space API? That
interface has to work or the drivers will not work.

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

Re: [PATCH] testsuite/spcache01: Clear allocated coherent cache memory

[Chris Johns]

On 18/10/21 4:50 pm, Sebastian Huber wrote:
> On 18/10/2021 07:19, chr...@rtems.org wrote:
>> From: Chris Johns
>>
>> - Coherent cache memory is used in libbsd for things like descriptors
>>    and it optionally clears the memory on allocation. Test is works.
> 
> There is no guarantee that memset() and memcpy() work with cache coherent
> memory. Such memory areas may disallow misaligned access for example.

That seems reasonable however this change about testing the implicit
requirements we have that memset works. LibBSD requires memset works ...

https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/rtems/rtems-kernel-bus-dma.c?h=6-freebsd-12#n260

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

ZynqMP and Versal crash clearing coherent cache memory with memset

[Chris Johns]

Hi,

I cannot run libbsd on real hardware because the cadence rx descriptor cache
coherent allocation crashes in `memset`. It is used to clear the memory.

The rtemsbsd allocator call optionally clears the memory and it seems the newlib
aarch64 memset code crashes when doing this. A basic loop with 8bit or 32bit
writes does not crash. The memset call happily clears an array in cached memory
with different offsets.

I have posted a patch to spcache01 that generates the crash on Versal and ZynqMP
hardware. The crash dump is:

test cache coherent allocation
clear cache coherent with memset: 0x1fe00050


*** FATAL ***
fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)


X0   = 0x1fe00050 X17  = 0x000c
X1   = 0x X18  = 0x17b0
X2   = 0x0110 X19  = 0x1fe00050
X3   = 0x1fe000c0 X20  = 0x1fdfff80
X4   = 0x1fe00250 X21  = 0x10013ab0
X5   = 0x0004 X22  = 0x
X6   = 0x0001 X23  = 0x
X7   = 0x X24  = 0x10103140
X8   = 0x X25  = 0x
X9   = 0xff80ffc8 X26  = 0x
X10  = 0x X27  = 0x
X11  = 0x1010ca78 X28  = 0x
X12  = 0x0001 FP   = 0x1010cc30
X13  = 0x1fe00050 LR   = 0x10001f94
X14  = 0x SP   = 0x1010cc30
X15  = 0x0004 PC   = 0x100125c0
X16  = 0x1000f700 DAIF = 0x03c0
VEC  = 0x0004 CPSR = 0x6005
ESR  = EC: 0b100101 IL: 0b1 ISS: 0b00111
   Data Abort taken without a change in Exception level
FAR  = 0x1fe000c0
FPCR = 0x FPSR = 0x0010

The Versal (A72) fails in exactly the same way. The allocated address is
0x1fe00050 and the FAR is 0x1fe000c0 so I am not sure if the "0xc0 - 0x50"
section is aligning the pointer to a larger word size for better performance and
that first part is OK but the different word size breaks.

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

Re: [rtems-tools commit] tester/exe: Adjust timeouts by the step size

[Chris Johns]

On 16/10/21 1:14 am, Sebastian Huber wrote:
> On 15/10/2021 08:26, Chris Johns wrote:
>> On 15/10/21 5:15 pm, Sebastian Huber wrote:
>>> On 22/09/2021 00:59, Chris Johns wrote:
>>>> Module:    rtems-tools
>>>> Branch:    master
>>>> Commit:    cfd5aa41e847752cd98cde65515df7ce45ff9665
>>>> Changeset:http://git.rtems.org/rtems-tools/commit/?id=cfd5aa41e847752cd98cde65515df7ce45ff9665
>>>>
>>>>
>>>>
>>>> Author:    Chris Johns
>>>> Date:  Mon Sep 20 21:32:24 2021 -1000
>>>>
>>>> tester/exe: Adjust timeouts by the step size
>>> With this change I get a timeout
>> Looking at the change I made I think it should be `/` and not `*`?
>>
>> Does that work?
>>
>> I normal need a `*` because the `step` is a number and not a fraction which
>> Python uses.
> 
> Changing '*' to '/' fixed the timeout issue,

Thanks. The change is OK to push. If you would like me to push it please let me
know.

> but I have no idea what this code is supposed to do.

It monitors the test and generates a timeout test failure.s There are two layers
of timeout, one for output and the other for a test running too long.

The test needs to generate some output within the first timeout period and the
second timeout detects if the test has run too long. The first timeout detects a
target has locked up. The second is for a test looping generating output.

With exe type tests the output is buffered in a separate thread.

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

Re: [rtems-tools commit] tester/exe: Adjust timeouts by the step size

[Chris Johns]

On 15/10/21 5:15 pm, Sebastian Huber wrote:
> On 22/09/2021 00:59, Chris Johns wrote:
>> Module:    rtems-tools
>> Branch:    master
>> Commit:    cfd5aa41e847752cd98cde65515df7ce45ff9665
>> Changeset:http://git.rtems.org/rtems-tools/commit/?id=cfd5aa41e847752cd98cde65515df7ce45ff9665
>>
>>
>> Author:    Chris Johns
>> Date:  Mon Sep 20 21:32:24 2021 -1000
>>
>> tester/exe: Adjust timeouts by the step size
> 
> With this change I get a timeout

Looking at the change I made I think it should be `/` and not `*`?

Does that work?

I normal need a `*` because the `step` is a number and not a fraction which
Python uses.

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

Re: [rtems-tools commit] tester/exe: Adjust timeouts by the step size

[Chris Johns]

On 15/10/21 5:15 pm, Sebastian Huber wrote:
> On 22/09/2021 00:59, Chris Johns wrote:
>> Module:    rtems-tools
>> Branch:    master
>> Commit:    cfd5aa41e847752cd98cde65515df7ce45ff9665
>> Changeset:http://git.rtems.org/rtems-tools/commit/?id=cfd5aa41e847752cd98cde65515df7ce45ff9665
>>
>>
>> Author:    Chris Johns
>> Date:  Mon Sep 20 21:32:24 2021 -1000
>>
>> tester/exe: Adjust timeouts by the step size
> 
> With this change I get a timeout:
> 
> rtems-test --rtems-bsp=leon3-sis --jobs=48 --report-format=yaml
> --report-path=report build/sparc/gr712rc/testsuites/smptests/
> 
> Passed:    60
> Failed: 0
> User Input: 0
> Expected Fail:  0
> Indeterminate:  0
> Benchmark:  0
> Timeout:    0
> Test too long:  0
> Invalid:    0
> Wrong Version:  0
> Wrong Build:    0
> Wrong Tools:    0
> Wrong Header:   0
> -
> Total: 60
> 
> Average test time: 0:00:01.004370
> Testing time : 0:01:00.262202
> 
> vs.

Verses what?

> 
> Passed:    58
> Failed: 0
> User Input: 0
> Expected Fail:  0
> Indeterminate:  0
> Benchmark:  0
> Timeout:    2
> Test too long:  0
> Invalid:    0
> Wrong Version:  0
> Wrong Build:    0
> Wrong Tools:    0
> Wrong Header:   0
> -
> Total: 60
> Timeouts:
>  smpmigration02.exe
>  smpmrsp01.exe
> Average test time: 0:00:00.842749
> Testing time : 0:00:50.564911
> 

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