Re: [PATCH] improved error checking in ticks per timeslice

[Joel Sherrill]

I'm cc'ing Sebastian because you edited the text in a generated file. He
should be able to point us to the right place to fix it.

On Mon, Feb 12, 2024 at 8:26 PM  wrote:

> From: Zack leung 
>
> diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
> index bd7cde628f..d480eb3971 100644
> --- a/cpukit/doxygen/appl-config.h
> +++ b/cpukit/doxygen/appl-config.h
> @@ -3312,7 +3312,7 @@
>   * @parblock
>   * The following constraints apply to this configuration option:
>   *
> - * * The value of the configuration option shall be greater than or equal
> to
> + * * The value of the configuration option shall be greater than
>   *   zero.
>


This file is generated from something in rtems-central. This was at the top
of the file:

 * This file is part of the RTEMS quality process and was automatically
 * generated.  If you find something that needs to be fixed or
 * worded better please post a report or patch to an RTEMS mailing list



>   *
>   * * The value of the configuration option shall be less than or equal to
>  diff --git a/cpukit/include/rtems/confdefs/clock.h
> b/cpukit/include/rtems/confdefs/clock.h
> index 26519cc70b..d0d7c453bc 100644
> --- a/cpukit/include/rtems/confdefs/clock.h
> +++ b/cpukit/include/rtems/confdefs/clock.h
> @@ -74,6 +74,10 @@
>#error "CONFIGURE_MICROSECONDS_PER_TICK must be positive"
>  #endif
>
> +#if CONFIGURE_TICKS_PER_TIMESLICE <= 0 &&
> defined(CONFIGURE_TICKS_PER_TIMESLICE)
> +  #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
> +#endif
> +
>

This is modifying the right file but I think it is safer to check that it
is defined
before checking its value.

--joel


>  #ifdef __cplusplus
>  extern "C" {
>  #endif
> --
> 2.43.0
>
> ___
> 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] improved error checking in ticks per timeslice

[Sebastian Huber]

On 14.02.24 15:18, Joel Sherrill wrote:
I'm cc'ing Sebastian because you edited the text in a generated file. He 
should be able to point us to the right place to fix it.


On Mon, Feb 12, 2024 at 8:26 PM > wrote:


From: Zack leung mailto:z.liang...@gmail.com>>

diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index bd7cde628f..d480eb3971 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -3312,7 +3312,7 @@
   * @parblock
   * The following constraints apply to this configuration option:
   *
- * * The value of the configuration option shall be greater than or
equal to
+ * * The value of the configuration option shall be greater than
   *   zero.



This file is generated from something in rtems-central. This was at the 
top of the file:


  * This file is part of the RTEMS quality process and was automatically
  * generated.  If you find something that needs to be fixed or
  * worded better please post a report or patch to an RTEMS mailing list


No, problem. I can fix this before I check in the patch.



   *
   * * The value of the configuration option shall be less than or
equal to This is modifying the right file but I think it is safer to check that 
it is defined

before checking its value.


Yes, the defined() check should be first.

--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
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

Re: [PATCH rtems-source-builder 2/2] devel/qemu-xilinx: Fix build on GCC 13.2.0

[Sam Price]

I was wondering if you had any notes on your process of working with
qemu in the rtems builder.
I imagine you have your own xilinx qemu forked to work on, and then
take the patches and integrate them into the rsb builder?

Thanks,
Sam

On Sun, Feb 11, 2024 at 9:51 PM Kinsey Moore  wrote:
>
> GCC 13.2.0 adds new warnings/errors when mixing ints and enums. This
> changes the pminsn helper type to correctly use enums.
> ---
>  bare/config/devel/qemu-xilinx-v2020.2-1.cfg | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/bare/config/devel/qemu-xilinx-v2020.2-1.cfg 
> b/bare/config/devel/qemu-xilinx-v2020.2-1.cfg
> index ca70ebd..6352268 100644
> --- a/bare/config/devel/qemu-xilinx-v2020.2-1.cfg
> +++ b/bare/config/devel/qemu-xilinx-v2020.2-1.cfg
> @@ -24,6 +24,13 @@
>  %hash sha512 xlnx_cgem_zynqmp_versal.patch \
>
> tGjJn7o8/fQwdC0sgsYmPW6bqDzMkwhKRqBwuuy8sdEKivDj7uGISMj7p8Iwy9fkHiO3Dd3feno+iz5fHYGBkA==
>
> +#
> +# Patch to fix PPC64 build under GCC 13.2.0
> +#
> +%patch add qemu --rsb-file=xlnx_ppc64_enum.patch -p1 
> https://devel.rtems.org/raw-attachment/ticket/4988/0001-target-ppc-Resolve-int-enum-mismatch-on-ppc64.patch
> +%hash sha512 xlnx_ppc64_enum.patch \
> +  
> afYfClJ5IO9eV23dOAqxurzAnwS1YmiOEPCts/ftXS/ddXp9Rx2oQYuKeZriawKw7MVlqWNv9eTc5ERoFhRKOg==
> +
>  #
>  # The Qemu build instructions. We use 5.x.x Release 1.
>  #
> --
> 2.39.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



-- 
Sincerely,

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

Re: [PATCH rtems-source-builder 2/2] devel/qemu-xilinx: Fix build on GCC 13.2.0

[Kinsey Moore]

On Wed, Feb 14, 2024 at 9:14 AM Sam Price  wrote:

