Re: [PATCH 01/34] validation: Test sparc/leon3 BSP family

[Chris Johns]

On 14/6/2023 1:02 am, Sebastian Huber wrote:
> On 02.06.23 02:57, Chris Johns wrote:
>> [ resending ... ]
>>
>> On 1/6/2023 3:28 am, Sebastian Huber wrote:
>>> On 31.05.23 19:25, Joel Sherrill wrote:
>>>> On Wed, May 31, 2023 at 12:18 PM Sebastian Huber
>>>> >>> <mailto:sebastian.hu...@embedded-brains.de>> wrote:
>>>>
>>>>  On 31.05.23 19:14, Joel Sherrill wrote:
>>>>   > This patch has a couple of issues.
>>>>   >
>>>>   > (1) It includes modifications to arm files which doesn't seem
>>>>  consistent.
>>>>
>>>>  Sorry, these are
>>>>
>>>>  -- Copyright (C) 2020-2023 embedded brains GmbH
>>>>  (http://www.embedded-brains.de <http://www.embedded-brains.de>)
>>>>  +- Copyright (C) 2020-2023 embedded brains GmbH & Co. KG
>>>>
>>>>  changes added by accident. I will fix this separately.
>>>>
>>>>   >
>>>>   > (2) It adds BSP specific tests. There has been on discussion of
>>>>  how BSP
>>>>   > specific
>>>>   > tests should be included in the tree. We have some in this
>>>>  category and
>>>>   > I am pretty
>>>>   > sure Chris has some as well. We need to have a consistent
>>>>  approach to
>>>>   > where they
>>>>   > go.
>>>>
>>>>  Yes, this is why I mentioned this in the cover letter.
>>>>
>>>>  The new build system can handle BSP-specific tests quite easily.
>>>>
>>>>
>>>> I didn't argue that. Do we have a discussed and agreed upon location and
>>>> organization for these tests?
>>>
>>> No, this is why I mentioned this in the cover letter.
>>>
>>
>> There is currently 295 files in testsuites/validation without these new 
>> ones. Is
>> there an limit on the number of files we put here? Are all the files 
>> generated?
> 
> All files are generated, except the ones matching tx-*.

OK

>> I think adding hardware tests to testsuites/validation is starting to pull 
>> the
>> validation string a bit far. I suggest somewhere else specific to bsps, a bsp
>> family or arch. The level could reflect how the drivers and tests may be 
>> shared.
>> I guess grlib will end up in leon and riscv flavours.
> 
> I like Gedares suggestion.

Great

>> There appears to be a naming convention in use in the validation directory 
>> but I
>> could not see if this is explained?
> 
> I will add something to
> 
> https://docs.rtems.org/branches/master/eng/req/howto.html

Thanks

>> A leon of any type is a tier 2 device and with no published hardware test
>> results I have no idea about any of this code and we have no means to show
>> otherwise. 
> 
> Test results are available in the QDPs:
> 
> https://rtems-qual.io.esa.int/

"Access denied"

The GSoC project active this year will scrap the build list emails and in time
generate the tier results so posting something to that list is the best way to
handle this.

>> I have no specific objection to the changes and I think the change to
>> use store and load functions is a good move but the use of a struct member to
>> generate the address makes the change seem half done. Is there a validation 
>> test
>> with the register offsets as constants that checks the register offsets in 
>> the
>> reg structs are valid?
> 
> There are no validation tests for this. They could be generated, however, I 
> see
> no need for this. The structure layout is clearly defined by the ABI.

You are more trusting the compiler is right than me. I would have thought
showing it is doing the right thing is what validation tests are for?

I should point out adding offsets as values anywhere kind of removes the need
for a struct. :) The function interface you are adding could accept them
directly. Offsets are humanly verifiable and not effected by the compiler.

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

Re: style question: breaking inline assembly lines

[Chris Johns]

On 14/6/2023 10:20 am, Joel Sherrill wrote:
> 
> 
> On Tue, Jun 13, 2023, 4:43 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
> On 14/6/2023 5:47 am, Joel Sherrill wrote:
> >
> >
> > On Tue, Jun 13, 2023 at 9:51 AM Sebastian Huber
> >  <mailto:sebastian.hu...@embedded-brains.de>
> <mailto:sebastian.hu...@embedded-brains.de
> <mailto:sebastian.hu...@embedded-brains.de>>>
> > wrote:
> >
> >     On 13.06.23 00:04, Gedare Bloom wrote:
> >     >       "b _ARM_Exception_default\n"
> >     >       :
> >     > -    : [cpufsz] "i" (sizeof(CPU_Exception_frame)),
> >     > -      [cpuspoff] "i" (offsetof(CPU_Exception_frame, 
> register_sp)),
> >     > -      [v7mlroff] "i" (offsetof(ARMV7M_Exception_frame, 
> register_lr)),
> >     > -      [cpuvecoff] "J" (offsetof(CPU_Exception_frame, vector)),
> >     > -      [cpuvfpoff] "i" (ARM_EXCEPTION_FRAME_VFP_CONTEXT_OFFSET),
> >     > -      [cpacr] "i" (ARMV7M_CPACR),
> >     > -      [vfpsz] "i" (ARM_VFP_CONTEXT_SIZE)
> >     > +    : [cpufsz] "i"( sizeof( CPU_Exception_frame ) ),
> >
> >     If we place operators (e.g. &&, ||, ...) at the end of a broken 
> line,
> >     then we should do this for the : as well.
> >
> >
> > OK.
> >  
> >
> >
> >     My current preference would be to format all non-third-party sources
> >     with a standard clang-format selection. I guess in the long run, 
> this
> >     will be the easiest approach to maintain. If we use exotic options, 
> then
> >     we may up ending as clang-format maintainers.
> >
> >
> > I think this is the thing we have to keep in mind and I even said I 
> would
> > go along with compromises when we started. Get as close as you can
> > and we will have to accept that -- for now. We should definitely file 
> tickets 
> > with clang-format and ourselves to track things we don't like. If we 
> get an 
> > option in the future whether we or someone else implements it, we can 
> > use it and reformat again. Those hopefully are not that invasive.
> 
> Sounds like a plan.
> 
> I am a little concerned about the version of clang-format I need as some
> machines I work on are no at current OS versions.
> 
> 
> I am finding myself experimenting with it for a customer's C++ project. So 
> far,
> I have not matched the style. But I am now on Rocky 9 since I built it from
> source and needed cmake 3 at least. So you can't be on an old distribution and
> build from source.

I use clang-format on a couple projects with something close the standard
format. It works well.

> And Doxygen has and three different major versions between RHEL 7, 8, and 9.
> Using a configuration file from one on another seems to give you warnings 
> about
> unknown options or obsolete options. 
> 
> Mixing new and old systems is a pain.

It is but we have to for reasons specific to local sites.

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

Re: style question: breaking inline assembly lines

[Chris Johns]

On 14/6/2023 5:47 am, Joel Sherrill wrote:
> 
> 
> On Tue, Jun 13, 2023 at 9:51 AM Sebastian Huber
>  >
> wrote:
> 
> On 13.06.23 00:04, Gedare Bloom wrote:
> >       "b _ARM_Exception_default\n"
> >       :
> > -    : [cpufsz] "i" (sizeof(CPU_Exception_frame)),
> > -      [cpuspoff] "i" (offsetof(CPU_Exception_frame, register_sp)),
> > -      [v7mlroff] "i" (offsetof(ARMV7M_Exception_frame, register_lr)),
> > -      [cpuvecoff] "J" (offsetof(CPU_Exception_frame, vector)),
> > -      [cpuvfpoff] "i" (ARM_EXCEPTION_FRAME_VFP_CONTEXT_OFFSET),
> > -      [cpacr] "i" (ARMV7M_CPACR),
> > -      [vfpsz] "i" (ARM_VFP_CONTEXT_SIZE)
> > +    : [cpufsz] "i"( sizeof( CPU_Exception_frame ) ),
> 
> If we place operators (e.g. &&, ||, ...) at the end of a broken line,
> then we should do this for the : as well.
> 
> 
> OK.
>  
> 
> 
> My current preference would be to format all non-third-party sources
> with a standard clang-format selection. I guess in the long run, this
> will be the easiest approach to maintain. If we use exotic options, then
> we may up ending as clang-format maintainers.
> 
> 
> I think this is the thing we have to keep in mind and I even said I would
> go along with compromises when we started. Get as close as you can
> and we will have to accept that -- for now. We should definitely file tickets 
> with clang-format and ourselves to track things we don't like. If we get an 
> option in the future whether we or someone else implements it, we can 
> use it and reformat again. Those hopefully are not that invasive.

Sounds like a plan.

I am a little concerned about the version of clang-format I need as some
machines I work on are no at current OS versions.

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

Re: [PATCH] testsuites/flashdev01: Use correct page_size type

[Chris Johns]

OK

Thanks
Chris

On 10/6/2023 2:15 am, Kinsey Moore wrote:
> The page size ioctl requires an int pointer to retrieve the page size.
> The test currently uses a size_t which mostly works fine for systems
> where size_t and int are the same size, but can leave junk data in the
> upper bits when they differ in size causing an assert in the test to
> fail in some cases. This updates the variable to the correct type.
> ---
>  testsuites/libtests/flashdev01/init.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/testsuites/libtests/flashdev01/init.c 
> b/testsuites/libtests/flashdev01/init.c
> index 8896ad796c..6ce9709496 100644
> --- a/testsuites/libtests/flashdev01/init.c
> +++ b/testsuites/libtests/flashdev01/init.c
> @@ -57,7 +57,7 @@ static void run_test(void) {
>rtems_flashdev_ioctl_page_info pg_info;
>rtems_flashdev_region region;
>uint32_t jedec;
> -  size_t page_count;
> +  int page_count;
>int type;
>size_t wb_size;
>  
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] score: Remove CPU port atomic operations API

[Chris Johns]

On 31/5/2023 5:53 pm, Sebastian Huber wrote:
> On 26.05.23 07:19, Sebastian Huber wrote:
>> Use the C/C++ standard API directly.
> 
> Any comments to this patch set?
> 

Not from me. I think cleaning up the files is a good.

A very minor point ... should the documentation's recommendation in the SMP
section be change to say the atomic operations are provided by the C/C++
standard interfaces directly?

Chris


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

Re: [PATCH 01/34] validation: Test sparc/leon3 BSP family

[Chris Johns]

On 1/6/2023 3:28 am, Sebastian Huber wrote:
> On 31.05.23 19:25, Joel Sherrill wrote:
>> On Wed, May 31, 2023 at 12:18 PM Sebastian Huber
>> > > wrote:
>>
>>     On 31.05.23 19:14, Joel Sherrill wrote:
>>  > This patch has a couple of issues.
>>  >
>>  > (1) It includes modifications to arm files which doesn't seem
>>     consistent.
>>
>>     Sorry, these are
>>
>>     -- Copyright (C) 2020-2023 embedded brains GmbH
>>     (http://www.embedded-brains.de )
>>     +- Copyright (C) 2020-2023 embedded brains GmbH & Co. KG
>>
>>     changes added by accident. I will fix this separately.
>>
>>  >
>>  > (2) It adds BSP specific tests. There has been on discussion of
>>     how BSP
>>  > specific
>>  > tests should be included in the tree. We have some in this
>>     category and
>>  > I am pretty
>>  > sure Chris has some as well. We need to have a consistent
>>     approach to
>>  > where they
>>  > go.
>>
>>     Yes, this is why I mentioned this in the cover letter.
>>
>>     The new build system can handle BSP-specific tests quite easily.
>>
>>
>> I didn't argue that. Do we have a discussed and agreed upon location and
>> organization for these tests?
> 
> No, this is why I mentioned this in the cover letter.
> 

There is currently 295 files in testsuites/validation without these new ones. Is
there an limit on the number of files we put here? Are all the files generated?

I think adding hardware tests to testsuites/validation is starting to pull the
validation string a bit far. I suggest somewhere else specific to bsps, a bsp
family or arch. The level could reflect how the drivers and tests may be shared.
I guess grlib will end up in leon and riscv flavours.

There appears to be a naming convention in use in the validation directory but I
could not see if this is explained?

A leon of any type is a tier 2 device and with no published hardware test
results I have no idea about any of this code and we have no means to show
otherwise. I have no specific objection to the changes and I think the change to
use store and load functions is a good move but the use of a struct member to
generate the address makes the change seem half done. Is there a validation test
with the register offsets as constants that checks the register offsets in the
reg structs are valid?

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

Re: [PATCH 10/34] bsp/leon3: Move and simplify bsp_irq_fixup()

[Chris Johns]

On 1/6/2023 2:30 am, Sebastian Huber wrote:
> ---
>  bsps/sparc/leon3/clock/ckinit.c |  4 ++--
>  bsps/sparc/leon3/include/bsp/irq.h  |  1 -
>  bsps/sparc/leon3/include/bsp/leon3.h| 31 +
>  bsps/sparc/leon3/include/leon.h | 18 --
>  bsps/sparc/leon3/start/eirq.c   |  8 ++-
>  bsps/sparc/shared/irq/bsp_isr_handler.c |  4 
>  bsps/sparc/shared/irq/irq-shared.c  |  4 
>  7 files changed, 43 insertions(+), 27 deletions(-)
> 
> diff --git a/bsps/sparc/leon3/clock/ckinit.c b/bsps/sparc/leon3/clock/ckinit.c
> index b66ac793fc..2ec701fe2a 100644
> --- a/bsps/sparc/leon3/clock/ckinit.c
> +++ b/bsps/sparc/leon3/clock/ckinit.c
> @@ -40,9 +40,9 @@
>   */
>  
>  #include 
> -#include 
> -#include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/bsps/sparc/leon3/include/bsp/irq.h 
> b/bsps/sparc/leon3/include/bsp/irq.h
> index a7054030e2..ef0f6245f9 100644
> --- a/bsps/sparc/leon3/include/bsp/irq.h
> +++ b/bsps/sparc/leon3/include/bsp/irq.h
> @@ -37,7 +37,6 @@
>  #ifndef LIBBSP_LEON3_IRQ_CONFIG_H
>  #define LIBBSP_LEON3_IRQ_CONFIG_H
>  
> -#include 
>  #include 
>  
>  #define BSP_INTERRUPT_VECTOR_MAX_STD 15 /* Standard IRQ controller */
> diff --git a/bsps/sparc/leon3/include/bsp/leon3.h 
> b/bsps/sparc/leon3/include/bsp/leon3.h
> index c0105e02f0..05915a7dea 100644
> --- a/bsps/sparc/leon3/include/bsp/leon3.h
> +++ b/bsps/sparc/leon3/include/bsp/leon3.h
> @@ -66,6 +66,14 @@ extern volatile struct irqmp_regs *LEON3_IrqCtrl_Regs;
>   */
>  extern struct ambapp_dev *LEON3_IrqCtrl_Adev;
>  
> +/**
> + * @brief This object provides the interrupt number used to multiplex 
> extended
> + *   interrupts or is zero if no extended interrupts are available.
> + *
> + * This object should be read-only after initialization.
> + */
> +extern uint32_t LEON3_IrqCtrl_EIrq;
> +
>  /**
>   * @brief Initializes the interrupt controller for the boot processor.
>   *
> @@ -73,6 +81,29 @@ extern struct ambapp_dev *LEON3_IrqCtrl_Adev;
>   */
>  void leon3_ext_irq_init( volatile struct irqmp_regs *regs );
>  
> +/**
> + * @brief Acknowledges and maps extended interrupts if this feature is
> + * available and the interrupt for extended interrupts is present.
> + *
> + * @param irq is the standard interrupt number.
> + */
> +static inline uint32_t bsp_irq_fixup( uint32_t irq )
> +{
> +  uint32_t eirq;
> +
> +  if ( irq != LEON3_IrqCtrl_EIrq ) {
> +return irq;
> +  }
> +
> +  eirq = LEON3_IrqCtrl_Regs->intid[ _LEON3_Get_current_processor() ] & 0x1f;
> +
> +  if ( eirq < 16 ) {
> +return irq;
> +  }
> +
> +  return eirq;
> +}
> +
>  /** @} */
>  
>  #ifdef __cplusplus
> diff --git a/bsps/sparc/leon3/include/leon.h b/bsps/sparc/leon3/include/leon.h
> index 0623eaa4ff..82e93ddb41 100644
> --- a/bsps/sparc/leon3/include/leon.h
> +++ b/bsps/sparc/leon3/include/leon.h
> @@ -154,24 +154,6 @@ extern struct ambapp_dev *LEON3_Timer_Adev;
>  /* LEON3 CPU Index of boot CPU */
>  extern uint32_t LEON3_Cpu_Index;
>  
> -/* The external IRQ number, -1 if not external interrupts */
> -extern int LEON3_IrqCtrl_EIrq;
> -
> -static __inline__ int bsp_irq_fixup(int irq)
> -{
> -  int eirq, cpu;
> -
> -  if (LEON3_IrqCtrl_EIrq != 0 && irq == LEON3_IrqCtrl_EIrq) {
> -/* Get interrupt number from IRQ controller */
> -cpu = _LEON3_Get_current_processor();
> -eirq = LEON3_IrqCtrl_Regs->intid[cpu] & 0x1f;
> -if (eirq & 0x10)
> -  irq = eirq;
> -  }
> -
> -  return irq;
> -}
> -
>  /* Macros used for manipulating bits in LEON3 GP Timer Control Register */
>  
>  #define LEON3_IRQMPSTATUS_CPUNR 28
> diff --git a/bsps/sparc/leon3/start/eirq.c b/bsps/sparc/leon3/start/eirq.c
> index 0371cfe98f..d9c5402dd0 100644
> --- a/bsps/sparc/leon3/start/eirq.c
> +++ b/bsps/sparc/leon3/start/eirq.c
> @@ -36,7 +36,7 @@
>  #include 
>  
>  /* GRLIB extended IRQ controller IRQ number */
> -int LEON3_IrqCtrl_EIrq = -1;
> +uint32_t LEON3_IrqCtrl_EIrq;
>  
>  rtems_interrupt_lock LEON3_IrqCtrl_Lock =
>RTEMS_INTERRUPT_LOCK_INITIALIZER("LEON3 IrqCtrl");
> @@ -47,11 +47,7 @@ void leon3_ext_irq_init(volatile struct irqmp_regs *regs)
>regs->mask[LEON3_Cpu_Index] = 0;
>regs->force[LEON3_Cpu_Index] = 0;
>regs->iclear = 0x;
> -
> -  if ( (regs->mpstat >> 16) & 0xf ) {
> -/* Extended IRQ controller available */
> -LEON3_IrqCtrl_EIrq = (regs->mpstat >> 16) & 0xf;
> -  }
> +  LEON3_IrqCtrl_EIrq = (regs->mpstat >> 16) & 0xf;
>  }
>  
>  bool bsp_interrupt_is_valid_vector(rtems_vector_number vector)
> diff --git a/bsps/sparc/shared/irq/bsp_isr_handler.c 
> b/bsps/sparc/shared/irq/bsp_isr_handler.c
> index cf2800cd85..22d168cdb6 100644
> --- a/bsps/sparc/shared/irq/bsp_isr_handler.c
> +++ b/bsps/sparc/shared/irq/bsp_isr_handler.c
> @@ -30,6 +30,10 @@
>  #include 
>  #include 
>  
> +#ifdef LEON3
> +#include 
> +#endif

Why not have the bsp.h for the leon3 include this?

> +
>  /*
>   * This function is called 

Re: [PATCH 01/34] validation: Test sparc/leon3 BSP family

[Chris Johns]

[ resending ... ]

On 1/6/2023 3:28 am, Sebastian Huber wrote:
> On 31.05.23 19:25, Joel Sherrill wrote:
>> On Wed, May 31, 2023 at 12:18 PM Sebastian Huber
>> > > wrote:
>>
>>     On 31.05.23 19:14, Joel Sherrill wrote:
>>  > This patch has a couple of issues.
>>  >
>>  > (1) It includes modifications to arm files which doesn't seem
>>     consistent.
>>
>>     Sorry, these are
>>
>>     -- Copyright (C) 2020-2023 embedded brains GmbH
>>     (http://www.embedded-brains.de )
>>     +- Copyright (C) 2020-2023 embedded brains GmbH & Co. KG
>>
>>     changes added by accident. I will fix this separately.
>>
>>  >
>>  > (2) It adds BSP specific tests. There has been on discussion of
>>     how BSP
>>  > specific
>>  > tests should be included in the tree. We have some in this
>>     category and
>>  > I am pretty
>>  > sure Chris has some as well. We need to have a consistent
>>     approach to
>>  > where they
>>  > go.
>>
>>     Yes, this is why I mentioned this in the cover letter.
>>
>>     The new build system can handle BSP-specific tests quite easily.
>>
>>
>> I didn't argue that. Do we have a discussed and agreed upon location and
>> organization for these tests?
> 
> No, this is why I mentioned this in the cover letter.
> 

There is currently 295 files in testsuites/validation without these new ones. Is
there an limit on the number of files we put here? Are all the files generated?

I think adding hardware tests to testsuites/validation is starting to pull the
validation string a bit far. I suggest somewhere else specific to bsps, a bsp
family or arch. The level could reflect how the drivers and tests may be shared.
I guess grlib will end up in leon and riscv flavours.

There appears to be a naming convention in use in the validation directory but I
could not see if this is explained?

A leon of any type is a tier 2 device and with no published hardware test
results I have no idea about any of this code and we have no means to show
otherwise. I have no specific objection to the changes and I think the change to
use store and load functions is a good move but the use of a struct member to
generate the address makes the change seem half done. Is there a validation test
with the register offsets as constants that checks the register offsets in the
reg structs are valid?

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

Re: [PATCHv2 rtems_waf] Allow vendor field in toolchain target triplet

[Chris Johns]

On 27/5/2023 2:03 am, martinerikwerner@gmail.com wrote:

On Fri, 2023-05-26 at 08:33 +1000, Chris Johns wrote:

On 25/5/2023 6:53 pm, martinerikwerner@gmail.com wrote:

While poking around some more, it seems like there's more places in
this file where assumptions of no vendor in the triplet might come
into
play (but did not affect my use of it), if I'm reading it
correctly?:

227 conf.env.ARCH_BSP = '%s/%s' % (arch.split('-')[0], bsp)

232 conf.env.RTEMS_ARCH = arch.split('-')[0]

554 return _arch_from_arch_bsp(arch_bsp).split('-')[0]

931 ab = arch_bsp.split('-')
(...)
939 flagstr = subprocess.check_output(
940 [config, '--bsp',
941  '%s/%s' % (ab[0], ab[2]), flags_map[flags]])

I'm also a bit uncertain, what is the "arch" actually supposed to
be in
general, given that the _arch_from_arch_bsp(arch_bsp) and
arch(arch_bsp) seem to disagree (former include the os (rtems)
field,
latter excludes it).


I suspect the uncertainly is due to things evolving and me not paying
close
enough attention because it did not matter. The vendor field changes
that. I
will take a look and see if I can clean it up.

What is the full text for the `arch_bsp` you are working with so I
can test it?


waf gives the following if I instrument the rtems.py code:

   arch_bsp: sparc-gaisler-rtems5-leon3

This is based on a minimal application with the rtems_waf submodule
(c721249+instrumentation) and pointing at a downloaded rcc-1.3.1-gcc
toolchain and bsp:

   ./waf configure --rtems=$HOME/binary/rcc-1.3.1-gcc 
--rtems-bsps=sparc-gaisler/leon3


Thanks

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

Re: [PATCH] score: Unify

[Chris Johns]

On 26/5/2023 1:38 pm, Andy wrote:
> 
> If you need my reply, I am ok to switch to BSD-2-Clause license. 
> 

Thank you and thank you for letting us know. :)

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

Re: [PATCH] score: Unify

[Chris Johns]

On 25/5/2023 3:54 pm, Sebastian Huber wrote:
> On 25.05.23 03:40, Kinsey Moore wrote:> Is there any reason this isn't just
> being moved to a shared directory if
>> they're all being made identical?
> 
> Initially, they were all identical. We already have a shared implementation
> 
> https://git.rtems.org/rtems/tree/cpukit/include/rtems/score/cpustdatomic.h
> 
> The CPU port specific  allows a custom implementation
> if needed. I would keep this ability.
> 

Why not just add the file back if it is needed when it is needed and then remove
it once it is not?

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

Re: [PATCHv2 rtems_waf] Allow vendor field in toolchain target triplet

[Chris Johns]

On 25/5/2023 6:53 pm, martinerikwerner@gmail.com wrote:
> While poking around some more, it seems like there's more places in
> this file where assumptions of no vendor in the triplet might come into
> play (but did not affect my use of it), if I'm reading it correctly?:
> 
> 227 conf.env.ARCH_BSP = '%s/%s' % (arch.split('-')[0], bsp)
> 
> 232 conf.env.RTEMS_ARCH = arch.split('-')[0]
> 
> 554 return _arch_from_arch_bsp(arch_bsp).split('-')[0]
> 
> 931 ab = arch_bsp.split('-')
> (...)
> 939 flagstr = subprocess.check_output(
> 940 [config, '--bsp',
> 941  '%s/%s' % (ab[0], ab[2]), flags_map[flags]])
> 
> I'm also a bit uncertain, what is the "arch" actually supposed to be in
> general, given that the _arch_from_arch_bsp(arch_bsp) and
> arch(arch_bsp) seem to disagree (former include the os (rtems) field,
> latter excludes it).

I suspect the uncertainly is due to things evolving and me not paying close
enough attention because it did not matter. The vendor field changes that. I
will take a look and see if I can clean it up.

What is the full text for the `arch_bsp` you are working with so I can test it?

> I'm not sure I am aware of all places where this is used as a
> submodule, my only testing has been as part of a custom user
> application...

Oh nice to hear. I will look through the repos we have and look at updating 
them.

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

Re: [PATCH] score: Unify

[Chris Johns]

On 25/5/2023 3:51 pm, Sebastian Huber wrote:
> 
> 
> On 25.05.23 02:11, Chris Johns wrote:
>> On 24/5/2023 11:00 pm, Sebastian Huber wrote:
>>> All CPU ports use the same file.
>>> ---
>>>   .../aarch64/include/rtems/score/cpuatomic.h   |  8 ++---
>>>   .../cpu/arm/include/rtems/score/cpuatomic.h   | 11 +-
>>>   .../cpu/bfin/include/rtems/score/cpuatomic.h  | 36 ---
>>>   .../cpu/i386/include/rtems/score/cpuatomic.h  | 11 +-
>>>   .../cpu/lm32/include/rtems/score/cpuatomic.h  | 36 ---
>>>   .../cpu/m68k/include/rtems/score/cpuatomic.h  | 11 +-
>>>   .../include/rtems/score/cpuatomic.h   |  7 ++--
>>>   .../cpu/mips/include/rtems/score/cpuatomic.h  | 11 +-
>>>   .../cpu/moxie/include/rtems/score/cpuatomic.h | 11 +-
>>>   .../cpu/nios2/include/rtems/score/cpuatomic.h | 11 +-
>>>   .../cpu/or1k/include/rtems/score/cpuatomic.h  | 11 +-
>>>   .../powerpc/include/rtems/score/cpuatomic.h   | 11 +-
>>>   .../cpu/riscv/include/rtems/score/cpuatomic.h | 33 +++--
>>>   .../cpu/sh/include/rtems/score/cpuatomic.h    | 36 ---
>>>   .../cpu/sparc/include/rtems/score/cpuatomic.h |  7 ++--
>>>   .../sparc64/include/rtems/score/cpuatomic.h   | 11 +-
>>>   .../cpu/v850/include/rtems/score/cpuatomic.h  | 11 +-
>>>   .../x86_64/include/rtems/score/cpuatomic.h    | 36 ---
>>>   18 files changed, 261 insertions(+), 48 deletions(-)
>>>
>>> diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
>>> b/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
>>> index ed8091d73c..772d496741 100644
>>> --- a/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
>>> +++ b/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
>>> @@ -3,14 +3,14 @@
>>>   /**
>>>    * @file
>>>    *
>>> - * @ingroup RTEMSScoreCPU
>>> + * @ingroup RTEMSScoreAtomicCPU
>>>    *
>>> - * @brief AArch64 Atomics support
>>> + * @brief This header file provides interfaces of the atomic operations
>>> + *   implementation using functions provided by the C11/C++11.
>>>    */
>>>     /*
>>> - * Copyright (C) 2020 On-Line Applications Research Corporation (OAR)
>>> - * Written by Kinsey Moore
>>> + * Copyright (C) 2012, 2013 Deng Hengyi
>> Is this change correct?
> 
> Yes, the file contains no copyrightable content from OAR. It hardly contains 
> any
> copyrightable content at all.

Thanks

>>>    *
>>>    * Redistribution and use in source and binary forms, with or without
>>>    * modification, are permitted provided that the following conditions
>>> diff --git a/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h
>>> b/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h
>>> index 01bb99cda3..772d496741 100644
>>> --- a/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h
>>> +++ b/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h
>>> @@ -1,7 +1,16 @@
>>>   /* SPDX-License-Identifier: BSD-2-Clause */
>>>   +/**
>>> + * @file
>>> + *
>>> + * @ingroup RTEMSScoreAtomicCPU
>>> + *
>>> + * @brief This header file provides interfaces of the atomic operations
>>> + *   implementation using functions provided by the C11/C++11.
>>> + */
>>> +
>>>   /*
>>> - * COPYRIGHT (c) 2012-2013 Deng Hengyi.
>>> + * Copyright (C) 2012, 2013 Deng Hengyi
>> Why are these lines changing? Can we edit this as the license clearly states 
>> it
>> must be retained as is?
> 
> We have a copyright line template:
> 
> https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#copyright-and-license-block
> 
> Independent of this, it seems we didn't have a permission from Deng Hengyi to
> switch to BSD-2-Clause license:
> 
> https://devel.rtems.org/ticket/3053
> 

Ah OK. I was not wanting to open any rabbit holes. I was just wanting to have
something listed.

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

Re: [PATCH 0/5] Minor ARM BSP Improvements

[Chris Johns]

These look good. Thanks

Chris

On 24/5/2023 11:05 pm, Sebastian Huber wrote:
> Sebastian Huber (5):
>   bsps/arm: Use interrupt entry for 
>   bsps/arm: Use interrupt entry for clock driver
>   bsps/arm: Use interrupt entry for IPI
>   arm/xilinx-zynq: Do not provide legacy API
>   arm/xilinx-zynq: Initialize debug console once
> 
>  bsps/arm/shared/clock/clock-a9mpcore.c   | 15 --
>  bsps/arm/shared/start/arm-a9mpcore-smp.c | 16 +++---
>  bsps/arm/xilinx-zynq/console/debug-console.c |  6 +++
>  bsps/arm/xilinx-zynq/include/bsp/irq.h   |  1 -
>  bsps/include/dev/irq/arm-gic-tm27.h  | 52 +---
>  5 files changed, 60 insertions(+), 30 deletions(-)
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Unify

[Chris Johns]

On 24/5/2023 11:00 pm, Sebastian Huber wrote:
> All CPU ports use the same file.
> ---
>  .../aarch64/include/rtems/score/cpuatomic.h   |  8 ++---
>  .../cpu/arm/include/rtems/score/cpuatomic.h   | 11 +-
>  .../cpu/bfin/include/rtems/score/cpuatomic.h  | 36 ---
>  .../cpu/i386/include/rtems/score/cpuatomic.h  | 11 +-
>  .../cpu/lm32/include/rtems/score/cpuatomic.h  | 36 ---
>  .../cpu/m68k/include/rtems/score/cpuatomic.h  | 11 +-
>  .../include/rtems/score/cpuatomic.h   |  7 ++--
>  .../cpu/mips/include/rtems/score/cpuatomic.h  | 11 +-
>  .../cpu/moxie/include/rtems/score/cpuatomic.h | 11 +-
>  .../cpu/nios2/include/rtems/score/cpuatomic.h | 11 +-
>  .../cpu/or1k/include/rtems/score/cpuatomic.h  | 11 +-
>  .../powerpc/include/rtems/score/cpuatomic.h   | 11 +-
>  .../cpu/riscv/include/rtems/score/cpuatomic.h | 33 +++--
>  .../cpu/sh/include/rtems/score/cpuatomic.h| 36 ---
>  .../cpu/sparc/include/rtems/score/cpuatomic.h |  7 ++--
>  .../sparc64/include/rtems/score/cpuatomic.h   | 11 +-
>  .../cpu/v850/include/rtems/score/cpuatomic.h  | 11 +-
>  .../x86_64/include/rtems/score/cpuatomic.h| 36 ---
>  18 files changed, 261 insertions(+), 48 deletions(-)
> 
> diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h 
> b/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
> index ed8091d73c..772d496741 100644
> --- a/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
> +++ b/cpukit/score/cpu/aarch64/include/rtems/score/cpuatomic.h
> @@ -3,14 +3,14 @@
>  /**
>   * @file
>   *
> - * @ingroup RTEMSScoreCPU
> + * @ingroup RTEMSScoreAtomicCPU
>   *
> - * @brief AArch64 Atomics support
> + * @brief This header file provides interfaces of the atomic operations
> + *   implementation using functions provided by the C11/C++11.
>   */
>  
>  /*
> - * Copyright (C) 2020 On-Line Applications Research Corporation (OAR)
> - * Written by Kinsey Moore 
> + * Copyright (C) 2012, 2013 Deng Hengyi

Is this change correct?

>   *
>   * Redistribution and use in source and binary forms, with or without
>   * modification, are permitted provided that the following conditions
> diff --git a/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h 
> b/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h
> index 01bb99cda3..772d496741 100644
> --- a/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h
> +++ b/cpukit/score/cpu/arm/include/rtems/score/cpuatomic.h
> @@ -1,7 +1,16 @@
>  /* SPDX-License-Identifier: BSD-2-Clause */
>  
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreAtomicCPU
> + *
> + * @brief This header file provides interfaces of the atomic operations
> + *   implementation using functions provided by the C11/C++11.
> + */
> +
>  /*
> - * COPYRIGHT (c) 2012-2013 Deng Hengyi.
> + * Copyright (C) 2012, 2013 Deng Hengyi

Why are these lines changing? Can we edit this as the license clearly states it
must be retained as is?

>   *
>   * Redistribution and use in source and binary forms, with or without
>   * modification, are permitted provided that the following conditions
> diff --git a/cpukit/score/cpu/bfin/include/rtems/score/cpuatomic.h 
> b/cpukit/score/cpu/bfin/include/rtems/score/cpuatomic.h
> index 598ee76b20..772d496741 100644
> --- a/cpukit/score/cpu/bfin/include/rtems/score/cpuatomic.h
> +++ b/cpukit/score/cpu/bfin/include/rtems/score/cpuatomic.h
> @@ -1,9 +1,37 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreAtomicCPU
> + *
> + * @brief This header file provides interfaces of the atomic operations
> + *   implementation using functions provided by the C11/C++11.
> + */
> +
>  /*
> - * COPYRIGHT (c) 2012-2013 Deng Hengyi.
> + * Copyright (C) 2012, 2013 Deng Hengyi
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
>   *
> - * The license and distribution terms for this file may be
> - * found in the file LICENSE in this distribution or at
> - * http://www.rtems.org/license/LICENSE.
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED 

Re: Discussion: How to handle HALs, SDKs and libraries

[Chris Johns]

On 24/5/2023 5:07 pm, Christian MAUDERER wrote:
> Hello Chris,
> 
> On 2023-05-24 03:44, Chris Johns wrote:
>> Hi Christian,
>>
>> Thanks for raising this topic. It is a tough one.
>>
>> On 24/5/2023 12:11 am, Kinsey Moore wrote:
>>> On Tue, May 23, 2023 at 2:26 AM Christian MAUDERER
>>> >> <mailto:christian.maude...@embedded-brains.de>> wrote:
>>>
>>>  Hello,
>>>
>>>  I recently updated the HAL in the i.MXRT BSP. I used the same approach
>>>  that we use for a lot of similar cases: Import the sources into RTEMS
>>>  and adapt them slightly so that they work for us. So basically a
>>>  Clone-and-Own approach.
>>>
>>>  During the discussion of the patches, some concerns were raised, 
>>> whether
>>>  we should find a better solution to handle HALs, SDKs and similar 
>>> cases.
>>>  We should start discussing a solution that can be used after the 6
>>>  release so that maybe someone can start to work on a prototype.
>>>
>>>  Some example cases are:
>>>
>>>  - the mcux_sdk in the imxrt BSP
>>>  - the hal in the stm32h7 BSP
>>>  - general ARM CMSIS files
>>>  - zlib
>>>  - libfdt
>>>
>>>  One solution could be to build these libraries external and only link
>>>  RTEMS with them. There are disadvantages to this aproach:
>>>
>>>  - Also in my experience, the API of the HALs / SDKs / libraries seems 
>>> to
>>>  be quite stable, it's possible that there are combinations where some
>>>  unexpected change breaks a driver or makes it impossible to link the
>>>  applications.
>>
>> Xilinx with the more complex devices like the Versal have been moving things
>> about. The Versal SMC call set is fluid and the PM (platform manager) seems 
>> to
>> functionally align to Xilinx tools releases plus Petalinux versions. For 
>> example
>> there are stable defined API calls in Versal Linux (XRT/zocl) that depends 
>> on PM
>> code that is commented in the code as "to be removed".
>>
>> When I first used the Zynq I used Xilinx's drivers like OAR is currently with
>> the Microblaze. I could not release the results because of the license at the
>> time. I quickly found the drivers lacked functionality for general use and 
>> broke
>> under high loads and boundary conditions. The fixes are part of a project and
>> cannot be released because the license at the time made it impossible. What I
>> leant from the exercise is to not depend on their drivers.
> 
> That sounds like a quite bad case. So it's a good example for that discussion.
> Thanks for bringing it up.

I view the repo as open but not open source ... if that sentence makes sense?

> 
>>
>> I feel what we considered stable will depend on the origin of the code and 
>> that
>> will be case by case.
> 
> Agreed.
> 
>>
>>>  - BSPs rely on basic drivers from these libraries (like console or 
>>> clock
>>>  driver). If we link against the libraries, the testsuite wouldn't build
>>>  any more without preinstalled libraries.
>>
>> Yes the mutual dependence if built externally and before RTEMS is not easy to
>> solve. The idea of the HAL code being supplied as .h and a .a does let a user
>> update the drivers without needing an RTEMS version update.
>>
>>>  Another solution could be to include libraties like that as submodules
>>>  and build them using the RTEMS build system. We could clone the repos
>>>  onto the RTEMS git server, and add necessary patches. Advantage would 
>>> be
>>>  that it is more similar to the process that we currently have. Another
>>>  advantage is that we have a known-working version of the files. 
>>> Upstream
>>>  updates could be either merged or we could rebase our patches to a new
>>>  version.
>>
>> See below for the problems this creates.
>>
>>>   From my point of view, the second option would be the better one
>>>  especially because we have a tested, fixed version of the library
>>>  instead telling the user to just use some random version that might or
>>>  might not work.
>>
>> This is important. We need to define what a release is and it is a 
>> requirement
>> we provide all code as tarball files. This implies the release process knows 
>> how
>> to create the ta

Re: [PATCH rtems-libbsd] ipsec-tools: Fix copying fd_set prior to select

[Chris Johns]

On 24/5/2023 11:42 pm, Christian MAUDERER wrote:
> On 2023-05-24 02:33, Chris Johns wrote:
>> On 24/5/2023 9:13 am, Chris Johns wrote:
>>> On 23/5/2023 5:30 pm, Christian MAUDERER wrote:
>>>> Hello Chris,
>>>>
>>>> On 2023-05-23 08:53, Chris Johns wrote:
>>>>> On 23/5/2023 4:25 pm, Christian MAUDERER wrote:
>>>>>> Hello Chris,
>>>>>>
>>>>>> On 2023-05-23 03:36, Chris Johns wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have been resolving this by adding:
>>>>>>>
>>>>>>> #define preset_mask *preset_mask_prealloc
>>>>>>> #define active_mask *active_mask_prealloc
>>>>>>>
>>>>>>> as the assignment logic works as is. It does not catch FD_ZERO which is 
>>>>>>> a
>>>>>>> shame
>>>>>>> but is helps avoid us adding a special case.
>>>>>>
>>>>>> Thanks for the suggestion. I used that solution already in the file 
>>>>>> during
>>>>>> the
>>>>>> initial port. But it doesn't work in this case (and maybe we should check
>>>>>> other
>>>>>> cases in libbsd too). It only copies the first element of the array of
>>>>>> fd_sets.
>>>>>>
>>>>>> The variables / defines are (in the patched version - see [1]):
>>>>>>
>>>>>> static fd_set *allocated_preset_mask, *allocated_active_mask;
>>>>>> static struct fd_monitor *allocated_fd_monitors;
>>>>>> #define preset_mask (*allocated_preset_mask)
>>>>>> #define active_mask (*allocated_active_mask)
>>>>>> #define fd_monitors (allocated_fd_monitors)
>>>>>>
>>>>>> They are allocated as follows (see [2]):
>>>>>>
>>>>>>   allocated_preset_mask = calloc(sizeof(fd_set),
>>>>>>   howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
>>>>>>   allocated_active_mask = calloc(sizeof(fd_set),
>>>>>>   howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
>>>>>>   allocated_fd_monitors = calloc(
>>>>>>   rtems_libio_number_iops, sizeof(struct fd_monitor));
>>>>>>
>>>>>> So basically it's a bunch of arrays of fd_sets. If I now use the 
>>>>>> following
>>>>>> (unpatched) assignment:
>>>>>>
>>>>>>   active_mask = preset_mask;
>>>>>>
>>>>>> After the preprocessor the line will be
>>>>>>
>>>>>>   (*allocated_active_mask) = (*allocated_preset_mask);
>>>>>>
>>>>>> Which copies only the first element. That's why I had to add the memcpy.
>>>>>> Did I
>>>>>> miss some better solution?
>>>>>
>>>>> I am using this in ntpd which I checked yesterday:
>>>>>
>>>>> #ifdef __rtems__
>>>>> #include 
>>>>> static size_t rtems_ntpd_fds_size;
>>>>> static int rtems_fd_set_alloc(fd_set **setp) {
>>>>>   if (*setp == NULL) {
>>>>>   rtems_ntpd_fds_size = sizeof(fd_set) *
>>>>> (howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
>>>>>   *setp = malloc(rtems_ntpd_fds_size);
>>>>>   if (*setp == NULL) {
>>>>>   errno = ENOMEM;
>>>>>   return -1;
>>>>>   }
>>>>>   memset(*setp, 0, rtems_ntpd_fds_size);
>>>>>   }
>>>>>   return 0;
>>>>> }
>>>>> #define activefds (*activefds_prealloc)
>>>>> static fd_set *activefds_prealloc;
>>>>> #define rtems_activefds_alloc() rtems_fd_set_alloc(_prealloc)
>>>>> #else /* __rtems__ */
>>>>> static fd_set activefds;
>>>>> #endif /* __rtems__ */
>>>>>
>>>>> and:
>>>>>
>>>>> #if __rtems__
>>>>>   #define rdfdes (*rdfdes_prealloc)
>>>>>   static fd_set *rdfdes_prealloc;
>>>>> #else /* __rtems__ */
>>>>>   fd_set rdfdes;
>>>>> #endif /* __

Re: [PATCHv2 rtems_waf] Allow vendor field in toolchain target triplet

[Chris Johns]

Looks good and thanks. I have pushed this.

If you would like to submit module update patches for the various repos using
rtems_waf please feel free to do so.

Chris

On 25/5/2023 4:13 am, Martin Erik Werner wrote:
> Rework the splitting of arch and bsp to rely on the last field in the
> arch section starting with "rtems", instead of relying on the arch being
> exactly two fields in size.
> 
> This makes sure that toolchains with a vendor field in their target
> triplet can be used with this build system.
> 
> Toolchains produced by the RTEMS source builder tend to omit the vendor
> field, but for example the SPARC LEON/ERC32 toolchain provided by
> Gaisler through the RCC package does include a vendor field.
> ---
> 
> v2 fixes an off-by-one error in list indexing compared to v1.
> 
>  rtems.py | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/rtems.py b/rtems.py
> index 0b24645..c65a7d2 100644
> --- a/rtems.py
> +++ b/rtems.py
> @@ -858,11 +858,15 @@ def _check_arch_bsps(req, config, path, archs, version):
>  
>  
>  def _arch_from_arch_bsp(arch_bsp):
> -return '-'.join(arch_bsp.split('-')[:2])
> +fields = arch_bsp.split('-')
> +rtems_field_index = next(i for i, field in enumerate(fields) if 
> field.startswith('rtems'))
> +return '-'.join(fields[:(rtems_field_index + 1)])
>  
>  
>  def _bsp_from_arch_bsp(arch_bsp):
> -return '-'.join(arch_bsp.split('-')[2:])
> +fields = arch_bsp.split('-')
> +rtems_field_index = next(i for i, field in enumerate(fields) if 
> field.startswith('rtems'))
> +return '-'.join(fields[(rtems_field_index + 1):])
>  
>  
>  def _pkgconfig_path(path):
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Discussion: How to handle HALs, SDKs and libraries

[Chris Johns]

Hi Christian,

Thanks for raising this topic. It is a tough one.

On 24/5/2023 12:11 am, Kinsey Moore wrote:
> On Tue, May 23, 2023 at 2:26 AM Christian MAUDERER
>  > wrote:
> 
> Hello,
> 
> I recently updated the HAL in the i.MXRT BSP. I used the same approach
> that we use for a lot of similar cases: Import the sources into RTEMS
> and adapt them slightly so that they work for us. So basically a
> Clone-and-Own approach.
> 
> During the discussion of the patches, some concerns were raised, whether
> we should find a better solution to handle HALs, SDKs and similar cases.
> We should start discussing a solution that can be used after the 6
> release so that maybe someone can start to work on a prototype.
> 
> Some example cases are:
> 
> - the mcux_sdk in the imxrt BSP
> - the hal in the stm32h7 BSP
> - general ARM CMSIS files
> - zlib
> - libfdt
> 
> One solution could be to build these libraries external and only link
> RTEMS with them. There are disadvantages to this aproach:
> 
> - Also in my experience, the API of the HALs / SDKs / libraries seems to
> be quite stable, it's possible that there are combinations where some
> unexpected change breaks a driver or makes it impossible to link the
> applications.

Xilinx with the more complex devices like the Versal have been moving things
about. The Versal SMC call set is fluid and the PM (platform manager) seems to
functionally align to Xilinx tools releases plus Petalinux versions. For example
there are stable defined API calls in Versal Linux (XRT/zocl) that depends on PM
code that is commented in the code as "to be removed".

When I first used the Zynq I used Xilinx's drivers like OAR is currently with
the Microblaze. I could not release the results because of the license at the
time. I quickly found the drivers lacked functionality for general use and broke
under high loads and boundary conditions. The fixes are part of a project and
cannot be released because the license at the time made it impossible. What I
leant from the exercise is to not depend on their drivers.

I feel what we considered stable will depend on the origin of the code and that
will be case by case.

> - BSPs rely on basic drivers from these libraries (like console or clock
> driver). If we link against the libraries, the testsuite wouldn't build
> any more without preinstalled libraries.

Yes the mutual dependence if built externally and before RTEMS is not easy to
solve. The idea of the HAL code being supplied as .h and a .a does let a user
update the drivers without needing an RTEMS version update.

> Another solution could be to include libraties like that as submodules
> and build them using the RTEMS build system. We could clone the repos
> onto the RTEMS git server, and add necessary patches. Advantage would be
> that it is more similar to the process that we currently have. Another
> advantage is that we have a known-working version of the files. Upstream
> updates could be either merged or we could rebase our patches to a new
> version.

See below for the problems this creates.

>  From my point of view, the second option would be the better one
> especially because we have a tested, fixed version of the library
> instead telling the user to just use some random version that might or
> might not work.

This is important. We need to define what a release is and it is a requirement
we provide all code as tarball files. This implies the release process knows how
to create the tarfiles.

> Regardless which aproach we use: We have to think about how to handle
> that on releases. In the link aproach (first case), we have to somehow
> archive source tar balls and some kind of build recipe. In the submodule
> aproach, we could checkout all submodules and pack the files into the
> RTEMS release tar ball. So I would expect that the second aproach has
> less impact here too.
> 
> Comments? Improvements? Better suggestions?
> 
> I would definitely prefer the submodule approach over the linking approach to
> avoid the test issues since some of these HALs bring core functionality. The
> Xilinx driver framework (embeddedsw repo on Github) would be well-suited to 
> the
> submodule approach since it is already broken out into the shared driver space
> because it can apply to at least 3 architectures (ARM, AArch64, MicroBlaze).

I suggest you avoid making that repo a submodule of anything. The code in that
repo is "over the wall" and there is no continuity. I have it as a submodule in
my XRT repo and a Xilinx push of the next release of tools broke the code. What
I had depended on was removed and moved somewhere else. The Xilinx updates are
based on the release cycle of their tools and they do not respond to issues or
PRs. They are free to make what ever changes they like and 

Re: [PATCH rtems-libbsd] ipsec-tools: Fix copying fd_set prior to select

[Chris Johns]