> I was wondering if you had any notes on your process of working with
> qemu in the rtems builder.
> I imagine you have your own xilinx qemu forked to work on, and then
> take the patches and integrate them into the rsb builder?
>

Nothing so fancy. Here's my current setup for this:
* have a checkout of the qemu-xilinx repo to generate patches
* copy generated patches into the rsb/rtems/patches directory
* set up the RSB recipe to pull in the patch with appropriate SHA512
* attempt build

This lets me pull in a custom patch for testing without actually hosting it
somewhere. I've been wanting an easier way to do this since it's a pain to
push patches elsewhere for test hosting before actually pushing it to the
ticket, but this is the compromise I've settled on that smooths out the
workflow just enough. Ideally, I'd be able to specify a local file path for
a patch for test purposes, but that would necessitate some very verbose
flag to sb-set-builder like
--really-allow-local-patches-just-for-test-purposes because we really don't
want to host these patches within RSB.

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

Re: [PATCH rtems-source-builder 2/2] devel/qemu-xilinx: Fix build on GCC 13.2.0

[Sam Price]

I was trying to debug while only some of the uart interrupt vectors
seem to work on the microblaze.
I thought it would be nice to compile qemu with debug flags.

Also eventually I would like to develop my own firmware driver
emulation for qemu.  Which would probably require me to have my own
qemu fork anyways.

I think just integrating all the rtems patches into a fork and
changing the remote would work, but maybe im am missing something.

Thanks for the reply.
If I get some free time to hack on this and figure anything out i will
let you know.

Sam.
On Wed, Feb 14, 2024 at 2:37 PM Kinsey Moore  wrote:
>
> On Wed, Feb 14, 2024 at 9:14 AM Sam Price  wrote:
>>
>> I was wondering if you had any notes on your process of working with
>> qemu in the rtems builder.
>> I imagine you have your own xilinx qemu forked to work on, and then
>> take the patches and integrate them into the rsb builder?
>
>
> Nothing so fancy. Here's my current setup for this:
> * have a checkout of the qemu-xilinx repo to generate patches
> * copy generated patches into the rsb/rtems/patches directory
> * set up the RSB recipe to pull in the patch with appropriate SHA512
> * attempt build
>
> This lets me pull in a custom patch for testing without actually hosting it 
> somewhere. I've been wanting an easier way to do this since it's a pain to 
> push patches elsewhere for test hosting before actually pushing it to the 
> ticket, but this is the compromise I've settled on that smooths out the 
> workflow just enough. Ideally, I'd be able to specify a local file path for a 
> patch for test purposes, but that would necessitate some very verbose flag to 
> sb-set-builder like --really-allow-local-patches-just-for-test-purposes 
> because we really don't want to host these patches within RSB.
>
> Kinsey



-- 
Sincerely,

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

Re: [PATCH] improved error checking in ticks per timeslice

[zack leung]

 > This file is generated from something in rtems-central. This was at the
> top of the file:
>
>   * This file is part of the RTEMS quality process and was automatically
>   * generated.  If you find something that needs to be fixed or
>   * worded better please post a report or patch to an RTEMS mailing list

No, problem. I can fix this before I check in the patch.

re: this do you need me to change it to something?

On Wed, 14 Feb 2024 at 09:28, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> On 14.02.24 15:18, Joel Sherrill wrote:
> > I'm cc'ing Sebastian because you edited the text in a generated file. He
> > should be able to point us to the right place to fix it.
> >
> > On Mon, Feb 12, 2024 at 8:26 PM  > > wrote:
> >
> > From: Zack leung mailto:z.liang...@gmail.com
> >>
> >
> > diff --git a/cpukit/doxygen/appl-config.h
> b/cpukit/doxygen/appl-config.h
> > index bd7cde628f..d480eb3971 100644
> > --- a/cpukit/doxygen/appl-config.h
> > +++ b/cpukit/doxygen/appl-config.h
> > @@ -3312,7 +3312,7 @@
> >* @parblock
> >* The following constraints apply to this configuration option:
> >*
> > - * * The value of the configuration option shall be greater than or
> > equal to
> > + * * The value of the configuration option shall be greater than
> >*   zero.
> >
> >
> >
> > This file is generated from something in rtems-central. This was at the
> > top of the file:
> >
> >   * This file is part of the RTEMS quality process and was automatically
> >   * generated.  If you find something that needs to be fixed or
> >   * worded better please post a report or patch to an RTEMS mailing list
>
> No, problem. I can fix this before I check in the patch.
>
> >
> >*
> >* * The value of the configuration option shall be less than or
> > equal to  > diff --git a/cpukit/include/rtems/confdefs/clock.h
> > b/cpukit/include/rtems/confdefs/clock.h
> > index 26519cc70b..d0d7c453bc 100644
> > --- a/cpukit/include/rtems/confdefs/clock.h
> > +++ b/cpukit/include/rtems/confdefs/clock.h
> > @@ -74,6 +74,10 @@
> > #error "CONFIGURE_MICROSECONDS_PER_TICK must be positive"
> >   #endif
> >
> > +#if CONFIGURE_TICKS_PER_TIMESLICE <= 0 &&
> > defined(CONFIGURE_TICKS_PER_TIMESLICE)
> > +  #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
> > +#endif
> > +
> >
> >
> > This is modifying the right file but I think it is safer to check that
> > it is defined
> > before checking its value.
>
> Yes, the defined() check should be first.
>
> --
> embedded brains GmbH & Co. KG
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> 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