On 24/5/2023 9:13 am, Chris Johns wrote:
> On 23/5/2023 5:30 pm, Christian MAUDERER wrote:
>> Hello Chris,
>>
>> On 2023-05-23 08:53, Chris Johns wrote:
>>> On 23/5/2023 4:25 pm, Christian MAUDERER wrote:
>>>> Hello Chris,
>>>>
>>>> On 2023-05-23 03:36, Chris Johns wrote:
>>>>> Hi,
>>>>>
>>>>> I have been resolving this by adding:
>>>>>
>>>>> #define preset_mask *preset_mask_prealloc
>>>>> #define active_mask *active_mask_prealloc
>>>>>
>>>>> as the assignment logic works as is. It does not catch FD_ZERO which is a 
>>>>> shame
>>>>> but is helps avoid us adding a special case.
>>>>
>>>> Thanks for the suggestion. I used that solution already in the file during 
>>>> the
>>>> initial port. But it doesn't work in this case (and maybe we should check 
>>>> other
>>>> cases in libbsd too). It only copies the first element of the array of 
>>>> fd_sets.
>>>>
>>>> The variables / defines are (in the patched version - see [1]):
>>>>
>>>> static fd_set *allocated_preset_mask, *allocated_active_mask;
>>>> static struct fd_monitor *allocated_fd_monitors;
>>>> #define preset_mask (*allocated_preset_mask)
>>>> #define active_mask (*allocated_active_mask)
>>>> #define fd_monitors (allocated_fd_monitors)
>>>>
>>>> They are allocated as follows (see [2]):
>>>>
>>>>  allocated_preset_mask = calloc(sizeof(fd_set),
>>>>  howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
>>>>  allocated_active_mask = calloc(sizeof(fd_set),
>>>>  howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
>>>>  allocated_fd_monitors = calloc(
>>>>  rtems_libio_number_iops, sizeof(struct fd_monitor));
>>>>
>>>> So basically it's a bunch of arrays of fd_sets. If I now use the following
>>>> (unpatched) assignment:
>>>>
>>>>  active_mask = preset_mask;
>>>>
>>>> After the preprocessor the line will be
>>>>
>>>>  (*allocated_active_mask) = (*allocated_preset_mask);
>>>>
>>>> Which copies only the first element. That's why I had to add the memcpy. 
>>>> Did I
>>>> miss some better solution?
>>>
>>> I am using this in ntpd which I checked yesterday:
>>>
>>> #ifdef __rtems__
>>> #include 
>>> static size_t rtems_ntpd_fds_size;
>>> static int rtems_fd_set_alloc(fd_set **setp) {
>>>  if (*setp == NULL) {
>>>  rtems_ntpd_fds_size = sizeof(fd_set) *
>>> (howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
>>>  *setp = malloc(rtems_ntpd_fds_size);
>>>  if (*setp == NULL) {
>>>  errno = ENOMEM;
>>>  return -1;
>>>  }
>>>  memset(*setp, 0, rtems_ntpd_fds_size);
>>>  }
>>>  return 0;
>>> }
>>> #define activefds (*activefds_prealloc)
>>> static fd_set *activefds_prealloc;
>>> #define rtems_activefds_alloc() rtems_fd_set_alloc(_prealloc)
>>> #else /* __rtems__ */
>>> static fd_set activefds;
>>> #endif /* __rtems__ */
>>>
>>> and:
>>>
>>> #if __rtems__
>>>  #define rdfdes (*rdfdes_prealloc)
>>>  static fd_set *rdfdes_prealloc;
>>> #else /* __rtems__ */
>>>  fd_set rdfdes;
>>> #endif /* __rtems__ */
>>>  int nfound;
>>>
>>> #if __rtems__
>>>  if (rtems_fd_set_alloc(_prealloc) < 0) {
>>>  return;
>>>  }
>>>  memset(rdfdes_prealloc, 0, rtems_ntpd_fds_size);
>>> #else /* __rtems__ */
>>>  FD_ZERO();
>>> #endif /* __rtems__ */
>>>
>>> with:
>>>
>>>  ++handler_calls;
>>>  rdfdes = activefds;
>>
>> But isn't that line resolving to
>>
>>   (*rdfdes_prealloc) = (*activefds_prealloc);
>>
>> That would also copy only the first element.
>>
>>>
>>> Stepping:
>>>
>>> Thread 9 hit Breakpoint 1, _ntp_io_handler () at
>>> ../../bsd/freebsd/contrib/ntp/ntpd/ntp_io.c:3727
>>> 3727    rdfdes = activefds;
>>> (gdb) x /8bx activefds_prealloc
>>> 0x1083e650: 0x20    0x44    0x05    0x20    0x00    0x40    0x00    0x00
>>> (gdb) x /8bx rdfdes_prealloc
>>> 0x108353a0: 0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
>>> (gdb) n
>>> 3736    t1.tv_usec = 0;
>>> (gdb) x /8bx rdfdes_prealloc
>>> 0x108353a0: 0x20    0x44    0x05    0x20    0x00    0x40    0x00    0x00
>>>
>>> Looks ok to me.
>>
>> fd_set is 64 bit wide. So a copy of the first 64 bit works. Does it still 
>> work
>> if you have 256 files in the system?
> 
> Good question. I have not checked but I will.
> 
> FYI EPICS has set its limit to 64 because of this issue with select. I suspect
> they do not want to hack their select calls like this and I understand them
> taking that position.

Yes, I see the issue. The equate only works if the file ops count is the same as
the newlib defined fd_set.

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

Re: [PATCH rtems-libbsd] ipsec-tools: Fix copying fd_set prior to select

[Chris Johns]

On 23/5/2023 5:30 pm, Christian MAUDERER wrote:
> Hello Chris,
> 
> On 2023-05-23 08:53, Chris Johns wrote:
>> On 23/5/2023 4:25 pm, Christian MAUDERER wrote:
>>> Hello Chris,
>>>
>>> On 2023-05-23 03:36, Chris Johns wrote:
>>>> Hi,
>>>>
>>>> I have been resolving this by adding:
>>>>
>>>> #define preset_mask *preset_mask_prealloc
>>>> #define active_mask *active_mask_prealloc
>>>>
>>>> as the assignment logic works as is. It does not catch FD_ZERO which is a 
>>>> shame
>>>> but is helps avoid us adding a special case.
>>>
>>> Thanks for the suggestion. I used that solution already in the file during 
>>> the
>>> initial port. But it doesn't work in this case (and maybe we should check 
>>> other
>>> cases in libbsd too). It only copies the first element of the array of 
>>> fd_sets.
>>>
>>> The variables / defines are (in the patched version - see [1]):
>>>
>>> static fd_set *allocated_preset_mask, *allocated_active_mask;
>>> static struct fd_monitor *allocated_fd_monitors;
>>> #define preset_mask (*allocated_preset_mask)
>>> #define active_mask (*allocated_active_mask)
>>> #define fd_monitors (allocated_fd_monitors)
>>>
>>> They are allocated as follows (see [2]):
>>>
>>>  allocated_preset_mask = calloc(sizeof(fd_set),
>>>  howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
>>>  allocated_active_mask = calloc(sizeof(fd_set),
>>>  howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
>>>  allocated_fd_monitors = calloc(
>>>  rtems_libio_number_iops, sizeof(struct fd_monitor));
>>>
>>> So basically it's a bunch of arrays of fd_sets. If I now use the following
>>> (unpatched) assignment:
>>>
>>>  active_mask = preset_mask;
>>>
>>> After the preprocessor the line will be
>>>
>>>  (*allocated_active_mask) = (*allocated_preset_mask);
>>>
>>> Which copies only the first element. That's why I had to add the memcpy. 
>>> Did I
>>> miss some better solution?
>>
>> I am using this in ntpd which I checked yesterday:
>>
>> #ifdef __rtems__
>> #include 
>> static size_t rtems_ntpd_fds_size;
>> static int rtems_fd_set_alloc(fd_set **setp) {
>>  if (*setp == NULL) {
>>  rtems_ntpd_fds_size = sizeof(fd_set) *
>> (howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
>>  *setp = malloc(rtems_ntpd_fds_size);
>>  if (*setp == NULL) {
>>  errno = ENOMEM;
>>  return -1;
>>  }
>>  memset(*setp, 0, rtems_ntpd_fds_size);
>>  }
>>  return 0;
>> }
>> #define activefds (*activefds_prealloc)
>> static fd_set *activefds_prealloc;
>> #define rtems_activefds_alloc() rtems_fd_set_alloc(_prealloc)
>> #else /* __rtems__ */
>> static fd_set activefds;
>> #endif /* __rtems__ */
>>
>> and:
>>
>> #if __rtems__
>>  #define rdfdes (*rdfdes_prealloc)
>>  static fd_set *rdfdes_prealloc;
>> #else /* __rtems__ */
>>  fd_set rdfdes;
>> #endif /* __rtems__ */
>>  int nfound;
>>
>> #if __rtems__
>>  if (rtems_fd_set_alloc(_prealloc) < 0) {
>>  return;
>>  }
>>  memset(rdfdes_prealloc, 0, rtems_ntpd_fds_size);
>> #else /* __rtems__ */
>>  FD_ZERO();
>> #endif /* __rtems__ */
>>
>> with:
>>
>>  ++handler_calls;
>>  rdfdes = activefds;
> 
> But isn't that line resolving to
> 
>   (*rdfdes_prealloc) = (*activefds_prealloc);
> 
> That would also copy only the first element.
> 
>>
>> Stepping:
>>
>> Thread 9 hit Breakpoint 1, _ntp_io_handler () at
>> ../../bsd/freebsd/contrib/ntp/ntpd/ntp_io.c:3727
>> 3727    rdfdes = activefds;
>> (gdb) x /8bx activefds_prealloc
>> 0x1083e650: 0x20    0x44    0x05    0x20    0x00    0x40    0x00    0x00
>> (gdb) x /8bx rdfdes_prealloc
>> 0x108353a0: 0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
>> (gdb) n
>> 3736    t1.tv_usec = 0;
>> (gdb) x /8bx rdfdes_prealloc
>> 0x108353a0: 0x20    0x44    0x05    0x20    0x00    0x40    0x00    0x00
>>
>> Looks ok to me.
> 
> fd_set is 64 bit wide. So a copy of the first 64 bit works. Does it still work
> if you have 256 files in the system?

Good question. I have not checked but I will.

FYI EPICS has set its limit to 64 because of this issue with select. I suspect
they do not want to hack their select calls like this and I understand them
taking that position.

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

Re: [PATCH rtems-libbsd] ipsec-tools: Fix copying fd_set prior to select

[Chris Johns]

On 23/5/2023 4:25 pm, Christian MAUDERER wrote:
> Hello Chris,
> 
> On 2023-05-23 03:36, Chris Johns wrote:
>> Hi,
>>
>> I have been resolving this by adding:
>>
>> #define preset_mask *preset_mask_prealloc
>> #define active_mask *active_mask_prealloc
>>
>> as the assignment logic works as is. It does not catch FD_ZERO which is a 
>> shame
>> but is helps avoid us adding a special case.
> 
> Thanks for the suggestion. I used that solution already in the file during the
> initial port. But it doesn't work in this case (and maybe we should check 
> other
> cases in libbsd too). It only copies the first element of the array of 
> fd_sets.
> 
> The variables / defines are (in the patched version - see [1]):
> 
> static fd_set *allocated_preset_mask, *allocated_active_mask;
> static struct fd_monitor *allocated_fd_monitors;
> #define preset_mask (*allocated_preset_mask)
> #define active_mask (*allocated_active_mask)
> #define fd_monitors (allocated_fd_monitors)
> 
> They are allocated as follows (see [2]):
> 
> allocated_preset_mask = calloc(sizeof(fd_set),
>     howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
> allocated_active_mask = calloc(sizeof(fd_set),
>     howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
> allocated_fd_monitors = calloc(
>     rtems_libio_number_iops, sizeof(struct fd_monitor));
> 
> So basically it's a bunch of arrays of fd_sets. If I now use the following
> (unpatched) assignment:
> 
> active_mask = preset_mask;
> 
> After the preprocessor the line will be
> 
> (*allocated_active_mask) = (*allocated_preset_mask);
> 
> Which copies only the first element. That's why I had to add the memcpy. Did I
> miss some better solution?

I am using this in ntpd which I checked yesterday:

#ifdef __rtems__
#include 
static size_t rtems_ntpd_fds_size;
static int rtems_fd_set_alloc(fd_set **setp) {
if (*setp == NULL) {
rtems_ntpd_fds_size = sizeof(fd_set) *
(howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
*setp = malloc(rtems_ntpd_fds_size);
if (*setp == NULL) {
errno = ENOMEM;
return -1;
}
memset(*setp, 0, rtems_ntpd_fds_size);
}
return 0;
}
#define activefds (*activefds_prealloc)
static fd_set *activefds_prealloc;
#define rtems_activefds_alloc() rtems_fd_set_alloc(_prealloc)
#else /* __rtems__ */
static fd_set activefds;
#endif /* __rtems__ */

and:

#if __rtems__
#define rdfdes (*rdfdes_prealloc)
static fd_set *rdfdes_prealloc;
#else /* __rtems__ */
fd_set rdfdes;
#endif /* __rtems__ */
int nfound;

#if __rtems__
if (rtems_fd_set_alloc(_prealloc) < 0) {
return;
}
memset(rdfdes_prealloc, 0, rtems_ntpd_fds_size);
#else /* __rtems__ */
FD_ZERO();
#endif /* __rtems__ */

with:

++handler_calls;
rdfdes = activefds;

Stepping:

Thread 9 hit Breakpoint 1, _ntp_io_handler () at
../../bsd/freebsd/contrib/ntp/ntpd/ntp_io.c:3727
3727rdfdes = activefds;
(gdb) x /8bx activefds_prealloc
0x1083e650: 0x200x440x050x200x000x400x000x00
(gdb) x /8bx rdfdes_prealloc
0x108353a0: 0x000x000x000x000x000x000x000x00
(gdb) n
3736t1.tv_usec = 0;
(gdb) x /8bx rdfdes_prealloc
0x108353a0: 0x200x440x050x200x000x400x000x00

Looks ok to me.

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

Re: [PATCH rtems-libbsd] ipsec-tools: Fix copying fd_set prior to select

[Chris Johns]

Hi,

I have been resolving this by adding:

#define preset_mask *preset_mask_prealloc
#define active_mask *active_mask_prealloc

as the assignment logic works as is. It does not catch FD_ZERO which is a shame
but is helps avoid us adding a special case.

Chris

On 22/5/2023 5:36 pm, Christian Mauderer wrote:
> The racoon session code copies an fd_set from one variable into another
> prior to calling select. That works well for simple structures.
> 
> In libbsd we have to allocate fd_sets instead of using fixed structures
> to avoid a problem with file numbers bigger than FD_SETSIZE. The simple
> assignment didn't work in that case.
> 
> This patch makes sure that a memcpy is used instead.
> ---
>  ipsec-tools/src/racoon/session.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/ipsec-tools/src/racoon/session.c 
> b/ipsec-tools/src/racoon/session.c
> index 7ea857ba..bd2bd316 100644
> --- a/ipsec-tools/src/racoon/session.c
> +++ b/ipsec-tools/src/racoon/session.c
> @@ -215,6 +215,8 @@ session(void)
>  #ifndef __rtems__
>   FD_ZERO(_mask);
>  #else /* __rtems__ */
> + size_t allocated_mask_size = sizeof(fd_set) *
> + howmany(rtems_libio_number_iops, sizeof(fd_set) * 8);
>   allocated_preset_mask = calloc(sizeof(fd_set),
>   howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
>   if (allocated_preset_mask == NULL)
> @@ -352,7 +354,12 @@ session(void)
>  
>   /* schedular can change select() mask, so we reset
>* the working copy here */
> +#ifndef __rtems__
>   active_mask = preset_mask;
> +#else /* __rtems__ */
> + memcpy(allocated_active_mask, allocated_preset_mask,
> + allocated_mask_size);
> +#endif /* __rtems__ */
>  
>   error = select(nfds + 1, _mask, NULL, NULL, timeout);
>   if (error < 0) {
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/5] build: Use CSafeLoader if available

[Chris Johns]

On 22/5/2023 6:29 pm, Sebastian Huber wrote:
> On 22.05.23 01:48, Chris Johns wrote:
>>> The support for the CSafeLoader is just about 60 lines of additional code.
>>> It would be a nice improvement for systems supporting this feature. I don't 
>>> have
>>> time to work on adding PyYAML with libyaml to the RTEMS Tools right now and 
>>> I
>>> think this would open another maintenance issues. If someone would be 
>>> unable to
>>> get a yaml module with a CSafeLoader, then he would be no longer able to 
>>> build
>>> RTEMS.
>> It is not about the size of the implementation, it is about making 2 classes 
>> of
>> performance, those with and those without csafe. I am a firm believer all
>> developers and especially core developers need to be using the exact same 
>> tools
>> and code our community users are using. We did not always do this and it
>> resulted in the developers being disconnected from the user experience and I
>> decided I would do what I could to avoid this happening again.
> 
> I really don't see the issue here. It is just the way to load the items from 
> the
> file system. This is a very isolated task in the build and having two ways to 
> do
> this is not a big deal from my point of view.

Great, lets not go down this path and we all use the same process.

>> In regards to PyYAML there are a few basic issues with it that I am not sure
>> about. The package can be built without support for the C library even if it 
>> is
>> installed. I cannot tell if a pip installed version is using the C YAML 
>> package
>> or not. I would like more certainty across our supported hosts before 
>> agreeing
>> to us using it.
> 
> I think it is just too complicated to make sure that the user has a PyYAML 
> with
> the CSafeLoader available when RTEMS is built. A more robust approach is a 
> fall
> back to the current implementation if needed.

Maybe we move away from YAML for the build system data? Amar and I originally
had python and INI files.

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

Re: [PATCH 2/5] build: Use CSafeLoader if available

[Chris Johns]

On 19/5/2023 4:46 pm, Sebastian Huber wrote:
> On 15.05.23 01:44, Chris Johns wrote:
>> On 5/5/2023 8:16 pm, Sebastian Huber wrote:
>>> On 05.05.23 01:38, Chris Johns wrote:
>>>>> When I install it
>>>>> through pip, I get the CSafeLoader on my machine. I don't have a libyaml
>>>>> development package installed.
>>>> This is what I was not understanding. If it can be loaded in a python.org
>>>> install on a N2 MacOS with a virtual env then I think we are close to a
>>>> resolution.
>>> I tried to understand how the PyYAML package is built. It seems that 
>>> libyaml and
>>> its header files need to be installed to use the C bindings.
>> This is what I thought happened with this package. It depends on the base OS
>> packaging system. The documentation at
>> https://pyyaml.org/wiki/PyYAMLDocumentation  says:
>>
>>   $ python setup.py install
>>
>>   If you want to use LibYAML bindings, which are much faster than the pure
>>   Python version, you need to download and install LibYAML. Then you may
>>   build and install the bindings by executing
>>
>>   $ python setup.py --with-libyaml install
>>
>> I cannot see if pip has any further detail on the nature of the build it
>> contains so this is not looking good. This leaves building and installing 
>> when
>> the tools are built by the RSB.
> 
> The current approach with the pickle cache works reasonably fine and requires
> not extra packages. I don't think this implementation should be removed in any
> case. 

Agreed.

> The support for the CSafeLoader is just about 60 lines of additional code.
> It would be a nice improvement for systems supporting this feature. I don't 
> have
> time to work on adding PyYAML with libyaml to the RTEMS Tools right now and I
> think this would open another maintenance issues. If someone would be unable 
> to
> get a yaml module with a CSafeLoader, then he would be no longer able to build
> RTEMS.

It is not about the size of the implementation, it is about making 2 classes of
performance, those with and those without csafe. I am a firm believer all
developers and especially core developers need to be using the exact same tools
and code our community users are using. We did not always do this and it
resulted in the developers being disconnected from the user experience and I
decided I would do what I could to avoid this happening again.

In regards to PyYAML there are a few basic issues with it that I am not sure
about. The package can be built without support for the C library even if it is
installed. I cannot tell if a pip installed version is using the C YAML package
or not. I would like more certainty across our supported hosts before agreeing
to us using it.

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

Re: [PATCH rtems-source-builder] rtems-gcc-*-newlib-head.cfg: Update to include true long double math

[Chris Johns]

OK

Thanks
Chris

On 20/5/2023 12:54 am, Joel Sherrill wrote:
> Previously newlib only had long double math functions when the
> sizeof(double) was equal to sizeof(long double). Newlib now includes
> support for true long double on x86, x86_64, and aarch64.
> 
> These files were not included in the previous commit.
> ---
>  rtems/config/tools/rtems-gcc-10-newlib-head.cfg   | 4 ++--
>  rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg | 4 ++--
>  rtems/config/tools/rtems-gcc-head-newlib-head.cfg | 4 ++--
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> index a06bfe9..39b97a5 100644
> --- a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
> @@ -17,12 +17,12 @@
>  %patch add newlib -p1 
> https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
>  %hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch 
> 7ca237eabfd5b382713186e1fc290dfc999a353315795ecb8dd0d22fcd1ab7f5bf31f4329954adab91ad04c100dcac0e86d406fdbce8f82cf9dc23842c88caf6
>  
> -%define newlib_version c3798a2
> +%define newlib_version 9ae9eef
>  %define newlib_external 1
>  %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
>  %hash sha512 newlib-%{newlib_version}.tar.gz \
> -  
> 8qSfmZdAuDUgRX8WFyuMDGgEf+6CPbfo6bxOsBgrPHR++9QzunlFhMEnc1bV46pnCZUmcCWTXPH/+A7TSN4n4A==
> +  
> fV58RABHBBWQudHD0a/B0FLN75Uoy0NiieV1q/83OcP61p484DT2oLp41MlLcVMw8YOXxG+gfJ9KcRlw87A4GQ==
>  
>  %define with_threads 1
>  %define with_plugin 0
> diff --git a/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> index b83abeb..84b5223 100644
> --- a/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
> @@ -20,12 +20,12 @@
>  %patch add newlib -p1 
> https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
>  %hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch 
> 7ca237eabfd5b382713186e1fc290dfc999a353315795ecb8dd0d22fcd1ab7f5bf31f4329954adab91ad04c100dcac0e86d406fdbce8f82cf9dc23842c88caf6
>  
> -%define newlib_version c3798a2
> +%define newlib_version 9ae9eef
>  %define newlib_external 1
>  %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
>  %hash sha512 newlib-%{newlib_version}.tar.gz \
> -  
> 8qSfmZdAuDUgRX8WFyuMDGgEf+6CPbfo6bxOsBgrPHR++9QzunlFhMEnc1bV46pnCZUmcCWTXPH/+A7TSN4n4A==
> +  
> fV58RABHBBWQudHD0a/B0FLN75Uoy0NiieV1q/83OcP61p484DT2oLp41MlLcVMw8YOXxG+gfJ9KcRlw87A4GQ==
>  
>  %define with_threads 1
>  %define with_plugin 0
> diff --git a/rtems/config/tools/rtems-gcc-head-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
> index d98fe88..d39a0b5 100644
> --- a/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
> @@ -8,12 +8,12 @@
>  %hash sha512 %{gcc_expand_name}.tar.gz \
>
> E5KKObrZDIF1nEAFmZ6zGstL/VAPGCR+FIkCVW3akyTmAPITsmlaNErGHESHjG8PRmCO8zkCHkjkAv6MaHsWvQ==
>  
> -%define newlib_version c3798a2
> +%define newlib_version 9ae9eef
>  %define newlib_external 1
>  %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
>  %hash sha512 newlib-%{newlib_version}.tar.gz \
> -  
> 8qSfmZdAuDUgRX8WFyuMDGgEf+6CPbfo6bxOsBgrPHR++9QzunlFhMEnc1bV46pnCZUmcCWTXPH/+A7TSN4n4A==
> +  
> fV58RABHBBWQudHD0a/B0FLN75Uoy0NiieV1q/83OcP61p484DT2oLp41MlLcVMw8YOXxG+gfJ9KcRlw87A4GQ==
>  
>  %patch add newlib -p1 
> https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
>  %hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch 
> 7ca237eabfd5b382713186e1fc290dfc999a353315795ecb8dd0d22fcd1ab7f5bf31f4329954adab91ad04c100dcac0e86d406fdbce8f82cf9dc23842c88caf6
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] libdl: Add support for LDST128_ABS_LO12_NC

[Chris Johns]

OK

Chris

On 20/5/2023 5:16 am, Kinsey Moore wrote:
> ---
>  cpukit/libdl/rtl-mdreloc-aarch64.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/cpukit/libdl/rtl-mdreloc-aarch64.c 
> b/cpukit/libdl/rtl-mdreloc-aarch64.c
> index 25057ce9d7..46f87e9178 100644
> --- a/cpukit/libdl/rtl-mdreloc-aarch64.c
> +++ b/cpukit/libdl/rtl-mdreloc-aarch64.c
> @@ -329,6 +329,7 @@ rtems_rtl_elf_reloc_rela (rtems_rtl_obj*obj,
>  case R_AARCH_LDST16_ABS_LO12_NC:
>  case R_AARCH_LDST32_ABS_LO12_NC:
>  case R_AARCH_LDST64_ABS_LO12_NC:
> +case R_AARCH64_LDST128_ABS_LO12_NC:
>switch (ELF_R_TYPE(rela->r_info)) {
>  case R_AARCH64_ADD_ABS_LO12_NC:
>  case R_AARCH64_LDST8_ABS_LO12_NC:
> @@ -343,6 +344,9 @@ rtems_rtl_elf_reloc_rela (rtems_rtl_obj*obj,
>  case R_AARCH_LDST64_ABS_LO12_NC:
>shift = 3;
>break;
> +case R_AARCH64_LDST128_ABS_LO12_NC:
> +  shift = 4;
> +  break;
>  default:
>printf("illegal rtype: %" PRIu64 "\n", ELF_R_TYPE(rela->r_info));
>break;
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/2] bsps/microblaze: GPIO improvements

[Chris Johns]

OK. This is a great change to see and a good direction for the Microblaze to 
take.

Thanks
Chris

On 19/5/2023 1:46 pm, Alex White wrote:
> Hi,
> 
> This patch set removes the build system options for the GPIO driver and adds
> device tree support. The build system options were removed because they are 
> now
> supplied by the application or pulled from the device tree. This removes a lot
> of clutter and makes the driver more flexible.
> 
> Alex
> 
> Alex White (2):
>   bsps/microblaze: Remove GPIO build system options
>   bsps/microblaze: Add device tree support to GPIO
> 
>  .../microblaze_fpga/gpio/microblaze-gpio.c| 93 ---
>  .../include/bsp/microblaze-gpio.h | 26 --
>  .../bsps/microblaze/microblaze_fpga/grp.yml   | 18 
>  .../microblaze_fpga/optgpio1baseaddress.yml   | 19 
>  .../microblaze_fpga/optgpio1dualchannel.yml   | 16 
>  .../microblaze_fpga/optgpio1interrupt.yml | 16 
>  .../microblaze_fpga/optgpio1irq.yml   | 18 
>  .../microblaze_fpga/optgpio2baseaddress.yml   | 19 
>  .../microblaze_fpga/optgpio2dualchannel.yml   | 16 
>  .../microblaze_fpga/optgpio2enable.yml| 17 
>  .../microblaze_fpga/optgpio2interrupt.yml | 16 
>  .../microblaze_fpga/optgpio2irq.yml   | 18 
>  12 files changed, 79 insertions(+), 213 deletions(-)
>  delete mode 100644 
> spec/build/bsps/microblaze/microblaze_fpga/optgpio1baseaddress.yml
>  delete mode 100644 
> spec/build/bsps/microblaze/microblaze_fpga/optgpio1dualchannel.yml
>  delete mode 100644 
> spec/build/bsps/microblaze/microblaze_fpga/optgpio1interrupt.yml
>  delete mode 100644 spec/build/bsps/microblaze/microblaze_fpga/optgpio1irq.yml
>  delete mode 100644 
> spec/build/bsps/microblaze/microblaze_fpga/optgpio2baseaddress.yml
>  delete mode 100644 
> spec/build/bsps/microblaze/microblaze_fpga/optgpio2dualchannel.yml
>  delete mode 100644 
> spec/build/bsps/microblaze/microblaze_fpga/optgpio2enable.yml
>  delete mode 100644 
> spec/build/bsps/microblaze/microblaze_fpga/optgpio2interrupt.yml
>  delete mode 100644 spec/build/bsps/microblaze/microblaze_fpga/optgpio2irq.yml
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-source-builder] rtems-gcc-12-newlib-head.cfg: Update to include true long double math

[Chris Johns]

OK. Well done on the long doubles work.

Chris

On 18/5/2023 7:13 am, Joel Sherrill wrote:
> Previously newlib only had long double math functions when the
> sizeof(double) was equal to sizeof(long double). Newlib now includes
> support for true long double on x86, x86_64, and aarch64.
> ---
>  rtems/config/tools/rtems-gcc-12-newlib-head.cfg | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> index 16d075f..f4c47d4 100644
> --- a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> @@ -38,13 +38,13 @@
>  
> KEmxHjYOqY4LTXCMZ3I60tbHusbR5GlnP0CLARHPAnhCnovDj9K3U43C1bsMxDDGRqD6fwtrEFoEgqVFX63IuQ==
>  # Comment above related to #4657 and patches ends here
>  
> -%define newlib_version c3798a2
> +%define newlib_version 9ae9eef
>  %define newlib_external 1
>  %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz \
> 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
>  %hash sha512 newlib-%{newlib_version}.tar.gz \
> -  
> 8qSfmZdAuDUgRX8WFyuMDGgEf+6CPbfo6bxOsBgrPHR++9QzunlFhMEnc1bV46pnCZUmcCWTXPH/+A7TSN4n4A==
> +  
> fV58RABHBBWQudHD0a/B0FLN75Uoy0NiieV1q/83OcP61p484DT2oLp41MlLcVMw8YOXxG+gfJ9KcRlw87A4GQ==
>  
>  %define with_threads 1
>  %define with_plugin 0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems 00/12] bsp/imxrt: Update SDK and prepare for new variant

[Chris Johns]

On 15/5/2023 6:13 pm, o...@c-mauderer.de wrote:
> Hello Chris,
> 
> Am 15.05.23 um 05:18 schrieb Chris Johns:
>>
>>
>> On 6/5/2023 2:02 am, Gedare Bloom wrote:
>>> On Fri, May 5, 2023 at 9:02 AM  wrote:
>>>>
>>>> Hello Gedare,
>>>>
>>>> thanks for taking a look at the patch set.
>>>>
>>>> Am 05.05.23 um 15:56 schrieb Gedare Bloom:
>>>>> On Thu, May 4, 2023 at 9:01 AM Christian Mauderer
>>>>>  wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> this patch set for the arm/imxrt BSP family updates the SDK files to the
>>>>>> latest version of the mcux-sdk from NXP and prepares the BSP for further
>>>>>> chip variants. I plan to add a BSP that uses the IMXRT1166 soon.
>>>>>>
>>>>>> As a base for the mcux-sdk files, I now use the NXP git repository
>>>>>> instead of zip files that can be downloaded from NXP. I kept the exact
>>>>>> file system structure to make future updates simpler.
>>>>>>
>>>>>> To import the files, I used a script. It is not a clean script and it
>>>>>> was only tested on a Linux machine. Despite that, I added that script to
>>>>>> the BSP directory in case someone else ever wants to update the
>>>>>> mcux-sdk. Updating the SDK is also possible without the script. It's
>>>>>> just a lot more manual work. So if we don't want a script in that state
>>>>>> in the repository, I can also just keep it on a private branch.
>>>>>>
>>>>> I would recommend that you document the import/update process for the
>>>>> SDK in this BSP (or family) documentation. You could provide a stable
>>>>> external link to the script there instead of including it in the
>>>>> rtems.git tree. I'm not convinced that including scripts etc in the
>>>>> same tree as the source they manipulate is a great practice. It seems
>>>>> to violate separation of concerns.
>>>>
>>>> Disadvantage is that the script (and documentation) is a bit less simple
>>>> to find. But that's not a problem for me (I know where to search) so I
>>>> will adapt that.
>>>>
>>>> De we have an official preferred stable location? Otherwise, I think
>>>> either a small repo in my https://git.rtems.org/christianm or a repo on
>>>> github should be a good place (most likely the later one).
>>>>
>>> This should be fine. ftp.rtems.org should also be usable (in theory)
>>>
>>>>>
>>>>>> The patches that import the new SDK files (patch 0002) and remove the
>>>>>> old ones (patch 0004) are too big for the list. I'll only send the
>>>>>> summary. You can find the full patches here:
>>>>>>
>>>>>>     0002:
>>>>>> https://gitlab.com/c-mauderer/rtems/-/commit/2a871672767a95598e5af42373bfebd3eb9440d3
>>>>>>     0004:
>>>>>> https://gitlab.com/c-mauderer/rtems/-/commit/2a3e104fa808d7f34a1930344d7b39d11cf39f3d
>>>>>>
>>>>>> The complete patch set is on this branch:
>>>>>>
>>>>>>     https://gitlab.com/c-mauderer/rtems/-/commits/cm/20230504_imxrt/
>>>>>>
>>>>>> At the moment, I import the support files for all currently available
>>>>>> i.MXRT* variants. The headers for the CPU registers are really big (a
>>>>>> few megabytes per header) which makes the complete source tree of the
>>>>>> mcux-sdk bigger than 90MB. If preferred, I can remove most variants and
>>>>>> only keep the ones that are currently used or will be used soon
>>>>>> (IMXRT1052 and IMXRT1166) to reduce the size.
>>>>>>
>>>>> Thanks, I think this is fine. The increase in the number of HAL/SDK
>>>>> that we have to import is starting to concern me in general. I wonder
>>>>> if there is a better way to manage these external sources.
>>>>>
>>>>
>>>> I think I have a language problem here: Is it fine that I push 96MB or
>>>> is it fine that I reduce the size of the patch before pushing?
>>>>
>>> My apologies, I missed this also. If it's not that much more work, it
>>> might be best to remove the unused variants. We don't like to carry
>>> around dead c

Re: [PATCH rtems 00/12] bsp/imxrt: Update SDK and prepare for new variant

[Chris Johns]

On 6/5/2023 2:02 am, Gedare Bloom wrote:
> On Fri, May 5, 2023 at 9:02 AM  wrote:
>>
>> Hello Gedare,
>>
>> thanks for taking a look at the patch set.
>>
>> Am 05.05.23 um 15:56 schrieb Gedare Bloom:
>>> On Thu, May 4, 2023 at 9:01 AM Christian Mauderer
>>>  wrote:

 Hello,

 this patch set for the arm/imxrt BSP family updates the SDK files to the
 latest version of the mcux-sdk from NXP and prepares the BSP for further
 chip variants. I plan to add a BSP that uses the IMXRT1166 soon.

 As a base for the mcux-sdk files, I now use the NXP git repository
 instead of zip files that can be downloaded from NXP. I kept the exact
 file system structure to make future updates simpler.

 To import the files, I used a script. It is not a clean script and it
 was only tested on a Linux machine. Despite that, I added that script to
 the BSP directory in case someone else ever wants to update the
 mcux-sdk. Updating the SDK is also possible without the script. It's
 just a lot more manual work. So if we don't want a script in that state
 in the repository, I can also just keep it on a private branch.

>>> I would recommend that you document the import/update process for the
>>> SDK in this BSP (or family) documentation. You could provide a stable
>>> external link to the script there instead of including it in the
>>> rtems.git tree. I'm not convinced that including scripts etc in the
>>> same tree as the source they manipulate is a great practice. It seems
>>> to violate separation of concerns.
>>
>> Disadvantage is that the script (and documentation) is a bit less simple
>> to find. But that's not a problem for me (I know where to search) so I
>> will adapt that.
>>
>> De we have an official preferred stable location? Otherwise, I think
>> either a small repo in my https://git.rtems.org/christianm or a repo on
>> github should be a good place (most likely the later one).
>>
> This should be fine. ftp.rtems.org should also be usable (in theory)
> 
>>>
 The patches that import the new SDK files (patch 0002) and remove the
 old ones (patch 0004) are too big for the list. I'll only send the
 summary. You can find the full patches here:

0002: 
 https://gitlab.com/c-mauderer/rtems/-/commit/2a871672767a95598e5af42373bfebd3eb9440d3
0004: 
 https://gitlab.com/c-mauderer/rtems/-/commit/2a3e104fa808d7f34a1930344d7b39d11cf39f3d

 The complete patch set is on this branch:

https://gitlab.com/c-mauderer/rtems/-/commits/cm/20230504_imxrt/

 At the moment, I import the support files for all currently available
 i.MXRT* variants. The headers for the CPU registers are really big (a
 few megabytes per header) which makes the complete source tree of the
 mcux-sdk bigger than 90MB. If preferred, I can remove most variants and
 only keep the ones that are currently used or will be used soon
 (IMXRT1052 and IMXRT1166) to reduce the size.

>>> Thanks, I think this is fine. The increase in the number of HAL/SDK
>>> that we have to import is starting to concern me in general. I wonder
>>> if there is a better way to manage these external sources.
>>>
>>
>> I think I have a language problem here: Is it fine that I push 96MB or
>> is it fine that I reduce the size of the patch before pushing?
>>
> My apologies, I missed this also. If it's not that much more work, it
> might be best to remove the unused variants. We don't like to carry
> around dead code in the repo as another general rule.
> 
>> In this case I only updated the existing HAL with more chips, but I
>> agree that having a better solution to manage HALs than the
>> clone-and-own approach would be great.
>>
>> One possible solutions could be to use subrepos. We can clone the lib to
>> the git.rtems.org, add necessary patches and add that as a subrepo. If
>> an update is necessary, patches can just be rebased on the latest
>> version of the upstream lib. Another one could be something like the
>> west tool that is used in Zephyr. Maybe can also make it simpler to
>> include libs with vendor specific licenses.
>>
>> But approaches like that will have a big impact on how to handle a lot
>> of tasks in RTEMS. For example you would have to init submodules before
>> building BSPs. The submodules have to be handled during release. And a
>> lot more. So we shouldn't discuss that as a side note to a patch set but
>> rather as a new mail thread.
>>
> Agreed.

Do these HAL systems provide stable API interfaces? If so is all RTEMS needs to
interface to is the API headers?

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

Re: [PATCH 00/12] Update documentation of specification items

[Chris Johns]

No issues here.

Chris

On 6/5/2023 12:07 am, Gedare Bloom wrote:
> these look ok. I'll leave the register one for Chris to comment.
> 
> On Fri, May 5, 2023 at 2:46 AM Sebastian Huber
>  wrote:
>>
>> Sebastian Huber (12):
>>   eng: Rework performance meansurement items
>>   eng: Generalize external references
>>   eng: Add conditional build dependencies
>>   eng: Use type refinement for validation method
>>   eng: Add optional floating-point number type
>>   eng: Update application configuration how-to
>>   eng: Remove obsolete type listing
>>   eng: Add design target item type
>>   eng: Add proxy item type
>>   eng: Remove ambiguous interface types
>>   eng: Add an item type for not defined defines
>>   eng: Make design group identifiers optional
>>
>>  eng/glossary.rst  |   3 +
>>  eng/req/howto.rst |  54 +++
>>  eng/req/items.rst | 384 --
>>  3 files changed, 296 insertions(+), 145 deletions(-)
>>
>> --
>> 2.35.3
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] eng: Add register block specification types

[Chris Johns]

Hi,

Sorry about the delay, I have been out sick for the last week or so.

I am ok with this to be pushed. I have a minor correction below and a clean up
if you want.

On 5/5/2023 6:50 pm, Sebastian Huber wrote:
> A register block may be used to specify the interface of devices which
> contain registers associated with an integer address.  Register blocks
> consist of register block members specified by the ``definition``
> attribute.  Register block members are either instances of registers
> specified by the ``registers`` attribute or instances of other register
> blocks specified by links with the "register-block-include" link role.
> Registers consists of bit fields.  The register block members are placed
> into the address space of the device relative to the base address of the
> register block.  Register member offests and the register block size are
> specified in units of the address space granule.
> 
> Update #3715.
> ---
> For examples see:
> 
> https://git.rtems.org/rtems-central/tree/spec/dev/grlib/if
> 
> v2:
> 
> Clarify wording and remove the "register-block-type" attribute.
> 
> v3:
> 
> Do not mention a linear address space.
> 
>  eng/req/items.rst | 338 ++
>  1 file changed, 338 insertions(+)
> 
> diff --git a/eng/req/items.rst b/eng/req/items.rst
> index 783800f..59e3d30 100644
> --- a/eng/req/items.rst
> +++ b/eng/req/items.rst
> @@ -99,6 +99,8 @@ The specification item types have the following hierarchy:
>  
>  * :ref:`SpecTypeInterfaceVariableItemType`
>  
> +* :ref:`SpecTypeRegisterBlockItemType`
> +
>* :ref:`SpecTypeProxyItemTypes`
>  
>* :ref:`SpecTypeRequirementItemType`
> @@ -1159,6 +1161,8 @@ This type is refined by the following types:
>  
>  * :ref:`SpecTypeInterfaceVariableItemType`
>  
> +* :ref:`SpecTypeRegisterBlockItemType`
> +
>  .. _SpecTypeApplicationConfigurationGroupItemType:
>  
>  Application Configuration Group Item Type
> @@ -1619,6 +1623,65 @@ depend on configuration options.  For example, in one 
> configuration a constant
>  could be a compile time constant and in another configuration it could be a
>  read-only object.
>  
> +.. _SpecTypeRegisterBlockItemType:
> +
> +Register Block Item Type
> +
> +
> +This type refines the :ref:`SpecTypeInterfaceItemType` through the
> +``interface-type`` attribute if the value is ``register-block``. This set of
> +attributes specifies a register block.  A register block may be used to 
> specify
> +the interface of devices.  Register blocks consist of register block members
> +specified by the ``definition`` attribute. Register block members are either
> +instances of registers specified by the ``registers`` attribute or instances 
> of
> +other register blocks specified by links with the
> +:ref:`SpecTypeRegisterBlockIncludeRole`. Registers consists of bit fields 
> (see
> +:ref:`SpecTypeRegisterBitsDefinition`. The register block members are placed
> +into the address space of the device relative to the base address of the
> +register block.  Register member offests and the register block size are

offests -> offsets

> +specified in units of the address space granule.  The address space granule 
> is
> +usually 8-bits also known as one byte. 

Does "usually" mean using right or usually wrong? I am fine if the reference to
8-bits is removed.

Chris

> All explicit attributes shall be
> +specified. The explicit attributes for this type are:
> +
> +brief
> +The attribute value shall be an :ref:`SpecTypeInterfaceBriefDescription`.
> +
> +definition
> +The attribute value shall be a list. Each list element shall be a
> +:ref:`SpecTypeRegisterBlockMemberDefinitionDirective`.
> +
> +description
> +The attribute value shall be an :ref:`SpecTypeInterfaceDescription`.
> +
> +identifier
> +The attribute value shall be an :ref:`SpecTypeInterfaceGroupIdentifier`.
> +
> +name
> +The attribute value shall be a string. It shall be the name of the 
> register
> +block.
> +
> +notes
> +The attribute value shall be an :ref:`SpecTypeInterfaceNotes`.
> +
> +register-block-group
> +The attribute value shall be a string. It shall be the name of the
> +interface group defined for the register block.  For the group identifier
> +see the ``identifier`` attribute.
> +
> +register-block-size
> +The attribute value shall be an :ref:`SpecTypeOptionalInteger`. If the
> +value is present, then it shall be the size of the register block in 
> units
> +of the address space granule.
> +
> +register-prefix
> +The attribute value shall be an optional string. If the value is present,
> +then it will be used to prefix register bit field names, otherwise the
> +value of the ``name`` attribute will be used.
> +
> +registers
> +The attribute value shall be a list. Each list element shall be a
> +:ref:`SpecTypeRegisterDefinition`.
> +
>  .. _SpecTypeRequirementItemType:
>  
>  Requirement Item Type
> @@ 

Re: [PATCH 2/5] build: Use CSafeLoader if available

[Chris Johns]

On 5/5/2023 8:16 pm, Sebastian Huber wrote:
> On 05.05.23 01:38, Chris Johns wrote:
>>> When I install it
>>> through pip, I get the CSafeLoader on my machine. I don't have a libyaml
>>> development package installed.
>> This is what I was not understanding. If it can be loaded in a python.org
>> install on a N2 MacOS with a virtual env then I think we are close to a
>> resolution.
> 
> I tried to understand how the PyYAML package is built. It seems that libyaml 
> and
> its header files need to be installed to use the C bindings.

This is what I thought happened with this package. It depends on the base OS
packaging system. The documentation at
https://pyyaml.org/wiki/PyYAMLDocumentation says:

 $ python setup.py install

 If you want to use LibYAML bindings, which are much faster than the pure
 Python version, you need to download and install LibYAML. Then you may
 build and install the bindings by executing

 $ python setup.py --with-libyaml install

I cannot see if pip has any further detail on the nature of the build it
contains so this is not looking good. This leaves building and installing when
the tools are built by the RSB.

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

Re: [PATCH 2/5] build: Use CSafeLoader if available

[Chris Johns]

On 4/5/2023 4:16 pm, Sebastian Huber wrote:
> On 04.05.23 05:35, Chris Johns wrote:
>> On 3/5/2023 7:40 pm, Sebastian Huber wrote:
>>> On 03.05.23 05:30, Chris Johns wrote:
>>>> On 28/4/2023 3:38 pm, Sebastian Huber wrote:
>>>>> On 27.04.23 20:27, Gedare Bloom wrote:
>>>>>> On Wed, Apr 26, 2023 at 11:46 PM Sebastian Huber
>>>>>>   wrote:
>>>>>>> On 27.04.23 02:11, Chris Johns wrote:
>>>>>>>> On 26/4/2023 6:04 pm, Sebastian Huber wrote:
>>>>>>>>> The CSafeLoader uses the C libyaml libary to considerably speed up the
>>>>>>>>> loading of YAML files.
>>>>>>>> No from me.
>>>>>>> What do you mean with not for me? You have the CSafeLoader available and
>>>>>>> it is slow? Do you have some timings before and after the patch set for
>>>>>>> a "./waf configure" and "./waf build"? On my systems the configure needs
>>>>>>> less than a second with the CSafeLoader and the waf build setup time is
>>>>>>> less than 100ms.
>>>>>>>
>>>>>>>> I do not agree with conditional states of operation in the build system
>>>>>>>> that
>>>>>>>> depend on packages a host has installed. If speed is an important 
>>>>>>>> factor
>>>>>>>> all
>>>>>>>> users then I suggest you find a means to have it available 
>>>>>>>> automatically
>>>>>>>> on the
>>>>>>>> hosts we support (Linux, FreeBSD, MacOS, Windows MINGW64 and Cygwin.
>>>>>>> I am not sure if we should automatically install system Python packages
>>>>>>> on user machines.
>>>>>>>
>>>>>>> The fall back is the Python PyYAML package available through the RTEMS
>>>>>>> sources. This is what we use currently. For RTEMS users, this is
>>>>>>> acceptable since they are not supposed to touch the YAML files. For
>>>>>>> RTEMS maintainers, not having the cache makes working with the build
>>>>>>> system more efficient.
>>>>>>>
>>>>>>> If they system PyYAML package is not installed, then you get now a hint
>>>>>>> to install it:
>>>>>>>
>>>>>>> Setting top to   : 
>>>>>>> /home/EB/sebastian_h/src/rtems
>>>>>>> Setting out to   :
>>>>>>> /home/EB/sebastian_h/src/rtems/build
>>>>>>> Regenerate the build specification cache.  Install the PyYAML Python
>>>>>>> package to avoid this.  The cache regeneration needs a couple of 
>>>>>>> seconds...
>>>>>>> Configure board support package (BSP)    : arm/realview_pbx_a9_qemu
>>>>>>>
>>>>>> I have two questions, which are related to Chris's concern I think.
>>>>>> 1. Are the output of PyYAML and C libyaml guaranteed to be consistent?
>>>>>
>>>>> I trust the PyYAML maintainers that the SafeLoader and CSafeLoader 
>>>>> produce the
>>>>> same results. With respect to the alternative ItemCache class
>>>>> implementation in
>>>>> the wscript I am quite confident that this produces the same results. This
>>>>> part
>>>>> just has to load the item data from the files. The CSafeLoader based 
>>>>> ItemCache
>>>>> has 53 lines of code.
>>>>>
>>>>>>
>>>>>> 2. Why not make C libyaml part of the RTEMS toolchain?
>>>>>>
>>>>>> Any dependencies that exist in the build system are (by definition)
>>>>>> suitable to be checked/provided by the tool buildset.
>>>>>
>>>>> Yes, this is an option. If we remove the pickle cache, then we force
>>>>> everyone to
>>>>> use the libyaml based PyYAML module. Is this really necessary right now?
>>>>
>>>> If we leave it who would do it? I would like to understand the next 
>>>> question
>>>> before we decide if this is important. The key objective is to have 
>>>> consistent
>>>> performance for every one. If the package is easy to build then we should 
>>>> do it
>

Re: [PATCH 2/5] build: Use CSafeLoader if available

[Chris Johns]

On 3/5/2023 7:40 pm, Sebastian Huber wrote:
> On 03.05.23 05:30, Chris Johns wrote:
>> On 28/4/2023 3:38 pm, Sebastian Huber wrote:
>>> On 27.04.23 20:27, Gedare Bloom wrote:
>>>> On Wed, Apr 26, 2023 at 11:46 PM Sebastian Huber
>>>>   wrote:
>>>>> On 27.04.23 02:11, Chris Johns wrote:
>>>>>> On 26/4/2023 6:04 pm, Sebastian Huber wrote:
>>>>>>> The CSafeLoader uses the C libyaml libary to considerably speed up the
>>>>>>> loading of YAML files.
>>>>>> No from me.
>>>>> What do you mean with not for me? You have the CSafeLoader available and
>>>>> it is slow? Do you have some timings before and after the patch set for
>>>>> a "./waf configure" and "./waf build"? On my systems the configure needs
>>>>> less than a second with the CSafeLoader and the waf build setup time is
>>>>> less than 100ms.
>>>>>
>>>>>> I do not agree with conditional states of operation in the build system 
>>>>>> that
>>>>>> depend on packages a host has installed. If speed is an important factor 
>>>>>> all
>>>>>> users then I suggest you find a means to have it available automatically
>>>>>> on the
>>>>>> hosts we support (Linux, FreeBSD, MacOS, Windows MINGW64 and Cygwin.
>>>>> I am not sure if we should automatically install system Python packages
>>>>> on user machines.
>>>>>
>>>>> The fall back is the Python PyYAML package available through the RTEMS
>>>>> sources. This is what we use currently. For RTEMS users, this is
>>>>> acceptable since they are not supposed to touch the YAML files. For
>>>>> RTEMS maintainers, not having the cache makes working with the build
>>>>> system more efficient.
>>>>>
>>>>> If they system PyYAML package is not installed, then you get now a hint
>>>>> to install it:
>>>>>
>>>>> Setting top to   : /home/EB/sebastian_h/src/rtems
>>>>> Setting out to   :
>>>>> /home/EB/sebastian_h/src/rtems/build
>>>>> Regenerate the build specification cache.  Install the PyYAML Python
>>>>> package to avoid this.  The cache regeneration needs a couple of 
>>>>> seconds...
>>>>> Configure board support package (BSP)    : arm/realview_pbx_a9_qemu
>>>>>
>>>> I have two questions, which are related to Chris's concern I think.
>>>> 1. Are the output of PyYAML and C libyaml guaranteed to be consistent?
>>>
>>> I trust the PyYAML maintainers that the SafeLoader and CSafeLoader produce 
>>> the
>>> same results. With respect to the alternative ItemCache class 
>>> implementation in
>>> the wscript I am quite confident that this produces the same results. This 
>>> part
>>> just has to load the item data from the files. The CSafeLoader based 
>>> ItemCache
>>> has 53 lines of code.
>>>
>>>>
>>>> 2. Why not make C libyaml part of the RTEMS toolchain?
>>>>
>>>> Any dependencies that exist in the build system are (by definition)
>>>> suitable to be checked/provided by the tool buildset.
>>>
>>> Yes, this is an option. If we remove the pickle cache, then we force 
>>> everyone to
>>> use the libyaml based PyYAML module. Is this really necessary right now?
>>
>> If we leave it who would do it? I would like to understand the next question
>> before we decide if this is important. The key objective is to have 
>> consistent
>> performance for every one. If the package is easy to build then we should do 
>> it
>> when we build the tools and the questions we are having go away.
> 
> The PyYAML package had some security issues in the past. If we ship this
> package, who will monitor this package, update it, and write security 
> advisories?

The same way we would handle any security issue. When we become aware we update
what we provide.

Is PyYAML a pip package or is it provided by a distro package when using Linux?
My assumption, which may be wrong, is building libyaml (the C part) is all we
need to do?

>>> For
>>> most use cases the Python only solution works fine. If you spend your time
>>> developing BSPs, then the CSafeLoader pays off.
>>
>> Maybe I am not understanding how this works. Why is there a difference

Re: [PATCH 2/5] build: Use CSafeLoader if available

[Chris Johns]

On 28/4/2023 3:38 pm, Sebastian Huber wrote:
> On 27.04.23 20:27, Gedare Bloom wrote:
>> On Wed, Apr 26, 2023 at 11:46 PM Sebastian Huber
>>   wrote:
>>> On 27.04.23 02:11, Chris Johns wrote:
>>>> On 26/4/2023 6:04 pm, Sebastian Huber wrote:
>>>>> The CSafeLoader uses the C libyaml libary to considerably speed up the
>>>>> loading of YAML files.
>>>> No from me.
>>> What do you mean with not for me? You have the CSafeLoader available and
>>> it is slow? Do you have some timings before and after the patch set for
>>> a "./waf configure" and "./waf build"? On my systems the configure needs
>>> less than a second with the CSafeLoader and the waf build setup time is
>>> less than 100ms.
>>>
>>>> I do not agree with conditional states of operation in the build system 
>>>> that
>>>> depend on packages a host has installed. If speed is an important factor 
>>>> all
>>>> users then I suggest you find a means to have it available automatically 
>>>> on the
>>>> hosts we support (Linux, FreeBSD, MacOS, Windows MINGW64 and Cygwin.
>>> I am not sure if we should automatically install system Python packages
>>> on user machines.
>>>
>>> The fall back is the Python PyYAML package available through the RTEMS
>>> sources. This is what we use currently. For RTEMS users, this is
>>> acceptable since they are not supposed to touch the YAML files. For
>>> RTEMS maintainers, not having the cache makes working with the build
>>> system more efficient.
>>>
>>> If they system PyYAML package is not installed, then you get now a hint
>>> to install it:
>>>
>>> Setting top to   : /home/EB/sebastian_h/src/rtems
>>> Setting out to   :
>>> /home/EB/sebastian_h/src/rtems/build
>>> Regenerate the build specification cache.  Install the PyYAML Python
>>> package to avoid this.  The cache regeneration needs a couple of seconds...
>>> Configure board support package (BSP)    : arm/realview_pbx_a9_qemu
>>>
>> I have two questions, which are related to Chris's concern I think.
>> 1. Are the output of PyYAML and C libyaml guaranteed to be consistent?
> 
> I trust the PyYAML maintainers that the SafeLoader and CSafeLoader produce the
> same results. With respect to the alternative ItemCache class implementation 
> in
> the wscript I am quite confident that this produces the same results. This 
> part
> just has to load the item data from the files. The CSafeLoader based ItemCache
> has 53 lines of code.
> 
>>
>> 2. Why not make C libyaml part of the RTEMS toolchain?
>>
>> Any dependencies that exist in the build system are (by definition)
>> suitable to be checked/provided by the tool buildset.
> 
> Yes, this is an option. If we remove the pickle cache, then we force everyone 
> to
> use the libyaml based PyYAML module. Is this really necessary right now?

If we leave it who would do it? I would like to understand the next question
before we decide if this is important. The key objective is to have consistent
performance for every one. If the package is easy to build then we should do it
when we build the tools and the questions we are having go away.

> For
> most use cases the Python only solution works fine. If you spend your time
> developing BSPs, then the CSafeLoader pays off.

Maybe I am not understanding how this works. Why is there a difference for
developers vs a user who does not have this package installed? Does the
difference scale?

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

Re: [PATCH rtems-libbsd] Revert "waf: Move the tools/BSP include path to be last"

[Chris Johns]

OK and thanks for cleaning this up.

Chris

On 2/5/2023 11:58 am, Kinsey Moore wrote:
> This reverts commit 6ee31ae968323c71c478b2f52ec5a5cbff8c8f5d.
> 
> A fix has been committed to RTEMS pkgcfg and Makefile generation to
> handle this issue and having this in place with the fix in RTEMS causes
> a failure to build.
> ---
>  waf_libbsd.py | 29 -
>  1 file changed, 8 insertions(+), 21 deletions(-)
> 
> diff --git a/waf_libbsd.py b/waf_libbsd.py
> index acf93a2f..81818956 100644
> --- a/waf_libbsd.py
> +++ b/waf_libbsd.py
> @@ -2,7 +2,7 @@
>  """LibBSD build configuration to waf integration module.
>  """
>  
> -# Copyright (c) 2015, 2021 Chris Johns . All rights 
> reserved.
> +# Copyright (c) 2015, 2020 Chris Johns . All rights 
> reserved.
>  #
>  # Copyright (c) 2009, 2015 embedded brains GmbH.  All rights reserved.
>  #
> @@ -62,13 +62,6 @@ def _add_flags_if_not_present(current_flags, 
> addional_flags):
>  if flag not in current_flags:
>  current_flags.append(flag)
>  
> -def _remove_bsp_include_path(bsp_include_path, current_flags):
> -# this does not handle quted strings; maybe needed
> -for bsp_path in bsp_include_path:
> -if bsp_path in current_flags:
> -current_flags = [flag for flag in current_flags if flag != 
> bsp_path]
> -return current_flags
> -
>  #
>  # The waf builder for libbsd.
>  #
> @@ -194,12 +187,6 @@ class Builder(builder.ModuleManager):
>  conf.env['HAVE_%s' % l.upper()] = True
>  else:
>  bld.fatal('invalid config test: %s' % (configTest))
> -conf.env.CFLAGS = _remove_bsp_include_path(conf.env.IFLAGS,
> -   conf.env.CFLAGS)
> -conf.env.CXXFLAGS = _remove_bsp_include_path(conf.env.IFLAGS,
> -
> conf.env.CXXFLAGS)
> -conf.env.LINKFLAGS = _remove_bsp_include_path(conf.env.IFLAGS,
> -  conf.env.LINKFLAGS)
>  section_flags = ["-fdata-sections", "-ffunction-sections"]
>  _add_flags_if_not_present(conf.env.CFLAGS, section_flags)
>  _add_flags_if_not_present(conf.env.CXXFLAGS, section_flags)
> @@ -250,7 +237,7 @@ class Builder(builder.ModuleManager):
>  inc_paths = sorted(include_paths)
>  inc_paths.remove('build')
>  inc_paths.remove('cpu')
> -includes = { 'bsp': [p[2:] for p in bld.env.IFLAGS] }
> +includes = {}
>  for inc in inc_paths:
>  includes[inc] = include_paths[inc]
>  # cpu include paths must be the first searched
> @@ -445,7 +432,7 @@ class Builder(builder.ModuleManager):
>  bld.objects(target='kvmsymbols',
>  features='c',
>  cflags=cflags,
> -includes=kvmsymbols_includes + includes['kernel'] + 
> includes['bsp'],
> +includes=kvmsymbols_includes + includes['kernel'],
>  source=kvmsymbols['files']['all']['default'][0])
>  libbsd_use += ["kvmsymbols"]
>  
> @@ -500,7 +487,7 @@ class Builder(builder.ModuleManager):
>  bld.objects(target='lex_%s' % (lex['sym']),
>  features='c',
>  cflags=cflags,
> -includes=lexIncludes + includes['user'] + 
> includes['bsp'],
> +includes=lexIncludes + includes['user'],
>  defines=defines + lexDefines,
>  source=lex['file'][:-2] + '.c')
>  libbsd_use += ['lex_%s' % (lex['sym'])]
> @@ -540,7 +527,7 @@ class Builder(builder.ModuleManager):
>  bld.objects(target='yacc_%s' % (yaccSym),
>  features='c',
>  cflags=cflags,
> -includes=yaccIncludes + includes['user'] + 
> includes['bsp'],
> +includes=yaccIncludes + includes['user'],
>  defines=defines + yaccDefines,
>  source=yaccFile[:-2] + '.c')
>  libbsd_use += ['yacc_%s' % (yaccSym)]
> @@ -574,7 +561,7 @@ class Builder(builder.ModuleManager):
>  cflags=cflags + bld_cflags,
>  cxxflags=cxxflags,
>  includ

Re: RSB repo commits need approval

[Chris Johns]

On 29/4/2023 3:48 am, o...@c-mauderer.de wrote:
> Hello Joel,
> 
> Am 28.04.23 um 00:19 schrieb Joel Sherrill:
>>
>>
>> On Wed, Apr 26, 2023 at 7:06 PM Chris Johns > <mailto:chr...@rtems.org>> wrote:
>>
>>     Hi,
>>
>>     All RSB repo commits need to be posted for review and independent
>>     approval given
>>     before being pushed to the top level repo.
>>
>>
>> I thought this was the policy for all top level repositories. There is a
>> degree of trust
>> on any posted patch that it has been tested by the submitter with the
>> understanding
>> that things do slip through. If someone is regularly submitting modifications
>> without
>> testing them, then we have a larger problem.
> 
> Regarding the policy: I think that is documented in the rtems.git in the
> MAINTAINERS-file:
> 
>   https://git.rtems.org/rtems/tree/MAINTAINERS
> 
> We have a few people who are trusted to distinguish between patches that can 
> be
> pushed without review and patches that should get a review while all other
> should post a patch for review and wait at least for a few days before pushing
> it (for BSP specific stuff) or need an acknowledge (for general stuff).
> 
> 
> Chris: Is that a temporary rule for the blanket write privilege maintainers
> while trying to reach a stable release version? Is there a difference between
> the tools starting with "6/" (which should be the release version) and the 
> ones
> that start with "7/" (which are more or less an unstable test version)?

I think we should post all because it is simpler but it is a good and valid
question. A reason to post all changes is questions or a wrong interpretation
can be resolved up front. I also understand how much better and simpler a pull
request system would have on this process but it is not up and running at the
moment.

I only addressed the RSB with this post and it was done with the agreement of
Joel and Gedare. I did not just make the decision myself. We would like more
detail in some commit messages and a review may be a way to handle that.

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

Re: Change build specification files from YAML to JSON?

[Chris Johns]

On 26/4/2023 6:22 pm, Sebastian Huber wrote:
> On 26.04.23 01:52, Chris Johns wrote:
>> On 25/4/2023 5:35 pm, Sebastian Huber wrote:
>>> Tooling makes sense if you have a high change rate.
>>
>> That is not the use case I am discussing and it is not a factor.
>>
>>> This is not the case for the RTEMS build specification items.
>>
>> I am not saying it is.
>>
>>> For which use case do we need tooling support?
>>
>> We need tooling to lets us all understand this build system. YAML is easy to
>> learn however the data-structures, rules and the large number of file 
>> fragments
>> we have are complex and not apparent to anyone looking at it even if you have
>> invested time doing so. It reflects the fact that RTEMS is complicated to 
>> build.
> 
> I don't think building an RTEMS BSP is complicated once you have the tools
> installed.

Sorry, my "user" is someone developing something for RTEMS and needing to update
the spec files. I was not clear about this.

>> I am advocate for what we have and will continue to be one so I am 
>> attempting to
>> address some things we could do better. History has shown the RTEMS core
>> developers are not great judges of the community's view of the project's
>> usability and accessibility.
>>
>> The analogy is to consider the git command then the roles github and gitlab
>> provide with their user interfaces and tooling.
>>
>>> For a new option or BSP, you just copy and past from existing files/BSPs.
>>> Changing a specific part of an existing file is just copy and paste some 
>>> lines
>>> and edit them in most cases.
>>
>> My experience tells me it is not as simple as this. There is an element of 
>> guess
>> work a change is right. The recent dependency cases highlighted this and the
>> need for checking of some form to be present in the rtems.git repo.
>>
>> We need to step back and consider the role of the build system before we 
>> discuss
>> implementation details.
>>
>> The first requirement by a large margin is ease of use for users and the
>> community to make contributions. Meeting this requirement can be done a 
>> number
>> of ways. For example a user focused format for the relationships rather than 
>> one
>> that aids machine integration. The original ground work Amar did for the 
>> move to
>> waf was to define the build in Python as documented by waf. It was simple and
>> transparent. Another example is a machine focused format however we need 
>> tooling
>> to help the users manage making changes and accessing what is happening 
>> without
>> needing to learn the details of how it is implemented.
>>
>> For tooling my order of importance is:
>>
>> 1. Visualise the structures and dependencies in a human readable manner. An
>> indication of which file is doing what would be helpful.
>>
>> 2. A check of changes users make that raises errors, dependency problems, 
>> etc.
>> This can be a command you run if you are making changes and does not need to 
>> run
>> every build.
>>
>> I see JSON and tooling as linked together. I also not expect complete 
>> tooling to
>> be present for the change to happen. All I am wanting is the need for 
>> tooling be
>> agreed on and it is located in rtems.git. The development can then happen and
>> evolve as the community sees a need.
> 
> From my experience with waf I would not say that the waf build system is 
> simple
> and transparent. Things which are very easy with make are complicated with waf
> at least for me. 

Yes this is valid and I agree. If you are outside the scope of something simple
it can get hard. It does some things well and easily and others are hard. Waf is
not alone here.

> I asked a couple of waf questions on the RTEMS mailing list
> which no core developer could answer. The support from the waf developer was a
> great help, but without this help I would not have been able to write the waf
> based build system for RTEMS.

Developing a framework does require a different level of integration with waf
and it can be involved. Waf is good as the base of a framework and I think what
we have is a good example.

I agree with Joel, we have not explained or sold the change as well as we need
to have.

What ever the format I would like the ability to create user focused tools but
currently the code to load the YAML (pickled for not) is not accessible as a
module in rtems.git.

> I think our biggest obstacle to improve things in the area you outlined above 
> is
> the scattered project infrastructure with several G

Re: RSB repo commits need approval

[Chris Johns]

On 28/4/2023 4:05 am, Gedare Bloom wrote:
> On Thu, Apr 27, 2023 at 3:27 AM Karel Gardas  wrote:
>> On 4/27/23 08:13, Sebastian Huber wrote:
>>> Why
>>> don't we use a Git pull request workflow with CI pipelines in the RTEMS
>>> Project?
>>
>> I don't know, but certainly github.com is not available as an
>> open-source solution which may be seen as a major roadblock. Am I right
>> assuming that GitLab Community is the most close to that and available
>> for running by anyone?
> 100% this is the main reason, and most likely GitLab is where we would
> go. I believe the main issue to getting that in place at the moment is
> appropriate mechanisms to fund the remaining server upgrades and then
> installation/setup of the gitlab service on RTEMS Project
> infrastructure.

The work on this has currently slowed due to personal reasons outside of the
project. I hope we stay on the selected course and we see things start to move
again (pun intended).

The topic of commercial services was discussed on discord recently. A commercial
service needs someone to pay for it and we do not have a working foundation that
can do this for us independently and transparently on behalf of the community.
Companies and individuals are not suitable to hold the accounts and the control
that brings.

>> As an observer on another project with GitLab (GHC Haskell compiler)
>> I've seen this solution is not free as a work free, but requires some
>> man-hours investments...
>>
> Yes.
> 
>> So the question after "yes" to migrate (if the consensus is found!) is
>> "who will pay the price and do the job"...
>>
> Yes. Generally speaking, we have an excellent IT support in the
> background via Amar, but it can be a lot of work for him at times, and
> anything beyond the usual maintenance activities definitely requires
> more time/money allocations.

Thanks for mentioning this.

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

Re: [PATCH 2/5] build: Use CSafeLoader if available

[Chris Johns]

On 28/4/2023 4:27 am, Gedare Bloom wrote:
> On Wed, Apr 26, 2023 at 11:46 PM Sebastian Huber
>  wrote:
>>
>> On 27.04.23 02:11, Chris Johns wrote:
>>> On 26/4/2023 6:04 pm, Sebastian Huber wrote:
>>>> The CSafeLoader uses the C libyaml libary to considerably speed up the
>>>> loading of YAML files.
>>> No from me.
>>
>> What do you mean with not for me? You have the CSafeLoader available and
>> it is slow? Do you have some timings before and after the patch set for
>> a "./waf configure" and "./waf build"? On my systems the configure needs
>> less than a second with the CSafeLoader and the waf build setup time is
>> less than 100ms.

I do not agree this changing being merged as is. A move to csafeloader for all
users is a good idea but not conditionally.

>>> I do not agree with conditional states of operation in the build system that
>>> depend on packages a host has installed. If speed is an important factor all
>>> users then I suggest you find a means to have it available automatically on 
>>> the
>>> hosts we support (Linux, FreeBSD, MacOS, Windows MINGW64 and Cygwin.
>>
>> I am not sure if we should automatically install system Python packages
>> on user machines.
>>
>> The fall back is the Python PyYAML package available through the RTEMS
>> sources. This is what we use currently. For RTEMS users, this is
>> acceptable since they are not supposed to touch the YAML files. For
>> RTEMS maintainers, not having the cache makes working with the build
>> system more efficient.
>>
>> If they system PyYAML package is not installed, then you get now a hint
>> to install it:
>>
>> Setting top to   : /home/EB/sebastian_h/src/rtems
>> Setting out to   :
>> /home/EB/sebastian_h/src/rtems/build
>> Regenerate the build specification cache.  Install the PyYAML Python
>> package to avoid this.  The cache regeneration needs a couple of seconds...
>> Configure board support package (BSP): arm/realview_pbx_a9_qemu
>>
> 
> I have two questions, which are related to Chris's concern I think.
> 1. Are the output of PyYAML and C libyaml guaranteed to be consistent?
> 
> 2. Why not make C libyaml part of the RTEMS toolchain?
> 
> Any dependencies that exist in the build system are (by definition)
> suitable to be checked/provided by the tool buildset.

Yes this is a good summary, thanks.

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

Re: RSB repo commits need approval

[Chris Johns]

On 27/4/2023 4:13 pm, Sebastian Huber wrote:
> what is your (or the RTEMS Project in general) plan to maintain the tools and
> ensure that we can use up to date versions of Newlib, GCC, Binutils, and GDB?
> This involves building the latest versions, reviewing build issues, reporting
> bugs, writing patches, etc. Currently, I do the majority of this work. I do 
> this
> occasionally. This way, we do not offer a quality of service from an RTEMS
> Project point of view.

Thanks for the work you are doing with the tools. Is there an issue with posting
patches for review before committing?

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

Re: [PATCH 2/5] build: Use CSafeLoader if available

[Chris Johns]

On 26/4/2023 6:04 pm, Sebastian Huber wrote:
> The CSafeLoader uses the C libyaml libary to considerably speed up the
> loading of YAML files.

No from me.

I do not agree with conditional states of operation in the build system that
depend on packages a host has installed. If speed is an important factor all
users then I suggest you find a means to have it available automatically on the
hosts we support (Linux, FreeBSD, MacOS, Windows MINGW64 and Cygwin.

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

RSB repo commits need approval

[Chris Johns]

Hi,

All RSB repo commits need to be posted for review and independent approval given
before being pushed to the top level repo.

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

Re: Change build specification files from YAML to JSON?

[Chris Johns]

On 25/4/2023 5:35 pm, Sebastian Huber wrote:
> Tooling makes sense if you have a high change rate. 

That is not the use case I am discussing and it is not a factor.

> This is not the case for the RTEMS build specification items.

I am not saying it is.

> For which use case do we need tooling support?

We need tooling to lets us all understand this build system. YAML is easy to
learn however the data-structures, rules and the large number of file fragments
we have are complex and not apparent to anyone looking at it even if you have
invested time doing so. It reflects the fact that RTEMS is complicated to build.

I am advocate for what we have and will continue to be one so I am attempting to
address some things we could do better. History has shown the RTEMS core
developers are not great judges of the community's view of the project's
usability and accessibility.

The analogy is to consider the git command then the roles github and gitlab
provide with their user interfaces and tooling.

> For a new option or BSP, you just copy and past from existing files/BSPs.
> Changing a specific part of an existing file is just copy and paste some lines
> and edit them in most cases.

My experience tells me it is not as simple as this. There is an element of guess
work a change is right. The recent dependency cases highlighted this and the
need for checking of some form to be present in the rtems.git repo.

We need to step back and consider the role of the build system before we discuss
implementation details.

The first requirement by a large margin is ease of use for users and the
community to make contributions. Meeting this requirement can be done a number
of ways. For example a user focused format for the relationships rather than one
that aids machine integration. The original ground work Amar did for the move to
waf was to define the build in Python as documented by waf. It was simple and
transparent. Another example is a machine focused format however we need tooling
to help the users manage making changes and accessing what is happening without
needing to learn the details of how it is implemented.

For tooling my order of importance is:

1. Visualise the structures and dependencies in a human readable manner. An
indication of which file is doing what would be helpful.

2. A check of changes users make that raises errors, dependency problems, etc.
This can be a command you run if you are making changes and does not need to run
every build.

I see JSON and tooling as linked together. I also not expect complete tooling to
be present for the change to happen. All I am wanting is the need for tooling be
agreed on and it is located in rtems.git. The development can then happen and
evolve as the community sees a need.

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

Re: Change build specification files from YAML to JSON?

[Chris Johns]

On 26/4/2023 4:01 am, Sebastian Huber wrote:
> On 25.04.23 13:02, Karel Gardas wrote:
>> On 4/25/23 12:32, Sebastian Huber wrote:
>>> On 25.04.23 12:10, Karel Gardas wrote:
 On 4/25/23 11:03, Sebastian Huber wrote:
>
>
> On 25.04.23 11:00, Karel Gardas wrote:
>> On 4/25/23 09:35, Sebastian Huber wrote:
>>> The change from YAML to JSON for the build specification files is just 
>>> an
>>> implementation detail of the new build system. For the users of the new
>>> build system nothing changes.
>>
>> Let me ask for clarification. Does this yaml -> json transition include
>> (or not) files in RTEMS spec directory, e.g. files here:
>>
>> https://git.rtems.org/rtems/tree/spec
>
> It would affect all YAML files in this directory and no other files.

 Oh. Let me ask, what is your future plan with the spec files? Considering
 you would like to move them to JSON, would you also like to provide some 
 DSL
 + compiler which would generates those? Or would you just like to keep JSON
 and have developers editing those?
>>>
>>> I would keep the JSON and have developer editing those.
>>>
>>> An alternative to changing the format could be to use the CSafeLoader of the
>>> system yaml module if it is available. It is not as fast as the JSON loader,
>>> but acceptable (0.65s to 0.2s on my machine for loading the items).
>>
>> Sorry for perhaps silly question, but why do you invest that much energy in
>> optimizing build speed -- by fraction of seconds here? I so far fail so to 
>> see
>> driving motivation force hence my question...
> 
> We have a fraction of a second if we use the CSafeLoader and no item cache.
> Currently we use the SafeLoader which results in about 5 seconds. I would like
> to use the build system for more stuff, so this could grow to 10, 15, or more
> seconds which then start to get annoying if you work frequently with it.

Then please outline what all you have in mind and what the long term plan is
then we can consider the overall direction.

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

Re: Change build specification files from YAML to JSON?

[Chris Johns]

On 25/4/2023 12:20 am, Sebastian Huber wrote:
> On 24.04.23 16:17, Kinsey Moore wrote:
>> I think we've been moving away from in-file comments in the YAML and toward
>> actual labels in the data, anyway. If it's important information, it should 
>> be
>> kept properly.
> 
> Yes, there should be no comments in the build specification files. They would 
> be
> lost in YAML load/save cycle.

I am fine with json as a format. Comments are useful even for copyright notices
which would be lost. Is that OK?

My concern is a major shift on top of a major change to waf so close together.
As a community we have only just started to get a number of people across what
we have and then things change? I see the counter point about making this happen
before 6 however I am still not sure what the cost/benefit is?

The YAML lacks support tooling in rtems.git but it is usable as is. I am
concerned a move to json would compound the problem. On the other hand if we
considered json as the data could tooling mean we avoid hand editing?

If that was the approach how would we move to have tooling to help?

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

Re: [PATCH] score: Avoid cyclic header file dependencies

[Chris Johns]

Looks good and thanks for sorting this out.

Chris

On 24/4/2023 11:00 pm, Sebastian Huber wrote:
> There was a cyclic dependency: For RTEMS_STATIC_ANALYSIS we needed
> basedefs.h in assert.h. For RTEMS_UNREACHABLE() we needed _Assert() from
> assert.h in basedefs.h.
> 
> Fix this by introducing _Debug_Unreachable() in basedefs.h.
> 
> Add RTEMS_FUNCTION_NAME to basedefs.h and use it in basedefs.h and
> assert.h.
> 
> Close #4900.
> ---
>  cpukit/include/rtems/score/assert.h  |  17 +--
>  cpukit/include/rtems/score/basedefs.h| 109 +++
>  cpukit/score/src/debugunreachable.c  |  49 +
>  spec/build/cpukit/librtemscpu.yml|   1 +
>  testsuites/validation/tc-basedefs-no-debug.c |  20 ++--
>  5 files changed, 129 insertions(+), 67 deletions(-)
>  create mode 100644 cpukit/score/src/debugunreachable.c
> 
> diff --git a/cpukit/include/rtems/score/assert.h 
> b/cpukit/include/rtems/score/assert.h
> index 9eeccacf76..cff4801036 100644
> --- a/cpukit/include/rtems/score/assert.h
> +++ b/cpukit/include/rtems/score/assert.h
> @@ -71,22 +71,7 @@ extern "C" {
> * @note This is based on the code in newlib's assert.h.
> */
>#ifndef __RTEMS_ASSERT_FUNCTION
> -/* Use g++'s demangled names in C++.  */
> -#if defined __cplusplus && defined __GNUC__
> -  #define __RTEMS_ASSERT_FUNCTION __PRETTY_FUNCTION__
> -
> -/* C99 requires the use of __func__.  */
> -#elif __STDC_VERSION__ >= 199901L
> -  #define __RTEMS_ASSERT_FUNCTION __func__
> -
> -/* Older versions of gcc don't have __func__ but can use __FUNCTION__.  
> */
> -#elif __GNUC__ >= 2
> -  #define __RTEMS_ASSERT_FUNCTION __FUNCTION__
> -
> -/* failed to detect __func__ support.  */
> -#else
> -  #define __RTEMS_ASSERT_FUNCTION ((char *) 0)
> -#endif
> +#define __RTEMS_ASSERT_FUNCTION RTEMS_FUNCTION_NAME
>#endif /* !__RTEMS_ASSERT_FUNCTION */
>  
>#if !defined( RTEMS_SCHEDSIM )
> diff --git a/cpukit/include/rtems/score/basedefs.h 
> b/cpukit/include/rtems/score/basedefs.h
> index c182ea02ec..96b1d65e27 100644
> --- a/cpukit/include/rtems/score/basedefs.h
> +++ b/cpukit/include/rtems/score/basedefs.h
> @@ -12,7 +12,7 @@
>  /*
>   * Copyright (C) 2014 Paval Pisa
>   * Copyright (C) 2011, 2013 On-Line Applications Research Corporation (OAR)
> - * Copyright (C) 2009, 2021 embedded brains GmbH 
> (http://www.embedded-brains.de)
> + * Copyright (C) 2009, 2023 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
> @@ -355,6 +355,47 @@ extern "C" {
>   */
>  #define RTEMS_EXPAND( _token ) _token
>  
> +/* Generated from spec:/rtems/basedefs/if/function-name */
> +
> +/**
> + * @ingroup RTEMSAPIBaseDefs
> + *
> + * @brief Expands to the name of the function containing the use of this
> + *   define.
> + */
> +#if defined(__cplusplus) && defined(__GNUC__)
> +  #define RTEMS_FUNCTION_NAME __PRETTY_FUNCTION__
> +#else
> +  #define RTEMS_FUNCTION_NAME __func__
> +#endif
> +
> +/* Generated from spec:/rtems/basedefs/if/no-return */
> +
> +/**
> + * @ingroup RTEMSAPIBaseDefs
> + *
> + * @brief Tells the compiler in a function declaration that this function 
> does
> + *   not return.
> + */
> +#if __cplusplus >= 201103L
> +  #define RTEMS_NO_RETURN [[noreturn]]
> +#elif __STDC_VERSION__ >= 201112L
> +  #define RTEMS_NO_RETURN _Noreturn
> +#elif defined(__GNUC__)
> +  #define RTEMS_NO_RETURN __attribute__(( __noreturn__ ))
> +#else
> +  #define RTEMS_NO_RETURN
> +#endif
> +
> +/* Generated from spec:/rtems/basedefs/if/compiler-no-return-attribute */
> +
> +/**
> + * @ingroup RTEMSAPIBaseDefs
> + *
> + * @brief Provided for backward compatibility.
> + */
> +#define RTEMS_COMPILER_NO_RETURN_ATTRIBUTE RTEMS_NO_RETURN
> +
>  /* Generated from spec:/rtems/basedefs/if/section */
>  
>  /**
> @@ -425,17 +466,25 @@ extern "C" {
>   */
>  #define RTEMS_XCONCAT( _x, _y ) RTEMS_CONCAT( _x, _y )
>  
> -/* Generated from spec:/score/basedefs/if/assert-unreachable */
> +#if !defined(ASM) && defined(RTEMS_DEBUG)
> +  /* Generated from spec:/score/basedefs/if/debug-unreachable */
>  
> -/**
> - * @ingroup RTEMSScore
> - *
> - * @brief Asserts that this program point is unreachable.
> - */
> -#if defined(RTEMS_DEBUG)
> -  #define _Assert_Unreachable() _Assert( 0 )
> -#else
> -  #define _Assert_Unreachable() do { } while ( 0 )
> +  /**
> +   * @ingroup RTEMSScore
> +   *
> +   * @brief Terminates the program with a failed assertion.
> +   *
> +   * @param file is the file name.
> +   *
> +   * @param line is the line of the file.
> +   *
> +   * @param func is the function name.
> +   */
> +  RTEMS_NO_RETURN void _Debug_Unreachable(
> +const char *file,
> +int line,
> +const char *func
> +  );
>  #endif
>  
>  #if !defined(ASM)
> @@ -614,33 +663,6 @@ extern "C" {
>#define RTEMS_NO_INLINE
>  #endif

Re: Qemu and missing dynamic libraries

[Chris Johns]

On 25/4/2023 7:05 am, Joel Sherrill wrote:
> 
> 
> On Mon, Apr 24, 2023 at 3:11 PM Karel Gardas  wrote:
> 
> On 4/24/23 21:33, Joel Sherrill wrote:
> >
> >
> > On Mon, Apr 24, 2023, 2:11 PM Karel Gardas  
> wrote:
> >
> >
> >     What have you done to this poor FBSD? ;-)
> 
> 
> Nothing. :)
> 
> I wonder when we started installing dynamic libraries with qemu. 
>  

Is there a static option to avoid shared libs?

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

Re: [PATCH] bsps/powerpc: Fix warnings with PPC_SPECIAL_PURPOSE_REGISTER

[Chris Johns]

On 24/4/2023 7:14 pm, Sebastian Huber wrote:
> Looks good, thanks.

Thanks for the review, pushed. Sorry about forgetting to post the fix.

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

Re: [PATCH v2 2/2] bsps/powerpc: Fix warnings with PPC_SPECIAL_PURPOSE_REGISTER

[Chris Johns]

On 24/4/2023 6:42 pm, Sebastian Huber wrote:
> On 12.04.23 03:56, chr...@rtems.org wrote:
>> From: Chris Johns
>>
>> - This change avoids the GCC extension of blocks in expressions that
>>    ISO forbids and is warned about with the pedantic warnings option.
> 
> This change is an API change and broke the build of some BSPs and maybe also
> applications. Is this really necessary just to fix a warning?

Yes. I have a patch to post but got distracted. I will post it tomorrow.

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

Re: [PATCH rtems-examples 1/6] c11/wscript: C11 concurrency does not require POSIX enabled

[Chris Johns]

Looks good.

Chris

On 24/4/2023 6:44 am, Joel Sherrill wrote:
> ---
>  c11/wscript | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/c11/wscript b/c11/wscript
> index 151c591..eeb60a9 100644
> --- a/c11/wscript
> +++ b/c11/wscript
> @@ -6,8 +6,7 @@
>  import rtems_waf.rtems as rtems
>  
>  def build(bld):
> -if rtems.check_posix(bld):
> -bld.recurse('c11_thread01 ')
> -bld.recurse('c11_mutex01 ')
> -bld.recurse('c11_cndvar01 ')
> -bld.recurse('c11_key01 ')
> +bld.recurse('c11_thread01 ')
> +bld.recurse('c11_mutex01 ')
> +bld.recurse('c11_cndvar01 ')
> +bld.recurse('c11_key01 ')
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 4/4] sb/pkg-config: Add --cflags-only-I and --cflags-only-other option

[Chris Johns]

On 23/4/2023 6:12 am, Joel Sherrill wrote:
> Do these  options need some help/explanation?

https://manpages.ubuntu.com/manpages/bionic/man1/pkg-config.1.html

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

Re: MIPS build requires native expat lib (Was: [rtems-source-builder PATCH] rtems: Add back gsed that was remove by mistake)

[Chris Johns]

On 21/4/2023 2:53 am, Frank Kühndel wrote:
> Hi Chris,
> 
> I compared the successful Debian-11 MIPS build with the failing AlmaLinux MIPS
> build.
> 
> The Debian 11 container has a native "expat.h" and "libexpat.a" installed (and
> the source-builder uses
> "rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/include/gmp.h"):

This is what I suspected. It seems like the paths are not right for the internal
staged libraries and I suspect my test systems has the header installed.

> 
> 
>   minna@e7a01fbe81fa:~/src$ find /usr -name expat.h
>   /usr/include/expat.h
>   minna@e7a01fbe81fa:~/src$ find /usr -name libexpat.\*
>   /usr/lib/x86_64-linux-gnu/libexpat.so
>   /usr/lib/x86_64-linux-gnu/libexpat.a
> 
> 
> With other words, the build on Debian is only successful because it uses the
> native "expat" from the OS. On Almalinux it is not installed so it fails. (The
> "expat" on Debian must be pulled in by some dependency from other needed 
> packages.)
> 
> The "6/rtems-mips.bset" build "gmp" and "gdb" twice but "expat" only once. In
> "tools/rtems-default-tools.bset" "gmp", "expat" and "gdb" are build the first 
> time:

The expat build is not internal and so this could be related. I made changes to
fix the internal builds and that may have broken the external staged build.

This raises a couple of questions:

1. Should expat be built if present on the system?

2. Should expat be an internal build?

Expat was added before I supported internal builds.

> 
> 
> %{with_rtems_dtc}
> %{with_rtems_expat}
> %{with_rtems_gmp}
> %{with_rtems_gsed}
> %{with_rtems_texinfo}
> %{with_rtems_gdb}
> %{with_rtems_binutils}
> %{with_rtems_gcc}
> %{with_rtems_tools}
> 
> 
> According to the log, after executing "tools/rtems-tools-6.cfg" there is a
> clean-up and all the above tools are cleaned away, including "gmp", "expat" 
> and
> "gdb", for example "expat":
> 
> 
> cleaning: expat-2.4.8-x86_64-linux-gnu-1
> [...]
> cleanup:
> /home/minna/src/rtems-source-builder/rtems/build/tmp/expat-2.4.8-x86_64-linux-gnu-1-1000
> removing:
> /home/minna/src/rtems-source-builder/rtems/build/tmp/expat-2.4.8-x86_64-linux-gnu-1-1000
> cleanup:
> /home/minna/src/rtems-source-builder/rtems/build/expat-2.4.8-x86_64-linux-gnu-1
> removing:
> /home/minna/src/rtems-source-builder/rtems/build/expat-2.4.8-x86_64-linux-gnu-1
> cleanup:
> /home/minna/src/rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-default-tools
> removing:
> /home/minna/src/rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-default-tools
> 
> 
> This is why it cannot be found later on and it is not in the remaining files.
> Afterwards "tools/rtems-mipstx39-gdb.bset" build "gmp" and "gdb" again but not
> "expat":
> 
> 
> devel/gmp-6.2.1
> tools/rtems-gdb-13.1
> 
> 
> This is the reason why this second "gdb" build finds "gmp" in
> "rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/include/gmp.h"
>  but not "expat.h". Yet, a copy of the whole stuff from the earlier 
> "tools/rtems-default-tools.bset" build is still in the 
> "rtems-source-builder/rtems/build/tmp/sb-1000-staging" tree. (Yet, it looks 
> like that at the end of the "tools/rtems-mipstx39-gdb.bset", the files from 
> second "gmp" build would overwrite the ones from first build in the 
> "sb-1000-staging" tree.
> 
> So I believe I am closer to the root of the problem now but I do not know what
> needs to be fixed.

All good. I think I have something solid to work on. I just need to find some
time to do this. It is important so it is high on my unfunded list.

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

Re: Build Linux: FAILED 6/rtems-v850 on x86_64-linux-gnu (v850-rtems6-gcc-28fc129-newlib-836d04d-x86_64-linux-gnu-1)

[Chris Johns]

On 20/4/2023 4:05 pm, Sebastian Huber wrote:
> On 19.04.23 02:07, Chris Johns wrote:
>> On 18/4/2023 11:29 pm,sebastian.hu...@embedded-brains.de  wrote:
>>> RTEMS Source Builder - Set Builder, 6 (7841a1e9056f)
>>> config: tools/rtems-gcc-10-newlib-head.cfg
>>> package: v850-rtems6-gcc-28fc129-newlib-836d04d-x86_64-linux-gnu-1
>>> warning: checksum error: gnu-mirror-gcc-28fc129.tar.gz
>> This gcc hash is not in the RSB?
> 
> I tried to update the tools since the GCC 13 release candidate will be 
> available
> soon.

Great and thanks for doing this. Is this for RTEMS 6?

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

Re: [rtems-source-builder PATCH] rtems: Add back gsed that was remove by mistake

[Chris Johns]

On 19/4/2023 11:26 pm, Frank Kühndel wrote:
> Hello Chris,
> 
> thanks for the introduction to package build. On AlmaLinux the file
> rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/build/gdb/config.log
>  (attached) contains this error:
> 
> 
> configure:21340: gcc -O2 -g -pipe
> -I/home/minna/src/rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/include
>  -o conftest -g -O2 
> -L/home/minna/src/rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/lib
>  conftest.c -lm -ldl  -lexpat >&5
> conftest.c:53:10: fatal error: expat.h: No such file or directory
>  #include "expat.h"
>   ^
> compilation terminated.
> 
> 
> The include file and the library would be in
> 
> rtems-source-builder/rtems/build/tmp/sb-1000-staging/include/expat.h

Is the staging include path in the build flags for GDB?

> rtems-source-builder/rtems/build/tmp/sb-1000-staging/lib/libexpat.a
> rtems-source-builder/rtems/build/tmp/sb-1000-staging/lib/libexpat.la
> 
> The directories mentioned in the gcc-invokation contain only
> 
>     84 -rw-r--r--   1  minna    users   84084 Apr 19 13:19
> rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/include/gmp.h
> 
> and
> 
>    6952 -rw-r--r--   1  minna    users 7115648 Apr 19 13:19
> rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/lib/libgmp.a
>   4 -rwxr-xr-x   1  minna    users 968 Apr 19 13:19
> rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/lib/libgmp.la
>   4 drwxr-xr-x   2  minna    users    4096 Apr 19 13:19
> rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/lib/pkgconfig
>   4 -rw-r--r--   1  minna    users 257 Apr 19 13:19
> rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/lib/pkgconfig/gmp.pc
> 
> Just for the records:
> 
> PARAM_ARCH="mips"
> PARAM_RTEMS_VERSION="6"
> PARAM_RSB_GIT_COMMIT="origin/master"
> GIT_HEAD="ae00c59541f21d8c459a33774efade80085c9b4a"
> CONT_OS_VERSION_ID="8.7"
> CONT_OS_ID="almalinux"
> 
> Let me know if you need more information. If you have a patch, I will be happy
> to feed our CI with it.

I do not know why this is happening so I am not sure how to fix it.

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

Re: [PATCH] bsps/microblaze: Add device tree support to GPIO driver

[Chris Johns]

On 20/4/2023 12:57 am, Alex White wrote:
> This removes the ability to statically configure a second GPIO device.
> Instead, any number of GPIO devices can be configured using the device
> tree. If a device tree is not used, a single GPIO device can still be
> configured statically.
> ---
>  .../microblaze_fpga/gpio/microblaze-gpio.c| 188 --
>  .../include/bsp/microblaze-gpio.h |  91 -
>  .../bsps/microblaze/microblaze_fpga/grp.yml   |  12 +-
>  .../microblaze_fpga/optgpio2dualchannel.yml   |  16 --
>  .../microblaze_fpga/optgpio2enable.yml|  17 --
>  .../microblaze_fpga/optgpio2interrupt.yml |  16 --
>  .../microblaze_fpga/optgpio2irq.yml   |  18 --

Is this for a custom FPGA image?

Are the IP pieces being used standard Xilinx IP? Could those IP pieces be used
on a Zynq or Versal? If so how would that happen?

We have other Xilinx IP in RTEMS without being specific to a BSP or using YAML
configuration options. The AXI I2C master is an example.

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

Re: [PATCH v2 1/3] cpukit/flash: Add API for Flash devices

[Chris Johns]

On 20/4/2023 7:42 am, Gedare Bloom wrote:
> On Mon, Apr 17, 2023 at 9:55 PM Chris Johns  wrote:
>>
>> On 18/4/2023 1:48 pm, Gedare Bloom wrote:
>>> On Sun, Apr 16, 2023 at 6:48 PM Aaron Nyholm
>>>  wrote:
>>>> As for the RTEMS_FLASHDEV_MAX_REGIONS being set at 32 I chose the value as 
>>>> it seamed a good balance between memory usage and function. I wanted to 
>>>> avoid using malloc as your previous feedback suggested. If configurable 
>>>> size is necessary what’s the best way to approach it without using malloc?
>>>>
>>> A configure-time option may be viable, e.g., spec/build/cpukit/opt*
>>> You should probably elevate that question to its own email thread to
>>> get other opinions.
>>
>> Is there an option that shows how to control a defined in an API header?
>>
> This has mostly been done in the past at a BSP level, so there are
> plenty of examples within BSP drivers and frameworks. Whether it is
> suitable to a cpukit driver framework is something I don't really
> know.
> 
> A quick example could be:
> BSP_CONSOLE_BAUD
> used in bsps/powerpc/shared/console
> define in spec/build/bsps/optconsolebaud.yml
> 
> I'm not saying this is for sure the right way to do this, but I think
> it is worth thinking through.

It is something Aaron and I discuss early on and it has just sat and not moved.
I think it is good to have it raised as part of the review.

> I think you would have to avoid using the define in the header itself
> to make it portable. The way it's defined in this code can be done
> with a RTEMS_ZERO_LENGTH_ARRAY. Then the driver that instantiates the
> structure can determine for itself the size of how many regions to
> support. Even that would be an improvement to the current hard-coded
> method. The size itself could be made a field of the rtems_flashdev
> that the driver would setup at init time. Whether it is made
> configurable in the spec/build approach, or determined by the driver
> itself, is less concerning to me than the fact it is currently not
> configurable at all and is assumed to be sufficient for all flash
> drivers to be 32.

We have just discussed this and he is looking at making the table a pointer and
adding a size for the table and the flash device instance can add a table that
suites the device. This means extra checks for the pointer being a NULL but not
much more (I hope). I think this change will make a better driver.

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

Re: Build Linux: FAILED 6/rtems-v850 on x86_64-linux-gnu (v850-rtems6-gcc-28fc129-newlib-836d04d-x86_64-linux-gnu-1)

[Chris Johns]

On 18/4/2023 11:29 pm, sebastian.hu...@embedded-brains.de wrote:
> RTEMS Source Builder - Set Builder, 6 (7841a1e9056f)
> config: tools/rtems-gcc-10-newlib-head.cfg
> package: v850-rtems6-gcc-28fc129-newlib-836d04d-x86_64-linux-gnu-1
> warning: checksum error: gnu-mirror-gcc-28fc129.tar.gz

This gcc hash is not in the RSB?

% grep -r 28fc129 config ../source-builder/config ../bare/config
% git st
On branch master
Your branch is up to date with 'origin/master'.

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

Re: [rtems-source-builder PATCH] rtems: Add back gsed that was remove by mistake

[Chris Johns]

t. 
>>> I
>>> only want to report an observation from our continuous integration (CI) 
>>> server.
>>>
>>> In the past the MIPS builds failed due to the fact that the packages
>>> (lib)gmp-devel and (lib)expat-devel where not installed in the containers. A
>>> minor nuisance because all other RTEMS tools do build without these. I never
>>> understood why in case of MIPS the host must provide native packages given
>>> the fact that "gmp" and "expat" are apparently configured in the MIPS 
>>> "bset".
>>>
>>> You recent patch thankfully improved the situation. Our CI builds MIPS on
>>> Debian and Ubuntu, now. I do not fully understand why but I believe those
>>> where the distros where the native gmp-devel packet was needed before your
>>> patch.
>>>
>>> For Alamalinux, Fedora and OpenSUSE the MIPS build still fails (apparently
>>> for the same reason they failed before your patch):
>>>
>>> [...]
>>> checking whether to use expat... yes
>>> checking for libexpat... no
>>> configure: error: expat is missing or unusable
>>> make[2]: *** [Makefile:11803: configure-gdb] Error 1
>>> make[2]: Leaving directory
>>> '/home/minna/src/rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/build'
>>> make[1]: *** [Makefile:1004: all] Error 2
>>> make[1]: Leaving directory
>>> '/home/minna/src/rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/build'
>>> shell cmd failed: /bin/sh -ex
>>> /home/minna/src/rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/do-build
>>> error: building mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1
>>>    See error report: 
>>> rsb-report-mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1.txt
>>>    Note: In some cases the error appears only in
>>>    the complete build log (see --log option)
>>>
>>>
>>> This is the end of the build log from Alamlinux 8.7. The error logs from the
>>> other distributions are identical.
>>>
>>> As I indicated before, you do not need to look into this or fix this issue
>>> for me as I do not use MIPS and I can easily add the required
>>> (lib)expat-devel packet to those containers. I just write because I thought
>>> you maybe interested in knowing this detail.
>>>
>>> Greetings
>>> Frank
>>>
>>>
>>> On 4/15/23 00:56, chr...@rtems.org wrote:
>>>> From: Chris Johns
>>>>
>>>> - Build GNU sed for hosts that it is not installed on for the MIPS
>>>>    tools.
>>>> ---
>>>>   rtems/config/tools/rtems-default-tools.bset | 3 ++-
>>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/rtems/config/tools/rtems-default-tools.bset
>>>> b/rtems/config/tools/rtems-default-tools.bset
>>>> index 0291786..35c9235 100644
>>>> --- a/rtems/config/tools/rtems-default-tools.bset
>>>> +++ b/rtems/config/tools/rtems-default-tools.bset
>>>> @@ -6,7 +6,7 @@
>>>>   # available
>>>>   #
>>>>   %define _internal_gsed_path %{_tmpinternal}
>>>> -%defineifnot with_rtems_gmp textproc/gsed-internal
>>>> +%defineifnot with_rtems_gsed textproc/gsed-internal
>>>>   # GNU tools need texinfo for makeinfo to build documentation
>>>>   %define _internal_texinfo_path %{_tmpinternal}
>>>> @@ -21,6 +21,7 @@
>>>>   %{with_rtems_dtc}
>>>>   %{with_rtems_expat}
>>>>   %{with_rtems_gmp}
>>>> +%{with_rtems_gsed}
>>>>   %{with_rtems_texinfo}
>>>>   %{with_rtems_gdb}
>>>>   %{with_rtems_binutils}
>>>> -- 2.37.1
>>>
>>> -- 
>>> embedded brains GmbH & Co. KG
>>> Herr Frank KÜHNDEL
>>> Dornierstr. 4
>>> 82178 Puchheim
>>> Germany
>>> email: frank.kuehn...@embedded-brains.de
>>> phone:  +49-89-18 94 741 - 23
>>> mobile: +49-176-15 22 06 - 11
>>>
>>> Registergericht: Amtsgericht München
>>> Registernummer: HRA 117265
>>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>>> Unsere Datenschutzerklärung finden Sie hier:
>>> https://embedded-brains.de/datenschutzerklaerung/
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>> -- 
>> embedded brains GmbH & Co. KG
>> Herr Frank KÜHNDEL
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: frank.kuehn...@embedded-brains.de
>> phone:  +49-89-18 94 741 - 23
>> mobile: +49-176-15 22 06 - 11
>>
>> Registergericht: Amtsgericht München
>> Registernummer: HRA 117265
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 1/3] cpukit/flash: Add API for Flash devices

[Chris Johns]

On 18/4/2023 1:48 pm, Gedare Bloom wrote:
> On Sun, Apr 16, 2023 at 6:48 PM Aaron Nyholm
>  wrote:
>> As for the RTEMS_FLASHDEV_MAX_REGIONS being set at 32 I chose the value as 
>> it seamed a good balance between memory usage and function. I wanted to 
>> avoid using malloc as your previous feedback suggested. If configurable size 
>> is necessary what’s the best way to approach it without using malloc?
>>
> A configure-time option may be viable, e.g., spec/build/cpukit/opt*
> You should probably elevate that question to its own email thread to
> get other opinions.

Is there an option that shows how to control a defined in an API header?

I have a quick look and could not see anything.

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

Re: [PATCH v2] bsps/aarch64: Enable MMU during remaps

[Chris Johns]

Looks good. OK to push.

Chris

On 18/4/2023 11:41 am, Kinsey Moore wrote:
> The MMU must be enabled during mapping changes and TLB invalidations.
> When this is not the case, TLB updates do not occur correctly in all
> cases. This is especially apparent when changing a block entry to a
> table entry when remapping small memory ranges in an otherwise
> contiguous block.
> ---
>  bsps/aarch64/shared/mmu/vmsav8-64.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/bsps/aarch64/shared/mmu/vmsav8-64.c 
> b/bsps/aarch64/shared/mmu/vmsav8-64.c
> index 270b9319ad..c426dec900 100644
> --- a/bsps/aarch64/shared/mmu/vmsav8-64.c
> +++ b/bsps/aarch64/shared/mmu/vmsav8-64.c
> @@ -54,10 +54,12 @@ rtems_status_code aarch64_mmu_map(
>  return RTEMS_INVALID_ADDRESS;
>}
>  
> -  /* Disable interrupts so they don't run while the MMU is disabled */
> +  /*
> +   * Disable interrupts so they don't run while the MMU tables are being
> +   * modified.
> +   */
>_ISR_Local_disable( level );
>  
> -  aarch64_mmu_disable();
>sc = aarch64_mmu_map_block(
>  (uint64_t *) bsp_translation_table_base,
>  0x0,
> @@ -72,7 +74,6 @@ rtems_status_code aarch64_mmu_map(
>);
>_AARCH64_Data_synchronization_barrier();
>_AARCH64_Instruction_synchronization_barrier();
> -  aarch64_mmu_enable();
>  
>_ISR_Local_enable( level );
>  
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems.org websites https not working?

[Chris Johns]

On 17/4/2023 6:16 am, Alan Cudmore wrote:
> Hi,
> When I try to go to docs.rtems.org , www.rtems.org
> , or git.rtems.org , I get an 
> error
> from my browser: ERR:CERT_DATE_INVALID.
> Just wanted to see if anyone else noticed this.

Thanks for the post and Amar has just sorted this.

We have a mix set of cert bots running (service1 new and service2 old) and the
certs on the older bot are still updated by hand. We plan to get the automation
sorted as part of the server work which is on going.

Chris

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

Re: [rtems-net-legacy PATCH] bsd: Add iface calls to help user manage the iface state

[Chris Johns]

On 15/4/2023 12:14 am, Gedare Bloom wrote:
> two nits below

Thanks for the review. I appreciate you doing it.

I will clean these up and push the result.

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

Re: [rtems-net-legacy commit] waf: Generate a version header called rtems-net-legacy.h

[Chris Johns]

On 15/4/2023 12:06 am, Gedare Bloom wrote:
> On Thu, Apr 13, 2023 at 11:59 PM Chris Johns  wrote:
>> +#ifndef _RTEMS_NET_LGEACY_H_
> typo in the header guard

Nice catch. Thanks. I will fix this.

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

Re: [rtems-net-legacy PATCH] waf: Generate a version header called rtems-net-legacy.h

[Chris Johns]

On 14/4/2023 3:40 pm, Vijay Kumar Banerjee wrote:
> 
> The patch looks great. Thanks.

Thanks for quick review. I will push it.

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

Re: [PATCH] spec/bsp/makecustom: Make BSP include path a system include path

[Chris Johns]

On 13/4/2023 11:48 pm, Will wrote:
> This change is fine, but it also needs the packageconfig change to match. The
> thread from October has the full patch (title was "[PATCH v2] spec/pkgconfig:
> Allow builds to override headers"). This also needs a change to libbsd to
> account for this alteration, IIRC.

I have just found the v2 version of your patch:

 https://lists.rtems.org/pipermail/devel/2022-October/073629.html

I will push it with a change to the commit message to close the ticket I opened.

This patch being missed highlights how we need a merge request system.

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

Re: [PATCH] spec/bsp/makecustom: Make BSP include path a system include path

[Chris Johns]

On 14/4/2023 1:32 am, Joel Sherrill wrote:
> On Thu, Apr 13, 2023 at 8:49 AM Will  > wrote:
> 
> This change is fine, but it also needs the packageconfig change to match.
> The thread from October has the full patch (title was "[PATCH v2]
> spec/pkgconfig: Allow builds to override headers"). This also needs a 
> change
> to libbsd to account for this alteration, IIRC.

Yes it does and thanks for raising this. I will pick up your changes as well.

> This is OK but the use of -B added to the system header file and library 
> include
> paths. If we don't want to use -B any longer,

GCC says:

 -Bprefix

This option specifies where to find the executables, libraries,
include files, and data files of the compiler itself.

I think -isystem is the option we want. The documentation says:

  The -isystem and -idirafter options also mark the directory as a
  system directory, so that it gets the same special treatment that
  is applied to the standard system directories.

Ref: https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html#Directory-Options

> there is likely a system library include argument that is needed.

That is not an issue with the packages I am dealing with. In Makefile.inc the
include path is part of CPPFLAGS and not LDFLAGS.

> And -B had nothing to do with the spec file except

Ah yes I was wrong.

> that it also told gcc where
> it was since it added that base directory as a system directory.

The documentation would indicate it is a compiler path and the -isystem path is
a system include path. We support builds with the tools (ie compiler) in one
path and RTEMS headers in another.

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

Re: [PATCH 00/18] Port PTPd to rtems-libbsd

[Chris Johns]

On 12/4/2023 11:54 pm, Gabriel Moyano wrote:
> These commits are for porting PTPd to rtems-libbsd and are based on the 
> master branch.
> 
> This work is a joint effort with Chris Johns, which we started some time ago.
> Originally, we wanted to port some of the commits to PTPd upstream but 
> unfortunately the project is no longer maintained (our pull request has been 
> open for more than a year).
> For this reason, we decided to add PTPd files as contrib.
> In fact, this is the first commit.
> 
> One important feature introduced to PTPd is the support for kqueue, which was 
> done by Chris.
> Also, a new test for running a PTPd instance was added to the test suit.
> 
> I'm happy to hear feedback from you.

Thank for you for all the work I know has gone into getting this package
together. It has been a journey. It is great to see the work reach this finished
level ready to merge.

Is this for the master, 6-freebsd-12 or both branches of libbsd?

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

Re: [PATCH 2/2] bsps/powerpc: Fix warnings with PPC_SPECIAL_PURPOSE_REGISTER

[Chris Johns]

On 11/4/2023 10:29 pm, Joel Sherrill wrote:
> Anything to add to the message beyond "fix" to explain this patch? :)
> 
> I think the software engineering guide uses a comment similar to this as an
> anti-pattern. Lol

How about:

- This change avoids the GCC extension of blocks in expressions that
  ISO forbids and is warned about with the pedantic warnings option.

?

Chris

> 
> On Tue, Apr 11, 2023, 12:00 AM mailto:chr...@rtems.org>> 
> wrote:
> 
> From: Chris Johns mailto:chr...@rtems.org>>
> 
> ---
>  bsps/powerpc/include/libcpu/powerpc-utility.h | 40 +++
>  .../powerpc/shared/exceptions/ppc_exc_print.c | 25 +++-
>  2 files changed, 38 insertions(+), 27 deletions(-)
> 
> diff --git a/bsps/powerpc/include/libcpu/powerpc-utility.h
> b/bsps/powerpc/include/libcpu/powerpc-utility.h
> index 922e5d2407..fb831c9fa8 100644
> --- a/bsps/powerpc/include/libcpu/powerpc-utility.h
> +++ b/bsps/powerpc/include/libcpu/powerpc-utility.h
> @@ -577,15 +577,11 @@ static inline void
> ppc_set_decrementer_register(uint32_t dec)
>   *
>   * @note This macro uses a GNU C extension.
>   */
> -#define PPC_SPECIAL_PURPOSE_REGISTER(spr) \
> -  ({ \
> -    uint32_t val; \
> -    __asm__ volatile (\
> -      "mfspr %0, " PPC_STRINGOF(spr) \
> -      : "=r" (val) \
> -    ); \
> -    val;\
> -  } )
> +#define PPC_SPECIAL_PURPOSE_REGISTER(spr, val) \
> +  __asm__ volatile (\
> +    "mfspr %0, " PPC_STRINGOF(spr) \
> +    : "=r" (val) \
> +  )
> 
>  /**
>   * @brief Sets the Special Purpose Register with number @a spr to the 
> value in
> @@ -612,7 +608,7 @@ static inline void 
> ppc_set_decrementer_register(uint32_t
> dec)
>      uint32_t val; \
>      uint32_t mybits = bits; \
>      _ISR_Local_disable(level); \
> -    val = PPC_SPECIAL_PURPOSE_REGISTER(spr); \
> +    PPC_SPECIAL_PURPOSE_REGISTER(spr, val); \
>      val |= mybits; \
>      PPC_SET_SPECIAL_PURPOSE_REGISTER(spr, val); \
>      _ISR_Local_enable(level); \
> @@ -632,7 +628,7 @@ static inline void 
> ppc_set_decrementer_register(uint32_t
> dec)
>      uint32_t mybits = bits; \
>      uint32_t mymask = mask; \
>      _ISR_Local_disable(level); \
> -    val = PPC_SPECIAL_PURPOSE_REGISTER(spr); \
> +    PPC_SPECIAL_PURPOSE_REGISTER(spr, val); \
>      val &= ~mymask; \
>      val |= mybits; \
>      PPC_SET_SPECIAL_PURPOSE_REGISTER(spr, val); \
> @@ -651,7 +647,7 @@ static inline void 
> ppc_set_decrementer_register(uint32_t
> dec)
>      uint32_t val; \
>      uint32_t mybits = bits; \
>      _ISR_Local_disable(level); \
> -    val = PPC_SPECIAL_PURPOSE_REGISTER(spr); \
> +    PPC_SPECIAL_PURPOSE_REGISTER(spr, val); \
>      val &= ~mybits; \
>      PPC_SET_SPECIAL_PURPOSE_REGISTER(spr, val); \
>      _ISR_Local_enable(level); \
> @@ -790,7 +786,9 @@ static inline void ppc_set_time_base(uint32_t val)
> 
>  static inline uint32_t ppc_time_base_upper(void)
>  {
> -  return PPC_SPECIAL_PURPOSE_REGISTER(TBRU);
> +  uint32_t val;
> +  PPC_SPECIAL_PURPOSE_REGISTER(TBRU, val);
> +  return val;
>  }
> 
>  static inline void ppc_set_time_base_upper(uint32_t val)
> @@ -810,12 +808,16 @@ static inline void ppc_set_time_base_64(uint64_t 
> val)
> 
>  static inline uint32_t ppc_alternate_time_base(void)
>  {
> -  return PPC_SPECIAL_PURPOSE_REGISTER(FSL_EIS_ATBL);
> +  uint32_t val;
> +  PPC_SPECIAL_PURPOSE_REGISTER(FSL_EIS_ATBL, val);
> +  return val;
>  }
> 
>  static inline uint32_t ppc_alternate_time_base_upper(void)
>  {
> -  return PPC_SPECIAL_PURPOSE_REGISTER(FSL_EIS_ATBU);
> +  uint32_t val;
> +  PPC_SPECIAL_PURPOSE_REGISTER(FSL_EIS_ATBU, val);
> +  return val;
>  }
> 
>  static inline uint64_t ppc_alternate_time_base_64(void)
> @@ -835,7 +837,9 @@ static inline uint64_t 
> ppc_alternate_time_base_64(void)
> 
>  static inline uint32_t ppc_processor_id(void)
>  {
> -  return PPC_SPECIAL_PURPOSE_REGISTER(BOOKE_PIR);
> +  uint32_t val;
> +  PPC_SPECIAL_PURPOSE_REGISTER(BOOKE_PIR, val);
> +  return val;
>  }
> 
>  static inline void ppc_set_processor_id(uint32_t val)
> @@ -845,7 +849,9 @@ static inline void ppc_set_processor_id(uint32_t val)
> 
>  static inline uint32_t ppc_fsl_system_version(void)
>  {
> -  return PPC_SPECIAL_PURPOS

Re: [PATCH 1/2] bsps/motorola_powerpc: Change defines from BSP names to avoid clash

[Chris Johns]

On 11/4/2023 10:44 pm, Joel Sherrill wrote:
> On Tue, Apr 11, 2023, 12:00 AM mailto:chr...@rtems.org>> 
> wrote:
> 
> From: Chris Johns mailto:chr...@rtems.org>>
> 
> - Change mvme2100 to mot_pcc_mvme2100 to avoid clashing with the
>   RTEMS_BSP value for the BSP. You cannot have a define that is the
>   BSP name.
> ---
>  bsps/mips/include/bsp/i8259.h                          |  4 ++--
>  bsps/powerpc/motorola_powerpc/include/bsp.h            |  6 +++---
>  bsps/powerpc/motorola_powerpc/include/bsp/VMEConfig.h  |  2 +-
>  bsps/powerpc/motorola_powerpc/include/bsp/irq.h        |  2 +-
>  bsps/powerpc/motorola_powerpc/start/bspreset.c         |  2 +-
>  bsps/powerpc/motorola_powerpc/start/bspstart.c         | 10 +-
>  bsps/powerpc/motorola_powerpc/start/motorola.c         |  2 +-
>  bsps/powerpc/shared/irq/irq_init.c                     |  6 +++---
>  bsps/powerpc/shared/pci/detect_raven_bridge.c          |  2 +-
>  bsps/powerpc/shared/rtc/todcfg.c                       |  6 +++---
>  .../bsps/powerpc/motorola_powerpc/optmvme2100.yml      |  2 +-
>  .../bsps/powerpc/motorola_powerpc/optmvme2307.yml      |  2 +-
>  .../bsps/powerpc/motorola_powerpc/optmvme2700.yml      |  2 +-
>  13 files changed, 24 insertions(+), 24 deletions(-)
> 
> diff --git a/bsps/mips/include/bsp/i8259.h b/bsps/mips/include/bsp/i8259.h
> index 1a947829b0..29e3853874 100644
> --- a/bsps/mips/include/bsp/i8259.h
> +++ b/bsps/mips/include/bsp/i8259.h
> @@ -37,7 +37,7 @@
>   * @{
>   */
> 
> 
> This patch looks ok except for this if 1. It appears it was already there but
> you touched it. Any explanation? Can the if 1 be removed? 
> 

It is a whitespace change and I decided to leave this in to clean it up. The
MIPS BSP as copied a header and I fixed the define to make sure all places have
been updated however any MIPS user should consider this common header being
shared but that is outside the scope of this change.

Is this OK?

Chris

> -#if 1
> +#if 1
>  #define ISA8259_M_ELCR                 0x4d0
>  #define ISA8259_S_ELCR                 0x4d1
>  #endif
> @@ -169,7 +169,7 @@ extern "C" {
> 
>  /** @} */
> 
> -#if defined(mvme2100)
> +#if defined(mot_ppc_mvme2100)
>  #define BSP_DEC21143_IRQ                (BSP_PCI_IRQ_LOWEST_OFFSET + 1)
>  #define BSP_PMC_PCMIP_TYPE1_SLOT0_IRQ   (BSP_PCI_IRQ_LOWEST_OFFSET + 2)
>  #define BSP_PCMIP_TYPE1_SLOT1_IRQ       (BSP_PCI_IRQ_LOWEST_OFFSET + 3)
> diff --git a/bsps/powerpc/motorola_powerpc/include/bsp.h
> b/bsps/powerpc/motorola_powerpc/include/bsp.h
> index db0995fa5c..d44bcd5cff 100644
> --- a/bsps/powerpc/motorola_powerpc/include/bsp.h
> +++ b/bsps/powerpc/motorola_powerpc/include/bsp.h
> @@ -89,7 +89,7 @@ extern "C" {
>   */
> 
>  /* fundamental addresses for BSP (CHRPxxx and PREPxxx are from 
> libcpu/io.h) */
> -#if defined(mvme2100)
> +#if defined(mot_ppc_mvme2100)
>  #define        _IO_BASE                CHRP_ISA_IO_BASE
>  #define        _ISA_MEM_BASE           CHRP_ISA_MEM_BASE
>  /* address of our ram on the PCI bus   */
> @@ -154,7 +154,7 @@ extern "C" {
>   *  find out what it is which is VERY different from other Motorola 
> boards.
>   */
> 
> -#if defined(mvme2100)
> +#if defined(mot_ppc_mvme2100)
>  #define BSP_UART_IOBASE_COM1 ((_IO_BASE)+0x01e1)
>  /* #define BSP_UART_IOBASE_COM1     (0xffe1) */
>  #define BSP_OPEN_PIC_BASE_OFFSET 0x4
> @@ -169,7 +169,7 @@ extern "C" {
>  #define BSP_VGA_IOBASE       ((_IO_BASE)+0x3c0)
>  #endif
> 
> -#if defined(mvme2300) || defined(mvme2307) || defined(mvme2700)
> +#if defined(mvme2300) || defined(mot_ppc_mvme2307) || 
> defined(mot_ppc_mvme2700)
>  #define MVME_HAS_DEC21140
>  #endif
>  #endif
> diff --git a/bsps/powerpc/motorola_powerpc/include/bsp/VMEConfig.h
> b/bsps/powerpc/motorola_powerpc/include/bsp/VMEConfig.h
> index 9b355819f1..9e57730d60 100644
> --- a/bsps/powerpc/motorola_powerpc/include/bsp/VMEConfig.h
> +++ b/bsps/powerpc/motorola_powerpc/include/bsp/VMEConfig.h
> @@ -66,7 +66,7 @@
>   * available and unused!
>   */
> 
> -#if defined(mvme2100)
> +#if defined(mot_ppc_mvme2100)
>  #define _VME_A32_WIN0_ON_PCI  0x9000
>  #define _VME_A24_ON_PCI      0x9f00
>  #define _VME_A16_ON_PCI      0x9fff
> diff --git a/bsps/powerpc/motorola_powerpc/include/bsp/irq.h
> b/bsps/powerpc/motorola_powerpc/include/bsp/irq.h
>

Re: Motorola PowerPC asm warning

[Chris Johns]

On 9/4/2023 1:26 am, Joel Sherrill wrote:
> 
> 
> On Fri, Apr 7, 2023, 6:55 PM Joel Sherrill  <mailto:j...@rtems.org>> wrote:
> 
> 
> 
> On Fri, Apr 7, 2023, 5:54 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
> Hi
> 
> Building the motorola_powerpc BSPs I noticed this warning:
> 
> ../../../bsps/powerpc/shared/exceptions/ppc_exc.S: Assembler messages:
> ../../../bsps/powerpc/shared/exceptions/ppc_exc.S:132: Warning: 
> invalid
> register
> expression
> ../../../bsps/powerpc/shared/exceptions/ppc_exc.S:135: Warning: 
> invalid
> register
> expression
> 
> 
> https://git.rtems.org/rtems/tree/bsps/powerpc/shared/exceptions/ppc_exc.S#n132
>  
> <https://git.rtems.org/rtems/tree/bsps/powerpc/shared/exceptions/ppc_exc.S#n132>
> 
> Can someone with an understanding of the PowerPC processors please
> comment if
> this is an issue or how we can remove the warning?
> 
> 
> It's from something in the macro. Any chance of a cut down of the
> preprocessed output and command it fails with?
> 
> 
> With that, we can compare the PPC model being compiled against with the
> instructions and registers. 
> 
> If it is Book E for an old PPC model, I don't think they will work since Book 
> E
> is way newer.

There are 3 machine flags used to build the file in the motorola_powerpc:

 -mcpu=603e
 -mcpu=604
 -mcpu=7400

and all have the warning. This is the command line for the mvme2100 BSP:

powerpc-rtems6-gcc -MMD -mcpu=603e -DASM -g \
  -Icpukit/include -I../../../cpukit/include \
  -Icpukit/score/cpu/powerpc/include \
  -I../../../cpukit/score/cpu/powerpc/include \
  -Ibsps/include -I../../../bsps/include -Ibsps/powerpc/include \
  -I../../../bsps/powerpc/include \
  -Ibsps/powerpc/motorola_powerpc/include \
  -I../../../bsps/powerpc/motorola_powerpc/include \
  ../../../bsps/powerpc/shared/exceptions/ppc_exc.S -c \
  -obsps/powerpc/shared/exceptions/ppc_exc.S.46.o

The warning is from the WRAP assembler macro:

https://git.rtems.org/rtems/tree/bsps/powerpc/shared/exceptions/ppc_exc_asm_macros.h#n730

The instruction in the TEST_LOCK_ assembler macro that is generating the 
warning is:

https://git.rtems.org/rtems/tree/bsps/powerpc/shared/exceptions/ppc_exc_asm_macros.h#n242

If I comment this instruction the warning goes away. The assembled object file
shows the instruction as:

06ac :
 6ac:   4e 52 11 02 crandc  4*cr4+eq,4*cr4+eq,eq

The pre-processed code is:

TEST_LOCK_crit_done_\_FLVR:
 crandc ((4)*4+2), ((4)*4+2), ((cr0)*4+2)

And in this case FLVR is bookE_crit. I have no idea what is happening in the 
code.

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

Re: [PATCH v3 1/3] bsps/microblaze: Allow copying FDT from U-Boot

[Chris Johns]

On 10/4/2023 1:47 pm, Alex White wrote:
>  .../microblaze_invalidate_dcache_range.S  | 104 ++

Why not provide the RTEMS cache API and use that?

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

Motorola PowerPC asm warning

[Chris Johns]

Hi

Building the motorola_powerpc BSPs I noticed this warning:

../../../bsps/powerpc/shared/exceptions/ppc_exc.S: Assembler messages:
../../../bsps/powerpc/shared/exceptions/ppc_exc.S:132: Warning: invalid register
expression
../../../bsps/powerpc/shared/exceptions/ppc_exc.S:135: Warning: invalid register
expression

https://git.rtems.org/rtems/tree/bsps/powerpc/shared/exceptions/ppc_exc.S#n132

Can someone with an understanding of the PowerPC processors please comment if
this is an issue or how we can remove the warning?

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

Re: [PATCH] bsps/motorola_powerpc: Add spec support for BSP defines

[Chris Johns]

Hi

I pushed this but had not noticed it results in:

SHLL [/] # rtems bsp
BSP: 1

which is fair enough, it is doing what is should.

I will rework the defines for mvme2307 and mvme2700 in the header file to be
`mot_ppc_mvme2307` and `mot_ppc_mvme2700` to avoid the clash of the names with
the macros.

Chris

On 6/4/2023 2:27 pm, chr...@rtems.org wrote:
> From: Chris Johns 
> 
> - These are need by the net legacy stack
> ---
>  .../bsps/powerpc/motorola_powerpc/grp.yml  |  4 
>  .../powerpc/motorola_powerpc/optmvme2307.yml   | 18 ++
>  .../powerpc/motorola_powerpc/optmvme2700.yml   | 18 ++
>  3 files changed, 40 insertions(+)
>  create mode 100644 spec/build/bsps/powerpc/motorola_powerpc/optmvme2307.yml
>  create mode 100644 spec/build/bsps/powerpc/motorola_powerpc/optmvme2700.yml
> 
> diff --git a/spec/build/bsps/powerpc/motorola_powerpc/grp.yml 
> b/spec/build/bsps/powerpc/motorola_powerpc/grp.yml
> index 0e5506ad88..c4849b6061 100644
> --- a/spec/build/bsps/powerpc/motorola_powerpc/grp.yml
> +++ b/spec/build/bsps/powerpc/motorola_powerpc/grp.yml
> @@ -32,6 +32,10 @@ links:
>uid: optmpc8240
>  - role: build-dependency
>uid: optmvme2100
> +- role: build-dependency
> +  uid: optmvme2307
> +- role: build-dependency
> +  uid: optmvme2700
>  - role: build-dependency
>uid: optqemu
>  - role: build-dependency
> diff --git a/spec/build/bsps/powerpc/motorola_powerpc/optmvme2307.yml 
> b/spec/build/bsps/powerpc/motorola_powerpc/optmvme2307.yml
> new file mode 100644
> index 00..da417b9c9b
> --- /dev/null
> +++ b/spec/build/bsps/powerpc/motorola_powerpc/optmvme2307.yml
> @@ -0,0 +1,18 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- get-boolean: null
> +- define-condition: null
> +build-type: option
> +copyrights:
> +- Copyright (C) 2023 Chris Johns
> +default:
> +- enabled-by: powerpc/mvme2307
> +  value: true
> +- enabled-by: true
> +  value: false
> +description: |
> +  Defined for MVME2307 -- undefined for others
> +enabled-by: true
> +links: []
> +name: mvme2307
> +type: build
> diff --git a/spec/build/bsps/powerpc/motorola_powerpc/optmvme2700.yml 
> b/spec/build/bsps/powerpc/motorola_powerpc/optmvme2700.yml
> new file mode 100644
> index 00..5b968bd1f0
> --- /dev/null
> +++ b/spec/build/bsps/powerpc/motorola_powerpc/optmvme2700.yml
> @@ -0,0 +1,18 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- get-boolean: null
> +- define-condition: null
> +build-type: option
> +copyrights:
> +- Copyright (C) 2023 Chris Johns
> +default:
> +- enabled-by: powerpc/mvme2700
> +  value: true
> +- enabled-by: true
> +  value: false
> +description: |
> +  Defined for MVME2700 -- undefined for others
> +enabled-by: true
> +links: []
> +name: mvme2700
> +type: build
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: powerpc/motorola_powerpc: Add MVME2700 BSP

[Chris Johns]

On 7/4/2023 1:28 am, Joel Sherrill wrote:
> Random (and late) question. For this generic BSP, the bsp.h has this:
> 
> LIBBSP_POWERPC_MOTOROLA_POWERPC_BSP_H
> 
> as the bsp guard. libbsd uses that to configure the nexus device and 
> peripherals. Are there board model differences which need to be taken
> into account? We would need a secondary define. The QorIQ has
> examples of that I think.

There is more work needed in libbsd for the BSP variants. At the moment on the
6-freebsd-12 branch it is only the DEC tulip driver and the unknown PHY. We can
use the RTEMS_BSP define to implement the specific changes when the time comes.
I am not sure when that will be. This patch is about the legacy stack and
compatibility and not libbsd.

The tulip driver in libbsd is for version 3 (I think) and later silicon and the
MVME2700 has rev 1 so I am not comfortable using it in production until it has a
number of hours in testing. As a result I am making sure the legacy stack is
fully functional with RTEMS 6 and it is. Nice work Vijay. This however effects
the RTEMS and EPICS integration.

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

Re: Add Flash Device API

[Chris Johns]

Hi Aaron,

Thanks for this. Is this v2 of patches?

Chris

On 6/4/2023 4:52 pm, aaron.nyh...@unfoldedeffective.com wrote:
> Attached is the updated flashdev API. I've focused on the feedback
> previously provided. I've added called the missing calls to bring
> this API inline with that of the zephyr example provided. The
> formatting is brought inline with RTEMS style. The shell command is
> extended to include all previous and added API calls. Included is a
> testsuite which tests the API calls and wraps a virtual flash device.
> 
> I want to thank you all for your understanding and feedback on my
> first submission. I'm more than happy to make further changes to 
> this submission based on feedback to provide an acceptable addition.
> 
> Thanks,
> Aaron.
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-net-legacy PATCH 2/2] testsuite: Add telenet02 test

[Chris Johns]

The commit missed the doco update. I will send a v2.

Chris

On 6/4/2023 3:08 pm, chr...@rtems.org wrote:
> From: Chris Johns 
> 
> ---
>  testsuites/telnetd02/init.c| 116 +
>  testsuites/telnetd02/telnetd02.doc |  11 +++
>  testsuites/telnetd02/telnetd02.scn |  11 +++
>  testsuites/telnetd02/wscript   |  50 +
>  testsuites/wscript |   2 +-
>  5 files changed, 189 insertions(+), 1 deletion(-)
>  create mode 100644 testsuites/telnetd02/init.c
>  create mode 100644 testsuites/telnetd02/telnetd02.doc
>  create mode 100644 testsuites/telnetd02/telnetd02.scn
>  create mode 100644 testsuites/telnetd02/wscript
> 
> diff --git a/testsuites/telnetd02/init.c b/testsuites/telnetd02/init.c
> new file mode 100644
> index 000..6f762db
> --- /dev/null
> +++ b/testsuites/telnetd02/init.c
> @@ -0,0 +1,116 @@
> +/*
> + * Copyright (c) 2018 embedded brains GmbH.  All rights reserved.
> + *
> + *  embedded brains GmbH
> + *  Dornierstr. 4
> + *  82178 Puchheim
> + *  Germany
> + *  
> + *
> + * The license and distribution terms for this file may be
> + * found in the file LICENSE in this distribution or at
> + * http://www.rtems.org/license/LICENSE.
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +const char rtems_test_name[] = "TELNETD 2";
> +
> +struct rtems_bsdnet_config rtems_bsdnet_config;
> +
> +rtems_shell_env_t env;
> +
> +static void telnet_shell( char *name, void *arg )
> +{
> +  rtems_shell_dup_current_env(  );
> +
> +  env.devname = name;
> +  env.taskname = "TLNT";
> +
> +  rtems_shell_main_loop(  );
> +}
> +
> +rtems_telnetd_config_table rtems_telnetd_config = {
> +  .command = telnet_shell,
> +  .stack_size = 8 * RTEMS_MINIMUM_STACK_SIZE,
> +};
> +
> +static rtems_task Init(rtems_task_argument argument)
> +{
> +  rtems_status_code sc;
> +  int rv;
> +
> +  TEST_BEGIN();
> +
> +  rtems_test_assert(rtems_net_legacy_config(_bsdnet_config));
> +
> +  rv = rtems_bsdnet_initialize_network();
> +  rtems_test_assert(rv == 0);
> +
> +  sc = rtems_telnetd_start( _telnetd_config );
> +  rtems_test_assert( sc == RTEMS_SUCCESSFUL );
> +
> +  sc = rtems_shell_init(
> +"SHLL",   /* task name */
> +RTEMS_MINIMUM_STACK_SIZE * 4, /* task stack size */
> +1,/* task priority */
> +"/dev/console",   /* device name */
> +false,/* run forever */
> +true, /* wait for shell to terminate */
> +NULL  /* login check function,
> + use NULL to disable a login check */
> +  );
> +  rtems_test_assert( sc == RTEMS_SUCCESSFUL );
> +
> +  TEST_END();
> +  rtems_test_exit(0);
> +}
> +
> +#define CONFIGURE_INIT
> +
> +#define CONFIGURE_MICROSECONDS_PER_TICK 1
> +
> +#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
> +#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> +#define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
> +
> +#define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS 32
> +
> +#define CONFIGURE_MAXIMUM_TASKS 12
> +
> +#define CONFIGURE_MAXIMUM_POSIX_KEYS 10
> +#define CONFIGURE_MAXIMUM_SEMAPHORES 20
> +#define CONFIGURE_MAXIMUM_MESSAGE_QUEUES 10
> +
> +#define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
> +
> +#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
> +
> +#define CONFIGURE_INIT_TASK_ATTRIBUTES RTEMS_FLOATING_POINT
> +
> +#define CONFIGURE_UNLIMITED_OBJECTS
> +#define CONFIGURE_UNIFIED_WORK_AREAS
> +
> +#define RTEMS_NETWORKING 1
> +#define CONFIGURE_SHELL_COMMANDS_INIT
> +#define CONFIGURE_SHELL_COMMANDS_ALL
> +#define CONFIGURE_SHELL_COMMANDS_ALL_NETWORKING
> +
> +#include 
> +
> +#include 
> diff --git a/testsuites/telnetd02/telnetd02.doc 
> b/testsuites/telnetd02/telnetd02.doc
> new file mode 100644
> index 000..7931c3c
> --- /dev/null
> +++ b/testsuites/telnetd02/telnetd02.doc
> @@ -0,0 +1,11 @@
> +This file describes the directives and concepts tested by this test set.
> +
> +test set name: telnetd01
> +
> +directives:
> +
> +  - rtems_telnetd_start()
> +
> +concepts:
> +
> ++ Check if Telnet server works.
> diff --git a/testsuites/telnetd02/telnetd02.scn 
> b/testsuites/telnetd02/telnetd02.scn
> new file mode 100644
> index 000..3e9cc00
> --- /dev/null
> +++ b/test

Re: [PATCH 7/8] rtems/mipsstx39: Update to GDB 13.1 and stage build GMP

[Chris Johns]

On 6/4/2023 3:27 am, Joel Sherrill wrote:
> This is separate because mipstx39 is not a full toolchain but we have to built
> this target to get the jmr3904 simulator. It should normally be in sync with 
> the
> other gdb configurations.
> 
> This looks ok.

Thanks. The ability for the RSB to stage builds based on build sets is proving
to be valuable in these type of situations. Fine grain control of dependent
packages seems to be an important long term need yet staging was added for other
reasons.

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

Re: [PATCH 1/8] dtc: Disable warnings

[Chris Johns]

On 6 Apr 2023, at 3:27 am, Joel Sherrill  wrote:Looks good.Does this stop build failures for warnings?YesChrisOn Tue, Apr 4, 2023 at 8:31 PM <chr...@rtems.org> wrote:From: Chris Johns <ch...@contemporary.net.au>

Updates #4892
---
 source-builder/config/dtc-1-1.cfg | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/source-builder/config/dtc-1-1.cfg b/source-builder/config/dtc-1-1.cfg
index 686a1e0..d42e91e 100644
--- a/source-builder/config/dtc-1-1.cfg
+++ b/source-builder/config/dtc-1-1.cfg
@@ -37,7 +37,7 @@ URL:     https://www.devicetree.org/

   %{build_build_flags}

-  %{__make} PREFIX=%{_prefix}
+  %{__make} PREFIX=%{_prefix} WARNINGS=

   cd ${build_top}

@@ -47,6 +47,6 @@ URL:     https://www.devicetree.org/
   rm -rf $SB_BUILD_ROOT

   cd dtc-%{dtc_version}
-  %{__make} DESTDIR=$SB_BUILD_ROOT PREFIX=%{_prefix} install
+  %{__make} DESTDIR=$SB_BUILD_ROOT PREFIX=%{_prefix} WARNINGS= install

   cd ${build_top}
-- 
2.37.1

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

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

Re: [PATCH 2/2] cpukit/libdl: Resolve size mismatch warnings

[Chris Johns]

OK to the libdl patch

Chris

On 5/4/2023 7:33 am, Kinsey Moore wrote:
> Resolve warnings about mismatched pointer and integer sizes in AArch64
> libdl when building with the ILP32 ABI.
> ---
>  cpukit/libdl/rtl-elf.c |  4 ++--
>  cpukit/libdl/rtl-mdreloc-aarch64.c | 31 +++---
>  cpukit/libdl/rtl-rap.c |  4 ++--
>  3 files changed, 20 insertions(+), 19 deletions(-)
> 
> diff --git a/cpukit/libdl/rtl-elf.c b/cpukit/libdl/rtl-elf.c
> index 8a21c5df73..5754070518 100644
> --- a/cpukit/libdl/rtl-elf.c
> +++ b/cpukit/libdl/rtl-elf.c
> @@ -192,7 +192,7 @@ rtems_rtl_elf_find_symbol (rtems_rtl_obj*  obj,
>  if (!*symbol)
>return false;
>  
> -*value = (Elf_Addr) (*symbol)->value;
> +*value = (Elf_Addr)(uintptr_t) (*symbol)->value;
>  return true;
>}
>  
> @@ -202,7 +202,7 @@ rtems_rtl_elf_find_symbol (rtems_rtl_obj*  obj,
>if (!sect)
>  return false;
>  
> -  *value = sym->st_value + (Elf_Addr) sect->base;
> +  *value = sym->st_value + (Elf_Addr)(uintptr_t) sect->base;
>  
>return true;
>  }
> diff --git a/cpukit/libdl/rtl-mdreloc-aarch64.c 
> b/cpukit/libdl/rtl-mdreloc-aarch64.c
> index e44238e636..25057ce9d7 100644
> --- a/cpukit/libdl/rtl-mdreloc-aarch64.c
> +++ b/cpukit/libdl/rtl-mdreloc-aarch64.c
> @@ -107,7 +107,7 @@ checkoverflow(Elf_Addr addr, int bitwidth, Elf_Addr 
> targetaddr,
>const Elf_Addr mask = ~__BITS(bitwidth - 1, 0);
>  
>if (((addr & mask) != 0) && ((addr & mask) != mask)) {
> -printf("kobj_reloc: Relocation 0x%jx too far from %p"
> +printf("kobj_reloc: Relocation 0x%" PRIxPTR " too far from %p"
>  " (base+0x%jx) for %dbit%s\n",
>  (uintptr_t)targetaddr, where, off, bitwidth, bitscale);
>  return true;
> @@ -120,7 +120,7 @@ static inline bool
>  checkalign(Elf_Addr addr, int alignbyte, void *where, Elf64_Addr off)
>  {
>if ((addr & (alignbyte - 1)) != 0) {
> -printf("kobj_reloc: Relocation 0x%jx unaligned at %p"
> +printf("kobj_reloc: Relocation 0x%" PRIxPTR " unaligned at %p"
>  " (base+0x%jx). must be aligned %d\n",
>  (uintptr_t)addr, where, off, alignbyte);
>  return true;
> @@ -257,7 +257,7 @@ rtems_rtl_elf_reloc_rela (rtems_rtl_obj*obj,
>  
>  if (rtems_rtl_trace (RTEMS_RTL_TRACE_RELOC))
>printf ("rtl: reloc 64/GLOB_DAT in %s --> %p in %s\n",
> -  sect->name, (void *)*where,
> +  sect->name, (void *)(uintptr_t)*where,
>rtems_rtl_obj_oname (obj));
>}
>break;
> @@ -270,10 +270,10 @@ rtems_rtl_elf_reloc_rela (rtems_rtl_obj*obj,
>   */
>  case R_TYPE(RELATIVE):  /* Delta(S) + A */
>if (!parsing) {
> -*where = (Elf_Addr)(sect->base + rela->r_addend);
> +*where = (Elf_Addr)(uintptr_t)(sect->base + rela->r_addend);
>  if (rtems_rtl_trace (RTEMS_RTL_TRACE_RELOC))
>printf ("rtl: reloc RELATIVE in %s --> %p in %s\n",
> -  sect->name, (void *)*where,
> +  sect->name, (void *)(uintptr_t)*where,
>rtems_rtl_obj_oname (obj));
>}
>break;
> @@ -304,7 +304,7 @@ rtems_rtl_elf_reloc_rela (rtems_rtl_obj*obj,
>shift = 12;
>break;
>  default:
> -  printf("illegal rtype: %ld\n", ELF_R_TYPE(rela->r_info));
> +  printf("illegal rtype: %" PRIu64 "\n", ELF_R_TYPE(rela->r_info));
>break;
>}
>  
> @@ -344,7 +344,7 @@ rtems_rtl_elf_reloc_rela (rtems_rtl_obj*obj,
>shift = 3;
>break;
>  default:
> -  printf("illegal rtype: %ld\n", ELF_R_TYPE(rela->r_info));
> +  printf("illegal rtype: %" PRIu64 "\n", ELF_R_TYPE(rela->r_info));
>break;
>}
>  
> @@ -360,9 +360,9 @@ rtems_rtl_elf_reloc_rela (rtems_rtl_obj*obj,
>  target = (Elf_Addr)symvalue + rela->r_addend;
>  if (checkalign(target, 1 << shift, where, off)) {
>printf ("rtl: reloc checkalign failed in %s --> %p in %s\n",
> -  sect->name, (void *)*where,
> +  sect->name, (void *)(uintptr_t)*where,
>rtems_rtl_obj_oname (obj));
> -  printf("ELF_R_TYPE is : %ld\n", ELF_R_TYPE(rela->r_info));
> +  printf("ELF_R_TYPE is : %" PRIu64 "\n", ELF_R_TYPE(rela->r_info));
>break;
>  }
>  target &= WIDTHMASK(12);
> @@ -433,7 +433,7 @@ rtems_rtl_elf_reloc_rela (rtems_rtl_obj*obj,
>return rtems_rtl_elf_rel_failure;
>  }
>  
> -tramp_addr = ((Elf_Addr) obj->tramp_brk) | (symvalue & 1);
> +tramp_addr = ((Elf_Addr)(uintptr_t)obj->tramp_brk) | (symvalue & 1);
>  obj->tramp_brk = set_veneer(obj->tramp_brk, symvalue);
>  
>  target = tramp_addr + rela->r_addend - (uintptr_t)where;
> @@ -468,29 +468,30 @@ rtems_rtl_elf_reloc_rela (rtems_rtl_obj*  

Re: [PATCH rtems-lwip] rtemslwip/xil_shims: Perform flush with invalidate

[Chris Johns]

On 4/4/2023 10:23 pm, Kinsey Moore wrote:
> On Mon, Apr 3, 2023 at 8:00 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
> On 31/3/2023 8:13 am, Kinsey Moore wrote:
> > Xilinx wrote their A53 HAL with the assumption that the CPU did not
> > support cache invalidation without a flush, so the flush and
> > invalidation functions were combined and all range invalidations are
> > promoted to flush/invalidate. The implementation written for lwIP was
> > written to the original intent of the function and thus was not flushing
> > in some cases when it needed to. This resolves that issue which prevents
> > DMA transmit errors in some cases.
> > ---
> >  rtemslwip/zynqmp/xil_shims.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/rtemslwip/zynqmp/xil_shims.c b/rtemslwip/zynqmp/xil_shims.c
> > index 2eda0c5..1b1b3cf 100644
> > --- a/rtemslwip/zynqmp/xil_shims.c
> > +++ b/rtemslwip/zynqmp/xil_shims.c
> > @@ -102,7 +102,12 @@ void XScuGic_DisableIntr ( u32 DistBaseAddress, u32
> Int_Id )
> >    rtems_interrupt_vector_disable( Int_Id );
> >  }
> > 
> > +/*
> > + * The Xilinx code was written such that it assumed there was no
> invalidate-only
> > + * functionality on A53 cores. This function must flush and invalidate
> because
> > + * of how they mapped things.
> > + */
> >  void Xil_DCacheInvalidateRange( INTPTR adr, INTPTR len )
> >  {
> > -  rtems_cache_invalidate_multiple_data_lines( (const void *) adr, len 
> );
> > +  rtems_cache_flush_multiple_data_lines( (const void *) adr, len );
> >  }
> 
> Does the Xilinx code use Xil_DCacheInvalidateRange in any DMA receive 
> paths? If
> it does is this change correct as the invalidate has been removed?
> 
> 
> It just so happens that the way the code was written, a flush and invalidate
> works fine for the receive path. The invalidation that occurs in the receive
> path occurs before the pointer to the memory is passed to the DMA engine, so a
> flush there doesn't hurt anything (at least for this particular driver). If 
> more
> Xilinx drivers get pulled in, that may have to be reevaluated.

Sure. If you think it is fine and are happy that is all that is need.

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

Re: [PATCH rtems-lwip] rtemslwip/xil_shims: Perform flush with invalidate

[Chris Johns]

On 31/3/2023 8:13 am, Kinsey Moore wrote:
> Xilinx wrote their A53 HAL with the assumption that the CPU did not
> support cache invalidation without a flush, so the flush and
> invalidation functions were combined and all range invalidations are
> promoted to flush/invalidate. The implementation written for lwIP was
> written to the original intent of the function and thus was not flushing
> in some cases when it needed to. This resolves that issue which prevents
> DMA transmit errors in some cases.
> ---
>  rtemslwip/zynqmp/xil_shims.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/rtemslwip/zynqmp/xil_shims.c b/rtemslwip/zynqmp/xil_shims.c
> index 2eda0c5..1b1b3cf 100644
> --- a/rtemslwip/zynqmp/xil_shims.c
> +++ b/rtemslwip/zynqmp/xil_shims.c
> @@ -102,7 +102,12 @@ void XScuGic_DisableIntr ( u32 DistBaseAddress, u32 
> Int_Id )
>rtems_interrupt_vector_disable( Int_Id );
>  }
>  
> +/*
> + * The Xilinx code was written such that it assumed there was no 
> invalidate-only
> + * functionality on A53 cores. This function must flush and invalidate 
> because
> + * of how they mapped things.
> + */
>  void Xil_DCacheInvalidateRange( INTPTR adr, INTPTR len )
>  {
> -  rtems_cache_invalidate_multiple_data_lines( (const void *) adr, len );
> +  rtems_cache_flush_multiple_data_lines( (const void *) adr, len );
>  }

Does the Xilinx code use Xil_DCacheInvalidateRange in any DMA receive paths? If
it does is this change correct as the invalidate has been removed?

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

Re: [PATCH v2] docs/user: add docs for riscv/kendrytek210 BSP variant

[Chris Johns]

On 4/4/2023 12:55 am, Alan Cudmore wrote:
> Hi Chris,
> Sorry I should have read that and formatted my changes correctly. I submitted 
> a
> v5 patch, but as I sent it, I realized that there are a couple of places where
> the RTEMS version macro can be embedded rather than hard-coding "6". I should
> have taken more time and avoided flooding the mailing list with extra 
> traffic. -
> But I'm much better at this process now :)
> Later today, I'll send a v6 patch with the rtems version macros.

Thanks for doing this and the contribution. It is appreciated.

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

Re: [PATCH v2] docs/user: add docs for riscv/kendrytek210 BSP variant

[Chris Johns]

Hi Alan,

We have a standard for the documentation source:

 https://git.rtems.org/rtems-docs/tree/README.txt#n469

Please note the line length. That can be relaxed when pasting in output but we
need the written text to be within the bounds.

Thanks
Chris

On 1/4/2023 3:15 am, Alan Cudmore wrote:
> This patch adds the documentation for building and running RTEMS on the 
> Kendryte K210
> RISC-V SoC. The generic riscv introducion was re-arranged to list the 
> multilib variants
> then the specific hardware targets. In addition a couple of errors were fixed 
> for the
> generic QEMU commands.
> 
> V2 corrected a typo, expanded K210 Console UART parameters, and addded a 
> hyperlink
> to renode.io install instructions.
> 
> Closes #4876
> ---
>  user/bsps/bsps-riscv.rst | 116 ++-
>  1 file changed, 103 insertions(+), 13 deletions(-)
> 
> diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rst
> index 41f369f..af79e6e 100644
> --- a/user/bsps/bsps-riscv.rst
> +++ b/user/bsps/bsps-riscv.rst
> @@ -8,7 +8,7 @@ riscv (RISC-V)
>  riscv
>  =
>  
> -This BSP offers 12 variants:
> +**This BSP offers 10 variants, each corresponding to a GCC multilib:**
>  
>  * rv32i
>  
> @@ -30,23 +30,22 @@ This BSP offers 12 variants:
>  
>  * rv64imafdc
>  
> -* frdme310arty
> -
> -* mpfs64imafdc
> -
> -Each rv* variant corresponds to a GCC multilib.  A particular variant 
> reflects an
> -ISA with ABI and code model choice. All rv64 BSPs have medany code model by
> +Each variant reflects an ISA with ABI and code model choice. All rv64 BSPs 
> have medany code model by
>  default, while rv32 BSPs are medlow. The reason is that RV32 medlow can 
> access
>  the entire 32-bit address space, while RV64 medlow can only access addresses
>  below 0x8000. With RV64 medany, it's possible to perform accesses above
> -0x8000.
> +0x8000. The BSP must be started in machine mode.
> +
> +The reference platform for the rv* variants is the QEMU `virt` machine.
> +
> +**The BSP also provides the following 3 variants for specific hardware 
> targets:**
>  
> -The BSP must be started im machine mode.
> +* frdme310arty - The reference platform for this variant is the Arty FPGA 
> board with the Sifive Freedom E310 reference design.
>  
> -The reference platform for this BSP is the QEMU `virt` machine.
> +* mpfs64imafdc - The reference platform for this variant is the Microchip 
> PolarFire SoC Icicle Kit.
> +
> +* kendrytek210 - The reference platform for this variant is the Kendryte 
> K210 SoC on the Sipeed MAiX Bit or MAiXDuino board.
>  
> -The reference platform for the mpfs64imafdc BSP variant is the Microchip
> -PolarFire SoC Icicle Kit.
>  
>  Build Configuration Options
>  ---
> @@ -90,6 +89,9 @@ configuration INI file. The ``waf`` defaults can be used to 
> inspect the values.
>   The maximum number of NS16550 devices supported by the console driver (2
>   by default).
>  
> +``RISCV_ENABLE_SIFIVE_UART_SUPPORT``
> + Enable the Sifive console UART (disabled by default)
> +
>  ``RISCV_RAM_REGION_BEGIN``
>   The begin of the RAM region for linker command file (default is 
> 0x8000).
>  
> @@ -104,6 +106,10 @@ configuration INI file. The ``waf`` defaults can be used 
> to inspect the values.
>   Enables support Microchip PolarFire SoC if defined to a non-zero
>   value, otherwise it is disabled (disabled by default).
>  
> +``RISCV_ENABLE_KENDRYTE_K210_SUPPORT``
> + Enables support for the Kendtryte K210 SoC if defined to a non-zero
> + value, otherwise it is disabled (disabled by default).
> +
>  ``RISCV_BOOT_HARTID``
>   The boot hartid (processor number) of risc-v cpu by default 0.
>  
> @@ -131,7 +137,7 @@ The console driver supports devices compatible to
>  
>  * "ns16750" (see ``RISCV_CONSOLE_MAX_NS16550_DEVICES`` BSP option).
>  
> -* "sifive,uart0" (see ``RISCV_ENABLE_FRDME310ARTY_SUPPORT`` BSP option).
> +* "sifive,uart0" (see ``RISCV_ENABLE_SIFIVE_UART_SUPPORT`` BSP option). This 
> console driver is used by the frdme310arty and kendrytek210 BSP variants.
>  
>  They are initialized according to the device tree.  The console driver does 
> not
>  configure the pins or peripheral clocks.  The console device is selected
> @@ -145,11 +151,13 @@ and spike machines. For instance, to run the 
> ``rv64imafdc`` BSP with the
>  following "config.ini" file.
>  
>  .. code-block:: none
> +
>  [riscv/rv64imafdc]
>  
>  Run the following QEMU command.
>  
>  .. code-block:: shell
> +
>  $ qemu-system-riscv64 -M virt -nographic -bios $RTEMS_EXE
>  $ qemu-system-riscv64 -M spike -nographic -bios $RTEMS_EXE
>  
> @@ -160,11 +168,13 @@ For instance, to run the ``rv64imafdc`` BSP with the 
> following
>  "config.ini" file.
>  
>  .. code-block:: none
> +
>  [riscv/rv64imafdc]
>  
>  Run the following Spike command.
>  
>  .. code-block:: shell
> +
>  $ spike --isa=rv64imafdc $RTEMS_EXE
>  
>  Unlike QEMU, Spike 

Re: [PATCH rtems-net-legacy] leon3: Replace ambapp_plb with ambapp_plb()

[Chris Johns]

OK to push.

Thanks
Chris

On 31/3/2023 11:20 am, Vijay Kumar Banerjee wrote:
> RTEMS commit 2c07f24af210c4738fbe6f75a53c58fbd80fb658 removed the ambapp_plb
> global variable
> ---
>  bsps/sparc/leon3/net/leon_greth.c|  3 ++-
>  bsps/sparc/leon3/net/leon_open_eth.c |  5 +++--
>  bsps/sparc/leon3/net/leon_smc9.c | 11 ++-
>  3 files changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/bsps/sparc/leon3/net/leon_greth.c 
> b/bsps/sparc/leon3/net/leon_greth.c
> index 5b0c99d..934728f 100644
> --- a/bsps/sparc/leon3/net/leon_greth.c
> +++ b/bsps/sparc/leon3/net/leon_greth.c
> @@ -13,6 +13,7 @@
>  
>  #include 
>  #include 
> +#include 
>  /*#if (GRETH_DEBUG & GRETH_DEBUG_PRINT_REGISTERS)*/
>  #include 
>  /*#endif*/
> @@ -36,7 +37,7 @@ int rtems_leon_greth_driver_attach(
>struct ambapp_apb_info *apb;
>  
>/* Scan for MAC AHB slave interface */
> -  adev = (void *)ambapp_for_each(_plb, (OPTIONS_ALL|OPTIONS_APB_SLVS),
> +  adev = (void *)ambapp_for_each(ambapp_plb(), 
> (OPTIONS_ALL|OPTIONS_APB_SLVS),
>   VENDOR_GAISLER, GAISLER_ETHMAC,
>   ambapp_find_by_idx, NULL);
>if (adev) {
> diff --git a/bsps/sparc/leon3/net/leon_open_eth.c 
> b/bsps/sparc/leon3/net/leon_open_eth.c
> index 2b386f8..315f6b7 100644
> --- a/bsps/sparc/leon3/net/leon_open_eth.c
> +++ b/bsps/sparc/leon3/net/leon_open_eth.c
> @@ -17,6 +17,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #if (OPEN_ETH_DEBUG & OPEN_ETH_DEBUG_PRINT_REGISTERS)
>  #include 
>  #endif
> @@ -40,11 +41,11 @@ int rtems_leon_open_eth_driver_attach(
>struct ambapp_ahb_info *ahb;
>  
>/* Scan for MAC AHB slave interface */
> -  adev = (void *)ambapp_for_each(_plb, (OPTIONS_ALL|OPTIONS_AHB_SLVS),
> +  adev = (void *)ambapp_for_each(ambapp_plb(), 
> (OPTIONS_ALL|OPTIONS_AHB_SLVS),
>   VENDOR_OPENCORES, OPENCORES_ETHMAC,
>   ambapp_find_by_idx, NULL);
>if (!adev) {
> -adev = (void *)ambapp_for_each(_plb, 
> (OPTIONS_ALL|OPTIONS_AHB_SLVS),
> +adev = (void *)ambapp_for_each(ambapp_plb(), 
> (OPTIONS_ALL|OPTIONS_AHB_SLVS),
> VENDOR_GAISLER, GAISLER_ETHAHB,
> ambapp_find_by_idx, NULL);
>}
> diff --git a/bsps/sparc/leon3/net/leon_smc9.c 
> b/bsps/sparc/leon3/net/leon_smc9.c
> index 70b2dcc..6577f28 100644
> --- a/bsps/sparc/leon3/net/leon_smc9.c
> +++ b/bsps/sparc/leon3/net/leon_smc9.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define SMC9_BASE_ADDR (void*)0x2300
>  #define SMC9_BASE_IRQ  4
> @@ -45,7 +46,7 @@ rtems_smc9_driver_attach_leon3 (struct 
> rtems_bsdnet_ifconfig *config,
>struct ambapp_apb_info apbpio;
>struct ambapp_apb_info apbmctrl;
>  
> -  if (ambapp_find_apbslv(_plb, VENDOR_GAISLER, GAISLER_GPIO, )
> +  if (ambapp_find_apbslv(ambapp_plb(), VENDOR_GAISLER, GAISLER_GPIO, )
>!= 1) {
>  printk("SMC9111_leon3: didn't find PIO\n");
>  return 0;
> @@ -54,12 +55,12 @@ rtems_smc9_driver_attach_leon3 (struct 
> rtems_bsdnet_ifconfig *config,
>/* In order to access the SMC controller the memory controller must have
> * I/O bus enabled. Find first memory controller.
> */
> -  if (ambapp_find_apbslv(_plb, VENDOR_ESA, ESA_MCTRL, ) != 
> 1) {
> -if (ambapp_find_apbslv(_plb, VENDOR_GAISLER, GAISLER_FTMCTRL,
> +  if (ambapp_find_apbslv(ambapp_plb(), VENDOR_ESA, ESA_MCTRL, ) != 
> 1) {
> +if (ambapp_find_apbslv(ambapp_plb(), VENDOR_GAISLER, GAISLER_FTMCTRL,
> ) != 1) {
> -  if (ambapp_find_apbslv(_plb, VENDOR_GAISLER, GAISLER_FTSRCTRL,
> +  if (ambapp_find_apbslv(ambapp_plb(), VENDOR_GAISLER, GAISLER_FTSRCTRL,
>   ) != 1) {
> -if (ambapp_find_apbslv(_plb, VENDOR_GAISLER, 
> GAISLER_FTSRCTRL8,
> +if (ambapp_find_apbslv(ambapp_plb(), VENDOR_GAISLER, 
> GAISLER_FTSRCTRL8,
> ) != 1) {
>printk("SMC9111_leon3: didn't find any memory controller\n");
>return 0;
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-lwip] rtemslwip/xil_shims: Avoid hang in IRQ context

[Chris Johns]

OK

Chris

On 31/3/2023 3:49 am, Kinsey Moore wrote:
> Do not try to alter IRQ server handlers while executing in the IRQ
> server thread context. This change avoids a deadlock in CGEM error
> condition handling that causes a reinitialization of the driver which
> attempts to reinstall the IRQ handler from within the IRQ handler. This
> deadlocks inside the IRQ server handler installation code while holding
> the lwIP system protection lock thus deadlocking all threads that try to
> access lwIP functionality.
> ---
>  rtemslwip/zynqmp/xil_shims.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/rtemslwip/zynqmp/xil_shims.c b/rtemslwip/zynqmp/xil_shims.c
> index ec9ed12..2eda0c5 100644
> --- a/rtemslwip/zynqmp/xil_shims.c
> +++ b/rtemslwip/zynqmp/xil_shims.c
> @@ -27,8 +27,10 @@
>  #include "xil_mmu.h"
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  
>  #define TWO_MB (2*1024*1024)
>  #define ONE_GB (1024*1024*1024)
> @@ -67,6 +69,15 @@ BaseType_t xPortInstallInterruptHandler(
>void *pvCallBackRef
>  )
>  {
> +  char name[10];
> +
> +  /* Is this running in the context of any interrupt server tasks? */
> +  _Thread_Get_name( _Thread_Get_executing(), name, sizeof( name ) );
> +  if (strcmp(name, "IRQS") == 0) {
> +/* Can't run this from within an IRQ Server thread context */
> +return RTEMS_ILLEGAL_ON_SELF;
> +  }
> +
>rtems_status_code sc = rtems_interrupt_server_handler_install(
>  RTEMS_INTERRUPT_SERVER_DEFAULT,
>  ucInterruptID,
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/3] bsps/microblaze: Add support for multiple UARTs

[Chris Johns]

On 31/3/2023 2:55 am, Alex White wrote:
> On Wed, Mar 29, 2023 at 11:04 PM Chris Johns  wrote:
>>
>> On 30/3/2023 12:26 pm, Sam Price wrote:
>>> Same IP as the regular KCU105.
>>> The current uart ip is dependent on the fpga.
>>> I don't believe this modifies the kcu105 bsp, but allows other bsps to
>>> support up to 4 uarts.
>>
>> I am not sure if this patch is OK. If the UART driver is needed for a console
>> does that limits how it's configuration can be handled? If so that means the
>> patch is OK. Adding options for a user's custom IP is questionable.
> 
> This patch allows the user to use multiple instances of the same UART IP (AXI 
> UART Lite v2.0) which is currently the only IP supported by the BSP.

What happens if a user needs more than 4 ports? I was discussing such a project
recently with someone and Microblaze may be an option?

I do not have a better solution at the moment so I am just understand the what
we accept and why plus how we manage it.

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

Re: [PATCH 2/3] bsps/microblaze: Add support for multiple UARTs

[Chris Johns]

On 30/3/2023 12:26 pm, Sam Price wrote:
> Same IP as the regular KCU105.
> The current uart ip is dependent on the fpga.
> I don't believe this modifies the kcu105 bsp, but allows other bsps to
> support up to 4 uarts.

I am not sure if this patch is OK. If the UART driver is needed for a console
does that limits how it's configuration can be handled? If so that means the
patch is OK. Adding options for a user's custom IP is questionable.

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

Re: [PATCH] Add support for ELF notes

[Chris Johns]

On 30/3/2023 2:07 am, Sebastian Huber wrote:
> On 28.03.23 23:46, Chris Johns wrote:
>> On 29/3/2023 5:36 am, Sebastian Huber wrote:
>>> On 28.03.23 09:26, Chris Johns wrote:
>>>> On 28/3/2023 6:20 pm, Sebastian Huber wrote:
>>>>> On 28.03.23 09:03, Chris Johns wrote:
>>>>>> On 28/3/2023 5:48 pm, Sebastian Huber wrote:
>>>>>>> On 25.03.23 00:39, Chris Johns wrote:
>>>>>>>> On 24/3/2023 7:32 pm, Sebastian Huber wrote:
>>>>>>>>> On 23.03.23 20:07, Chris Johns wrote:
>>>>>>>>>> On 24/3/2023 3:57 am, Sebastian Huber wrote:
>>>>>>>>>>> On 23.03.23 17:52, Will wrote:
>>>>>>>>>>>> Great idea to store this information in the executable itself. Does
>>>>>>>>>>>> this
>>>>>>>>>>>> need
>>>>>>>>>>>> a RTEMS_TEST_STATE_LINK_ONLY test state or something similar for
>>>>>>>>>>>> minimum.exe?
>>>>>>>>>>> With the notes you can build the test. The test runner would look 
>>>>>>>>>>> at the
>>>>>>>>>>> notes
>>>>>>>>>>> and then decide if it makes sense to run the test or not. It could 
>>>>>>>>>>> still
>>>>>>>>>>> run the
>>>>>>>>>>> minimum.exe and see if it terminates.
>>>>>>>>>> I welcome notes support. Thanks for adding it.
>>>>>>>>>>
>>>>>>>>>> How will we control and manage the notes we support?
>>>>>>>>> In the new elfnote.h header file there are defines for the note type
>>>>>>>>> (domain-specific integer).
>>>>>>>> Great.
>>>>>>>>
>>>>>>>>>> Should we document the top level notes domains (?) with some we
>>>>>>>>>> control and
>>>>>>>>>> restrict and others users can use? For example `note.rtems.test`,
>>>>>>>>>> `note.rtems.kernel`, `note.rtems.bsp`, and `note.rtems.user`?
>>>>>>>>> The section name doesn't matter. You can divide the number space of 
>>>>>>>>> the
>>>>>>>>> note
>>>>>>>>> type for this.
>>>>>>>> Does this mean we define the numbers or number ranges or is it left 
>>>>>>>> open?
>>>>>>>> I am
>>>>>>>> not sure I am following this bit.
>>>>>>> The patch has this:
>>>>>>>
>>>>>>> #define ELF_NOTE_RTEMS_TYPE( _index ) ( ( _index ) + 0x1 )
>>>>>>>
>>>>>>> We basically have 32-bits available. We could also use something like 
>>>>>>> this:
>>>>>>>
>>>>>>> #define ELF_NOTE_RTEMS_BASE_TYPE( _index ) ( ( _index ) + 0x1000 )
>>>>>>>
>>>>>>> #define ELF_NOTE_RTEMS_TEST_TYPE( _index ) ( ( _index ) + 0x2000 )
>>>>>>>
>>>>>>> #define ELF_NOTE_RTEMS_USER_TYPE( _index ) ( ( _index ) + 0x3000 )
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>> Nice.
>>>>> Maybe we should also encode the data type here, for example:
>>>>>
>>>>> #define ELF_NOTE_DATA_TYPE_BOOL 0
>>>>> #define ELF_NOTE_DATA_TYPE_INT8 1
>>>>> #define ELF_NOTE_DATA_TYPE_UINT8 2
>>>>> #define ELF_NOTE_DATA_TYPE_INT16 3
>>>>> #define ELF_NOTE_DATA_TYPE_UINT16 4
>>>>> #define ELF_NOTE_DATA_TYPE_INT32 5
>>>>> #define ELF_NOTE_DATA_TYPE_UINT32 6
>>>>> #define ELF_NOTE_DATA_TYPE_INT64 7
>>>>> #define ELF_NOTE_DATA_TYPE_UINT64 8
>>>>> #define ELF_NOTE_DATA_TYPE_FLOAT32 9
>>>>> #define ELF_NOTE_DATA_TYPE_FLOAT32 10
>>>>> #define ELF_NOTE_DATA_TYPE_FLOAT64 11
>>>>> #define ELF_NOTE_DATA_TYPE_FLOAT64 12
>>>>> #define ELF_NOTE_DATA_TYPE_STRING 13
>>>>> #define ELF_NOTE_DATA_TYPE_BINARY 14
>>>>>
>>>>> #define ELF_NOTE_RTEMS_BASE_TYPE( _data_type, _index ) \
>>>>>     ( ( ( _data_type ) << 28 ) | ( ( _index ) + 0x100 ) )
>>>>>
>>>>> This could be used by the host tool to more easily produce the right JSON
>>>>> data.
>>>>>
>>>> Good idea. I cannot think of anything else as scoping would tend to reduce 
>>>> to a
>>>> new type.
>>> Another option would be to add a GNU note type for JSON data. The note
>>> description would be an arbitrary JSON string.
>> Wooo that is interesting. JSON can be useful in these situations. I like it.
> 
> It looks like we are not the only ones needing such a thing. Nick Clifton
> suggested to use this:
> 
> https://systemd.io/ELF_PACKAGE_METADATA/
> 
> https://sourceware.org/pipermail/binutils/2023-March/126822.html

This is interesting and useful. I still think your notes support is needed.

Between the addition of considered notes and DWARF you can tell a lot about the
make up of an executable and that could form the base of a audit type check. For
example all objects are built with the same compiler and ABI options. I see no
point in saying a test has passed if the make up of the exe is not considered
"correct".

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

Re: [PATCH rtems-lwip 1/2] rtemslwip: Use common lwipopts for all BSPs

[Chris Johns]

This looks good. Thanks for cleaning this up.

Chris

On 30/3/2023 7:51 am, Kinsey Moore wrote:
> This reworks all BSPs to use a shared lwipopts.h that includes
> lwipbspopts.h for per-BSP configuration instead of having lwIP
> configuration scattered everywhere for individual BSPs. This also
> consolidates the shared portions of ZynqMP BSP-specific configuration
> and Xilinx-specific configuration into shared files for reuse.
> ---
>  defs/bsps/arm/tms570_base.json  |   1 +
>  rtemslwip/beaglebone/lwipbspopts.h  |   1 +
>  rtemslwip/beaglebone/lwipopts.h | 276 ---
>  rtemslwip/include/legacy_lwipopts.h |  53 +
>  rtemslwip/include/lwipopts.h| 281 
>  rtemslwip/tms570/lwipbspopts.h  |   1 +
>  rtemslwip/xilinx/xlwipopts.h|  35 +++
>  rtemslwip/zynqmp/common_lwipopts.h  |   3 +
>  rtemslwip/zynqmp/lwipopts.h | 128 ---
>  rtemslwip/zynqmp_cfc400x/lwipbspopts.h  |   2 +-
>  rtemslwip/zynqmp_hardware/lwipbspopts.h |   2 +-
>  rtemslwip/zynqmp_qemu/lwipbspopts.h |   2 +-
>  uLan/ports/os/lwipopts.h| 272 ---
>  13 files changed, 378 insertions(+), 679 deletions(-)
>  create mode 100644 rtemslwip/beaglebone/lwipbspopts.h
>  delete mode 100644 rtemslwip/beaglebone/lwipopts.h
>  create mode 100644 rtemslwip/include/legacy_lwipopts.h
>  create mode 100644 rtemslwip/include/lwipopts.h
>  create mode 100644 rtemslwip/tms570/lwipbspopts.h
>  create mode 100644 rtemslwip/xilinx/xlwipopts.h
>  create mode 100644 rtemslwip/zynqmp/common_lwipopts.h
>  delete mode 100644 rtemslwip/zynqmp/lwipopts.h
>  delete mode 100644 uLan/ports/os/lwipopts.h
> 
> diff --git a/defs/bsps/arm/tms570_base.json b/defs/bsps/arm/tms570_base.json
> index a1d1e24..e618d5c 100644
> --- a/defs/bsps/arm/tms570_base.json
> +++ b/defs/bsps/arm/tms570_base.json
> @@ -2,6 +2,7 @@
>   "header-paths-to-import": [
>   "uLan/ports/driver/tms570_emac",
>   "uLan/ports/os",
> + "rtemslwip/tms570",
>   "cpsw/src/include"
>   ],
>   "source-files-to-import": [
> diff --git a/rtemslwip/beaglebone/lwipbspopts.h 
> b/rtemslwip/beaglebone/lwipbspopts.h
> new file mode 100644
> index 000..85b08af
> --- /dev/null
> +++ b/rtemslwip/beaglebone/lwipbspopts.h
> @@ -0,0 +1 @@
> +#include 
> diff --git a/rtemslwip/beaglebone/lwipopts.h b/rtemslwip/beaglebone/lwipopts.h
> deleted file mode 100644
> index 888fae4..000
> --- a/rtemslwip/beaglebone/lwipopts.h
> +++ /dev/null
> @@ -1,276 +0,0 @@
> -#if 0
> -/*
> - * Copyright (c) 2001-2003 Swedish Institute of Computer Science.
> - * All rights reserved. 
> - * 
> - * 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.
> - * 3. The name of the author may not be used to endorse or promote products
> - *derived from this software without specific prior written permission. 
> - *
> - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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 AUTHOR 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.
> - *
> - * This file is part of the lwIP TCP/IP stack.
> - * 
> - * Author: Simon Goldschmidt
> - *
> - */
> -#ifndef LWIP_HDR_LWIPOPTS_H__
> -#define LWIP_HDR_LWIPOPTS_H__
> -
> -/* Prevent having to link sys_arch.c (we don't test the API layers in unit 
> tests) */
> -#define NO_SYS  0
> -#define LWIP_NETCONN1
> -#define LWIP_SOCKET 1
> -#define LWIP_DNS1
> -
> -#define LWIP_IPV6   1
> -#define LWIP_IPV4   1
> -
> -#define LWIP_ETHERNET   1
> -#define LWIP_NETIF_API  1
> -#define LWIP_AUTOIP 1
> -/* Enable DHCP to test it, disable UDP checksum to easier inject packets */
> -#define 

Re: [PATCH 2/3] bsps/microblaze: Add support for multiple UARTs

[Chris Johns]

On 30/3/2023 6:22 am, Alex White wrote:
> From: "Maldonado, Sergio E. (GSFC-580.0)"   .../microblaze/microblaze_fpga/optuartirq.yml |  20 ++
>  .../microblaze/microblaze_fpga/optuseuart.yml |  17 ++
>  .../microblaze_fpga/optuseuart1.yml   |  17 ++
>  .../microblaze_fpga/optuseuart2.yml   |  17 ++
>  .../microblaze_fpga/optuseuart3.yml   |  17 ++
>  .../microblaze_fpga/optuseuart4.yml   |  17 ++

Are these 4 UARTs dependent on the IP built into the FPGA with the Microblaze 
core?

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

Re: [PATCH] Add support for ELF notes

[Chris Johns]

On 29/3/2023 5:36 am, Sebastian Huber wrote:
> On 28.03.23 09:26, Chris Johns wrote:
>> On 28/3/2023 6:20 pm, Sebastian Huber wrote:
>>> On 28.03.23 09:03, Chris Johns wrote:
>>>> On 28/3/2023 5:48 pm, Sebastian Huber wrote:
>>>>> On 25.03.23 00:39, Chris Johns wrote:
>>>>>> On 24/3/2023 7:32 pm, Sebastian Huber wrote:
>>>>>>> On 23.03.23 20:07, Chris Johns wrote:
>>>>>>>> On 24/3/2023 3:57 am, Sebastian Huber wrote:
>>>>>>>>> On 23.03.23 17:52, Will wrote:
>>>>>>>>>> Great idea to store this information in the executable itself. Does 
>>>>>>>>>> this
>>>>>>>>>> need
>>>>>>>>>> a RTEMS_TEST_STATE_LINK_ONLY test state or something similar for
>>>>>>>>>> minimum.exe?
>>>>>>>>> With the notes you can build the test. The test runner would look at 
>>>>>>>>> the
>>>>>>>>> notes
>>>>>>>>> and then decide if it makes sense to run the test or not. It could 
>>>>>>>>> still
>>>>>>>>> run the
>>>>>>>>> minimum.exe and see if it terminates.
>>>>>>>> I welcome notes support. Thanks for adding it.
>>>>>>>>
>>>>>>>> How will we control and manage the notes we support?
>>>>>>> In the new elfnote.h header file there are defines for the note type
>>>>>>> (domain-specific integer).
>>>>>> Great.
>>>>>>
>>>>>>>> Should we document the top level notes domains (?) with some we 
>>>>>>>> control and
>>>>>>>> restrict and others users can use? For example `note.rtems.test`,
>>>>>>>> `note.rtems.kernel`, `note.rtems.bsp`, and `note.rtems.user`?
>>>>>>> The section name doesn't matter. You can divide the number space of the 
>>>>>>> note
>>>>>>> type for this.
>>>>>> Does this mean we define the numbers or number ranges or is it left open?
>>>>>> I am
>>>>>> not sure I am following this bit.
>>>>> The patch has this:
>>>>>
>>>>> #define ELF_NOTE_RTEMS_TYPE( _index ) ( ( _index ) + 0x1 )
>>>>>
>>>>> We basically have 32-bits available. We could also use something like 
>>>>> this:
>>>>>
>>>>> #define ELF_NOTE_RTEMS_BASE_TYPE( _index ) ( ( _index ) + 0x1000 )
>>>>>
>>>>> #define ELF_NOTE_RTEMS_TEST_TYPE( _index ) ( ( _index ) + 0x2000 )
>>>>>
>>>>> #define ELF_NOTE_RTEMS_USER_TYPE( _index ) ( ( _index ) + 0x3000 )
>>>>>
>>>>> ...
>>>>>
>>>> Nice.
>>> Maybe we should also encode the data type here, for example:
>>>
>>> #define ELF_NOTE_DATA_TYPE_BOOL 0
>>> #define ELF_NOTE_DATA_TYPE_INT8 1
>>> #define ELF_NOTE_DATA_TYPE_UINT8 2
>>> #define ELF_NOTE_DATA_TYPE_INT16 3
>>> #define ELF_NOTE_DATA_TYPE_UINT16 4
>>> #define ELF_NOTE_DATA_TYPE_INT32 5
>>> #define ELF_NOTE_DATA_TYPE_UINT32 6
>>> #define ELF_NOTE_DATA_TYPE_INT64 7
>>> #define ELF_NOTE_DATA_TYPE_UINT64 8
>>> #define ELF_NOTE_DATA_TYPE_FLOAT32 9
>>> #define ELF_NOTE_DATA_TYPE_FLOAT32 10
>>> #define ELF_NOTE_DATA_TYPE_FLOAT64 11
>>> #define ELF_NOTE_DATA_TYPE_FLOAT64 12
>>> #define ELF_NOTE_DATA_TYPE_STRING 13
>>> #define ELF_NOTE_DATA_TYPE_BINARY 14
>>>
>>> #define ELF_NOTE_RTEMS_BASE_TYPE( _data_type, _index ) \
>>>    ( ( ( _data_type ) << 28 ) | ( ( _index ) + 0x100 ) )
>>>
>>> This could be used by the host tool to more easily produce the right JSON 
>>> data.
>>>
>> Good idea. I cannot think of anything else as scoping would tend to reduce 
>> to a
>> new type.
> 
> Another option would be to add a GNU note type for JSON data. The note
> description would be an arbitrary JSON string. 

Wooo that is interesting. JSON can be useful in these situations. I like it.

Chris

> For example:
> 
> diff --git a/binutils/readelf.c b/binutils/readelf.c
> index cafba9a4f56..1d977376b77 100644
> --- a/binutils/readelf.c
> +++ b/binutils/readelf.c
> @@ -20261,6 +20261,10 @@ print_gnu_note (Filedata * filedata, 
> Elf_Internal_Note
> *pnote)
>    print_gnu_property_note (filedata, pnote);
>    break;
> 
> +    case NT_GNU_JSON:
> +  print_json_note (filedata, pnote);
> +  break;
> +
>  default:
>    /* Handle unrecognised types.  An error message should have already 
> been
>  created by get_gnu_elf_note_type(), so all that we need to do is to
> diff --git a/include/elf/common.h b/include/elf/common.h
> index ebcd8f9e82c..c5671447074 100644
> --- a/include/elf/common.h
> +++ b/include/elf/common.h
> @@ -805,6 +805,7 @@
>  #define NT_GNU_BUILD_ID    3   /* Generated by ld 
> --build-id.  */
>  #define NT_GNU_GOLD_VERSION    4   /* Generated by gold.  */
>  #define NT_GNU_PROPERTY_TYPE_0  5  /* Generated by gcc.  */
> +#define NT_GNU_JSON    6   /* Contains arbitrary JSON data.  */
> 
>  #define NT_GNU_BUILD_ATTRIBUTE_OPEN    0x100
>  #define NT_GNU_BUILD_ATTRIBUTE_FUNC    0x101
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add support for ELF notes

[Chris Johns]

On 28/3/2023 6:20 pm, Sebastian Huber wrote:
> On 28.03.23 09:03, Chris Johns wrote:
>> On 28/3/2023 5:48 pm, Sebastian Huber wrote:
>>> On 25.03.23 00:39, Chris Johns wrote:
>>>> On 24/3/2023 7:32 pm, Sebastian Huber wrote:
>>>>> On 23.03.23 20:07, Chris Johns wrote:
>>>>>> On 24/3/2023 3:57 am, Sebastian Huber wrote:
>>>>>>> On 23.03.23 17:52, Will wrote:
>>>>>>>> Great idea to store this information in the executable itself. Does 
>>>>>>>> this
>>>>>>>> need
>>>>>>>> a RTEMS_TEST_STATE_LINK_ONLY test state or something similar for
>>>>>>>> minimum.exe?
>>>>>>> With the notes you can build the test. The test runner would look at the
>>>>>>> notes
>>>>>>> and then decide if it makes sense to run the test or not. It could still
>>>>>>> run the
>>>>>>> minimum.exe and see if it terminates.
>>>>>> I welcome notes support. Thanks for adding it.
>>>>>>
>>>>>> How will we control and manage the notes we support?
>>>>> In the new elfnote.h header file there are defines for the note type
>>>>> (domain-specific integer).
>>>> Great.
>>>>
>>>>>> Should we document the top level notes domains (?) with some we control 
>>>>>> and
>>>>>> restrict and others users can use? For example `note.rtems.test`,
>>>>>> `note.rtems.kernel`, `note.rtems.bsp`, and `note.rtems.user`?
>>>>> The section name doesn't matter. You can divide the number space of the 
>>>>> note
>>>>> type for this.
>>>> Does this mean we define the numbers or number ranges or is it left open? 
>>>> I am
>>>> not sure I am following this bit.
>>> The patch has this:
>>>
>>> #define ELF_NOTE_RTEMS_TYPE( _index ) ( ( _index ) + 0x1 )
>>>
>>> We basically have 32-bits available. We could also use something like this:
>>>
>>> #define ELF_NOTE_RTEMS_BASE_TYPE( _index ) ( ( _index ) + 0x1000 )
>>>
>>> #define ELF_NOTE_RTEMS_TEST_TYPE( _index ) ( ( _index ) + 0x2000 )
>>>
>>> #define ELF_NOTE_RTEMS_USER_TYPE( _index ) ( ( _index ) + 0x3000 )
>>>
>>> ...
>>>
>> Nice.
> 
> Maybe we should also encode the data type here, for example:
> 
> #define ELF_NOTE_DATA_TYPE_BOOL 0
> #define ELF_NOTE_DATA_TYPE_INT8 1
> #define ELF_NOTE_DATA_TYPE_UINT8 2
> #define ELF_NOTE_DATA_TYPE_INT16 3
> #define ELF_NOTE_DATA_TYPE_UINT16 4
> #define ELF_NOTE_DATA_TYPE_INT32 5
> #define ELF_NOTE_DATA_TYPE_UINT32 6
> #define ELF_NOTE_DATA_TYPE_INT64 7
> #define ELF_NOTE_DATA_TYPE_UINT64 8
> #define ELF_NOTE_DATA_TYPE_FLOAT32 9
> #define ELF_NOTE_DATA_TYPE_FLOAT32 10
> #define ELF_NOTE_DATA_TYPE_FLOAT64 11
> #define ELF_NOTE_DATA_TYPE_FLOAT64 12
> #define ELF_NOTE_DATA_TYPE_STRING 13
> #define ELF_NOTE_DATA_TYPE_BINARY 14
> 
> #define ELF_NOTE_RTEMS_BASE_TYPE( _data_type, _index ) \
>   ( ( ( _data_type ) << 28 ) | ( ( _index ) + 0x100 ) )
> 
> This could be used by the host tool to more easily produce the right JSON 
> data.
> 

Good idea. I cannot think of anything else as scoping would tend to reduce to a
new type.

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

Re: [PATCH] Add support for ELF notes

[Chris Johns]

On 28/3/2023 5:48 pm, Sebastian Huber wrote:
> On 25.03.23 00:39, Chris Johns wrote:
>> On 24/3/2023 7:32 pm, Sebastian Huber wrote:
>>> On 23.03.23 20:07, Chris Johns wrote:
>>>> On 24/3/2023 3:57 am, Sebastian Huber wrote:
>>>>> On 23.03.23 17:52, Will wrote:
>>>>>> Great idea to store this information in the executable itself. Does this 
>>>>>> need
>>>>>> a RTEMS_TEST_STATE_LINK_ONLY test state or something similar for 
>>>>>> minimum.exe?
>>>>>
>>>>> With the notes you can build the test. The test runner would look at the 
>>>>> notes
>>>>> and then decide if it makes sense to run the test or not. It could still
>>>>> run the
>>>>> minimum.exe and see if it terminates.
>>>>
>>>> I welcome notes support. Thanks for adding it.
>>>>
>>>> How will we control and manage the notes we support?
>>>
>>> In the new elfnote.h header file there are defines for the note type
>>> (domain-specific integer).
>>
>> Great.
>>
>>>>
>>>> Should we document the top level notes domains (?) with some we control and
>>>> restrict and others users can use? For example `note.rtems.test`,
>>>> `note.rtems.kernel`, `note.rtems.bsp`, and `note.rtems.user`?
>>>
>>> The section name doesn't matter. You can divide the number space of the note
>>> type for this.
>>
>> Does this mean we define the numbers or number ranges or is it left open? I 
>> am
>> not sure I am following this bit.
> 
> The patch has this:
> 
> #define ELF_NOTE_RTEMS_TYPE( _index ) ( ( _index ) + 0x1 )
> 
> We basically have 32-bits available. We could also use something like this:
> 
> #define ELF_NOTE_RTEMS_BASE_TYPE( _index ) ( ( _index ) + 0x1000 )
> 
> #define ELF_NOTE_RTEMS_TEST_TYPE( _index ) ( ( _index ) + 0x2000 )
> 
> #define ELF_NOTE_RTEMS_USER_TYPE( _index ) ( ( _index ) + 0x3000 )
> 
> ...
> 

Nice.

>>>> Do you have any host side tools in mind to access notes apart from the
>>>> standards
>>>> like readefl? Maybe the rtems-exe-info tool could do this?
>>>
>>> Yes, it should be added to this tool.
>>
>> Great. Once we have something merged I can take a look.
>>
>>> I think the most important use case is the
>>> RTEMS tester currently. You can read the notes with the elftools for Python.
>>
>> I could not see an elftools module in the standard cpython support and I have
>> carefully avoided any pipy dependences in user facing tools. We have elf 
>> support
>> in the tool kit so if we can sort something out without needing to add 
>> something
>> else I would prefer it. I think the first thing to do is the get this into
>> rtems.git and then we can address the tooling we need.
> 
> We could add a JSON output to rtems-exe-info which is used by the RTEMS 
> Tester.
> The drawback is that you need a process for each executable.

The exe info tool is fast and yes exporting JSON is a good idea. I have a decent
C++ JSON implementation I am using that can be added to the toolkit and used.

>> We have a GSoC project to sort out the post link stuff that was stripped out
>> when we moved to waf. Could that detail be added as notes? There is something
>> nice about each executable having the needed info and not needing to match an
>> exe with a specific installed configuration set up.
> 
> I think we just have to try it out.

Great.

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

Re: [PATCH v2] eng: Add register block specification types

[Chris Johns]

On 23/3/2023 3:59 am, Sebastian Huber wrote:
> Hello Chris,
> 
> I would like to come back to this topic, because it blocks the integration of
> the sparc/gr712rc and sparc/gr740 changes we have done for the 
> pre-qualification
> activity.
> 
> On 27.09.21 02:23, Chris Johns wrote:
>> On 24/9/21 11:09 pm, Sebastian Huber wrote:
>>> A register block may be used to specify the interface of devices which
>>> use a linear address space.  Register blocks consist of register block
>>
>> Can we please move away from the "linear address" in the definitions? As 
>> stated
>> previously it only serves a specialized version of a bus and register-block.
>> What about something like this:
>>
>> A register block specifies a word addressable set of elements in a device
>> software is required to access and manipulate. The mechanics software uses to
>> access a register element in a register-block is defined by the 
>> bus-interface.
>> The software and register may be a direct coupling to the CPU bus as found 
>> in a
>> linear cache coherent memory mapped device or the access may be indirect 
>> through
>> a bus hierarchy that may require more than one software action to complete.
>> Device and register specifications are independent of the CPU architecture 
>> and
>> connecting bus architectures.
> 
> A linear address space is just an address space in which a single integer is
> sufficient to address something. So a word addressable set of elements in a
> device is a linear address space. In contrast to for example the AArch32 
> system
> register space, which uses a coprocessor index, Opcode_1, CRn, CRm, and
> Opcode_2. An address space granule is the smallest block of memory that can be
> addressed. This could be a subword depending on what a word is and the bus
> system capabilities.

I am sorry I have read and reread this and I do not follow. I do not know if you
are saying the aarch64 cp access and addressing is an example for or a counter
example?

The term "linear address" offers no value. An address bus at any point in a
circuit is are collection of signals wired to the address decoder of a device so
by the nature of how that works it is going to resolve itself to a number and to
be accurate it is a whole number because the concept of negative addressing
would be interesting. The wiring of the interfacing address to a device's
address bus does not have to be 1:1 and it does not need to be continuous in the
external interface's addressing scheme. If linear is saying there is a series of
numbers then again I wonder what the value is. You can view this in datasheets
and code that maps struct to memory mapping devices because reserved (or what
ever they get called) are added. Adding these reserved etc fields is doing
nothing more than making a memory mapped struct work as you hope and I mean
hope. That logic needs a continuous address space.

> The offsets in the register block specification are just the offset you find 
> in
> the corresponding datasheet.
> 
>>
>> I know this is just the commit message but I think this should be in the 
>> manual.
>>
>> bus-interface:
>>
>> A bus interface is the mechanics software uses to access a register word 
>> element
>> in a device. A bus interface specifies the requirements needed by software to
>> access a register word. It must consider timing, CPU word size to device word
>> size, byte ordering for word sizes greater than 8bits, cache considerations 
>> and
>> sequencing of multiple software accesses if required.
>>
>> I would like to see a bus-interface section and the device reference it. It 
>> only
>> needs to cover the type of bus interface you need to specify at this point in
>> time.
> 
> At the moment I just have a header file generator for memory-mapped devices. I
> don't think there will be major issues to adopt the generator to output
> interfaces for some bus space API.

I think the language used is too specific to memory mapped devices.

>>> use a linear address space.
>>> members specified by the ``definition`` attribute.  Register block
>>> members are either instances of registers specified by the ``registers``
>>> attribute or instances of other register blocks specified by links with
>>> the "register-block-include" link role.  Registers consists of bit
>>> fields.
>>
>> Registers are defined in terms of the device word size. The bus interface 
>> needs
>> to deal with the CPU word size to device word size.
> 
> I don't think that a single "word size" is sufficient. A device may have
> registers of different sizes. F

Re: [PATCH rtems-lwip] wscript: Build a header instead of using -D

[Chris Johns]

On 28/3/2023 2:28 am, Kinsey Moore wrote:
> This change moves the use of items configured in config.ini from using
> -D to set defines on the command line to using a header built by waf.
> This also resolves an issue where configuration parameters were bleeding
> between BSPs when multiple BSPs were configured.
> ---
>  rtemslwip/beaglebone/lwipopts.h |  2 ++
>  rtemslwip/zynqmp/lwipopts.h |  2 ++
>  wscript | 19 ---
>  3 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/rtemslwip/beaglebone/lwipopts.h b/rtemslwip/beaglebone/lwipopts.h
> index 888fae4..71ddd9f 100644
> --- a/rtemslwip/beaglebone/lwipopts.h
> +++ b/rtemslwip/beaglebone/lwipopts.h
> @@ -117,6 +117,8 @@
>  #ifndef __LWIPOPTS_H__
>  #define __LWIPOPTS_H__
>  
> +#include 
> +
>  
> /*
>  **   CONFIGURATIONS
>  
> */
> diff --git a/rtemslwip/zynqmp/lwipopts.h b/rtemslwip/zynqmp/lwipopts.h
> index feabe73..d1b7334 100644
> --- a/rtemslwip/zynqmp/lwipopts.h
> +++ b/rtemslwip/zynqmp/lwipopts.h
> @@ -27,6 +27,8 @@
>  #ifndef __LWIPOPTS_H__
>  #define __LWIPOPTS_H__
>  
> +#include 

What about something simpler like `lwip-config.h`?

What include "zynqmp/lwipopts.h"? Sorry I do not know the lwip directory
structure. Is this by arch or a -I trick to allow just lwipopts.h?

> +
>  #define SYS_LIGHTWEIGHT_PROT 1
>  
>  #define NO_SYS 0
> diff --git a/wscript b/wscript
> index f1b919e..5e30279 100644
> --- a/wscript
> +++ b/wscript
> @@ -91,15 +91,23 @@ def get_configured_bsp_options(cp, arch, bsp):
>  return options
>  
>  
> +bsp_opts_target = "bsps/include/configuredlwipbspopts.h"
> +
> +
>  def bsp_configure(conf, arch_bsp):
>  cp = get_config()
>  arch = rtems.arch(arch_bsp)
>  bsp = rtems.bsp(arch_bsp)
>  config_options = get_configured_bsp_options(cp, arch, bsp)
>  for key, val in config_options.items():
> -flag = "-D"+key+"="+val
> -conf.env.CFLAGS.append(flag)
> -conf.env.CXXFLAGS.append(flag)
> +conf.define(key, val, quote=False)
> +conf.env.include_key = []
> +conf.write_config_header(
> +arch_bsp + "/" + bsp_opts_target,

Is this a file name? If so should it be a bld.path.??? node?

Chris

> +guard="CONFIGURED_LWIP_BSP_OPTS_H",
> +top=True
> +)
> +conf.env.include_key = None
>  lwip.bsp_configure(conf, arch_bsp)
>  
>  
> @@ -112,4 +120,9 @@ def configure(conf):
>  
>  def build(bld):
>  rtems.build(bld)
> +arch_bsp = bld.env.RTEMS_ARCH_BSP
> +arch = rtems._arch_from_arch_bsp(arch_bsp)
> +bsp = rtems.bsp(arch_bsp)
> +install_target = os.path.join(bld.env.PREFIX, arch, bsp, "lib", 
> "include")
> +bld.install_files(install_target, bsp_opts_target)
>  lwip.build(bld)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs] c-user/smp: Fix item rendering

[Chris Johns]

OK

Thanks
Chris

On 28/3/2023 6:33 am, Kinsey Moore wrote:
> ---
>  c-user/symmetric_multiprocessing_services.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/c-user/symmetric_multiprocessing_services.rst 
> b/c-user/symmetric_multiprocessing_services.rst
> index 89dc48c..9167ae9 100644
> --- a/c-user/symmetric_multiprocessing_services.rst
> +++ b/c-user/symmetric_multiprocessing_services.rst
> @@ -20,7 +20,7 @@ advised to check the BSP specific documentation and RTEMS 
> source code
>  to verify the status of SMP support for a specific BSP. The following
>  architectures have support for SMP:
>  
> --- AArch64
> +- AArch64,
>  
>  - ARMv7-A,
>  
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] tester/bsps: change stm32h7-stlink to handle SIGTRAP as a nostop

[Chris Johns]

OK to push

Thanks
Chris

On 25/3/2023 10:11 am, Karel Gardas wrote:
> The ST-Link GDB server throws spurious SIGTRAP into the GDB sometimes.
> When this happen, the gdb exits immediately as it's run in batch/script
> manner. Unfortunately this may be while testcase itself is still running
> and does not have enough time to print all the required output.
> Such testcase is then marked as failed although otherwise it may run
> well to its end.
> Adding handle of SIGTRAP as a nostop means that GDB will not exit
> after receiving SIGTRAP but rather be forced to continue as nothing
> would happen and the running testcase will have a chance to finish
> its business.
> ---
>  tester/rtems/testing/bsps/stm32h7-stlink.ini | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tester/rtems/testing/bsps/stm32h7-stlink.ini 
> b/tester/rtems/testing/bsps/stm32h7-stlink.ini
> index bf57bee..2c375f5 100644
> --- a/tester/rtems/testing/bsps/stm32h7-stlink.ini
> +++ b/tester/rtems/testing/bsps/stm32h7-stlink.ini
> @@ -40,4 +40,5 @@ gdb_script = bsp_gdb_script
>  requires   = bsp_tty_dev, bsp_gdb_script, target_pretest_command, 
> target_posttest_command
>  bsp_gdb_script = target extended-remote :61234
>   load
> + handle SIGTRAP nostop
>   cont
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel