Re: [PATCH] bsps/zynqmp: Fix and update device trees

2022-12-05 Thread Chris Johns
On 6/12/2022 5:04 pm, Kinsey Moore wrote:
> On 12/5/2022 9:48 PM, Chris Johns wrote:
>> I am still seeing issues with this change. The interface is `cgem0` and not
>> `cgem3`. I have confirmed I have the same RTEMS hash in the build. Is there
>> anything I need to set up to have the FDT be seem by libbsd?
> 
> Seeing the first interface to come up as cgem0 is what I observe with this 
> patch
> on the ZCU102, but I do get DHCP. I haven't yet worked out a way around the
> change in behavior for interface numbering. It may need to complete the probe
> and reject the attach. I'll have the person with the TE0802 double check this
> tomorrow.

Ah yes it is working for me. I hd altered the config to reference cgem3 and
needed to change it back.

I am fine with cgem0 being selected and used.

> The output you've shared with me thus far indicates that the device tree is
> being read and used and there should be no additional actions to take for it 
> to
> be utilized.

Great.

The patch looks good. Please push.

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


Re: [PATCH] bsps/zynqmp: Fix and update device trees

2022-12-05 Thread Chris Johns
I am still seeing issues with this change. The interface is `cgem0` and not
`cgem3`. I have confirmed I have the same RTEMS hash in the build. Is there
anything I need to set up to have the FDT be seem by libbsd?

Chris

On 6/12/2022 10:27 am, Kinsey Moore wrote:
> Add ref-clock-num identifiers to the device tree to ensure that
> interfaces use the correct clocks even when some are not used due to
> unconnected MII busses. This also adjusts the default ZynqMP PHY
> attachment to RGMII-ID which was the default before device trees were
> introduced.
> ---
>  bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts   |   4 +
>  bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c | 132 ++-
>  bsps/aarch64/xilinx-zynqmp/fdt/zynqmp.dts|  12 +-
>  bsps/aarch64/xilinx-zynqmp/fdt/zynqmp_dtb.c  | 104 ---
>  4 files changed, 137 insertions(+), 115 deletions(-)
> 
> diff --git a/bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts 
> b/bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts
> index 763a668a5c..05647e0848 100644
> --- a/bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts
> +++ b/bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts
> @@ -62,6 +62,7 @@
>   interrupts = <0x00 0x39 0x04>;
>   reg = <0x00 0xff0b 0x00 0x1000>;
>   phy-mode = "sgmii";
> + ref-clock-num = <0>;
>   };
>  
>   ethernet@ff0c {
> @@ -71,6 +72,7 @@
>   interrupts = <0x00 0x3b 0x04>;
>   reg = <0x00 0xff0c 0x00 0x1000>;
>   phy-mode = "sgmii";
> + ref-clock-num = <1>;
>   };
>  
>   ethernet@ff0d {
> @@ -80,6 +82,7 @@
>   interrupts = <0x00 0x3d 0x04>;
>   reg = <0x00 0xff0d 0x00 0x1000>;
>   phy-mode = "sgmii";
> + ref-clock-num = <2>;
>   };
>  
>   ethernet@ff0e {
> @@ -89,6 +92,7 @@
>   interrupts = <0x00 0x3f 0x04>;
>   reg = <0x00 0xff0e 0x00 0x1000>;
>   phy-mode = "sgmii";
> + ref-clock-num = <3>;
>   };
>  
>   serial@800a {
> diff --git a/bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c 
> b/bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c
> index 2d0078678e..7a45b4f7dd 100644
> --- a/bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c
> +++ b/bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c
> @@ -1,8 +1,8 @@
>  unsigned char zynqmp_dtb[] = {
> -  0xd0, 0x0d, 0xfe, 0xed, 0x00, 0x00, 0x05, 0xa3, 0x00, 0x00, 0x00, 0x38,
> -  0x00, 0x00, 0x04, 0xd0, 0x00, 0x00, 0x00, 0x28, 0x00, 0x00, 0x00, 0x11,
> -  0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xd3,
> -  0x00, 0x00, 0x04, 0x98, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0xd0, 0x0d, 0xfe, 0xed, 0x00, 0x00, 0x05, 0xf1, 0x00, 0x00, 0x00, 0x38,
> +  0x00, 0x00, 0x05, 0x10, 0x00, 0x00, 0x00, 0x28, 0x00, 0x00, 0x00, 0x11,
> +  0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xe1,
> +  0x00, 0x00, 0x04, 0xd8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01,
>0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x04,
>0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x03,
> @@ -39,33 +39,37 @@ unsigned char zynqmp_dtb[] = {
>0x00, 0x00, 0x00, 0x3e, 0x00, 0x00, 0x00, 0x00, 0xff, 0x0b, 0x00, 0x00,
>0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x03,
>0x00, 0x00, 0x00, 0x06, 0x00, 0x00, 0x00, 0x82, 0x73, 0x67, 0x6d, 0x69,
> -  0x69, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x01,
> -  0x65, 0x74, 0x68, 0x65, 0x72, 0x6e, 0x65, 0x74, 0x40, 0x66, 0x66, 0x30,
> -  0x63, 0x30, 0x30, 0x30, 0x30, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03,
> -  0x00, 0x00, 0x00, 0x09, 0x00, 0x00, 0x00, 0x1b, 0x63, 0x64, 0x6e, 0x73,
> -  0x2c, 0x67, 0x65, 0x6d, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03,
> -  0x00, 0x00, 0x00, 0x05, 0x00, 0x00, 0x00, 0x5f, 0x6f, 0x6b, 0x61, 0x79,
> -  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x04,
> -  0x00, 0x00, 0x00, 0x66, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x03,
> -  0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x77, 0x00, 0x00, 0x00, 0x00,
> -  0x00, 0x00, 0x00, 0x3b, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x03,
> -  0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x3e, 0x00, 0x00, 0x00, 0x00,
> -  0xff, 0x0c, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00,
> -  0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x06, 0x00, 0x00, 0x00, 0x82,
> -  0x73, 0x67, 0x6d, 0x69, 0x69, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02,
> +  0x69, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x04,
> +  0x00, 0x00, 0x00, 0x8b, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02,
>0x00, 0x00, 0x00, 0x01, 0x65, 0x74, 0x68, 0x65, 0x72, 0x6e, 0x65, 

Moving ticket milestones to a different RTEMS version

2022-12-01 Thread Chris Johns
Hi,

Joel and I have been cleaning up the 6 tickets and some have been moved to 7
(thanks) which may be appropriate however I am wondering about open ended
tickets for a specific set of work and release notes. These tickets are really
great for collecting commits for a specific change.

The release notes are based on the tickets for a release and milestone. An open
ended ticket for a specific task when part of release collects the related
commits however moving that ticket to the next release moves the commits to that
release's release notes and the current release does not see the commits in its
release notes?

Should the ticket be cloned (without comments?) to the next release and the one
on the current release closed. It seems to make sense to me. The work is
continuing however it is closed for the branch being release?

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


Re: [PATCH] cpukit/include/dev/can: Disabled debug prints in CAN Framework

2022-12-01 Thread Chris Johns
On 2/12/2022 2:38 pm, Chris Johns wrote:
> The CAN bus changes have warnings ...
> 
> In file included from ../../../cpukit/include/dev/can/canqueueimpl.h:48,
>  from ../../../cpukit/dev/can/can.c:45:
> ../../../cpukit/dev/can/can.c: In function 'can_bus_read':
> ../../../cpukit/dev/can/can.c:213:15: warning: format '%u' expects argument of
> type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat=]
>   213 | CAN_DEBUG("can_bus_read: buffer size is small min sizeof(struct
> can_msg) = %u\n",
>   |
> ^~
>   214 | sizeof(struct can_msg));
>   | ~~
>   | |
>   | long unsigned int
> ../../../cpukit/include/dev/can/can.h:53:14: note: in definition of macro
> 
> etc etc etc
> 
> Can these please be fixed? Use #4662.

I should add I used the aarch64/xilinx_zynqmp_lp64_zu3eg BSP so it looks like
these are 64bit related. I hope that helps. I do not see them with 32bit builds.

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


Re: [PATCH] cpukit/include/dev/can: Disabled debug prints in CAN Framework

2022-12-01 Thread Chris Johns
The CAN bus changes have warnings ...

In file included from ../../../cpukit/include/dev/can/canqueueimpl.h:48,
 from ../../../cpukit/dev/can/can.c:45:
../../../cpukit/dev/can/can.c: In function 'can_bus_read':
../../../cpukit/dev/can/can.c:213:15: warning: format '%u' expects argument of
type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat=]
  213 | CAN_DEBUG("can_bus_read: buffer size is small min sizeof(struct
can_msg) = %u\n",
  |
^~
  214 | sizeof(struct can_msg));
  | ~~
  | |
  | long unsigned int
../../../cpukit/include/dev/can/can.h:53:14: note: in definition of macro

etc etc etc

Can these please be fixed? Use #4662.

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


Re: [PATCH 0/3] Add CONFIGURE_RECORD_INTERRUPTS_ENABLED

2022-12-01 Thread Chris Johns
Looks good.

Thanks
Chris

On 1/12/2022 11:10 pm, Sebastian Huber wrote:
> This enables the tracing of interrupt entry/exit events through an
> application configuration option.  The interrupt processing can be
> viewed with Trace Compass.
> 
> Sebastian Huber (3):
>   bsps/irq: Rename handler in dispatch table
>   bsps/irq: Add bsp_interrupt_get_dispatch_table_slot()
>   config: Add CONFIGURE_RECORD_INTERRUPTS_ENABLED
> 
>  bsps/include/bsp/irq-generic.h| 79 ---
>  bsps/powerpc/mpc55xxevb/include/bsp/irq.h |  2 +-
>  bsps/riscv/riscv/include/tm27.h   |  4 +-
>  bsps/shared/irq/irq-entry-remove.c|  6 +-
>  bsps/shared/irq/irq-generic.c | 41 
>  bsps/shared/irq/irq-handler-iterate.c |  4 +-
>  bsps/shared/irq/irq-record.c  | 97 +++
>  cpukit/doxygen/appl-config.h  | 23 +
>  cpukit/include/rtems/confdefs/extensions.h|  8 ++
>  cpukit/include/rtems/record.h |  2 +
>  spec/build/bsps/objirq.yml|  1 +
>  spec/build/bsps/powerpc/ss555/bspss555.yml|  1 +
>  .../validation/tc-bsp-interrupt-spurious.c|  4 +-
>  testsuites/validation/tc-intr-entry-install.c |  4 +-
>  testsuites/validation/tc-intr-entry-remove.c  |  8 +-
>  .../validation/tc-intr-handler-iterate.c  |  4 +-
>  16 files changed, 218 insertions(+), 70 deletions(-)
>  create mode 100644 bsps/shared/irq/irq-record.c
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH] Document CONFIGURE_RECORD_INTERRUPTS_ENABLED

2022-12-01 Thread Chris Johns
Looks good.

Thanks
Chris

On 1/12/2022 11:11 pm, Sebastian Huber wrote:
> Close #4769.
> ---
>  c-user/config/event-record.rst  | 43 +-
>  user/tracing/eventrecording.rst | 65 +++--
>  2 files changed, 47 insertions(+), 61 deletions(-)
> 
> diff --git a/c-user/config/event-record.rst b/c-user/config/event-record.rst
> index 31a4fa9..f1e7969 100644
> --- a/c-user/config/event-record.rst
> +++ b/c-user/config/event-record.rst
> @@ -1,6 +1,6 @@
>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>  
> -.. Copyright (C) 2019, 2021 embedded brains GmbH 
> (http://www.embedded-brains.de)
> +.. Copyright (C) 2019, 2022 embedded brains GmbH 
> (http://www.embedded-brains.de)
>  
>  .. This file is part of the RTEMS quality process and was automatically
>  .. generated.  If you find something that needs to be fixed or
> @@ -150,6 +150,47 @@ in a fatal error extension (see :ref:`Terminate`).
>  The zlib compression needs about 512KiB of RAM.  This extension can be used
>  to produce crash dumps.
>  
> +.. Generated from spec:/acfg/if/record-interrupts-enabled
> +
> +.. raw:: latex
> +
> +\clearpage
> +
> +.. index:: CONFIGURE_RECORD_INTERRUPTS_ENABLED
> +
> +.. _CONFIGURE_RECORD_INTERRUPTS_ENABLED:
> +
> +CONFIGURE_RECORD_INTERRUPTS_ENABLED
> +---
> +
> +.. rubric:: CONSTANT:
> +
> +``CONFIGURE_RECORD_INTERRUPTS_ENABLED``
> +
> +.. rubric:: OPTION TYPE:
> +
> +This configuration option is a boolean feature define.
> +
> +.. rubric:: DEFAULT CONFIGURATION:
> +
> +If this configuration option is undefined, then the described feature is not
> +enabled.
> +
> +.. rubric:: DESCRIPTION:
> +
> +In case
> +
> +* this configuration option is defined
> +
> +* and :ref:`CONFIGURE_RECORD_PER_PROCESSOR_ITEMS` is properly defined,
> +
> +then the interrupt event recording is enabled.
> +
> +.. rubric:: NOTES:
> +
> +The interrupt event recording generates interrupt entry and exit events when
> +interrupt entries are dispatched.
> +
>  .. Generated from spec:/acfg/if/record-per-processor-items
>  
>  .. raw:: latex
> diff --git a/user/tracing/eventrecording.rst b/user/tracing/eventrecording.rst
> index 7130658..b5561cc 100644
> --- a/user/tracing/eventrecording.rst
> +++ b/user/tracing/eventrecording.rst
> @@ -48,8 +48,11 @@ The application enables the event recording support via 
> the configuration
>  option :c:macro:`CONFIGURE_RECORD_PER_PROCESSOR_ITEMS`.  The configuration
>  option :c:macro:`CONFIGURE_RECORD_EXTENSIONS_ENABLED` enables the generation 
> of
>  thread create, start, restart, delete, switch, begin, exitted and terminate
> -events.  Dumps of the event records in a fatal error handler can be enabled 
> by
> -the mutually exclusive :c:macro:`CONFIGURE_RECORD_FATAL_DUMP_BASE64` and
> +events.  The configuration option
> +:c:macro:`CONFIGURE_RECORD_INTERRUPTS_ENABLED` enables the generation of
> +interrupt entry and exit events.  Dumps of the event records in a fatal error
> +handler can be enabled by the mutually exclusive
> +:c:macro:`CONFIGURE_RECORD_FATAL_DUMP_BASE64` and
>  :c:macro:`CONFIGURE_RECORD_FATAL_DUMP_BASE64_ZLIB` configuration options.
>  
>  Custom events can be recorded for example with the
> @@ -98,64 +101,6 @@ instrumented functions:
>   );
> }
>  
> -To generate interrupt handler entry/exit events, the following patch can be
> -used:
> -
> -.. code-block:: diff
> -
> -diff --git a/bsps/arm/shared/clock/clock-armv7m.c 
> b/bsps/arm/shared/clock/clock-armv7m.c
> -index 255de1ca42..0d37c63ac6 100644
> ---- a/bsps/arm/shared/clock/clock-armv7m.c
> -+++ b/bsps/arm/shared/clock/clock-armv7m.c
> -@@ -29,6 +29,7 @@
> - #include 
> -
> - #include 
> -+#include 
> - #include 
> -
> - #ifdef ARM_MULTILIB_ARCH_V7M
> -@@ -45,9 +46,11 @@ static uint32_t _ARMV7M_TC_get_timecount(struct 
> timecounter *base)
> -
> - void _ARMV7M_Clock_handler(void)
> - {
> -+  rtems_record_produce(RTEMS_RECORD_INTERRUPT_ENTRY, 
> ARMV7M_VECTOR_SYSTICK);
> -   _ARMV7M_Interrupt_service_enter();
> -   Clock_isr(NULL);
> -   _ARMV7M_Interrupt_service_leave();
> -+  rtems_record_produce(RTEMS_RECORD_INTERRUPT_EXIT, 
> ARMV7M_VECTOR_SYSTICK);
> - }
> -
> - static void _ARMV7M_Clock_handler_install(void)
> -diff --git a/bsps/include/bsp/irq-generic.h 
> b/bsps/include/bsp/irq-generic.h
> -index 31835d07ba..2ab2f78b65 100644
> ---- a/bsps/include/bsp/irq-generic.h
> -+++ b/bsps/include/bsp/irq-generic.h
> -@@ -30,6 +30,7 @@
> - #include 
> -
> - #include 
> -+#include 
> - #include 
> -
> - #ifdef RTEMS_SMP
> -@@ -258,6 +259,7 @@ void 
> bsp_interrupt_vector_disable(rtems_vector_number vector);
> -  */
> - static inline void bsp_interrupt_handler_dispatch(rtems_vector_number 
> vector)
> - {
> -+  rtems_record_produce(RTEMS_RECORD_INTERRUPT_ENTRY, vector);
> -   if (bsp_interrupt_is_valid_vector(vector)) {
> - 

Re: [PATCH rtems-docs] c-user/*: Add trailing parentheses on methods in index which were missing it

2022-11-30 Thread Chris Johns
Looks good and thanks

Chris

On 1/12/2022 3:00 am, Joel Sherrill wrote:
> Closes #4766.
> ---
>  c-user/chains.rst | 46 
> +--
>  c-user/clock/removed-directives.rst   |  2 +-
>  c-user/constant_bandwidth_server.rst  | 24 +-
>  c-user/cpu_usage_statistics.rst   |  4 +--
>  c-user/directive_status_codes.rst |  2 +-
>  c-user/key_concepts.rst   | 12 -
>  c-user/task/deprecated-directives.rst |  2 +-
>  c-user/task/operations.rst| 10 
>  c-user/task/removed-directives.rst| 10 
>  c-user/timespec_helpers.rst   | 28 ++---
>  c-user/user-extensions/background.rst |  2 +-
>  11 files changed, 71 insertions(+), 71 deletions(-)
> 
> diff --git a/c-user/chains.rst b/c-user/chains.rst
> index 0dce1d9..f518ef4 100644
> --- a/c-user/chains.rst
> +++ b/c-user/chains.rst
> @@ -220,7 +220,7 @@ The section details the Chains directives.
>  .. _rtems_chain_initialize:
>  
>  .. index:: chain initialize
> -.. index:: rtems_chain_initialize
> +.. index:: rtems_chain_initialize()
>  
>  Initialize Chain With Nodes
>  ---
> @@ -258,7 +258,7 @@ NOTES:
>  .. _rtems_chain_initialize_empty:
>  
>  .. index:: chain initialize empty
> -.. index:: rtems_chain_initialize_empty
> +.. index:: rtems_chain_initialize_empty()
>  
>  Initialize Empty
>  
> @@ -287,7 +287,7 @@ NOTES:
>  .. _rtems_chain_is_null_node:
>  
>  .. index:: chain is node null
> -.. index:: rtems_chain_is_null_node
> +.. index:: rtems_chain_is_null_node()
>  
>  Is Null Node ?
>  --
> @@ -313,7 +313,7 @@ DESCRIPTION:
>  .. _rtems_chain_head:
>  
>  .. index:: chain get head
> -.. index:: rtems_chain_head
> +.. index:: rtems_chain_head()
>  
>  Head
>  
> @@ -338,7 +338,7 @@ DESCRIPTION:
>  .. _rtems_chain_tail:
>  
>  .. index:: chain get tail
> -.. index:: rtems_chain_tail
> +.. index:: rtems_chain_tail()
>  
>  Tail
>  
> @@ -363,7 +363,7 @@ DESCRIPTION:
>  .. _rtems_chain_are_nodes_equal:
>  
>  .. index:: chare are nodes equal
> -.. index:: rtems_chain_are_nodes_equal
> +.. index:: rtems_chain_are_nodes_equal()
>  
>  Are Two Nodes Equal ?
>  -
> @@ -391,7 +391,7 @@ DESCRIPTION:
>  .. _rtems_chain_is_empty:
>  
>  .. index:: chain is chain empty
> -.. index:: rtems_chain_is_empty
> +.. index:: rtems_chain_is_empty()
>  
>  Is the Chain Empty
>  --
> @@ -418,7 +418,7 @@ DESCRIPTION:
>  .. _rtems_chain_is_first:
>  
>  .. index:: chain is node the first
> -.. index:: rtems_chain_is_first
> +.. index:: rtems_chain_is_first()
>  
>  Is this the First Node on the Chain ?
>  -
> @@ -445,7 +445,7 @@ DESCRIPTION:
>  .. _rtems_chain_is_last:
>  
>  .. index:: chain is node the last
> -.. index:: rtems_chain_is_last
> +.. index:: rtems_chain_is_last()
>  
>  Is this the Last Node on the Chain ?
>  
> @@ -472,7 +472,7 @@ DESCRIPTION:
>  .. _rtems_chain_has_only_one_node:
>  
>  .. index:: chain only one node
> -.. index:: rtems_chain_has_only_one_node
> +.. index:: rtems_chain_has_only_one_node()
>  
>  Does this Chain have only One Node ?
>  
> @@ -499,7 +499,7 @@ DESCRIPTION:
>  .. _rtems_chain_node_count_unprotected:
>  
>  .. index:: chain only one node
> -.. index:: rtems_chain_node_count_unprotected
> +.. index:: rtems_chain_node_count_unprotected()
>  
>  Returns the node count of the chain (unprotected)
>  -
> @@ -524,7 +524,7 @@ DESCRIPTION:
>  .. _rtems_chain_is_head:
>  
>  .. index:: chain is node the head
> -.. index:: rtems_chain_is_head
> +.. index:: rtems_chain_is_head()
>  
>  Is this Node the Chain Head ?
>  -
> @@ -552,7 +552,7 @@ DESCRIPTION:
>  .. _rtems_chain_is_tail:
>  
>  .. index:: chain is node the tail
> -.. index:: rtems_chain_is_tail
> +.. index:: rtems_chain_is_tail()
>  
>  Is this Node the Chain Tail ?
>  -
> @@ -580,7 +580,7 @@ DESCRIPTION:
>  .. _rtems_chain_extract:
>  
>  .. index:: chain extract a node
> -.. index:: rtems_chain_extract
> +.. index:: rtems_chain_extract()
>  
>  Extract a Node
>  --
> @@ -611,7 +611,7 @@ NOTES:
>  .. _rtems_chain_extract_unprotected:
>  
>  .. index:: chain extract a node unprotected
> -.. index:: rtems_chain_extract_unprotected
> +.. index:: rtems_chain_extract_unprotected()
>  
>  Extract a Node (unprotected)
>  
> @@ -639,7 +639,7 @@ NOTES:
>  .. _rtems_chain_get:
>  
>  .. index:: chain get first node
> -.. index:: rtems_chain_get
> +.. index:: rtems_chain_get()
>  
>  Get the First Node
>  --
> @@ -672,7 +672,7 @@ NOTES:
>  .. _rtems_chain_get_unprotected:
>  
>  .. index:: chain get first node
> -.. index:: rtems_chain_get_unprotected
> +.. index:: rtems_chain_get_unprotected()
>  
>  Get 

Re: [PATCH rtems-docs] user/hosts/windows.rst: flex needs to be installed for msys2

2022-11-30 Thread Chris Johns
OK and thanks

Chris

On 1/12/2022 2:32 am, Joel Sherrill wrote:
> Closes #4382.
> ---
>  user/hosts/windows.rst | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/user/hosts/windows.rst b/user/hosts/windows.rst
> index fac1366..fd7ff55 100644
> --- a/user/hosts/windows.rst
> +++ b/user/hosts/windows.rst
> @@ -156,6 +156,7 @@ The packages we require are:
>  * python
>  * mingw-w64-x86_64-python2
>  * mingw-w64-x86_64-gcc
> +* flex
>  * git
>  * bison
>  * cvs
> @@ -176,7 +177,7 @@ Install the packages using ``pacman``:
>  .. code-block:: none
>  
>$ pacman -S python mingw-w64-x86_64-python2 mingw-w64-x86_64-gcc \
> -  bison cvs diffutils git make patch tar texinfo unzip
> +  bison flex cvs diffutils git make patch tar texinfo unzip
>resolving dependencies...
>looking for conflicting packages...
> output shortened for brevity 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: Fwd: Coverity Scan: Analysis completed for RTEMS

2022-11-28 Thread Chris Johns
On 25/11/2022 5:40 pm, Joel Sherrill wrote:
> Looks like edit.c may still have an issue since only one was eliminated. Late
> here and I didn't check the Coverity report for sure.

With Coverity is there anyway to check changes or do we consider the issues
raised, attempt a solution then just keep trying?

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


Re: [PATCH rtems-tools] fix _mkdir parameter error.

2022-11-27 Thread Chris Johns
Pushed. Thanks

Chris

On 27/11/2022 8:20 pm, zhengxiaojun wrote:
> fix _mkdir parameter error.
> 
> Signed-off-by: zhengxiaojun 
> ---
>  tester/covoar/ReportsBase.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tester/covoar/ReportsBase.cc b/tester/covoar/ReportsBase.cc
> index 0fb9ce0..eb56c4f 100644
> --- a/tester/covoar/ReportsBase.cc
> +++ b/tester/covoar/ReportsBase.cc
> @@ -65,7 +65,7 @@ void ReportsBase::OpenFile(
> 
>    // Create the output directory if it does not already exist
>  #ifdef _WIN32
> -  sc = _mkdir( symbolSetOutputDirectory );
> +  sc = _mkdir( symbolSetOutputDirectory.c_str() );
>  #else
>    sc = mkdir( symbolSetOutputDirectory.c_str(), 0755 );
>  #endif
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] spec/beagle: Add missing spi.h install

2022-11-27 Thread Chris Johns
Pushed. Thanks

Chris

On 26/11/2022 2:19 pm, Kinsey Moore wrote:
> The beagle SPI functions are unusable by applications unless this file
> is installed with the BSP. This ensures that the file is installed
> properly.
> ---
>  spec/build/bsps/arm/beagle/obj.yml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/spec/build/bsps/arm/beagle/obj.yml 
> b/spec/build/bsps/arm/beagle/obj.yml
> index 56072075c2..90b0499031 100644
> --- a/spec/build/bsps/arm/beagle/obj.yml
> +++ b/spec/build/bsps/arm/beagle/obj.yml
> @@ -20,6 +20,7 @@ install:
>- bsps/arm/beagle/include/bsp/irq.h
>- bsps/arm/beagle/include/bsp/pwmss.h
>- bsps/arm/beagle/include/bsp/qep.h
> +  - bsps/arm/beagle/include/bsp/spi.h
>  - destination: ${BSP_LIBDIR}
>source:
>- bsps/arm/beagle/start/linkcmds
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH] libmisc/shell: Support terminal size as env variables

2022-11-22 Thread Chris Johns
On 23/11/22 12:44 am, Joel Sherrill wrote:
> On Tue, Nov 22, 2022, 6:02 AM mailto:chr...@rtems.org>> 
> wrote:
>     From: Chris Johns mailto:chr...@rtems.org>>
> 
> Closes #4763
> ---
>  cpukit/libmisc/shell/main_edit.c | 17 +-
>  cpukit/libmisc/shell/main_help.c | 94 
>  cpukit/libmisc/shell/shell.c     | 83 +++-
>  3 files changed, 154 insertions(+), 40 deletions(-)
> 
> diff --git a/cpukit/libmisc/shell/main_edit.c 
> b/cpukit/libmisc/shell/main_edit.c
> index 4cc742719a..16c44f2a11 100644
> --- a/cpukit/libmisc/shell/main_edit.c
> +++ b/cpukit/libmisc/shell/main_edit.c
> @@ -755,8 +755,21 @@ static void get_console_size(struct env *env) {
>    env->cols = ws.ws_col;
>    env->lines = ws.ws_row - 1;
>  #elif defined(__rtems__)
> -  env->cols = 80;
> -  env->lines = 25;
> +  char* e;
> +  e = getenv("LINES");
> +  if (e != NULL) {
> +    int lines = strtol(e, 0, 10);
> +    if (lines > 0) {
> +      env->lines = lines - 1;
> +    }
> +  }
> +  e = getenv("COLUMNS");
> +  if (e != NULL) {
> +    int cols = strtol(e, 0, 10);
> +    if (cols > 0) {
> +      env->cols = cols - 1;
> +    }
> +  }
> 
> Does this lose the default values if the environment variables are not set?
> 

Yes. I will add the defaults back and then push.

Thanks for the review.

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

Re: [PATCH] aarch64/versal: Add UART interrupt support

2022-11-22 Thread Chris Johns
On 22/11/22 6:01 pm, Sebastian Huber wrote:
> Hello Chris,
> 
> On 22/11/2022 03:03, chr...@rtems.org wrote:
>> +static void versal_uart_write_support(
>> +  rtems_termios_device_context *base,
>> +  const char *buf,
>> +  size_t len
>> +)
>> +{
>> +#ifdef VERSAL_CONSOLE_USE_INTERRUPTS
>> +  versal_uart_context *ctx = (versal_uart_context *) base;
>> +  volatile versal_uart *regs = ctx->regs;
>> +
>> +  if (len > 0) {
>> +    rtems_interrupt_lock_context lock_context;
>> +    size_t len_remaining = len;
>> +    const char *p = [0];
>> +    rtems_interrupt_lock_acquire(>interrupt_lock, _context);
> 
> you don't need an extra interrupt lock. The rtems_termios_device_context 
> already
> contains an interrupt lock, see rtems_termios_device_lock_acquire(). This lock
> is held while the write support handler is called.
> 

Thanks for the review and I will remove. The driver took a while to isolate a
possible issue in the hardware. I have raised this with Xilinx. The TX will not
start with the single character write. I needed to write past the trigger point.

I think this driver could be moved to shared as the hardware is based on the ARM
IP for the PL011 UART. I wanted to get the chcanges in and used before
considering moving it. Xilinx has changed the IP a little which is a shame.

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

Re: Use of rtems_fdt_* and sp01

2022-11-20 Thread Chris Johns
On 20/11/2022 10:25 am, Joel Sherrill wrote:
> On Sat, Nov 19, 2022, 4:19 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
> On 19/11/22 2:13 am, Joel Sherrill wrote:
> > On Fri, Nov 18, 2022, 8:49 AM Kinsey Moore  <mailto:kinsey.mo...@oarcorp.com>
> > <mailto:kinsey.mo...@oarcorp.com <mailto:kinsey.mo...@oarcorp.com>>> 
> wrote:
> >     On Fri, Nov 18, 2022 at 12:44 AM Sebastian Huber
> >      <mailto:sebastian.hu...@embedded-brains.de>
> >     <mailto:sebastian.hu...@embedded-brains.de
> <mailto:sebastian.hu...@embedded-brains.de>>> wrote:
> >         On 18/11/2022 06:32, Kinsey Moore wrote:
> >         > On Thu, Nov 17, 2022 at 4:49 PM Chris Johns  <mailto:chr...@rtems.org>
> >         <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>
> >         > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>
> <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>>> wrote:
> >         >
> >         >     On 18/11/2022 2:39 am, Kinsey Moore wrote:
> >         >      > I recently added FDT support to the AArch64 ZynqMP 
> BSPs to
> >         >     support an optional
> >         >      > management console and managing ethernet parameters for
> LibBSD.
> >         >     Use of the
> >         >      > rtems_fdt_* functions implies use of malloc which adds 
> 4
> bytes in
> >         >     the TLS space.
> >         >      > The sp01 test uses rtems_task_construct and specifies a
> maximum
> >         >     TLS size of 0
> >         >      > bytes which causes a failure which the non-zero TLS 
> size is
> >         >     checked against the
> >         >      > maximum TLS size of 0.
> >         >
> >         >     Does this mean there exists a requirement a BSPs cannot
> internally
> >         >     use the heap?
> >         >
> >         >
> >         > That appears to be the case, at least practically. It works
> fine, but it
> >         > causes a test failure...
> >
> >         You can use the heap during system initialization. However, you 
> should
> >         avoid dependencies on errno, so instead of using 
> malloc()/calloc() use
> >         rtems_malloc()/rtems_calloc(). Independent of this, if the BSP
> >         initialization can easily avoid the heap, then it should not use
> the heap.
> >
> >         >
> >         >
> >         >     Maybe the test needs to be adjusted?
> >         >
> >         >
> >         > That's part of why I sent this to the list. I was unsure 
> whether
> it was
> >         > allowed or whether the test had bad assumptions baked into it.
> >
> >         The tests check specific aspects of the thread-local storage
> support and
> >         this works only if the BSP does not depend on TLS objects such 
> as
> errno.
> >
> >     This affects several other tests as well, so I guess my solution 
> here is
> >     either to alter the rtems_fdt_ wrappers to avoid dependencies on 
> TLS or
> >     proceed with the existing patch that uses the non-wrapped FDT 
> functions.
> >
> > I agree with Sebastian that fixing the bsp is right.
> >
> > But also rtems_ fdt methods should be changed to use rtems_malloc. That 
> would
> > leave those methods useful. They are broken now for many intended use 
> cases.
> 
> We are currently reviewing the support for ftbo files in Linux 
> (petalinux) with
> a view to seeing how we can support them on RTEMS. I see FDT being use 
> more and
> more in RTEMS and with a number of different use cases and flows there is 
> a need
> to try and unify how we handle them. I see benefits if we can support a 
> similar
> dtbo model as Linux and if that happens the specific area in question in
> rtems-fst can be move over to using it.
> 
> 
> FWIW Kinsey's patch to the rtems_fdt methods eliminated two coverity issues.

Yes and that is a worth while change. Thanks.

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

Re: Use of rtems_fdt_* and sp01

2022-11-19 Thread Chris Johns
On 19/11/22 2:13 am, Joel Sherrill wrote:
> On Fri, Nov 18, 2022, 8:49 AM Kinsey Moore  <mailto:kinsey.mo...@oarcorp.com>> wrote:
> On Fri, Nov 18, 2022 at 12:44 AM Sebastian Huber
>  <mailto:sebastian.hu...@embedded-brains.de>> wrote:
> On 18/11/2022 06:32, Kinsey Moore wrote:
> > On Thu, Nov 17, 2022 at 4:49 PM Chris Johns  <mailto:chr...@rtems.org>
> > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> wrote:
> >
> >     On 18/11/2022 2:39 am, Kinsey Moore wrote:
> >      > I recently added FDT support to the AArch64 ZynqMP BSPs to
> >     support an optional
> >      > management console and managing ethernet parameters for 
> LibBSD.
> >     Use of the
> >      > rtems_fdt_* functions implies use of malloc which adds 4 
> bytes in
> >     the TLS space.
> >      > The sp01 test uses rtems_task_construct and specifies a 
> maximum
> >     TLS size of 0
> >      > bytes which causes a failure which the non-zero TLS size is
> >     checked against the
> >      > maximum TLS size of 0.
> >
> >     Does this mean there exists a requirement a BSPs cannot 
> internally
> >     use the heap?
> >
> >
> > That appears to be the case, at least practically. It works fine, 
> but it
> > causes a test failure...
> 
> You can use the heap during system initialization. However, you should
> avoid dependencies on errno, so instead of using malloc()/calloc() use
> rtems_malloc()/rtems_calloc(). Independent of this, if the BSP
> initialization can easily avoid the heap, then it should not use the 
> heap.
> 
> >
> >
> >     Maybe the test needs to be adjusted?
> >
> >
> > That's part of why I sent this to the list. I was unsure whether it 
> was
> > allowed or whether the test had bad assumptions baked into it.
> 
> The tests check specific aspects of the thread-local storage support 
> and
> this works only if the BSP does not depend on TLS objects such as 
> errno.
> 
> This affects several other tests as well, so I guess my solution here is
> either to alter the rtems_fdt_ wrappers to avoid dependencies on TLS or
> proceed with the existing patch that uses the non-wrapped FDT functions.
> 
> I agree with Sebastian that fixing the bsp is right.
> 
> But also rtems_ fdt methods should be changed to use rtems_malloc. That would
> leave those methods useful. They are broken now for many intended use cases.

We are currently reviewing the support for ftbo files in Linux (petalinux) with
a view to seeing how we can support them on RTEMS. I see FDT being use more and
more in RTEMS and with a number of different use cases and flows there is a need
to try and unify how we handle them. I see benefits if we can support a similar
dtbo model as Linux and if that happens the specific area in question in
rtems-fst can be move over to using it.

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

Re: [PATCH] cpukit/rtems-fdt: Avoid use of malloc/errno

2022-11-18 Thread Chris Johns
Looks good and thanks

Chris

On 19/11/2022 2:47 am, Kinsey Moore wrote:
> Use of malloc implies errno which adds TLS dependencies and prevents use
> of this FDT wrapper library in BSP initialization code. This change
> makes use of rtems_malloc and rtems_calloc which avoid TLS dependencies.
> ---
>  cpukit/libmisc/rtems-fdt/rtems-fdt.c | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c 
> b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> index 1e382ca108..e5bab21664 100644
> --- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> +++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> @@ -25,9 +25,7 @@
>   * POSSIBILITY OF SUCH DAMAGE.
>   */
>  
> -#include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -35,6 +33,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  
> @@ -175,13 +174,13 @@ rtems_fdt_init_index (rtems_fdt_handle* fdt, 
> rtems_fdt_blob* blob)
>/*
> * Create the index.
> */
> -  entries = calloc(num_entries, sizeof(rtems_fdt_index_entry));
> +  entries = rtems_calloc(num_entries, sizeof(rtems_fdt_index_entry));
>if (!entries)
>{
>  return -RTEMS_FDT_ERR_NO_MEMORY;
>}
>  
> -  names = calloc(1, total_name_memory);
> +  names = rtems_calloc(1, total_name_memory);
>if (!names)
>{
>  free(entries);
> @@ -505,7 +504,7 @@ rtems_fdt_load (const char* filename, rtems_fdt_handle* 
> handle)
>{
>  size_t offset;
>  
> -cdata = malloc(sb.st_size);
> +cdata = rtems_malloc(sb.st_size);
>  if (!cdata)
>  {
>close (bf);
> @@ -546,7 +545,7 @@ rtems_fdt_load (const char* filename, rtems_fdt_handle* 
> handle)
>  
>name_len = strlen (filename) + 1;
>  
> -  blob = malloc(sizeof (rtems_fdt_blob) + name_len + bsize);
> +  blob = rtems_malloc(sizeof (rtems_fdt_blob) + name_len + bsize);
>if (!blob)
>{
>  free(cdata);
> @@ -649,7 +648,7 @@ rtems_fdt_register (const void* dtb, rtems_fdt_handle* 
> handle)
>  return fe;
>}
>  
> -  blob = malloc(sizeof (rtems_fdt_blob));
> +  blob = rtems_malloc(sizeof (rtems_fdt_blob));
>if (!blob)
>{
>  return -RTEMS_FDT_ERR_NO_MEMORY;
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: Use of rtems_fdt_* and sp01

2022-11-17 Thread Chris Johns
On 18/11/2022 2:39 am, Kinsey Moore wrote:
> I recently added FDT support to the AArch64 ZynqMP BSPs to support an optional
> management console and managing ethernet parameters for LibBSD. Use of the
> rtems_fdt_* functions implies use of malloc which adds 4 bytes in the TLS 
> space.
> The sp01 test uses rtems_task_construct and specifies a maximum TLS size of 0
> bytes which causes a failure which the non-zero TLS size is checked against 
> the
> maximum TLS size of 0.

Does this mean there exists a requirement a BSPs cannot internally use the heap?

Maybe the test needs to be adjusted?
> It appears that other BSPs that use FDT data avoid the rtems_fdt_* calls,
> possibly because they weren’t available until recently, and this is the path
> that I’ll be following to resolve this issue for the moment.
> 
> I thought it would be good to bring this up if the rtems_fdt_* wrappers are to
> be more widely useful.

FDT support seems to be based around isolated BSPs and how they use the FDT. I
guess this approach has been done to minimise the impact on RTEMS and I would
have most likely followed a similar path.

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

Announce: RTEMS 5.2-rc1 Release Candidate

2022-11-16 Thread Chris Johns
The RTEMS 5.2-rc1 Release Candidate is available. The release can be found at:

 https://ftp.rtems.org/pub/rtems/releases/5/rc/5.2-rc1/

Please follow the release instructions provided by the link. The release notes
can be found here:

 
https://ftp.rtems.org/pub/rtems/releases/5/rc/5.2-rc1/rtems-5.2-rc1-release-notes.html

They detail the changes that have been made on the 5 branch.

If you find a problem please raise a ticket and select the 5.2 milestone. The
simplest way to create a ticket is to head to the developer Wiki at:

 https://devel.rtems.org/

Then click on the "Next (milestone)" link for the RTEMS 5 Release. You will need
an account.

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


Re: [PATCH] aarch64/mmu: Prevent block descriptors at level -1

2022-11-16 Thread Chris Johns
Tested on Versal (A72) and large mappings are now working. I have pushed the 
patch.

Thanks for this. :)

Chris

On 17/11/2022 2:22 am, Kinsey Moore wrote:
> In the original implementation, level -1 was unused and all levels could
> have block-like descriptors (level 2 block descriptors are called page
> descriptors). When support for level -1 page tables was added the
> constraint on level -1 block descriptors was not honored. This prevents
> block descriptors from being mapped at level -1 since the hardware will
> not map them properly.
> ---
>  bsps/aarch64/include/bsp/aarch64-mmu.h | 23 +--
>  1 file changed, 13 insertions(+), 10 deletions(-)
> 
> diff --git a/bsps/aarch64/include/bsp/aarch64-mmu.h 
> b/bsps/aarch64/include/bsp/aarch64-mmu.h
> index 1287c67016..ebc224b9e1 100644
> --- a/bsps/aarch64/include/bsp/aarch64-mmu.h
> +++ b/bsps/aarch64/include/bsp/aarch64-mmu.h
> @@ -243,26 +243,29 @@ BSP_START_TEXT_SECTION static inline rtems_status_code 
> aarch64_mmu_map_block(
>  /* check for perfect block match */
>  if ( block_bottom == addr ) {
>if ( size >= chunk_size ) {
> -/* when page_flag is set the last level must be a page descriptor */
> -if ( page_flag || ( page_table[index] & MMU_DESC_TYPE_TABLE ) != 
> MMU_DESC_TYPE_TABLE ) {
> -  /* no sub-table, apply block properties */
> -  page_table[index] = addr | flags | page_flag;
> -  size -= chunk_size;
> -  addr += chunk_size;
> -  continue;
> +/* level -1 can't contain block descriptors, fall through to 
> subtable */
> +if ( level != -1 ) {
> +  /* when page_flag is set the last level must be a page descriptor 
> */
> +  if ( page_flag || ( page_table[index] & MMU_DESC_TYPE_TABLE ) != 
> MMU_DESC_TYPE_TABLE ) {
> +/* no sub-table, apply block properties */
> +page_table[index] = addr | flags | page_flag;
> +size -= chunk_size;
> +addr += chunk_size;
> +continue;
> +  }
>  }
>} else {
>  /* block starts on a boundary, but is short */
>  chunk_size = size;
>  
> - /* it isn't possible to go beyond page table level 2 */
> - if ( page_flag ) {
> +/* it isn't possible to go beyond page table level 2 */
> +if ( page_flag ) {
>/* no sub-table, apply block properties */
>page_table[index] = addr | flags | page_flag;
>size -= chunk_size;
>addr += chunk_size;
>continue;
> - }
> +}
>}
>  } else {
>uintptr_t block_top = RTEMS_ALIGN_UP( addr, granularity );
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [5 RSB PATCH 3/3] rtems/net-snmp: Update to 5.9.3 with the RTEMS patch

2022-11-14 Thread Chris Johns
On 15/11/22 3:22 am, Gedare Bloom wrote:
> ok thanks for sorting this out, and for linking the patch through
> trac. You've given me one more thing to check for in RSB patches that
> reference %patch command :)

Thanks for the review and yeah sorry about the extra bit to check. It cannot be
helped.

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


Re: [rtems-docs commit] Update build system related sections for RTEMS 6

2022-11-11 Thread Chris Johns
On 11/11/22 6:39 pm, Sebastian Huber wrote:
> On 10/11/2022 01:30, Chris Johns wrote:
>> The first is the maintenance of embedded the version numbers in the
>> documentation. If we can avoid doing that the work per release or dot release
>> is less.
> 
> We could use a simple search and replace for this. Searching for 'rtems[0-9]'
> shows a couple of spots which need a more through rework. We even have stuff
> with rtems4.10.

That may work for some places but I found it useful to review the documentation
at the same time given things may have changed. In the end I am not fussed how
we make the change. :)

>> The second is the changing of `kernel` to `src`. The use of `kernel` was
>> specific because it removes any ambiguity when a new user attempts to build a
>> package like libbsd in the same tree. Source can mean it is the place where
>> all source is placed. I think `kernel` should be used and returned.
> 
> I usually place all Git repositories in a "src" directory.

Is there a per repo directory under src? I am fine with that. The important
point is having a consistent arrangement that can be used when building other
things like libbsd or the examples without needing to delete or change anything.

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


Re: [PATCH rtems-lwip] rtemslwip: Add note to intentionally blank files

2022-11-10 Thread Chris Johns
On 11/11/22 8:36 am, Kinsey Moore wrote:
> This should be covered by COPYING.rtemslwip. I would say it isn't worth 
> putting
> it in the intentionally empty files.

Agreed. Copyright of "empty" does not make sense.

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


Re: [PATCH] cpukit/fdt: Fix typos and clarify params

2022-11-10 Thread Chris Johns
OK.

Thanks
Chris

On 10/11/22 4:01 am, Kinsey Moore wrote:
> ---
>  cpukit/include/rtems/rtems-fdt.h | 24 +++-
>  1 file changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/cpukit/include/rtems/rtems-fdt.h 
> b/cpukit/include/rtems/rtems-fdt.h
> index 3919593582..18e04352aa 100644
> --- a/cpukit/include/rtems/rtems-fdt.h
> +++ b/cpukit/include/rtems/rtems-fdt.h
> @@ -256,7 +256,7 @@ int rtems_fdt_register (const void* blob, 
> rtems_fdt_handle* handle);
>  
>  /**
>   * Unload a device tree blob or DTB file and release any memory allocated 
> when
> - * loading. The blob is removed from the list of registered.
> + * loading. The blob is removed from the list if registered.
>   *
>   * @param blob_desc A valid blob descriptor.
>   * @return int If less than 0 it is an error code else 0 is return on 
> success.
> @@ -296,7 +296,7 @@ int rtems_fdt_get_mem_rsv (rtems_fdt_handle* handle,
>   * larger string, such as a full path.
>   *
>   * @param blob_desc A valid blob descriptor.
> - * @param arentoffset Structure block offset of a node
> + * @param parentoffset Structure block offset of a node
>   * @param name Name of the subnode to locate.
>   * @param namelen Number of characters of name to consider.
>   * @return int If less than 0 it is an error code else the node offset is
> @@ -345,7 +345,9 @@ int rtems_fdt_path_offset (rtems_fdt_handle* handle, 
> const char* path);
>   *
>   * @param handle The FDT handle to the current blob.
>   * @param nodeoffset Structure block offset of the starting node.
> - * @param length Pointer to an integer variable (will be overwritten) or 
> NULL.
> + * @param length Pointer to an integer variable or NULL. If non-NULL, this 
> will
> + *   be overwritten with either the length in bytes or the error
> + *   code.
>   * @return const char* The node's name on success or NULL on error. The 
> length
>   * if non-NULL will hold the error code.
>   */
> @@ -378,7 +380,9 @@ int rtems_fdt_next_prop_offset(rtems_fdt_handle* handle, 
> int propoffset);
>   * @param handle The FDT handle to the current blob.
>   * @param propoffset Property offset
>   * @param name If not NULL set the pointer to the name string.
> - * @param length Pointer to an integer variable (will be overwritten) or 
> NULL.
> + * @param length Pointer to an integer variable or NULL. If non-NULL, this 
> will
> + *   be overwritten with either the length in bytes or the error
> + *   code.
>   * @return const void* The node's value data.
>   */
>  const void* rtems_fdt_getprop_by_offset(rtems_fdt_handle* handle,
> @@ -395,8 +399,9 @@ const void* rtems_fdt_getprop_by_offset(rtems_fdt_handle* 
> handle,
>   * @param nodeoffset Offset of the node whose property to find
>   * @param name The name of the property to find
>   * @param namelen The number of characters of name to consider
> - * @param length A pointer to an integer variable (will be overwritten) or
> - *   NULL.
> + * @param length Pointer to an integer variable or NULL. If non-NULL, this 
> will
> + *   be overwritten with either the length in bytes or the error
> + *   code.
>   * @return const void* The node's property on success or NULL on error. The
>   * length if non-NULL will hold the error code.
>   */
> @@ -416,8 +421,9 @@ const void *rtems_fdt_getprop_namelen (rtems_fdt_handle* 
> handle,
>   * @param handle The FDT handle to the current blob.
>   * @param nodeoffset The offset of the node whose property to find.
>   * @param name The name of the property to find.
> - * @param length A pointer to an integer variable (will be overwritten) or
> - *   NULL.
> + * @param length Pointer to an integer variable or NULL. If non-NULL, this 
> will
> + *   be overwritten with either the length in bytes or the error
> + *   code.
>   * @return const void* The node's property on success or NULL on error. The
>   * length if non-NULL will hold the error code.
>   */
> @@ -427,7 +433,7 @@ const void *rtems_fdt_getprop (rtems_fdt_handle* handle,
> int*  length);
>  
>  /**
> - * Retrieve the phandle of a given of the device tree node at structure block
> + * Retrieve the phandle of the device tree node at structure block
>   * offset nodeoffset.
>   *
>   * @param handle The FDT handle to the current blob.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [5 DOCS PATCH] waf: Backport from main build fixes

2022-11-10 Thread Chris Johns
On 10/11/22 3:40 pm, Gedare Bloom wrote:
> looks fine. i'm not sure where
> +   "review":   ("Gerrit Code Review",
> "https://review.rtems.org/;),
> came from, but I see it in before too.

It came from the initial work Amar did in moving us to the RST format.

There is no service provided and I have not removed the label.

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


Re: [PATCH rtems-libbsd v2 0/3] CFC400X support

2022-11-09 Thread Chris Johns

Looks good.

Thanks
Chris

On 9/11/2022 4:10 pm, Kinsey Moore wrote:

In this revised patch set, SGMII support has been reworked to use device
trees while preserving existing static instantiation used by Zynq and
Versal BSPs.

___
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: Add Formal Verification chapter v2

2022-11-09 Thread Chris Johns

On 9/11/2022 9:48 pm, andrew.butterfi...@scss.tcd.ie wrote:

ping

(my fault really, i've let this sit!)



Thank you for raising this and I am sorry we have not been as proactive 
as we should be.



But I have been busy, interacting with a group doing a follow-up IV project 
with the qualification data package we produced.
A conseuience of this is that I am helping them to add two extra manager models 
developed by students, for Barriers and Message Queues.

This would add two more entries to the model guide, and raises the question of 
the best place to document the models.
Is the RTEMS Software Engineering manual the best location for those? If not, 
where should they live?

Another side effect fo all this is that there is now a definitive version of 
the formal models and test generation in a public repo:

https://github.com/andrewbutterfield/RTEMS-SMP-Formal



Excellent.

I have no expertise in this area and I am more than happy to defer to 
you and your team in this area.


I have no objections to this working being merge as is. I see it as 
green field work and yours is the first here. I am sure updates or 
changes can be made over time by you or others as the work is absorbed 
and reviewed.


Thank you for all the efforts you and those with you have made. I 
personally think it is fantastic to have this work happen and being made 
public in this way so thank you from me.


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


Re: [rtems-docs commit] Update build system related sections for RTEMS 6

2022-11-09 Thread Chris Johns

On 9/11/2022 4:28 pm, Sebastian Huber wrote:

On 09/11/2022 01:35, Chris Johns wrote:


Was this posted for review? I do not remember seeing it?


Yes, on September 12.


Thanks. Sorry, I must have missed it.


There are a number of things that could be improved with this change.


I am sure things can be improved, but removing completely out of date 
stuff can't be that bad.


The change is needed, thanks.

I had a couple of points. Both minor in the context of the needed change.

The first is the maintenance of embedded the version numbers in the 
documentation. If we can avoid doing that the work per release or dot 
release is less.


The second is the changing of `kernel` to `src`. The use of `kernel` was 
specific because it removes any ambiguity when a new user attempts to 
build a package like libbsd in the same tree. Source can mean it is the 
place where all source is placed. I think `kernel` should be used and 
returned.


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


Re: [PATCH v2] zynqmp: Add support for the CFC-400X

2022-11-08 Thread Chris Johns

Looks good and thank you for sorting out this approach.

Thanks
Chris

On 9/11/2022 8:56 am, Kinsey Moore wrote:

This adds a BSP variant for the ZynqMP BSP family to support the
Innoflight CFC-400X platform. To properly support the CFC-400X, device
trees were added to the ZynqMP platform due to both the optional
management interface as well as alternate physical configuration of the
ethernet interfaces.
---
  bsps/aarch64/xilinx-zynqmp/console/console.c  | 163 +-
  bsps/aarch64/xilinx-zynqmp/fdt/bsp_fdt.c  |  51 ++
  bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts| 110 
  bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c  | 124 +
  bsps/aarch64/xilinx-zynqmp/fdt/zynqmp.dts |  94 ++
  bsps/aarch64/xilinx-zynqmp/fdt/zynqmp_dtb.c   |  97 +++
  bsps/aarch64/xilinx-zynqmp/include/bsp.h  |  15 ++
  .../aarch64/xilinx-zynqmp/start/bspstartmmu.c |   4 +
  .../aarch64/xilinx-zynqmp/bspcfc400xlp64.yml  |  21 +++
  .../aarch64/xilinx-zynqmp/bspqemuilp32.yml|   2 +
  .../aarch64/xilinx-zynqmp/bspqemulp64.yml |   2 +
  .../aarch64/xilinx-zynqmp/bspzu3egilp32.yml   |   2 +
  .../aarch64/xilinx-zynqmp/bspzu3eglp64.yml|   2 +
  spec/build/bsps/aarch64/xilinx-zynqmp/obj.yml |   1 +
  .../aarch64/xilinx-zynqmp/objfdtcfc400x.yml   |  14 ++
  .../aarch64/xilinx-zynqmp/objfdtzynqmp.yml|  14 ++
  .../bsps/aarch64/xilinx-zynqmp/optloadoff.yml |   1 +
  .../bsps/aarch64/xilinx-zynqmp/optramori.yml  |   1 +
  spec/build/cpukit/optsmp.yml  |   1 +
  19 files changed, 718 insertions(+), 1 deletion(-)
  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/bsp_fdt.c
  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts
  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c
  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/zynqmp.dts
  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/zynqmp_dtb.c
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/bspcfc400xlp64.yml
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/objfdtcfc400x.yml
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/objfdtzynqmp.yml

diff --git a/bsps/aarch64/xilinx-zynqmp/console/console.c 
b/bsps/aarch64/xilinx-zynqmp/console/console.c
index d1948f1a0c..d546db8535 100644
--- a/bsps/aarch64/xilinx-zynqmp/console/console.c
+++ b/bsps/aarch64/xilinx-zynqmp/console/console.c
@@ -9,7 +9,7 @@
   */
  
  /*

- * Copyright (C) 2020 On-Line Applications Research Corporation (OAR)
+ * Copyright (C) 2022 On-Line Applications Research Corporation (OAR)
   * Written by Kinsey Moore 
   *
   * Redistribution and use in source and binary forms, with or without
@@ -36,13 +36,165 @@
  
  #include 

  #include 
+#include 
+#include 
  #include 
  
+#include 

+#include 
  #include 
+
  #include 
  
  #include 
  
+#include 

+
+uint32_t mgmt_uart_reg_shift = 0;
+static uint8_t get_register(uintptr_t addr, uint8_t i)
+{
+  volatile uint8_t *reg = (uint8_t *) addr;
+
+  i <<= mgmt_uart_reg_shift;
+  return reg [i];
+}
+
+static void set_register(uintptr_t addr, uint8_t i, uint8_t val)
+{
+  volatile uint8_t *reg = (uint8_t *) addr;
+
+  i <<= mgmt_uart_reg_shift;
+  reg [i] = val;
+}
+
+static ns16550_context zynqmp_mgmt_uart_context = {
+  .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER("Management UART 0"),
+  .get_reg = get_register,
+  .set_reg = set_register,
+  .port = 0,
+  .irq = 0,
+  .clock = 0,
+  .initial_baud = 0,
+};
+
+__attribute__ ((weak)) void 
zynqmp_configure_management_console(rtems_termios_device_context *base)
+{
+  /* This SLIP-encoded watchdog command sets timeouts to 0x seconds. */
+  const char mgmt_watchdog_cmd[] =
+"\xc0\xda\x00\x00\xff\xff\xff\xff\xff\x00\xff\xff\xff\xffM#\xc0";
+
+  /* Send the system watchdog configuration command */
+  for (int i = 0; i < sizeof(mgmt_watchdog_cmd); i++) {
+ns16550_polled_putchar(base, mgmt_watchdog_cmd[i]);
+  }
+}
+
+static void zynqmp_management_console_init(void)
+{
+  /* Find the management console in the device tree */
+  rtems_fdt_handle fdt_handle;
+  const uint32_t *prop;
+  uint32_t outprop[4];
+  int proplen;
+  int node;
+
+  rtems_fdt_init_handle(_handle);
+  rtems_fdt_register(bsp_fdt_get(), _handle);
+  const char *alias = rtems_fdt_get_alias(_handle, "mgmtport");
+  if (alias == NULL) {
+rtems_fdt_release_handle(_handle);
+return;
+  }
+  node = rtems_fdt_path_offset(_handle, alias);
+
+  prop = rtems_fdt_getprop(_handle, node, "clock-frequency", );
+  if ( prop == NULL || proplen != 4 ) {
+rtems_fdt_release_handle(_handle);
+zynqmp_mgmt_uart_context.port = 0;
+return;
+  }
+  outprop[0] = rtems_uint32_from_big_endian((const uint8_t *) [0]);
+  zynqmp_mgmt_uart_context.clock = outprop[0];
+
+  prop = rtems_fdt_getprop(_handle, node, "current-speed", );
+  if ( prop == NULL || proplen != 4 ) {
+rtems_fdt_release_handle(_handle);
+zynqmp_mgmt_uart_context.port = 0;
+return;
+  }
+  outprop[0] = 

Documentation changes required for release

2022-11-08 Thread Chris Johns

Hello,

The following was add to the documentation build support for the RTEMS 6 
release to avoid the need for us to perform mindless updates of the 
documentation on each release cycle:


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

The text is:

10. Use the following to embed the version number in any part of the
documentation source:

 1. @rtems-version@

The complete version string of the documentation.

 2. @rtems-ver-major@

The version major number.

 2. @rtems-ver-minor@

The version minor number.

 2. @rtems-ver-revision@

The version revision number.

The replacement happens during the source read phase of the build
and is not context specific. The substitution will happen in code
blocks and other normally quoted area.

It is a requirement these be used then embedded commands or
related text in the documentation to let the documentation track
the release. For example `microblaze-rtems6-gdb` should be written
as `microblaze-rtems@rtems-ver-major@-gdb`.

Note, the support for these version number may require some adjustments 
of what is provided in the documentation to aid the text being moved 
across releases without change. There is no hard and fast set of rule so 
please use commonsense. Sometimes less is better but is it a piece by 
piece call.


I would appreciate this being followed rather than it being the 
responsibility of the people perform the release to sort out. It only 
delays the releases.


Thanks
Chris

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


Re: [rtems-docs commit] Update build system related sections for RTEMS 6

2022-11-08 Thread Chris Johns

Hi,

Was this posted for review? I do not remember seeing it?

There are a number of things that could be improved with this change.

Chris

On 8/11/2022 4:47 pm, Sebastian Huber wrote:

Module:rtems-docs
Branch:master
Commit:31199e3a69d2dbd0a8f360e424fd19f3e9ef66ce
Changeset: 
http://git.rtems.org/rtems-docs/commit/?id=31199e3a69d2dbd0a8f360e424fd19f3e9ef66ce

Author:Sebastian Huber 
Date:  Mon Sep 12 09:10:38 2022 +0200

Update build system related sections for RTEMS 6

Update sections which contained the word "bsp_specs".

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


Re: [PATCH 2/2] c-user/clock: Fix typo

2022-11-07 Thread Chris Johns
+1

On 8/11/2022 3:26 am, Gedare Bloom wrote:
> ok to both
> 
> On Mon, Nov 7, 2022 at 3:20 AM Matthew Joyce
>  wrote:
>>
>> From: Matt Joyce 
>>
>> ---
>>  c-user/clock/directives.rst | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/c-user/clock/directives.rst b/c-user/clock/directives.rst
>> index 6e1542c..877204a 100644
>> --- a/c-user/clock/directives.rst
>> +++ b/c-user/clock/directives.rst
>> @@ -1222,7 +1222,7 @@ system initialization using :term:`CLOCK_MONOTONIC`.
>>  .. rubric:: PARAMETERS:
>>
>>  ``uptime``
>> -This parameter is the pointer to a `struct timeval
>> +This parameter is the pointer to a `struct timespec
>>  
>> `_
>>  object.  When the directive call is successful, the seconds and 
>> nanoseconds
>>  elapsed since some time point during the system initialization and some
>> --
>> 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: xz_crc64.c not compiled

2022-11-07 Thread Chris Johns
On 8/11/2022 3:23 am, Gedare Bloom wrote:
> On Fri, Nov 4, 2022 at 5:05 PM Chris Johns  wrote:
>>
>> On 5/11/2022 6:46 am, Gedare Bloom wrote:
>>> On Fri, Nov 4, 2022 at 1:39 PM Joel Sherrill  wrote:
>>>>
>>>>
>>>>
>>>> On Fri, Nov 4, 2022, 2:37 PM Gedare Bloom  wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I don't see an entry in spec/build anywhere for xz_crc64.c
>>>>>
>>>>>  From what I can tell it is not compiled/tested. I guess the
>>>>> This leads me to believe it is not compiled. And therefore is not
>>>>> being called or tested anywhere.
>>>>>
>>>>> Should it be compiled, or should it be removed?
>>>>
>>>>
>>>> What about in 5 and the autotools build system?
>>>>
>>> It appears to be omitted from 5's cpukit/Makefile.am
>>>
>>> I don't see the code in 4.11. It was added by Chris to support untar
>>> of tgz files.
>>
>> Sorry I do not recall why it was not added into the build. There are no
>> calls in the code to it.
>>
> I guess the question then is whether to add it to the build and write
> a testsuite call to it, or to remove it from the tree.

Maybe add it? If you need to add a 64bit CRC the code is there?

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


Re: Apple's Ventura OS issue with RSB.

2022-11-06 Thread Chris Johns
On 7/11/2022 5:38 am, Karel Gardas wrote:
> 
> Side note before answering : the email was motivated by the fact that I 
> provided
> few patches to RSB to make that working well on Monterey running on M1. This 
> was
> just few weeks ago so I know, this was running well. Last week I've updated to
> Ventura and things felt apart. Hence the report here.
> 
> On 11/6/22 16:09, Joel Sherrill wrote:
>> Is the cross gcc compiled with the native compiler provided by Apple? 
> 
> Yes, it is.
> 
>> The alternative would likely be you installing something special.
> 
> No, I keep OS as clean as possible and as stock as possible to be as close as
> possible to customer configuration.
> 
>> I wonder if using gcc to compile it would work. But there's not a real 
>> solution.
> 
> Indeed, I'll see if I can do anything about that as that would also be usable
> for...
> 
>>
>> Seems like an issue which needs reporting to gcc.
>>
> 
> indeed, the report here is probably minimal thing I should do.

Sebastian has pushed updates to the tools to the RSB. Did you happen to pick up
those?

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


Re: xz_crc64.c not compiled

2022-11-04 Thread Chris Johns

On 5/11/2022 6:46 am, Gedare Bloom wrote:

On Fri, Nov 4, 2022 at 1:39 PM Joel Sherrill  wrote:




On Fri, Nov 4, 2022, 2:37 PM Gedare Bloom  wrote:


Hi all,

I don't see an entry in spec/build anywhere for xz_crc64.c

 From what I can tell it is not compiled/tested. I guess the
This leads me to believe it is not compiled. And therefore is not
being called or tested anywhere.

Should it be compiled, or should it be removed?



What about in 5 and the autotools build system?


It appears to be omitted from 5's cpukit/Makefile.am

I don't see the code in 4.11. It was added by Chris to support untar
of tgz files.


Sorry I do not recall why it was not added into the build. There are no 
calls in the code to it.


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


Re: Fwd: Identify 3rd party source in spec?

2022-11-04 Thread Chris Johns

On 5/11/2022 4:00 am, Gedare Bloom wrote:

Given the complexity of this tagging, I'm going to start with just the
true/false approach to categorize third-party sources. We can do
something like the above in the future.


Sounds good. We can consider a dict when someone maps out how to manage 
3rd party source. I think it would premature to do it without further 
consideration.


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


Re: [PATCH 2/2] wscript: rename bsp_list to bsplist

2022-11-03 Thread Chris Johns
+1

On 4/11/2022 2:59 am, Gedare Bloom wrote:
> ---
>  wscript | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/wscript b/wscript
> index a8510edbee..b42c8f1119 100755
> --- a/wscript
> +++ b/wscript
> @@ -1694,7 +1694,7 @@ COMPILER = {}""".format(
>  no_matches_error(ctx, white_list)
>  
>  
> -def bsp_list(ctx):
> +def bsplist(ctx):
>  """lists base BSP variants"""
>  check_forbidden_options(
>  ctx, ["compiler", "config", "options", "tools", "top_group", 
> "version"]
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: Fwd: Identify 3rd party source in spec?

2022-11-02 Thread Chris Johns
On 3/11/2022 2:50 pm, Chris Johns wrote:
> On 3/11/2022 10:30 am, Gedare Bloom wrote:
>> It was pointed out in Discord that the "third_party_list" command is
>> unusual with respect to other waf commands, which are given as oneword
>> formats (other than bsp_list and bsp_defaults). I think it makes sense
>> to go with such a oneword format for consistent commands. So I will
>> instead start prototyping this as
>> ./waf thirdparties
>>
>> instead of
>> ./waf third_party_list
>>
> 
> Great and thanks.
> 
>> Relatedly: I might look into changing
>> ./waf bsp_list
>> to
>> ./waf bsps
>>
>> and
>> ./waf bsp_defaults
>> to
>> ./waf bspdefaults
>>
>> the hard part will be chasing down the documentation.
> 
> I like the change and doing it now would mean it would change across releases.

Would not be changing across releases ... that is

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


Re: Fwd: Identify 3rd party source in spec?

2022-11-02 Thread Chris Johns
On 3/11/2022 10:30 am, Gedare Bloom wrote:
> It was pointed out in Discord that the "third_party_list" command is
> unusual with respect to other waf commands, which are given as oneword
> formats (other than bsp_list and bsp_defaults). I think it makes sense
> to go with such a oneword format for consistent commands. So I will
> instead start prototyping this as
> ./waf thirdparties
> 
> instead of
> ./waf third_party_list
> 

Great and thanks.

> Relatedly: I might look into changing
> ./waf bsp_list
> to
> ./waf bsps
> 
> and
> ./waf bsp_defaults
> to
> ./waf bspdefaults
> 
> the hard part will be chasing down the documentation.

I like the change and doing it now would mean it would change across releases.

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


Re: [PATCH rtems-libbsd] freebsd/cgem: Use SGMII when necessary

2022-11-01 Thread Chris Johns
On 2/11/2022 1:48 pm, Kinsey Moore wrote:
> On Tue, Nov 1, 2022 at 9:22 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> On 2/11/2022 1:18 pm, Kinsey Moore wrote:
> > On Tue, Nov 1, 2022 at 5:49 PM Chris Johns  <mailto:chr...@rtems.org>
> > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> wrote:
> >
> >     On 2/11/2022 8:56 am, Kinsey Moore wrote:
> >     > On Tue, Nov 1, 2022 at 4:14 PM Chris Johns  <mailto:chr...@rtems.org>
> >     <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>
> >     > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>
> <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>>> wrote:
> >     >     On 2/11/2022 5:51 am, Kinsey Moore wrote:
> >     >     > Certain hardware configurations will always use SGMII 
> instead
> of RGMII.
> >     >     > Apply the appropriate flags for the relevant BSPs.
> >     >     > ---
> >     >     >  freebsd/sys/dev/cadence/if_cgem.c | 10 ++
> >     >     >  1 file changed, 10 insertions(+)
> >     >     >
> >     >     > diff --git a/freebsd/sys/dev/cadence/if_cgem.c
> >     >     b/freebsd/sys/dev/cadence/if_cgem.c
> >     >     > index 3eaaf6b2..9b4cf693 100644
> >     >     > --- a/freebsd/sys/dev/cadence/if_cgem.c
> >     >     > +++ b/freebsd/sys/dev/cadence/if_cgem.c
> >     >     > @@ -1296,6 +1296,16 @@ cgem_config(struct cgem_softc *sc)
> >     >     >               CGEM_NET_CFG_FULL_DUPLEX |
> >     >     >               CGEM_NET_CFG_SPEED100;
> >     >     > 
> >     >     > +#ifdef __rtems__
> >     >     > +#define STRINGIFY(to_str) #to_str
> >     >     > +#define BSP_STR(to_str) STRINGIFY(to_str)
> >     >     > +     /* Configure the PHYs to use SGMII for particular 
> BSPs */
> >     >     > +     if ( 0 == strcmp( BSP_STR(RTEMS_BSP),
> >     "xilinx_zynqmp_lp64_cfc400x" ) ) {
> >     >     > +             net_cfg |= CGEM_NET_CFG_SGMII_EN;
> >     >     > +             net_cfg |= CGEM_NET_CFG_PCS_SEL;
> >     >     > +     }
> >     >
> >     >     This makes it a precedent a cgem device has to be an RTEMS 
> BSP to
> >     support SGMII.
> >     >     I do not think that is a good idea.
> >     >
> >     > I don't particularly like this solution either, but I evaluated a
> few other
> >     > options (see below).
> >
> >     I also do not like it.
> >
> >     >     Is the simplest solution adding a weak function call asks 
> which mode
> >     and the
> >     >     default call returns RGMII?
> >     >
> >     > The downside to that is that none of the tests can operate as
> expected on a
> >     > SGMII-attached-PHY system since the application would be 
> overriding
> the weak
> >     > symbol and the tests wouldn't do that. Another option would be to 
> have a
> >     generic
> >     > option in RTEMS that specifies the PHY attachment and can be set 
> in
> >     config.ini,
> >     > but that would appear to be dead code since it's not used within 
> RTEMS.
> >
> >     Would FDT solve this problem? Forcing FDT support onto the cgem 
> driver
> would
> >     break compatibility so it would have to handle a default state. If 
> FDT
> probes
> >     were tolerant of calls without a valid FDT being loaded it would be
> better but
> >     our FDT support seems to have no middle ground from what I can see.
> >
> >
> > FDT could technically solve the problem, current driver support and PHY
> > transport option support notwithstanding. As you pointed out, there 
> isn't
> > currently a way to have both static configuration and FDT support at 
> the same
> > time and multiple BSPs across multiple architectures use the CGEM 
> support - at
> > least Zynq, ZynqMP, and Versal - all of which would need the appropriate
> support
> > added. I thought we had a RISC-V BSP that used it as well, but I don't 
> see
> it at
> > the moment.
> >
> >
> >     > As far as I'm aware, the closest analog in LibBSD would be the 
> buildset
> >     > configuration, but that seems more like a place to define which
> modules get
> >     > built than a location for configuring hardware.
> >
> >     I think FDT is handling this stuff for other archs and the MRMAC 
> will also
> >     require FDT support.
> >
> >
> > It is and the FDT support in this driver in FreeBSD 13 is a bit better.
> 
> Does this mean existing Zynq etc BSPs would need to add FDT support?
> 
> 
> Yes, unless there's a solution that allows both to exist at the same time. I
> haven't investigated that option thoroughly.

Maybe we meet up and discuss the options.

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

Re: [PATCH rtems-libbsd] freebsd/cgem: Use SGMII when necessary

2022-11-01 Thread Chris Johns


On 2/11/2022 1:18 pm, Kinsey Moore wrote:
> On Tue, Nov 1, 2022 at 5:49 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
> On 2/11/2022 8:56 am, Kinsey Moore wrote:
> > On Tue, Nov 1, 2022 at 4:14 PM Chris Johns  <mailto:chr...@rtems.org>
> > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> wrote:
> >     On 2/11/2022 5:51 am, Kinsey Moore wrote:
> >     > Certain hardware configurations will always use SGMII instead of 
> RGMII.
> >     > Apply the appropriate flags for the relevant BSPs.
> >     > ---
> >     >  freebsd/sys/dev/cadence/if_cgem.c | 10 ++
> >     >  1 file changed, 10 insertions(+)
> >     >
> >     > diff --git a/freebsd/sys/dev/cadence/if_cgem.c
> >     b/freebsd/sys/dev/cadence/if_cgem.c
> >     > index 3eaaf6b2..9b4cf693 100644
> >     > --- a/freebsd/sys/dev/cadence/if_cgem.c
> >     > +++ b/freebsd/sys/dev/cadence/if_cgem.c
> >     > @@ -1296,6 +1296,16 @@ cgem_config(struct cgem_softc *sc)
> >     >               CGEM_NET_CFG_FULL_DUPLEX |
> >     >               CGEM_NET_CFG_SPEED100;
> >     > 
> >     > +#ifdef __rtems__
> >     > +#define STRINGIFY(to_str) #to_str
> >     > +#define BSP_STR(to_str) STRINGIFY(to_str)
> >     > +     /* Configure the PHYs to use SGMII for particular BSPs */
> >     > +     if ( 0 == strcmp( BSP_STR(RTEMS_BSP),
> "xilinx_zynqmp_lp64_cfc400x" ) ) {
> >     > +             net_cfg |= CGEM_NET_CFG_SGMII_EN;
> >     > +             net_cfg |= CGEM_NET_CFG_PCS_SEL;
> >     > +     }
> >
> >     This makes it a precedent a cgem device has to be an RTEMS BSP to
> support SGMII.
> >     I do not think that is a good idea.
> >
> > I don't particularly like this solution either, but I evaluated a few 
> other
> > options (see below).
> 
> I also do not like it.
> 
> >     Is the simplest solution adding a weak function call asks which mode
> and the
> >     default call returns RGMII?
> >
> > The downside to that is that none of the tests can operate as expected 
> on a
> > SGMII-attached-PHY system since the application would be overriding the 
> weak
> > symbol and the tests wouldn't do that. Another option would be to have a
> generic
> > option in RTEMS that specifies the PHY attachment and can be set in
> config.ini,
> > but that would appear to be dead code since it's not used within RTEMS.
> 
> Would FDT solve this problem? Forcing FDT support onto the cgem driver 
> would
> break compatibility so it would have to handle a default state. If FDT 
> probes
> were tolerant of calls without a valid FDT being loaded it would be 
> better but
> our FDT support seems to have no middle ground from what I can see.
> 
> 
> FDT could technically solve the problem, current driver support and PHY
> transport option support notwithstanding. As you pointed out, there isn't
> currently a way to have both static configuration and FDT support at the same
> time and multiple BSPs across multiple architectures use the CGEM support - at
> least Zynq, ZynqMP, and Versal - all of which would need the appropriate 
> support
> added. I thought we had a RISC-V BSP that used it as well, but I don't see it 
> at
> the moment.
> 
> 
> > As far as I'm aware, the closest analog in LibBSD would be the buildset
> > configuration, but that seems more like a place to define which modules 
> get
> > built than a location for configuring hardware.
> 
> I think FDT is handling this stuff for other archs and the MRMAC will also
> require FDT support.
> 
> 
> It is and the FDT support in this driver in FreeBSD 13 is a bit better.

Does this mean existing Zynq etc BSPs would need to add FDT support?

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

Re: [PATCH rtems-libbsd] freebsd/cgem: Use SGMII when necessary

2022-11-01 Thread Chris Johns
On 2/11/2022 8:56 am, Kinsey Moore wrote:
> On Tue, Nov 1, 2022 at 4:14 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> On 2/11/2022 5:51 am, Kinsey Moore wrote:
> > Certain hardware configurations will always use SGMII instead of RGMII.
> > Apply the appropriate flags for the relevant BSPs.
> > ---
> >  freebsd/sys/dev/cadence/if_cgem.c | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/freebsd/sys/dev/cadence/if_cgem.c
> b/freebsd/sys/dev/cadence/if_cgem.c
> > index 3eaaf6b2..9b4cf693 100644
> > --- a/freebsd/sys/dev/cadence/if_cgem.c
> > +++ b/freebsd/sys/dev/cadence/if_cgem.c
> > @@ -1296,6 +1296,16 @@ cgem_config(struct cgem_softc *sc)
> >               CGEM_NET_CFG_FULL_DUPLEX |
> >               CGEM_NET_CFG_SPEED100;
> > 
> > +#ifdef __rtems__
> > +#define STRINGIFY(to_str) #to_str
> > +#define BSP_STR(to_str) STRINGIFY(to_str)
> > +     /* Configure the PHYs to use SGMII for particular BSPs */
> > +     if ( 0 == strcmp( BSP_STR(RTEMS_BSP), 
> "xilinx_zynqmp_lp64_cfc400x" ) ) {
> > +             net_cfg |= CGEM_NET_CFG_SGMII_EN;
> > +             net_cfg |= CGEM_NET_CFG_PCS_SEL;
> > +     }
> 
> This makes it a precedent a cgem device has to be an RTEMS BSP to support 
> SGMII.
> I do not think that is a good idea.
> 
> I don't particularly like this solution either, but I evaluated a few other
> options (see below).

I also do not like it.

> Is the simplest solution adding a weak function call asks which mode and 
> the
> default call returns RGMII?
> 
> The downside to that is that none of the tests can operate as expected on a
> SGMII-attached-PHY system since the application would be overriding the weak
> symbol and the tests wouldn't do that. Another option would be to have a 
> generic
> option in RTEMS that specifies the PHY attachment and can be set in 
> config.ini,
> but that would appear to be dead code since it's not used within RTEMS.

Would FDT solve this problem? Forcing FDT support onto the cgem driver would
break compatibility so it would have to handle a default state. If FDT probes
were tolerant of calls without a valid FDT being loaded it would be better but
our FDT support seems to have no middle ground from what I can see.

> As far as I'm aware, the closest analog in LibBSD would be the buildset
> configuration, but that seems more like a place to define which modules get
> built than a location for configuring hardware.

I think FDT is handling this stuff for other archs and the MRMAC will also
require FDT support.

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

Re: [PATCH rtems-lwip 1/2] lwip.py: Remove redundant assignment

2022-11-01 Thread Chris Johns
+1

On 2/11/2022 7:28 am, Vijay Kumar Banerjee wrote:
> Hi Kinsey,
> 
> The patches look great. Thanks for the cleanup.
> 
> 
> Best regards,
> Vijay
> 
> On Tue, Nov 1, 2022 at 1:51 PM Kinsey Moore  wrote:
>>
>> ---
>>  lwip.py | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/lwip.py b/lwip.py
>> index c11ed1f..e6580eb 100644
>> --- a/lwip.py
>> +++ b/lwip.py
>> @@ -214,8 +214,6 @@ def build(bld):
>>  lib=['rtemscpu', 'rtemsbsp', 'rtemstest', 'lwip'],
>>  includes=' '.join(test_app_incl))
>>
>> -arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
>> -bld.env.RTEMS_ARCH_BSP)
>>  lib_path = os.path.join(bld.env.PREFIX, arch_lib_path)
>>  bld.read_stlib('telnetd', paths=[lib_path])
>>  bld.read_stlib('rtemstest', paths=[lib_path])
>> --
>> 2.30.2
>>
>> ___
>> 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] zynqmp: Add support for the CFC-400X

2022-11-01 Thread Chris Johns
On 2/11/2022 8:15 am, Kinsey Moore wrote:
> On Tue, Nov 1, 2022 at 3:59 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
> On 2/11/2022 5:38 am, Kinsey Moore wrote:> +#ifdef
> BSP_XILINX_ZYNQMP_MGMT_UART_BASE
> > +/**
> > + * @brief Zynq UltraScale+ MPSoC specific set up of a management 
> console.
> > + *
> > + * The ZynqMP SoC's programmable logic can provide a serial interface 
> for
> system
> > + * management which may need special initialization. Provide in the
> application
> > + * to override the defaults in the BSP.
> > + */
> 
> I am not comfortable with PL implementation dependences for specific 
> hardware
> being added to the generic BSP code. The Zynq, ZymqMP and Versal have so 
> far
> only referenced the hard IP.
> 
> Is the PL project and implementation for the PL logic openly available?
> 
> Unfortunately, not as far as I'm aware. The management interface is guaranteed
> to exist as a 16550 UART on all variants of the system and, from the RTEMS
> perspective, the PL is a locked/hard part of the system.

The PL is anything but hard, it is a feature of the device.

> The hardware requires I request a data sheet from the manufacturer and 
> that
> makes keeping this code in our open repo difficult.
> 
> I understand. The unfortunate part of this is that RTEMS isn't usable on this
> platform beyond a couple of seconds without pushing off the system watchdog 
> via
> the 16550 UART. I have automated the watchdog parameter manipulation 
> externally
> for testing purposes, but a system running outside that harness would 
> encounter
> problems with many tests in the testsuite.

I am not sure I am following. Have they wired a watchdog to accessing the UART?

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


Re: [PATCH rtems-libbsd] freebsd/cgem: Use SGMII when necessary

2022-11-01 Thread Chris Johns
On 2/11/2022 5:51 am, Kinsey Moore wrote:
> Certain hardware configurations will always use SGMII instead of RGMII.
> Apply the appropriate flags for the relevant BSPs.
> ---
>  freebsd/sys/dev/cadence/if_cgem.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/freebsd/sys/dev/cadence/if_cgem.c 
> b/freebsd/sys/dev/cadence/if_cgem.c
> index 3eaaf6b2..9b4cf693 100644
> --- a/freebsd/sys/dev/cadence/if_cgem.c
> +++ b/freebsd/sys/dev/cadence/if_cgem.c
> @@ -1296,6 +1296,16 @@ cgem_config(struct cgem_softc *sc)
>   CGEM_NET_CFG_FULL_DUPLEX |
>   CGEM_NET_CFG_SPEED100;
>  
> +#ifdef __rtems__
> +#define STRINGIFY(to_str) #to_str
> +#define BSP_STR(to_str) STRINGIFY(to_str)
> + /* Configure the PHYs to use SGMII for particular BSPs */
> + if ( 0 == strcmp( BSP_STR(RTEMS_BSP), "xilinx_zynqmp_lp64_cfc400x" ) ) {
> + net_cfg |= CGEM_NET_CFG_SGMII_EN;
> + net_cfg |= CGEM_NET_CFG_PCS_SEL;
> + }

This makes it a precedent a cgem device has to be an RTEMS BSP to support SGMII.
I do not think that is a good idea.

Is the simplest solution adding a weak function call asks which mode and the
default call returns RGMII?

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


Re: Fwd: Identify 3rd party source in spec?

2022-11-01 Thread Chris Johns
On 2/11/2022 3:25 am, o...@c-mauderer.de wrote:> Is it a good idea to make it a
mandatory attribute? It makes the yaml files
> bigger. It will only mean that we have to look for copy and paste bugs instead
> of missing attributes if someone adds a new third party library.

Can you avoid having to add the item to all? I am no spec build system expert
(having invested time) and seem to remember needing to hit a lot of files when
adding something ...

https://git.rtems.org/rtems/commit/?id=6f2aa8ad36e3aaffc9fa2cb8c744b04da7339ee2

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


Re: [PATCH] zynqmp: Add support for the CFC-400X

2022-11-01 Thread Chris Johns
On 2/11/2022 5:38 am, Kinsey Moore wrote:> +#ifdef 
BSP_XILINX_ZYNQMP_MGMT_UART_BASE
> +/**
> + * @brief Zynq UltraScale+ MPSoC specific set up of a management console.
> + *
> + * The ZynqMP SoC's programmable logic can provide a serial interface for 
> system
> + * management which may need special initialization. Provide in the 
> application
> + * to override the defaults in the BSP.
> + */

I am not comfortable with PL implementation dependences for specific hardware
being added to the generic BSP code. The Zynq, ZymqMP and Versal have so far
only referenced the hard IP.

Is the PL project and implementation for the PL logic openly available?

The hardware requires I request a data sheet from the manufacturer and that
makes keeping this code in our open repo difficult.

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


Re: [PATCH 1/2] bsps/riscv: Remove inaccurate statement about reliance on a boot loader

2022-10-31 Thread Chris Johns
On 31/10/2022 10:44 pm, Hesham Almatary wrote:
> Hello,
> 
> I tried to push that but got an error message:
> "remote: git_buildbot: ERROR: Could not connect to
> buildbot.int.rtems.org:9899: Connection was refused by other side: 61:
> Connection refused."

Please try again. We have had some server issues.

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


Re: Text Formatting Patches coming

2022-10-31 Thread Chris Johns
On 1/11/2022 2:59 am, Gedare Bloom wrote:
> I am planning to roll out several text formatting changes over the
> next 6 weeks or so, to include:
> 1. Removal of URLs from Copyright lines as per #4636. Note: Most of
> the included URLs currently are from EB or Chris Johns (Contemporary
> Software).
> 2. Consistent capitalization of Copyright (C) in file header blocks as
> per #4637.
> * Style Updates as per #3860.
> 
> This effort will include documentation, inclusion of automation tools,
> and 3rd party software management. I will send patches and give notice
> before any changes hit, but I wanted to give a heads up here that this
> process will be taking place. If you have any specific requests or
> patches pending in an area that I should avoid for now, please let me
> know.

Sounds good and looking forward to seeing this happen.

Where is the clang-format style? I would like to play and have look at the 
results?

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


Re: [PATCH 1/2] bsps/aarch64: Ensure FPU trap state is consistent

2022-10-27 Thread Chris Johns
On 28/10/2022 9:57 am, Kinsey Moore wrote:
> 
> On Thu, Oct 27, 2022 at 5:46 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
> On 28/10/2022 9:25 am, Kinsey Moore wrote:
> > On Thu, Oct 27, 2022 at 5:10 PM Chris Johns  <mailto:chr...@rtems.org>
> > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> wrote:
> >
> >     On 28/10/2022 9:05 am, Kinsey Moore wrote:
> >     > RTEMS may be booted from a dirty environment. Ensure that FPU trap
> >     > settings are consistent.
> >     > ---
> >     >  bsps/aarch64/shared/start/start.S | 10 ++
> >     >  1 file changed, 10 insertions(+)
> >     >
> >     > diff --git a/bsps/aarch64/shared/start/start.S
> >     b/bsps/aarch64/shared/start/start.S
> >     > index 8bd4f86f4e..de0fdf4c80 100644
> >     > --- a/bsps/aarch64/shared/start/start.S
> >     > +++ b/bsps/aarch64/shared/start/start.S
> >     > @@ -307,6 +307,16 @@ _el1_start:
> >     > 
> >     >    /* FPU does not need to be enabled on AArch64 */
> >     > 
> >     > +  /* Ensure FPU traps are disabled by default */
> >     > +  mrs x0, FPCR
> >     > +  bic x0, x0, #(1 << 8)
> >     > +  bic x0, x0, #(1 << 9)
> >     > +  bic x0, x0, #(1 << 10)
> >     > +  bic x0, x0, #(1 << 11)
> >     > +  bic x0, x0, #(1 << 12)
> >     > +  bic x0, x0, #(1 << 15)
> >
> >     Does `bic x0, x0, #((1 << 8) | (1 << 9) | (1 << 10) | ...)` work?
> >
> > The assembler complains about the operand being out of range. I can 
> split it
> > into 8-12 in one and 15 by itself and everything seems to work.
> 
> Huh? If you use a hex value does it work?
> 
> I think the equivalent value would be 0x9f00. That generates the same error as
> putting all the components on the same line. I think there's a 6-bit immediate
> involved that's the limitation.

Ah, must be an aarch64 thing. I have been using ARM and thumb mode asm this 
week :)

I will leave this with you to sort out which is best.

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

Re: [PATCH 1/2] bsps/aarch64: Ensure FPU trap state is consistent

2022-10-27 Thread Chris Johns
On 28/10/2022 9:25 am, Kinsey Moore wrote:
> On Thu, Oct 27, 2022 at 5:10 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
> On 28/10/2022 9:05 am, Kinsey Moore wrote:
> > RTEMS may be booted from a dirty environment. Ensure that FPU trap
> > settings are consistent.
> > ---
> >  bsps/aarch64/shared/start/start.S | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/bsps/aarch64/shared/start/start.S
> b/bsps/aarch64/shared/start/start.S
> > index 8bd4f86f4e..de0fdf4c80 100644
> > --- a/bsps/aarch64/shared/start/start.S
> > +++ b/bsps/aarch64/shared/start/start.S
> > @@ -307,6 +307,16 @@ _el1_start:
> > 
> >    /* FPU does not need to be enabled on AArch64 */
> > 
> > +  /* Ensure FPU traps are disabled by default */
> > +  mrs x0, FPCR
> > +  bic x0, x0, #(1 << 8)
> > +  bic x0, x0, #(1 << 9)
> > +  bic x0, x0, #(1 << 10)
> > +  bic x0, x0, #(1 << 11)
> > +  bic x0, x0, #(1 << 12)
> > +  bic x0, x0, #(1 << 15)
> 
> Does `bic x0, x0, #((1 << 8) | (1 << 9) | (1 << 10) | ...)` work?
> 
> The assembler complains about the operand being out of range. I can split it
> into 8-12 in one and 15 by itself and everything seems to work.

Huh? If you use a hex value does it work?

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

Re: [PATCH 1/2] bsps/aarch64: Ensure FPU trap state is consistent

2022-10-27 Thread Chris Johns
On 28/10/2022 9:05 am, Kinsey Moore wrote:
> RTEMS may be booted from a dirty environment. Ensure that FPU trap
> settings are consistent.
> ---
>  bsps/aarch64/shared/start/start.S | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/bsps/aarch64/shared/start/start.S 
> b/bsps/aarch64/shared/start/start.S
> index 8bd4f86f4e..de0fdf4c80 100644
> --- a/bsps/aarch64/shared/start/start.S
> +++ b/bsps/aarch64/shared/start/start.S
> @@ -307,6 +307,16 @@ _el1_start:
>  
>/* FPU does not need to be enabled on AArch64 */
>  
> +  /* Ensure FPU traps are disabled by default */
> +  mrs x0, FPCR
> +  bic x0, x0, #(1 << 8)
> +  bic x0, x0, #(1 << 9)
> +  bic x0, x0, #(1 << 10)
> +  bic x0, x0, #(1 << 11)
> +  bic x0, x0, #(1 << 12)
> +  bic x0, x0, #(1 << 15)

Does `bic x0, x0, #((1 << 8) | (1 << 9) | (1 << 10) | ...)` work?

The operand2 is a mask of bits to clear.

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


Re: Increase Frequency of Updates of RTEMS GitHub Tools Mirroring

2022-10-27 Thread Chris Johns
Hi Christian,

Thank you for your considered comments.

On 27/10/2022 12:06 am, Christian MAUDERER wrote:
> Am 26.10.22 um 01:06 schrieb Chris Johns:
>> On 26/10/2022 4:46 am, Joel Sherrill wrote:
>>>  In general, our current approach is quite a hack. We should do things
>>>  more event driven. For example, if you want to update the RSB, then you
>>>  create a pull request. This pull request starts a CI script which
>>>  updates the mirrors and builds the RSB on a selected set of platforms.
>>>  If everything is all right, the pull request can be merged.
>>>
>>> Just getting to the point where a pull request triggered an update would
>>> be useful. Assuming a pull request with no content would be ok.
>>
>> I feel starting to have pull requests will only result in changes being 
>> posted
>> there by users who see pull requests as active. It is reasonable for a user 
>> to
>> think this. Who will then field those and merge them?
>>
>> Chris
> 
> Hello Chris,
> 
> I agree that as long as the RTEMS project doesn't officially use pull 
> requests,
> it's not a good idea to have something that looks official but isn't used. On
> the other hand, I think that it would be a really good idea for the RTEMS
> project to migrate to a patch management system where a pull-request with
> automated CI run is the official method for contributing.

I would love a patch management system to be in place. Getting consensus on what
to use, how we host it, who does the work and who maintains it is hard.

> That would take a lot
> of work from the shoulders of the maintainers because for a lot of patches, no
> more manual tests whether the patch builds would be necessary. Of course the
> patch would still need review.

No question that would be the case. A good tool will also manage CI to make sure
we have buildable commits entering the repo.

> Beneath that, a system with pull requests usually has a nice overview over
> pending patches. At the moment we have patches on the mailing list mixed with
> discussions.

Yes this is true and I would like to add pull requests are widely used and
people know how to use them and trust them and this is important for us long
term. We need to stay current in the tools and methods we employ.

> A user has to get the attention of a maintainer to get a patch
> merged. Users that don't want to be pushy maybe don't ping such patches or 
> some
> might just forget that they send a patch to the list.

Agreed. I am guilty of forgetting.

> I'm sure that we lost
> quite a few patches due to that because no one felt responsible, no one noted
> the patch or no one had the time to test the patches before merging them.

I also think this is true.

> I know that I have even lost some of my own patches on the list because no one
> acknoledged them and I started to work on something else and forget them. I
> found some a few months later and was surprised that I didn't push them. I
> wouldn't guarantee that I found all of them. A patch management system should
> help to see whether there are still open ones.

Good to know I am not the only one.

> PS: I already mentioned it in another mail: I started to build some github CI
> scripts that we at embedded brains want to use for testing our own public
> patches. Github doesn't seem to limit the CI time on public projects so 
> everyone
> who wants to play a bit with it: Feel free to create pull requests to see how
> something like that works. Just select the "ci" branch on
> 
>   https://github.com/embedded-brains/rtems
> 
> That repo is clearly a fork (marked with "forked from RTEMS/rtems" so I don't
> see the risk that someone mixes it up with the official repos. But if unknown
> users will use it to create pull requests, I'll add a comment to the pull
> requests, that patches should be sent to the mailing list instead. If there 
> are
> a lot of unknown users, I'll automate the comments.

Yes I remember, maybe on discord. I took a look and it is nice. It is great to
see support companies running CI flows. OAR has tools builds and simulator test
runs posting to build results to the builds list and this is great and 
important.

I would like to see more hardware test runs and posted results. Does EB have any
plans to run the testsuite on hardware and post the results to builds?

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

Re: Increase Frequency of Updates of RTEMS GitHub Tools Mirroring

2022-10-25 Thread Chris Johns
On 26/10/2022 4:46 am, Joel Sherrill wrote:
> In general, our current approach is quite a hack. We should do things
> more event driven. For example, if you want to update the RSB, then you
> create a pull request. This pull request starts a CI script which
> updates the mirrors and builds the RSB on a selected set of platforms.
> If everything is all right, the pull request can be merged.
> 
> Just getting to the point where a pull request triggered an update would
> be useful. Assuming a pull request with no content would be ok.

I feel starting to have pull requests will only result in changes being posted
there by users who see pull requests as active. It is reasonable for a user to
think this. Who will then field those and merge them?

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


Re: [PATCH] bsps/microblaze: Fix console interrupt build errors

2022-10-24 Thread Chris Johns
OK to push

Chris

On 25/10/2022 12:36 pm, Alex White wrote:
> This fixes build errors seen when building with console interrupts
> enabled. A few places were missing bspopts.h includes, and one of the
> UART functions was not defined.
> ---
>  bsps/microblaze/include/dev/serial/uartlite.h  |  1 +
>  .../microblaze/include/dev/serial/uartlite_l.h | 18 ++
>  bsps/microblaze/shared/dev/serial/uartlite.c   |  3 ++-
>  3 files changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/bsps/microblaze/include/dev/serial/uartlite.h 
> b/bsps/microblaze/include/dev/serial/uartlite.h
> index 6e288d4dc7..2fda3796b3 100644
> --- a/bsps/microblaze/include/dev/serial/uartlite.h
> +++ b/bsps/microblaze/include/dev/serial/uartlite.h
> @@ -36,6 +36,7 @@
>  #ifndef LIBBSP_MICROBLAZE_SHARED_UARTLITE_H
>  #define LIBBSP_MICROBLAZE_SHARED_UARTLITE_H
>  
> +#include 
>  #include 
>  
>  #include 
> diff --git a/bsps/microblaze/include/dev/serial/uartlite_l.h 
> b/bsps/microblaze/include/dev/serial/uartlite_l.h
> index 8c0598e191..834fbb5f75 100644
> --- a/bsps/microblaze/include/dev/serial/uartlite_l.h
> +++ b/bsps/microblaze/include/dev/serial/uartlite_l.h
> @@ -234,6 +234,24 @@ static inline void Xil_Out32(UINTPTR Addr, u32 Value)
>((XUartLite_GetStatusReg((BaseAddress)) & XUL_SR_RX_FIFO_VALID_DATA) != \
>   XUL_SR_RX_FIFO_VALID_DATA)
>  
> +#ifdef __rtems__
> +//
> +/**
> +*
> +* Check to see if the transmitter is empty.
> +*
> +* @param BaseAddress is the  base address of the device
> +*
> +* @returnTRUE if the transmitter is empty, FALSE otherwise.
> +*
> +* @note  C-style Signature:
> +*int XUartLite_IsTransmitEmpty(u32 BaseAddress);
> +*
> +*/
> +#define XUartLite_IsTransmitEmpty(BaseAddress) \
> +  ((XUartLite_GetStatusReg((BaseAddress)) & XUL_SR_TX_FIFO_EMPTY) == \
> + XUL_SR_TX_FIFO_EMPTY)
> +#endif /* __rtems__ */
>  
>  
> //
>  /**
> diff --git a/bsps/microblaze/shared/dev/serial/uartlite.c 
> b/bsps/microblaze/shared/dev/serial/uartlite.c
> index 7387e22635..a5fc4fe82b 100644
> --- a/bsps/microblaze/shared/dev/serial/uartlite.c
> +++ b/bsps/microblaze/shared/dev/serial/uartlite.c
> @@ -35,6 +35,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #ifdef BSP_MICROBLAZE_FPGA_CONSOLE_INTERRUPTS
>  static void microblaze_uart_interrupt( void *arg )
> @@ -47,7 +48,7 @@ static void microblaze_uart_interrupt( void *arg )
>  rtems_termios_enqueue_raw_characters( tty, , 1 );
>}
>  
> -  while ( ctx->transmitting && !XUartLite_IsTransmitEmpty( ctx ) ) {
> +  while ( ctx->transmitting && !XUartLite_IsTransmitEmpty( ctx->address ) ) {
>  rtems_termios_dequeue_characters( tty, 1 );
>}
>  }
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH] testproc/gsed: fix compilation of GNU sed on Mac OS X

2022-10-23 Thread Chris Johns
Looks good. Ok to push.

Thanks
Chris

On 24/10/2022 8:36 am, Karel Gardas wrote:
> GNU sed compiles on Mac OS X fine, but without providing --host/--build
> configure options. Hence removing them solved the issue of configure
> not being able to recognize arm64-darwin platform.
> ---
>  source-builder/config/gsed-1.cfg | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/source-builder/config/gsed-1.cfg 
> b/source-builder/config/gsed-1.cfg
> index 828da50..87eb0fb 100644
> --- a/source-builder/config/gsed-1.cfg
> +++ b/source-builder/config/gsed-1.cfg
> @@ -86,7 +86,6 @@ URL:   https://www.gnu.org/software/sed/
>  --mandir=%{gsed_mandir} \
>  --infodir=%{gsed_infodir} \
>  --datadir=%{gsed_datadir} \
> ---build=%{_build} --host=%{_host}
>  
>%{__make} %{?_smp_mflags} all
>  
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH rtems-docs v2] user/bsps: Update riscv for PolarFire SoC

2022-10-21 Thread Chris Johns
On 21/10/2022 4:04 pm, padmarao.beg...@microchip.com wrote:
> The Patch v1 was reviewed by Alan, update few comments, and submitted Patch 
> v2.
>  https://lists.rtems.org/pipermail/devel/2022-October/073469.html - Patch v1
> 
> https://lists.rtems.org/pipermail/devel/2022-October/073528.html - Patch v2
> 
> Can you please review or merge it to rtems-docs git?

Sorry about the delay. I have merged the patch based on Alan's review.

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


Re: [libbsd 00/22] Remove FreeBSD file descriptors and avoid VFS

2022-10-20 Thread Chris Johns
On 20/10/2022 7:01 pm, Sebastian Huber wrote:
> On 29/08/2022 10:27, Sebastian Huber wrote:
>> Hello Chris,
>>
>> On 25/07/2022 08:12, Sebastian Huber wrote:
>>> On 11/07/2022 15:04, Sebastian Huber wrote:
 On 24/06/2022 08:33, Sebastian Huber wrote:
> This patch set removes the FreeBSD file descriptors.  The VFS is no longer
> used
> if only the USB, SD/MMC, network, PCI, and NVMe support is used by the
> application.  This change significantly reduce the memory usage of LibBSD 
> for
> these applications.  Using the media01 test case for the arm/lpc32xx BSP 
> as a
> benchmark, the heap usage dropped from 14.3MiB to 10.2MiB.  The "_BSD
> bufdaemon", "_BSD vnlru", "_BSD syncer", and "_BSD bufspacedaemon-" tasks 
> are
> no longer present in media01.  The code size is reduced by about 8KiB.  
> The
> data size is reduced by about 30KiB.  The throughput with a simple FTP 
> test
> increased by about 1%.
>
> The "Remove FreeBSD file descriptors" change removes more lines than 
> there are
> added.
>
> This change makes it easier to port the NFS support to the master branch 
> since
> now the changes are more localized.

 I have a target with only 8MiB of RAM (for code and data). So, this patch
 set is not just a micro optimization.
>>>
>>> This pending patch set is currently a blocker for me. I would like to work 
>>> on
>>> the NTP daemon integration and an update of the libbsd master branch to a
>>> more recent FreeBSD version. This patch set just restores what worked well
>>> for several years.
>>
>> did you have time to review this patch set in the meantime? The NTP client no
>> longer crashes with this patch set.
> 
> This patch set is now pending for about four months. From my point of view it 
> is
> a straight forward fix of some severe issues which prevent the use of libbsd 
> on
> lower end targets.

Is there a repo somewhere with the patches applied? I am being lazy asking as I
would like to avoid downloading the 22 patches and applying them by hand.

It seems the media test cannot grow by more than 9K of code and the heap by 5M!
Is my understanding correct? Anything else we need to understand about the low
end limits?

I have not seen any requirements on the lower end for libbsd before now. How do
we manage the competing requirement of low end support and adding functionality
to libbsd in the future if they clash?

Adding VFS support as FreeBSD implements it has pushed you over the edge but
that edge is not defined so it makes it difficult for anyone other than you to
work on this code base in a major way. I was not aware this was an issue and for
me the extra 9K of code is not a problem and a 5M change in heap is acceptable.

> It is not really good if our internal libbsd branches diverge
> too much from the RTEMS mainline.

Yes I agree. It is not in anyone's interest and that only benefits you.

I would like to reiterate we have an obligation to maintain the code base as
close to FreeBSD as possible. Some of these changes push that boundary. We need
to find a suitable path forward.

Reviewing the changes:

1. The break up of the syscalls file. The related comments are:

 "Collecting all system calls in a single translation unit is not good
  due to the library initialization through linker sets."

Could you please explain what the linker set issue is?

Why the need to change FreeBSD calls to static? Is it solely a performance
optimisation?

We are required to use function and data sections so I assume the syscall file
will be broken up by the linker where possible?

I cannot tell from the patches if the conditional syscall trace support is still
present?

I do not agree with your statement in the patches separation helps porting. My
experience was not that. When adding VFS and the NFS client I found the syscall
code all over the place and not easy to find, hard to review and it added
complexity. It adds unnecessary changes to the FreeBSD code against a base
requirement of the porting effort.

2. FreeBSD file descriptor removal

Does this mean we can never have them in libbsd? Does that limit what can be
brought across from FreeBSD in the future?

3. select, poll, and kqueue

Do these calls work with an NFS client fd?

4. Types of RTEMS fd's in libbsd

The change I made brought the types into a single location so it is easier to
review and understand. There is:

 - rtems_bsd_sysgen_dirops
 - rtems_bsd_sysgen_fileops
 - rtems_bsd_sysgen_nodeops
 - rtems_bsd_sysgen_imfsnodeops

VFS is now left to handle the specific vnode ops as FreeBSD is designed to do.

[
https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/rtems/rtems-bsd-syscall-api.c?h=6-freebsd-12
]

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

Re: Ping on ticket 4728 + patch

2022-10-17 Thread Chris Johns
On 18/10/2022 1:13 pm, Joel Sherrill wrote:
> On Sun, Oct 16, 2022 at 9:32 AM Alan Cudmore  > wrote:
> 
> On Fri, Oct 14, 2022 at 9:19 AM Joel Sherrill  > wrote:
> >
> > Pushed. Thanks for pinging. It does help.
> >
> > Since you are looking at the riscv BSPs, could you look at the four
> > BSP build failures reported here:
> >
> > https://lists.rtems.org/pipermail/build/2022-September/036496.html
> 
> >
> > I think they are all variants so one fix (maybe repeated) should do it.
> > The reported message isn't much help:
> >
> >    1 smp riscv/rv32iac build:
> >       configure: /home/tester/rtems-cron-6/rtems/waf configure\
> >       --prefix=/home/tester/rtems-cron-6/tools/6/bsps 
> --top=/home/tester\
> >       /rtems-cron-6/rtems --rtems-config=config-riscv-rv32iac-smp.ini
> >      error: ld/collect2:0 error: no error message found!
> >
> 
> I ran the bsp builder on the riscv BSPs with an updated toolchain and
> latest rtems master. I was able to reproduce only one of the failures
> with the rv32imafdc SMP configuration:
> Failures:
>    1 smp riscv/rv32imafdc build:
>       configure: /home/alan/rtems/test-build/rtems/waf configure\
>       --prefix=/home/alan/rtems/test-build/bsps\
>       --top=/home/alan/rtems/test-build/rtems 
> --rtems-config=config-riscv-\
>       rv32imafdc-smp.ini
>      error: ld/collect2:0 error: no error message found!
> 
> Average BSP Build Time: 0:00:26.253927
> Total Time 1:04:45.581263
> Passes: 147   Failures: 1
> 
> This is the detail from the log:
> [1424/1437] Compiling ../../../rtems/testsuites/samples/nsecs/init.c
> start.o: in function `.L0 ':
> 
> /home/alan/rtems/test-build/rtems/build/riscv/rv32imafdc/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_text+0x5
> c): relocation truncated to fit: R_RISCV_GPREL_I against symbol
> `bsp_section_bss_size' defined in *ABS* section in /home/
> 
> alan/rtems/test-build/rtems/build/riscv/rv32imafdc/testsuites/samples/minimum.exe
> collect2: error: ld returned 1 exit status
> 
> This seems to be similar to the error I get when I try to build the
> frdme310arty BSP with the testsuite and posix enabled:
> [4152/4326] Compiling testsuites/validation/tr-sem-surrender.c
> start.o: in function `.L0 ':
> 
> /home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_te
> xt+0x28): relocation truncated to fit: R_RISCV_GPREL_I against symbol
> `bsp_section_bss_size' defined in *ABS* section in
> 
> /home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/testsuites/validation/ts-validation-io-kernel.exe
> collect2: error: ld returned 1 exit status
> 
> I need to investigate this more.
> 
> 
> There are two issues. 
> 
> (1) The test in question does not fit on this target and needs to be disabled.
> 
> (2) Somewhere there is parsing of this output which may be able to be more 
> helpful.
> 
> Chris... any pointers on (2)? Can the output of bsp builder be improved?

1) There should be a log of all the build details. Check in that for the error.

2) Can you build it by hand and see the error?

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

Re: [PATCH] libdebugger: Add a target break call to suspend all running threads

2022-10-17 Thread Chris Johns
I have fixed the subject line as above in the commit to push :)

Chris

On 18/10/22 7:35 am, chr...@rtems.org wrote:
> From: Chris Johns 
> 
> - Optionally wait if there is no remote debugger connected and break
>   when the remote connects
> 
> Closes #4740
> ---
>  .../rtems/debugger/rtems-debugger-server.h|  1 +
>  cpukit/include/rtems/rtems-debugger.h |  8 +++
>  cpukit/libdebugger/rtems-debugger-server.c| 72 ++-
>  3 files changed, 65 insertions(+), 16 deletions(-)
> 
> diff --git a/cpukit/include/rtems/debugger/rtems-debugger-server.h 
> b/cpukit/include/rtems/debugger/rtems-debugger-server.h
> index 2189aac873..4d0407a951 100644
> --- a/cpukit/include/rtems/debugger/rtems-debugger-server.h
> +++ b/cpukit/include/rtems/debugger/rtems-debugger-server.h
> @@ -103,6 +103,7 @@ extern "C" {
>  #define RTEMS_DEBUGGER_FLAG_MULTIPROCESS (1 << 4)
>  #define RTEMS_DEBUGGER_FLAG_VERBOSE_LOCK (1 << 5)
>  #define RTEMS_DEBUGGER_FLAG_VERBOSE_CMDS (1 << 6)
> +#define RTEMS_DEBUGGER_FLAG_BREAK_WAITER (1 << 7)
>  
>  /**
>   * Forward decl for the threads and targets.
> diff --git a/cpukit/include/rtems/rtems-debugger.h 
> b/cpukit/include/rtems/rtems-debugger.h
> index 1fc8b3d522..7627e83382 100644
> --- a/cpukit/include/rtems/rtems-debugger.h
> +++ b/cpukit/include/rtems/rtems-debugger.h
> @@ -53,6 +53,14 @@ extern int rtems_debugger_start(const char*  
> remote,
>  rtems_task_priority  priority,
>  const rtems_printer* printer);
>  
> +/**
> + * Suspend all running threads including the caller if not
> + * excluded. Returns when the debugger has connected and continued.
> + *
> + * If wait is true and there is no remote connected wait then break.
> + */
> +extern int rtems_debugger_break(bool wait);
> +
>  /**
>   * Stop the Debugger.
>   */
> diff --git a/cpukit/libdebugger/rtems-debugger-server.c 
> b/cpukit/libdebugger/rtems-debugger-server.c
> index 9de9421b6b..b7b9727d84 100644
> --- a/cpukit/libdebugger/rtems-debugger-server.c
> +++ b/cpukit/libdebugger/rtems-debugger-server.c
> @@ -1678,18 +1678,30 @@ rtems_debugger_events(rtems_task_argument arg)
>  
>rtems_debugger_target_enable();
>  
> -  while (rtems_debugger_server_events_running()) {
> -rtems_debugger_server_events_wait();
> -if (rtems_debugger_verbose())
> -  rtems_debugger_printf("rtems-db: event woken\n");
> -if (!rtems_debugger_server_events_running())
> -  break;
> +  if (rtems_debugger_server_flag(RTEMS_DEBUGGER_FLAG_BREAK_WAITER)) {
> +rtems_debugger->flags &= ~RTEMS_DEBUGGER_FLAG_BREAK_WAITER;
>  r = rtems_debugger_thread_system_suspend();
> -if (r < 0)
> -  break;
> -r = remote_stop_reason(NULL, 0);
> -if (r < 0)
> -  break;
> +if (rtems_debugger_verbose())
> +  rtems_debugger_printf("rtems-db: break waiter\n");
> +rtems_debugger_server_events_signal();
> +if (rtems_debugger_verbose())
> +  rtems_debugger_printf("rtems-db: break waiter: signalled\n");
> +  }
> +
> +  if (r == 0) {
> +while (rtems_debugger_server_events_running()) {
> +  rtems_debugger_server_events_wait();
> +  if (rtems_debugger_verbose())
> +rtems_debugger_printf("rtems-db: event woken\n");
> +  if (!rtems_debugger_server_events_running())
> +break;
> +  r = rtems_debugger_thread_system_suspend();
> +  if (r < 0)
> +break;
> +  r = remote_stop_reason(NULL, 0);
> +  if (r < 0)
> +break;
> +}
>}
>  
>if (r < 0)
> @@ -1972,6 +1984,30 @@ rtems_debugger_server_crash(void)
>rtems_debugger->remote->end(rtems_debugger->remote);
>  }
>  
> +int
> +rtems_debugger_break(bool wait)
> +{
> +  int r = 0;
> +  if (!rtems_debugger_running()) {
> +errno = EIO;
> +r = -1;
> +  } else {
> +rtems_debugger_lock();
> +if (rtems_debugger_server_events_running()) {
> +  rtems_debugger_server_events_signal();
> +} else if (
> +  wait && !rtems_debugger_server_flag(RTEMS_DEBUGGER_FLAG_BREAK_WAITER)) 
> {
> +  rtems_debugger->flags |= RTEMS_DEBUGGER_FLAG_BREAK_WAITER;
> +  rtems_debugger_server_events_wait();
> +} else {
> +  errno = EIO;
> +  r = -1;
> +}
> +rtems_debugger_unlock();
> +  }
> +  return r;
> +}
> +
>  int
>  rtems_debugger_stop(void)
>  {
> @@ -1998,10 +2034,14 @@ rtems_debugger_set_verbose(bool on)
>  int
>  rtems_debugger_remote_debug(bool state)
>  {
> -  rtems_debugger_lo

Re: Documentation index entries for functions

2022-10-14 Thread Chris Johns
On 15/10/2022 12:58 am, Joel Sherrill wrote:
> On Fri, Oct 14, 2022 at 8:53 AM Sebastian Huber
>  >
> wrote:
> On 14.10.22 15:45, Joel Sherrill wrote:
> >
> > While teaching an RTEMS class this week, I noticed that rtems_build_name
> > is in the Classic API Guide index twice. Once with () and once without.
> > I started to fix that one case when I noticed that it appears we are
> > just very inconsistent.
> >
> > (rtemsdocs) [joel@localhost c-user]$ grep -r index::  | grep rtems_ |
> > grep "()$" | wc -l
> > 280
> > (rtemsdocs) [joel@localhost c-user]$ grep -r index::  | grep rtems_ |
> > grep -v "()$" | wc -l
> > 158
> >
> > There are 280 index entries with () on a method name and 158 without.
> 
> FWIW Some of the 158 without could be rtems_ data types.  
> 
> >
> > Which way should it be? :)
> 
> I strongly prefer the () style for functions and macros.
> 
> I should have mentioned that I also agree with this approach.  
> 
> If we get a third pro-parentheses vote, I'll make a sweep. 

+1

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

Re: [PATCH] TFTPFS: Adding missing diagram

2022-10-13 Thread Chris Johns
I have built HTML and PDF and it looks is fine. Pushed.

Thank you for updating the image and sorting this out. It is appreciated.

Chris

On 14/10/2022 2:41 am, Frank Kuehndel wrote:
> From: Frank Kühndel 
> 
> ---
>  filesystem/trivial_ftp.rst  |   8 --
>  images/filesystem/tftpfs_usage.png  | Bin 0 -> 47217 bytes
>  images/filesystem/tftpfs_usage.puml |  37 
>  3 files changed, 43 insertions(+), 2 deletions(-)
>  create mode 100644 images/filesystem/tftpfs_usage.png
>  create mode 100644 images/filesystem/tftpfs_usage.puml
> 
> diff --git a/filesystem/trivial_ftp.rst b/filesystem/trivial_ftp.rst
> index 3ef8bba..b8e1ae4 100644
> --- a/filesystem/trivial_ftp.rst
> +++ b/filesystem/trivial_ftp.rst
> @@ -275,16 +275,20 @@ repository):
>  Usage
>  =
>  
> -The following diagram shows how the TFTP filesystem is used by an
> +The following diagram usage_ shows how the TFTP filesystem is used by an
>  application.  The mount point can be any directory.  The name ``/tftp``
>  used in the figure serves only as an example.  The final unmounting and
>  remove directory steps are optional.
>  
> +.. _usage:
> +
>  .. figure:: ../images/filesystem/tftpfs_usage.png
> -  :width: 90%
> +  :width: 75%
>:align: center
>:alt: TFTP Usage Diagram
>  
> +  TFTP file system usage
> +
>  Mounting the TFTP Filesystem
>  
>  
> diff --git a/images/filesystem/tftpfs_usage.png 
> b/images/filesystem/tftpfs_usage.png
> new file mode 100644
> index 
> ..5faa72f768a0742c50f32fa30380a3be33e7
> GIT binary patch
> literal 47217
> zcmb5Wby$>L+ci#zAl)E{bV!4eN_PuL!_b}5jg%6C(jX-zQVt=V64EW*NaxTE-$uOe
> z=Xu}n_w73c!9DElX9HKD_0=San
> z*c$|XJ#m)MbT+nk@USs8bB2>LwKH`zbT&1iF!G?VaCUa!XJd1)F|>1bv9)0}wztJ$
> z=X(SPhrnm~O4IqD>u~VkHts1!s>=40?AX2^TK#zU@GCyj#!|)SsZ`=JGT_JFBUXwM
> zdsHlKWAgmvm#b60Y+-HN7`k4i)!N zOJ1-y&^qhgQ-6>8pa5eLMrq6!w-AZLxPZBlZbIdD^yz0w$8d9ut#Px<*CupWi+|;*
> zU|>3Q^mp4Q;VcFRQ=(_}U;O!xYLrPvbaUF#rc20=k*UY@&$}=Kmw#ad`m%3d_yxG{
> zj6tek_x&%zzDhmOu?@C5>8sGT{Vi zkVo{Pao!azuilYGlOob(j3vML5Kn*pP+h?(LsBX<*vRR<5n1&38)6xJNsnj)yE-JI
> zea%b_oPkq?2fQ}YVR3z7t=+L2c~(VVohcVz%{TIt!LEyv5b1ICYdI9VZUSGD#4KGt
> zBG`$G8FmcKw?44zc0cx=rA-7@TJN`%zsQDJP!AKW_X-JC`JHR-CvS=8f%
> z<1DMAu7#K{s(j&)K4+|d7{)<~KOlIUh|(zJlMfid{lKbJ8Y{W-gG3)yj6AEv{4
> znuFw1`5f+)570M?wPz91Fb)lE13}h<9yvYC@e0c%*Hz=nCyxHf$3;1j9>%Wr^0j9}
> z+s>1px>}=N=|8;8`pD~KAZ~G;dE^if=27L`W<=m>KzNv}XB)J}FJ(=OtGb<$h$EDr
> z2)#nU*yktFSNXvW2loa}MqK2TJ7g>Mf#xf ze>E2|OB}>?ZI4W! za3MJNZndv^HO*;fA*KJaFEz<4{7Qi;N}7i0YvMD1aquc0dm#?|E~IK^3Kgf)k_ghk
> z4HYj9LxIxZhMExIKxAleI~l3!qNQn~)x_Ot!AA>1U>lB}-m5z^J>5JpLwY}WhwD;m
> zhgd11Y^a(G3f3lPW4}Mpml)Y7Vi=tqsjHQQ{u*>*4c_kW_hQ~A!tJ!8s_W9{S^V&`
> z{1JTD*B7;4-<_ptmFwb_o=Ijl6TE*aQ0D2ev1VCYa3YK)KDLuwtr%4SI(C9RIV
> zpw>6EvYLLVgH^a?IiQ61{mBi~x#&2k`~2LWEL2Y_g9o#YZ)5hXV5pBOikYRkzy_(}
> zn%9BQB6{cIET+!*g`MuOMiv59UCj>j*b@O>MkXdE9-foIEUBRe>L_MP@BtUc3Rb(e
> zp+u?o;TPA-L03>LI73yjtY;(@g^8JkmWqmJt>#ho3UCibUR>yh1rQj7jHFo
> z(mpw`KYbd5B3Jqr1?m{9?ls@5>_u{zWsM-25`$B82#Z|XEl@8AEvB&!fia5dO(h2m
> zsNvOxnxkrM9j^PLo^aRl*wQyg7lLM>#~m+ZhREvelasIdixOTe90fL6kAJo-DJikE
> zv?Ph3 z^}W>E8aDL8Og8kyCDm|3rs>IhK9zboDzx z!2+h;@hig$Jo*7oo&=M;dsV0zsYIlM_x-^PL9w%og@uKU4Ku>{)|QQBdbD>@Dt
> z^XAL@?ys-ju|KBm`NqLrTf`Z9my
> z>CI5XWU&)HKR@5mAziMW8W%^qt%|#zB<>!UY)6+9NW_Cn@Ip3GVJS9rqNmHU!~4OP
> zY#dCg8t4Q|qSJ
> z8BH5Tz@(o4s?%xJsMSJF=7GgvCJv;+=FG~|^J}&+WpaXs#3M8>cYHTDH}lX+JKE!&
> znQz`_r9Ky~!k_aiWtt_|hjQo?A8F>P1n z_I{<+2r zZ?}K=;NP)1c43H!TwyufIzZW@l=f(MAfq~cj`!FRHvf1y7t8OI-R0-|g{S6`xTSlv
> z#T7{RyszeeM4ilThGw0{UYv}WcD-=h8pnKQHd@G0q_atac(Sz~(M$^8iZo
> z9E1)}Qm}^q+r}%x2#5Xw2nWRPiVMMSf)a%WgRHsEVlZ~4SKm;>SY!m3_J!T7eA97f
> z%t8by4>ovUNI1VcY)V7lCrat;p#POp|9(b>T$9$Ts5lq6+Tw+kmAC9k1fuS=6Uw)-
> zHvwb(*f9Vxd@kr)R_Qj3O3)S0tkv8>2@AzD?4T>0VAG#%|HjR(QJ}8X(V0NO%J}pt
> zD&^Dk=6qoqo%))wH}HD>X)_VA1scC!R=s3ih%=D_tB|f>k(S-GIZ@DjT<
> zKSW96+ok+hq90%0Nxc^TBpPPWaPPHph?>4vkzjfN_agz4LY9y`jl#sUpQI7rkp>HD
> zYcF;iH^24ZLS&8!7S!xY@gXH)$QV$)aKHVfs*j1uUc_kL%-bR*!Dv3+32fG1o0J3}
> z4i@PYTwdnd&2Rr6_E_mrrm%P1cS9q*JSbwTr`5|>_g)IA9Rd|F^?ZwIN+#78K
> zM51SwLm%TtYu#$Ao!Su_^nH$S{^^F?0>R^FU%fzJ7OxS~+s(ef+C0}T&+kp<$#C7?
> z;N$D`M00j>LQD;ogKxYnMGGB+wx4W{;q0*?Oc}Sk5?kVOTm6E4dS;1zkp`EkEQmA_
> z9bLg?JBj`7nf-N`Hd%-4bHD3!d(56hjue<|Y1Zu`$mw2xqx0d;>02feSI)e)yZe
> zM(=I<;*(Z6V}O>u1_S)1E+s{6QYA9KM|`LWQrKJFS*(kj6tRw}?s=DTQTa
> z(UsKGQQqYPd!&2!upu z**V>=ZPN}#n0s-!J0T-0R`z$nr`=zvU#c%=p7M4oDGONKD
> z7o-u*1@?qo%>)>;yRCgb3q!pAEG3_BnQWHMgb%r}MXdfS89ML{fS#8Jj
> zrgVpp(InKR|IL$8Z4Pfb(XoMnm-BIUxeB*$EFGzL(r}I6#GhK4c{hf+@BP~Jrqm&7
> zs6L`}ShJWQgQ*F%Zm7jT`nF$vvRIKS@$1BDl}d_|*e#9cIm8<<{*MgzNkmCCf0d
> zmX;1V?Sd2N`e-5ohL5?>2_%l#xSA(nUgT$MP8yiT2Rqp**JgP;Wrd5gTc6;Jt%d#9
> zM5h1b19M93VT)(Pm6WS0{ZBj_{fw>y<{IW4sFe-n^dm5N%N)-}5`}#e)O;u%
> zhL!YLcn56Xmx}AmxD{*HK{czDd(;<7g|)Rw!r z`i$kfB-_l;_=s+O!v0KN7p?U}%^#|+^#ty1uFlTS%3+9;1 zXOE>>A$el+s8AE~cuvMa{F4 z!!;+4)U*dZLSc-44}#jxd01H$b5u%TEbQzb{ojV_1%Hoz;~2bCksqG@+=gn;
> zaw{s12=_OprzbHg%z7Rwu{_ii(mQgbyD+eEgWT)fr_Op(t;jPwvgw
> 

Re: docs not building to PDF

2022-10-12 Thread Chris Johns
On 13/10/2022 4:06 pm, Sam Price wrote:
> example
> 
> https://mermaid.live/edit#pako:eNqFVG1vmzAQ_iuWP6UVaZM0DQGlkSYlnSJ1bUUyddmYkAlmYQEbGVP6sv732cdrtSrj0z0v9p19h1_xjgcU2ziTRNJFRH4JkvQfRy5zWcQi6WeBjVYqiEgcvVAUR76iSu2WyoKLwzu94lyWHBaRsNGOs0yi3Z4IdJrwnEkv5RGT6Aq5-FyGMnXxzBfnc0GzPNZ0cggi0UMdr4HW3sp5-PYV_amiz010dwKrdbWwAnK2e2mqh8CC9OdiFxsN7OZoSGez_LL2rlc3y_V2rWJvs71fepvrzf36iMlZflp4D85qs2xNLvZjvjtk6lquhoPR2CgiFvAC8Nh4pMLnGXVxWd6JPgJPKRPcRmGgitegh1Ii9wa685zF3e3NFimboES1xH-WNFMujXpqgYECIonn52FIhaHT6zw87HV5dFJvsItV7s5NAdb7aIPOXHxYxYNTV1GISNK2DIBtHQZkb3xHs-XQho6as6pv3XnRdSfBu-4C_sflMji8nmYUqkn0ynA202A-L2WEfpz-RP3-HFUzXtMVbKRmnFu5osACQ16LAEq6GsVGqTCIbVG1fIyBJeVc1GKJQNCtrGkdHyfh2rsKECCXTTiSvuhmL4CG1tY0gP_S7ypomQ9KKLOXnGreb9XetnkVDefSQ4ANnFCRkChQD9mrdrlY7mmi_i5bhQENiRoZ9fOzN2UlueTrZ7bDthQ5NXCeBu3Th-2QxJliU8K-c57UJgWx_YqfsD0cDs6soXk5mlyMR2PTmkwN_Kzo0dn4cmxZg4FlTqeTifVm4BfYQNkvLNMyzUvLvJhMp6b59hcqM78E
>  
> 
> 
> SVG link
> https://mermaid.ink/svg/pako:eNqFVG1v2jAQ_iuWP0GVtrxDIoo0CTohdaUCJsaWKXKIMzKIjRynKWX899mXV7SK5dM9L_adfRef8IZ7FFs4kkTScUB-CRLevrZsZrOABdKNPAtNVRCQffBO0T5wFZVqz1QmXOwu9IyzWbgbB8JCG84iiTZbItBNyGMmnQMPmEQPyMb30pcHGw9dcT8SNIr3mg53XiBqqOI10MKZzlffvqI_WfS5iGZ1WK2rhRWQs9xLUzUEFqQ_G9vYKGA1R0HOl5MvC-dx-jRZrBcqdpbrl4mzfFy-LK6Y5pNPY2c1ny4npcnG7p5vdpG6lodmo9UxkoB5PAHcMV6pcHlEbZyWV9dH4AfKBLeQ76niNaihA5FbA82c-Xj2_LRGyiYoUS1xj5JGyqVRTS0wkEckcdzY96kwdHqdh_u1Ko_q-QabvcpduSnAeh9t0JmTD6tYzfMqEhFIWpYBsKzDgOyF72q2GNpQUWOW9a06L7ru0LvoLuB_XDaDw-tpRr6aRCcNh0MNRqNURujHzU90eztC2YzndAYLqRjnUs4osMCQ5yKAlM5GsVAyDGJZVC5fY2BJOhe5mCIQdCtzWsfXSbj2qgIEyGkTrqRPqtkToKG1OQ3gv_RFBSXzQQlp9pRTzfut2ls2L6PhXHoIsIFDKkISeOohO2mXjeWWhurvslToUZ-okVE_PzsrK4klXxzZBltSxNTA8cErn76cPBD2nfMqxNYJv2Gr2Wzcmc1-t9Vrd1qdvtkbGPio6NZdp9sxzUbD7A8GvZ55NvA7bKDsbbNv9vtds9HtNcxm-_wXZ4G-ow
>  
> 
> 
> 
> I couldn't figure out how to get semi colons to work
> new lines are kind  of a pain also.

You are a legend (pun intended) :D

It is looking goo but Frank has the final say.

Chris

> 
> stateDiagram-v2
> 
> initbsd:Initialize libbsd
> initNetwork:Initialize Network
> mkDir:const char *mount_point = "/tftp"result = mkdir( mount_point, 
> S_IRWXU
> | S_IRWXG | S_IRWXO)
> 
> mountDir:result = mount(  "", mount_point,
> RTEMS_FILESYSTEM_TYPE_TFTPS, RTEMS_FILESYSTEM_READ_WRITE,
> "blocksize=1024,windowsize=4,verbose" )
> 
> openro:fd = open( path, O_RDONLY )
> read:bytes = read( fd, data_buffer, sizeof( data_buffer ) )
> readclose:result = close( fd )
> openw:fd = open( path, O_WRONLY )
> write:bytes = write( fd, data, size )
> writeclose:result = close( fd )
> umount:result = unmount( mount_point )
> rmdir:result = rmdir( mount_point )
> 
> state fork_state <>
> [*] --> initbsd
> initbsd --> initNetwork
> initNetwork --> mkDir
> mkDir --> mountDir
> mountDir --> fork_state
> fork_state
> fork_state --> openro
> openro --> read
> read --> read
> read --> readclose
> readclose --> umount
> fork_state --> openw
> openw --> write
> write --> write
> write --> writeclose
> writeclose --> umount
> state umount <>
> umount --> rmdir
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: docs not building to PDF

2022-10-12 Thread Chris Johns
On 13/10/2022 3:15 pm, Sam Price wrote:
> Yes
> https://github.com/mermaid-js/mermaid-cli
> 
> 
> There are command line tools so it can be integrated into pipelines.
> 
> 
>   Convert Mermaid mmd Diagram File To SVG
> 
> mmdc -i input.mmd -o output.svg
> 
> 
>   
> Create
>  A PNG With A Dark Theme And Transparent Background
> 
> mmdc -i input.mmd -o output.png -t dark -b transparent
> 
> You dont get much control though over how it places boxes. 
> But it does sequence diagrams.
> Im using it for gantt charts.
> 
> Its one of the mainstream alternatives to plantuml
> 

This tool looks really good and it fits the pattern of tools we can use.

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

Re: docs not building to PDF

2022-10-12 Thread Chris Johns
On 13/10/2022 2:01 pm, Sam Price wrote:
> Have you guys looked at mermaidjs for simplistic diagrams?
> https://mermaid-js.github.io/mermaid/#/flowchart
> 

No I have not.

> You can embed it in markdown. pandoc will convert it to images for html.
> it works on gitlab wiki, and prob others.

Can it generate a format we can embed in PDFs?

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

Re: Cygwin tools failure

2022-10-12 Thread Chris Johns
On 12/10/2022 3:24 pm, Chris Johns wrote:
> Consider a patch to add the piece removed at the end of this patch as 
> approved.

I see the patch was pushed, thanks. The RSB hash will need to be updated so
users pick it up.

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


Re: docs not building to PDF

2022-10-12 Thread Chris Johns


On 12/10/2022 8:56 pm, Frank Kühndel wrote:
> Hello Chris,
> On 10/11/22 23:47, Chris Johns wrote:
>> On 11/10/2022 7:12 pm, Frank Kühndel wrote:
>>> Hello Chris,
>>>
>>> On 10/11/22 03:09, Chris Johns wrote:
>>>> On 10/10/2022 9:22 pm, Frank Kühndel wrote:
>>>>> images/filesystem/tftpfs_usage.png:
>>>>> https://share.embedded-brains.de/index.php/s/fQ4WrLrqmBjcbwC
>>>> I have a greyed out image I cannot clearly see?
>>> The image has a transparent background. Some image viewers put a gray 
>>> pattern in
>>> the background in those case. The PDF has naturally a white background on 
>>> top of
>>> which the image is displayed.
>>>
>>>>> images/filesystem/ftpfs_usage.svg:
>>>>> https://share.embedded-brains.de/index.php/s/xk7kArkm6mbjcn2
>>>>>
>>>>> The SVG file is the source for the PNG. Both files must be placed in the
>>>>> images/filesystem folder.
>>>> How is the SVG file created and how can it be edited?
>>> I used Inkscape. It should be possible to edit it with (almost) any tool 
>>> that
>>> supports SVG.
>> I tried withhttps://pixelied.com/features/svg-editor  and it was a mess.
> 
> Yes. I tried another Web-based tool and it was the same mess. Yet, all 
> converter
> handle this correctly. For example:
> 
> $ firefox file:///home/frank/tftpfs_usage.svg
> $ convert -geometry 1422x1574 tftpfs_usage.svg tftpfs_usage.png
> $ display tftpfs_usage.svg
> $ libreoffice tftpfs_usage.svg
> $ rsvg-convert --width 1422 --height 1574 -o tftpfs_usage_Z.png 
> tftpfs_usage.svg
> 
> So, I guess it is a bug in the web-based tools.

The format is always going to be fragile and locked into the specific tool used
to create it. Being an open format does not help. Word is a form of XML and it
is also not suitable.

>> My concern is the widgets (or whatever they are called) a tool has may not be
>> available in another.
> 
> Inkscape is open source and available freely on (almost?) all operating 
> system.
> It is *the* standard open source tool for producing high-quality vector 
> graphics
> today.

I do not agree and I question "the" in your last sentence. Making a fact of your
view does not impress me.

We need a solution that can be maintained past your current employment.

>>> Your Web-Browser should be able to display SVG directly when you
>>> point it to the file like for 
>>> example:file:///home//tftpfs_usage.svg
>>>
>>> You can recreate the PNG with Inkscape on the command line with:
>>>
>>> $ inkscape --export-dpi=300 --export-filename=tftpfs_usage.png 
>>> tftpfs_usage.svg
>> We have a number of images in the doco created using PlantUML. Did you 
>> consider
>> using that tool? It has the advantage the images can be regenerated from the
>> source as part of the build if PlantUML and Ditaa are installed and we get a
>> consistent looking set of images.
> 
> I took a look into PlantUML:
> 
> * My image is not an UML diagram (or similar to another diagram input format 
> it
> supports)

Ditaa is an option and easy to use.

> * It may be realized as an Activity Diagram, yet. But it will not look very
> similar to the current image.
>
> * Most of all, I will need to spend significant time to learn PlantUML and to
> get the result in shape I will certainly need to do some trying and fumbling
> around.

Maybe an example would help:

https://git.rtems.org/rtems-docs/tree/images/user/exe-debug-libdebugger.ditaa

> Openly, my company will never pay me for converting the image to PlantUML. 
> Sorry
> about this.

Seems you have made this a commercial issue on a public mailing list I have
included Thomas on the email and he can reach out me directly. I always enjoy
catching up with him.

> Do you see any solution to this problem?

1. Revert the patch.

2. Use something like ditaa

3. Reword the section to not include the image

In the mean time the docs are not building.

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

Re: Cygwin tools failure

2022-10-11 Thread Chris Johns
On 12/10/2022 2:30 pm, Joel Sherrill wrote:
> 
> 
> On Tue, Oct 11, 2022 at 8:36 PM Ryan Long  > wrote:
> 
> Cygwin has been unable to build the tools for awhile. This has been due
> to an array subscript being a char while building DTC. The maintainers
> didn't see an issue with the code itself, so it's going to go on being
> broken for awhile I guess.
> 
> Joel recommended commented out the building of DTC through the RSB.
> After doing so, I'm running into the following error. I was building
> AArch64's tools. Disabling DTC and building with my Debian WSL instance
> built it just fine.
> 
> 
> [ 48/258] Compiling rtemstoolkit/elftoolchain/libelf/libelf_align.c
> ../rtemstoolkit/elftoolchain/libelf/elf.c:34:35: error: ‘LIBELF_ARCH’
> undeclared here (not in a function); did you mean ‘LIBELF_ERROR’?
>     34 | .libelf_arch    = LIBELF_ARCH,
>    |   ^~~
>    |   LIBELF_ERROR
> ../rtemstoolkit/elftoolchain/libelf/elf.c:35:35: error:
> ‘LIBELF_BYTEORDER’ undeclared here (not in a function); did you mean
> ‘LIBELF_ERROR’?
>     35 | .libelf_byteorder   = LIBELF_BYTEORDER,
>    |   ^~~~
>    |   LIBELF_ERROR
> ../rtemstoolkit/elftoolchain/libelf/elf.c:36:35: error: ‘LIBELF_CLASS’
> undeclared here (not in a function)
>     36 | .libelf_class   = LIBELF_CLASS,
>    |   ^~~~
> 
> Waf: Leaving directory
> 
> `/home/rtems-tester/rtems-cron-6/rtems-source-builder/rtems/build/rtems-tools-d0a65c72d1a170637258eb19f7d3e433be7c3c86-1/rtems-tools-d0a65c72d1a170637258eb19f7d3e433be7c3c86/build'
> 
> 
> Does anyone know a fix for this?
> 
> 
> rtemstoolkit/elftoolchain/libelf/_libelf_config.h has ifdef's for various host
> operating
> systems and does not have one for Cygwin or MSYS. But it can't know the 
> native ELF
> details because the native format is not ELF:
> 
> $ file /bin/cat.exe
> /bin/cat.exe: PE32+ executable (console) x86-64, for MS Windows
> 
> I'm not sure what to do about this. My first thought would be to add 
> Cygwin to the list like FreeBSD and see if that defines what you need.
> or find the x86_64 Linux settings and use those for Cygwin to let it
> compile.
> 
> I'm not sure why we need to know the native ELF details.

The tools use to build on Ming64...

https://git.rtems.org/rtems-tools/tree/rtemstoolkit/elftoolchain/libelf/_libelf_config.h?h=5#n191

This patch broke the support...

https://git.rtems.org/rtems-tools/commit/rtemstoolkit/elftoolchain/libelf/_libelf_config.h?id=ff68bccc25386c84d893187af36e4bac88db4b10

Consider a patch to add the piece removed at the end of this patch as approved.

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

Re: docs not building to PDF

2022-10-11 Thread Chris Johns
On 11/10/2022 7:12 pm, Frank Kühndel wrote:
> Hello Chris,
> 
> On 10/11/22 03:09, Chris Johns wrote:
>> On 10/10/2022 9:22 pm, Frank Kühndel wrote:
>>> images/filesystem/tftpfs_usage.png:
>>> https://share.embedded-brains.de/index.php/s/fQ4WrLrqmBjcbwC
>> I have a greyed out image I cannot clearly see?
> 
> The image has a transparent background. Some image viewers put a gray pattern 
> in
> the background in those case. The PDF has naturally a white background on top 
> of
> which the image is displayed.
> 
>>
>>> images/filesystem/ftpfs_usage.svg:
>>> https://share.embedded-brains.de/index.php/s/xk7kArkm6mbjcn2
>>>
>>> The SVG file is the source for the PNG. Both files must be placed in the
>>> images/filesystem folder.
>> How is the SVG file created and how can it be edited?
> 
> I used Inkscape. It should be possible to edit it with (almost) any tool that
> supports SVG. 

I tried with https://pixelied.com/features/svg-editor and it was a mess.

My concern is the widgets (or whatever they are called) a tool has may not be
available in another.

> Your Web-Browser should be able to display SVG directly when you
> point it to the file like for example: 
> file:///home//tftpfs_usage.svg
> 
> You can recreate the PNG with Inkscape on the command line with:
> 
> $ inkscape --export-dpi=300 --export-filename=tftpfs_usage.png 
> tftpfs_usage.svg

We have a number of images in the doco created using PlantUML. Did you consider
using that tool? It has the advantage the images can be regenerated from the
source as part of the build if PlantUML and Ditaa are installed and we get a
consistent looking set of images.

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

Re: Fwd: New Defects reported by Coverity Scan for RTEMS

2022-10-10 Thread Chris Johns
Hi,

Thanks Coverity for picking up I forgot to add the new error string. :)

I will push the 1 line change.

Chris

On 10/10/2022 10:46 pm, Joel Sherrill wrote:
> 
> -- Forwarded message -
> From: mailto:scan-ad...@coverity.com>>
> Date: Mon, Oct 10, 2022, 12:22 AM
> Subject: New Defects reported by Coverity Scan for RTEMS
> To: mailto:bu...@rtems.org>>
> 
> 
> Hi,
> 
> Please find the latest report on new defect(s) introduced to RTEMS found with
> Coverity Scan.
> 
> 1 new defect(s) introduced to RTEMS found with Coverity Scan.
> 
> 
> New defect(s) Reported-by: Coverity Scan
> Showing 1 of 1 defect(s)
> 
> 
> ** CID 1515930:  Memory - illegal accesses  (OVERRUN)
> /cpukit/libmisc/rtems-fdt/rtems-fdt.c: 971 in rtems_fdt_strerror()
> 
> 
> 
> *** CID 1515930:  Memory - illegal accesses  (OVERRUN)
> /cpukit/libmisc/rtems-fdt/rtems-fdt.c: 971 in rtems_fdt_strerror()
> 965         "blob has references"
> 966       };
> 967       if (errval > -RTEMS_FDT_ERR_RTEMS_MIN)
> 968         return fdt_strerror (errval);
> 969       if (errval < -RTEMS_FDT_ERR_MAX)
> 970         return "invalid error code";
     CID 1515930:  Memory - illegal accesses  (OVERRUN)
     Overrunning array "errors" of 5 4-byte elements at element index 5 
(byte
> offset 23) using index "-errval - 100" (which evaluates to 5).
> 971       return errors[(-errval) - RTEMS_FDT_ERR_RTEMS_MIN];
> 972     }
> 973     
> 974     int
> 975     rtems_fdt_prop_value(const char* const path,
> 976                          const char* const propname,
> 
> 
> 
> To view the defects in Coverity Scan visit,
> https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50ypUUzi-2FdSNmuyRB7BEFT8xQ4-2B8hpujh0hTgQljRGId4Dg-3D-3D3tGt_EU3W9teASMK00lBXX9WT4lsogDrkCcNZLvg-2FVxwAXMrx8nV9Pzi0hugn9s2FK6ZfLix8JmyqOKq3RkOqFldjBEAraGrjvpmsds-2B4Iivd5W95gEqWlcvVuG1EDWj6hubB5Z5pEtpqtddGnBcH49eyBbkHPbRwsax2k1rSx8EynyzF-2Fw-2BumI1vwItGf-2FpJNy6Us6XZ0o-2BY2bhnazRwWhumfA-3D-3D
>  
> 
> 
> ___
> build mailing list
> bu...@rtems.org 
> http://lists.rtems.org/mailman/listinfo/build
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: docs not building to PDF

2022-10-10 Thread Chris Johns
On 10/10/2022 9:22 pm, Frank Kühndel wrote:
> images/filesystem/tftpfs_usage.png:
> https://share.embedded-brains.de/index.php/s/fQ4WrLrqmBjcbwC
I have a greyed out image I cannot clearly see?

> images/filesystem/ftpfs_usage.svg:
> https://share.embedded-brains.de/index.php/s/xk7kArkm6mbjcn2
> 
> The SVG file is the source for the PNG. Both files must be placed in the
> images/filesystem folder.

How is the SVG file created and how can it be edited?

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

Re: docs not building to PDF

2022-10-07 Thread Chris Johns
On 8/10/2022 9:47 am, Chris Johns wrote:
> On 8/10/2022 10:12 am, Noor Aman wrote:
>> I can confirm that the same is happening on my PC too.
> 
> Could you please bisect the repo to find the patch that broke things?

A simpler way to find the commit is to see the last build on docs.rtems.org
which is 6.278550b and the next commit after 278550b is:

commit 23fc93bf648507ac417237c20069c4ab7c793251
Author: Frank Kühndel 
Date:   Thu Jun 9 15:21:05 2022 +0200

TFTPFS: New documentation

Frank ?

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

Re: docs not building to PDF

2022-10-07 Thread Chris Johns
On 8/10/2022 10:12 am, Noor Aman wrote:
> I can confirm that the same is happening on my PC too.

Could you please bisect the repo to find the patch that broke things?

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


Re: [PATCH rtems-docs v4] raspberrypi4.rst: Documentation for the new AArch64 Raspberry pi 4B BSP

2022-10-07 Thread Chris Johns
On 8/10/2022 10:29 am, Noor Aman wrote:
> I'm on an older commit of master branch (20 commits behind) and on that, the 
> pdf
> builds fine, If that helps you in any way.

Please make sure the patches you post are based on the latest when you post
them. We assume this is the case.

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


Re: [PATCH rtems-docs v4] raspberrypi4.rst: Documentation for the new AArch64 Raspberry pi 4B BSP

2022-10-07 Thread Chris Johns
Looks good. Thank you for your patience in getting the changes made.

Chris

On 7/10/2022 4:16 pm, Noor Aman wrote:
> New patch sent with new changes.
> 
> On Fri, 7 Oct 2022 at 10:30, Mohd Noor Aman  > wrote:
> 
> This patch adds the relevant documentations required for booting the new 
> BSP.
> JTAG support is added for debugging. I have built the HTML docs and 
> verified
> them.
> ---
>  user/bsps/aarch64/raspberrypi4.rst | 111 +
>  user/bsps/bsps-aarch64.rst         |   1 +
>  2 files changed, 112 insertions(+)
>  create mode 100644 user/bsps/aarch64/raspberrypi4.rst
> 
> diff --git a/user/bsps/aarch64/raspberrypi4.rst
> b/user/bsps/aarch64/raspberrypi4.rst
> new file mode 100644
> index 000..b36d47b
> --- /dev/null
> +++ b/user/bsps/aarch64/raspberrypi4.rst
> @@ -0,0 +1,111 @@
> +.. SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. Copyright (C) 2022 Mohd Noor Aman
> +
> +.. _BSP_aarch64_Raspberrypi_4:
> +
> +Raspberry Pi 4B
> +===
> +
> +The 'raspberrypi4b' BSP currently supports only the LP64 ABI. ILP32 is 
> not
> +supported. Raspberry pi 4B all variants and Raspberry Pi 400  are
> supported. The
> +default bootloader which is used by the Raspbian OS or other OS can be 
> used to
> +boot RTEMS. SMP is currently not supported.
> +
> +Raspberry Pi 4B has 2 types of interrupt controller, GIC-400 (GICv2) and 
> ARM
> +legacy generic controller. Both are supported. By default, raspberrypi 
> 4B uses
> +ARM legacy generic controller. Set ``enable_gic=1`` in the 
> ``config.txt`` file
> +to enable GIC.
> +
> +Clock Driver
> +
> +
> +The clock driver uses the `ARM Generic Timer`.
> +
> +Console Driver
> +--
> +
> +Raspberry pi 4B has 2 types of UARTs, ARM PL011 and Mini-uart. The PL011 
> is a
> +capable, broadly 16550-compatible UART, while the mini UART has a reduced
> +feature set. The console driver supports the default Qemu emulated ARM 
> PL011
> +PrimeCell UART as well as the physical ARM PL011 PrimeCell UART in the
> +raspberrypi hardware. Mini-uart is not supported.
> +
> +Preparing to boot
> +--
> +
> +Raspberry Pi uses a different mechanism to boot when compared with any 
> ARM SoC.
> +First the GPU initializes, loads the bootloader (Raspberry pi firmware) 
> and
> then
> +looks for the kernel img. This whole process is done by the GPU 
> (VideoCore IV)
> +till the kernel is loaded. More information can be found on the 
> `Raspberry pi
> +documentation page
> 
> +  
> >`_.
> +By default the arm64 mode looks for the ``kernel8.img``. Any other kernel
> can be
> +loaded by adding ``kernel=`` to the ``config.txt`` file.
> +
> +The Firmware files are required in order to boot RTEMS. The latest 
> firmware can
> +be downloaded from the `Raspberry Pi Firmware Repository
> + >`_. USB boot is supported. All 
> the
> +files (Firmwares and kernel) must be place in the FAT32 partition only. 
> Add
> +``arm_64bit=1`` in the ``config.txt`` file in order to boot the BSP in 
> 64bit
> +kernel mode.
> +
> +
> +UART Setup
> +^^
> +
> +Connect your serial device to the GPIO15 and GPIO14. Add the following 
> to the
> +``config.txt`` file in order to use the PL011 UART0 and thus disabling 
> the
> +default Mini-uart.
> +
> +.. code-block:: none
> +
> +  # if user wants to enable GIC, uncomment the next line
> +  # enable_gic=1
> +  arm_64bit=1
> +  dtoverlay = disable-bt
> +  enable_uart=1
> +
> +.. note::
> +  The Raspberry Pi 4B and 400 have an additional four PL011 UARTs. They 
> are
> not
> +  supported.
> +
> +Generating kernel image
> +^^^
> +
> +The following steps show how to run ``hello.exe`` on the BSP. Other 
> executables
> +can be processed in a similar way.
> +
> +To create the kernel image:
> +
> +.. code-block:: shell
> +
> +  $ aarch64-rtems@rtems-ver-major@-objcopy -Obinary hello.exe kernel8.img
> +
> +Copy the kernel image to the SD card.
> +
> +JTAG Setup
> +--
> +
> +The Raspberry Pi 4 doesn't have dedicated JTAG pins. Instead, you must
> configure
> +the GPIO pins (GPIO22-GPIO27) to activate the JTAG functionality. The 
> RPi 4
> +documentation refers to this as Alt4 functions of those pins. Alt5 does 
> exist
> +too, which goes from GPIO4, 5, 6, 

Re: [PATCH v2 06/13] score: Add CPU_THREAD_LOCAL_STORAGE_VARIANT

2022-10-06 Thread Chris Johns
On 7/10/2022 3:33 pm, Sebastian Huber wrote:
> On 07.10.22 06:31, Chris Johns wrote:
>> On 7/10/2022 3:23 pm, Sebastian Huber wrote:
>>> On 07.10.22 05:44, Chris Johns wrote:
>>>> On 6/10/2022 7:23 pm, Sebastian Huber wrote:
>>>>> +#if CPU_THREAD_LOCAL_STORAGE_VARIANT == 10
>>>>> +  tls_data = (void *)
>>>>> +    RTEMS_ALIGN_UP( (uintptr_t) tls_area + sizeof( *tcb ), alignment );
>>>>> +  tcb = (TLS_Thread_control_block *) ((char *) tls_data - sizeof( *tcb 
>>>>> ));
>>>>> +  return_value = tls_data;
>>>>> +#elif CPU_THREAD_LOCAL_STORAGE_VARIANT == 11
>>>>> +  tcb_size = RTEMS_ALIGN_UP( sizeof( *tcb ), alignment );
>>>>> +  tls_data = (void *)
>>>>> +    RTEMS_ALIGN_UP( (uintptr_t) tls_area + tcb_size, alignment );
>>>>> +  tcb = (TLS_Thread_control_block *) ((char *) tls_data - tcb_size);
>>>>> +  return_value = tcb;
>>>>> +#elif CPU_THREAD_LOCAL_STORAGE_VARIANT == 20
>>>>> +  alignment_2 = RTEMS_ALIGN_UP( alignment, CPU_SIZEOF_POINTER );
>>>>> +  tls_area = (void *) RTEMS_ALIGN_UP( (uintptr_t) tls_area, alignment_2 
>>>>> );
>>>>> +  size = _TLS_Get_size();
>>>>> +  tcb = (TLS_Thread_control_block *)
>>>>> +    ((char *) tls_area + RTEMS_ALIGN_UP( size, alignment_2 ));
>>>>> +  tls_data = (char *) tcb - RTEMS_ALIGN_UP( size, alignment );
>>>>> +  return_value = tcb;
>>>>> +#else
>>>>> +#error "unexpected CPU_THREAD_LOCAL_STORAGE_VARIANT value"
>>>> What are the expected values? I can see 10, 11, 20.
>>>>
>>>> Can this please be changed to something readable? For example:
>>>>
>>>> #if CPU_THREAD_LOCAL_STORAGE_VARIANT == CPU_THREAD_LOCAL_STORAGE_BLAH
>>>>
>>>> #elif CPU_THREAD_LOCAL_STORAGE_VARIANT == 
>>>> CPU_THREAD_LOCAL_STORAGE_BLAH_BLAH
>>>
>>> This is documented in the no_cpu/cpuimpl.h. I think the numbers are all 
>>> right if
>>> you know the TLS variants. Otherwise we would have to add an extra header 
>>> file
>>> just for the CPU_THREAD_LOCAL_STORAGE_* defines.
>>
>> Is the doco in this patch? I could not find it.
> 
> Yes, all the CPU port options are documented in the no_cpu port:
> 
> diff --git a/cpukit/score/cpu/no_cpu/include/rtems/score/cpuimpl.h
> b/cpukit/score/cpu/no_cpu/include/rtems/score/cpuimpl.h
> index d5082383e8..72d223de24 100644
> --- a/cpukit/score/cpu/no_cpu/include/rtems/score/cpuimpl.h
> +++ b/cpukit/score/cpu/no_cpu/include/rtems/score/cpuimpl.h
> @@ -54,6 +54,24 @@
>   */
>  #define CPU_PER_CPU_CONTROL_SIZE 0
> 
> +/**
> + * @brief Defines the thread-local storage (TLS) variant.
> + *
> + * Use one of the following values:
> + *
> + * 10: The architecture uses Variant I and the TLS offsets emitted by the
> + * linker neglect the TCB (examples: nios2, m68k, microblaze, powerpc,
> + * riscv).  The thread pointer directly references the thread-local data
> + * area.
> + *
> + * 11: The architecture uses Variant I and the TLS offsets emitted by the
> + * linker take the TCB into account (examples: arm, aarch64).
> + * The thread pointer references the TCB.
> + *
> + * 20: The architecture uses Variant II (examples: i386, sparc).
> + */
> +#define CPU_THREAD_LOCAL_STORAGE_VARIANT 10
> +
>  #ifndef ASM
> 
>  #ifdef __cplusplus

Thanks. The number now make sense to me.

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

Re: [PATCH v2 06/13] score: Add CPU_THREAD_LOCAL_STORAGE_VARIANT

2022-10-06 Thread Chris Johns
On 7/10/2022 3:23 pm, Sebastian Huber wrote:
> On 07.10.22 05:44, Chris Johns wrote:
>> On 6/10/2022 7:23 pm, Sebastian Huber wrote:
>>> +#if CPU_THREAD_LOCAL_STORAGE_VARIANT == 10
>>> +  tls_data = (void *)
>>> +    RTEMS_ALIGN_UP( (uintptr_t) tls_area + sizeof( *tcb ), alignment );
>>> +  tcb = (TLS_Thread_control_block *) ((char *) tls_data - sizeof( *tcb ));
>>> +  return_value = tls_data;
>>> +#elif CPU_THREAD_LOCAL_STORAGE_VARIANT == 11
>>> +  tcb_size = RTEMS_ALIGN_UP( sizeof( *tcb ), alignment );
>>> +  tls_data = (void *)
>>> +    RTEMS_ALIGN_UP( (uintptr_t) tls_area + tcb_size, alignment );
>>> +  tcb = (TLS_Thread_control_block *) ((char *) tls_data - tcb_size);
>>> +  return_value = tcb;
>>> +#elif CPU_THREAD_LOCAL_STORAGE_VARIANT == 20
>>> +  alignment_2 = RTEMS_ALIGN_UP( alignment, CPU_SIZEOF_POINTER );
>>> +  tls_area = (void *) RTEMS_ALIGN_UP( (uintptr_t) tls_area, alignment_2 );
>>> +  size = _TLS_Get_size();
>>> +  tcb = (TLS_Thread_control_block *)
>>> +    ((char *) tls_area + RTEMS_ALIGN_UP( size, alignment_2 ));
>>> +  tls_data = (char *) tcb - RTEMS_ALIGN_UP( size, alignment );
>>> +  return_value = tcb;
>>> +#else
>>> +#error "unexpected CPU_THREAD_LOCAL_STORAGE_VARIANT value"
>> What are the expected values? I can see 10, 11, 20.
>>
>> Can this please be changed to something readable? For example:
>>
>> #if CPU_THREAD_LOCAL_STORAGE_VARIANT == CPU_THREAD_LOCAL_STORAGE_BLAH
>>
>> #elif CPU_THREAD_LOCAL_STORAGE_VARIANT == CPU_THREAD_LOCAL_STORAGE_BLAH_BLAH
> 
> This is documented in the no_cpu/cpuimpl.h. I think the numbers are all right 
> if
> you know the TLS variants. Otherwise we would have to add an extra header file
> just for the CPU_THREAD_LOCAL_STORAGE_* defines.

Is the doco in this patch? I could not find it.

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

Re: [PATCH 06/13] config: Add rtems_malloc_task_stack_for_idle()

2022-10-06 Thread Chris Johns
On 7/10/2022 3:25 pm, Sebastian Huber wrote:
> On 07.10.22 04:57, Chris Johns wrote:
>> On 6/10/2022 6:35 pm, Sebastian Huber wrote:
>>> On 06/10/2022 00:13, Chris Johns wrote:
>>>> Will the IDLE TLS size be based on the
>>>> CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE if it is not zero? This effects
>>>> libdl once it supports loading TLS based code.
>>>
>>> Currently, only the actual TLS size is used. We would have to change
>>> _TLS_Get_allocation_size() to use the maximum if it is non-zero.
>>
>> It would be good to get this sorted and in before a push is made on libdl to
>> support TLS. I think the newlib change will make TLS a visible issue in 
>> libdl in
>> 6 so it needs to be fixed.
> 
> I checked _TLS_Get_allocation_size(). It already returns the maximum size if 
> it
> is configured:
> 
>     if ( _Thread_Maximum_TLS_size != 0 ) {
>   if ( allocation_size <= _Thread_Maximum_TLS_size ) {
>     _Assert( _Thread_Maximum_TLS_size % CPU_STACK_ALIGNMENT == 0 );
>     allocation_size = _Thread_Maximum_TLS_size;
>   } else {
>     _Internal_error( INTERNAL_ERROR_TOO_LARGE_TLS_SIZE );
>   }
>     }
> 

Thanks. I also checked and found this. It looks good to me.

Is the end of the TLS BSS area the start of the TSL space available for libdl to
use?

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

Re: [PATCH v2 06/13] score: Add CPU_THREAD_LOCAL_STORAGE_VARIANT

2022-10-06 Thread Chris Johns
On 6/10/2022 7:23 pm, Sebastian Huber wrote:
> +#if CPU_THREAD_LOCAL_STORAGE_VARIANT == 10
> +  tls_data = (void *)
> +RTEMS_ALIGN_UP( (uintptr_t) tls_area + sizeof( *tcb ), alignment );
> +  tcb = (TLS_Thread_control_block *) ((char *) tls_data - sizeof( *tcb ));
> +  return_value = tls_data;
> +#elif CPU_THREAD_LOCAL_STORAGE_VARIANT == 11
> +  tcb_size = RTEMS_ALIGN_UP( sizeof( *tcb ), alignment );
> +  tls_data = (void *)
> +RTEMS_ALIGN_UP( (uintptr_t) tls_area + tcb_size, alignment );
> +  tcb = (TLS_Thread_control_block *) ((char *) tls_data - tcb_size);
> +  return_value = tcb;
> +#elif CPU_THREAD_LOCAL_STORAGE_VARIANT == 20
> +  alignment_2 = RTEMS_ALIGN_UP( alignment, CPU_SIZEOF_POINTER );
> +  tls_area = (void *) RTEMS_ALIGN_UP( (uintptr_t) tls_area, alignment_2 );
> +  size = _TLS_Get_size();
> +  tcb = (TLS_Thread_control_block *)
> +((char *) tls_area + RTEMS_ALIGN_UP( size, alignment_2 ));
> +  tls_data = (char *) tcb - RTEMS_ALIGN_UP( size, alignment );
> +  return_value = tcb;
> +#else
> +#error "unexpected CPU_THREAD_LOCAL_STORAGE_VARIANT value"

What are the expected values? I can see 10, 11, 20.

Can this please be changed to something readable? For example:

#if CPU_THREAD_LOCAL_STORAGE_VARIANT == CPU_THREAD_LOCAL_STORAGE_BLAH

#elif CPU_THREAD_LOCAL_STORAGE_VARIANT == CPU_THREAD_LOCAL_STORAGE_BLAH_BLAH

> +#endif
> +
> +  _TLS_Initialize_TCB_and_DTV( tls_data, tcb, dtv );
> +  _TLS_Copy_and_clear( tls_data );
> +
> +  return return_value;
>  }

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


Re: [tools] tester: Check for begin/end of test

2022-10-06 Thread Chris Johns
OK

Thanks
Chris

On 6/10/2022 6:29 pm, Sebastian Huber wrote:
> Check for "BEGIN OF TEST" and "END OF TEST" to not use other information 
> blocks
> such as "END OF GCOV" to determine the test status.
> ---
>  tester/rt/report.py | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tester/rt/report.py b/tester/rt/report.py
> index d3bf1cb..21580e2 100644
> --- a/tester/rt/report.py
> +++ b/tester/rt/report.py
> @@ -144,11 +144,11 @@ class report(object):
>  if line[0] == output_prefix:
>  if line[1].startswith('*** '):
>  banner = line[1][4:]
> -if banner.startswith('BEGIN OF '):
> +if banner.startswith('BEGIN OF TEST '):
>  start = True
> -elif line[1][4:].startswith('END OF '):
> +elif banner.startswith('END OF TEST '):
>  end = True
> -elif line[1][4:].startswith('FATAL'):
> +elif banner.startswith('FATAL'):
>  fatal = True
>  elif banner.startswith('TIMEOUT TIMEOUT'):
>  timeout = True
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH 06/13] config: Add rtems_malloc_task_stack_for_idle()

2022-10-06 Thread Chris Johns
On 6/10/2022 6:35 pm, Sebastian Huber wrote:
> On 06/10/2022 00:13, Chris Johns wrote:
>> Will the IDLE TLS size be based on the
>> CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE if it is not zero? This effects
>> libdl once it supports loading TLS based code.
> 
> Currently, only the actual TLS size is used. We would have to change
> _TLS_Get_allocation_size() to use the maximum if it is non-zero.

It would be good to get this sorted and in before a push is made on libdl to
support TLS. I think the newlib change will make TLS a visible issue in libdl in
6 so it needs to be fixed.

Chris

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


Re: [PATCH rtems-docs v2] raspberrypi4.rst: Added Documentation for the new AArch64 Raspberry pi 4B BSP

2022-10-05 Thread Chris Johns
Thanks for the documentation. It is great to have this.

My comments are below.

On 5/10/2022 4:41 pm, Mohd Noor Aman wrote:
> This patch adds the relevant documentations required for booting the new BSP.
> JTAG support is added for debugging. I have built the HTML docs and verified
> them.
> ---
>  user/bsps/aarch64/raspberrypi4.rst | 99 ++
>  user/bsps/bsps-aarch64.rst |  1 +
>  2 files changed, 100 insertions(+)
>  create mode 100644 user/bsps/aarch64/raspberrypi4.rst
> 
> diff --git a/user/bsps/aarch64/raspberrypi4.rst 
> b/user/bsps/aarch64/raspberrypi4.rst
> new file mode 100644
> index 000..5a45c65
> --- /dev/null
> +++ b/user/bsps/aarch64/raspberrypi4.rst
> @@ -0,0 +1,99 @@
> +.. SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. Copyright (C) 2022 Mohd Noor Aman
> +
> +.. _BSP_aarch64_Raspberrypi_4:
> +
> +Raspberry Pi 4B
> +===
> +
> +The 'raspberrypi4b' BSP currently supports only the LP64 ABI. ILP32 is not

Should this be ``raspberrypi4b``?

> +supported. Raspberry pi 4B all variants and Raspberry Pi 400  are supported. 

Maybe:

All variants of the Raspberry pi 4B  and Raspberry Pi 400 are supported.

> The
> +default bootloader which is used by the Raspbian OS or other OS can be used 
> to
> +boot the RTEMS. 

I think it would help to explain what the default bootloader is? I am not sure
what this means.

> Currently, QEMU emulation is not supported. 
> +
> +Clock Driver
> +
> +
> +The clock driver uses the `ARM Generic Timer`.
> +
> +Console Driver
> +--
> +
> +Raspberry pi 4B has 2 types of UARTs, ARM PL011 and Mini-uart. The PL011 is a
> +capable, broadly 16550-compatible UART, while the mini UART has a reduced
> +feature set. The console driver supports the default Qemu emulated ARM PL011
> +PrimeCell UART as well as the physical ARM PL011 PrimeCell UART in the
> +raspberrypi hardware. Mini-uart is not supported.

What are the configuration options?

> +
> +Preparing to boot

Please change to:

Preparing to Boot

> +--
> +
> +Raspberry Pi uses a different mechanism to boot. First the GPU initializes,
> +loads the bootloader and then looks for the kernel img. By default the arm64

img should be image

> +mode looks for the ``kernel8.img``. Any other kernel can be loaded by adding
> +`kernel=` to the ``config.txt``.

Is config.txt explained, ie a text file in the root directory of the SD card?

> +
> +The Firmware files are required in order to boot RTEMS. The latest firmware 
> can
> +be downloaded from the `Raspberry Pi Firmware Repository
> +`_. USB boot is supported. All the
> +files (Firmwares and kernel) must be place in the FAT32 partition only. Add
> +``arm_64bit=1`` in the config.txt file in order to boot the BSP in 64bit 
> kernel
> +mode. 
> +
> +
> +UART Setup
> +^^
> +
> +Connect your serial device to the GPIO15 and GPIO14. Add the following to the
> +config.txt file in order to use the PL011 UART0 and thus disabling the 
> default
> +Mini-uart.
> +
> +.. code-block:: none
> +
> +  dtoverlay = disable-bt
> +  enable_uart=1
> +
> +.. note:: 
> +  The Raspberry Pi 4B and 400 have an additional four PL011 UARTs. They are 
> not 
> +  supported.
> +
> +Generating kernel image 

Change to:

Generating Kernel Image

> +^^^
> +
> +The following steps show how to run ``hello.exe`` on the BSP. Other 
> executables
> +can be processed in a similar way.
> +
> +To create the kernel image:
> +
> +.. code-block:: shell
> +
> +  $ aarch64-rtems@rtems-ver-major@-objcopy -Obinary hello.exe kernel8.img
> +
> +Copy the kernel image to the SD card.

To the root directory of the SD card?

> +
> +JTAG Setup

Change to:

JTAG Set-up

> +--
> +
> +The Raspberry Pi 4 doesn't have dedicated JTAG pins. Instead, you must 
> configure
> +the GPIO pins (GPIO22-GPIO27) to activate the JTAG functionality. The RPi 4
> +documentation refers to this as Alt4 functions of those pins. Alt5 does exist
> +too, which goes from GPIO4, 5, 6, 12 and 13. you can check this out from
> +`pinout.xyz `_ or `eLinux
> +`_
> +

What about:

The Raspberry Pi 4 doesn't have dedicated JTAG pins. To use JTAG configure
the GPIO pins (GPIO22-GPIO27) to activate the JTAG functionality. The RPi 4
documentation refers to this as Alt4 functions of those pins. Alt5 does exist
and goes from GPIO4, 5, 6, 12 and 13. You can check this out from
`pinout.xyz `_ or `eLinux
> +`_

Also what does Alt5 offer? I see it mentioned but I do not know why?

> +One more thing to note on JTAG with Raspberry pi 4B is that, by default, All 
> the
> +GPIO pins are pulled down, according to the `BCM2711 documentation
> +`_. This
> +wasn't the case in the earlier models. So in order to let 

Re: [PATCH 06/13] config: Add rtems_malloc_task_stack_for_idle()

2022-10-05 Thread Chris Johns
On 5/10/2022 4:00 pm, Sebastian Huber wrote:
> On 04/10/2022 23:21, Chris Johns wrote:
>> On 5/10/2022 12:41 am, Sebastian Huber wrote:
>>> On 04/10/2022 15:21, Joel Sherrill wrote:
>>>> On Tue, Oct 4, 2022 at 12:40 AM Sebastian Huber
>>>> >>> <mailto:sebastian.hu...@embedded-brains.de>> wrote:
>>>>
>>>>  On 30/09/2022 23:39, Chris Johns wrote:
>>>>   > On 30/9/2022 7:21 pm, Sebastian Huber wrote:
>>>>   >> Update #4524.
>>>>   >> ---
>>>>   >>   cpukit/doxygen/appl-config.h                | 13 +
>>>>   >>   cpukit/include/rtems/rtems/config.h         | 29 +-
>>>>   >>   cpukit/include/rtems/score/interr.h         |  1 +
>>>>   >>   cpukit/sapi/src/interrtext.c                |  3 +-
>>>>   >>   cpukit/sapi/src/malloctaskstackforidle.c    | 59
>>>>  +
>>>>   >>   spec/build/cpukit/librtemscpu.yml           |  1 +
>>>>   >>   spec/build/testsuites/sptests/grp.yml       |  2 +
>>>>   >>   spec/build/testsuites/sptests/spfatal36.yml | 19 +++
>>>>   >>   testsuites/sptests/spfatal36/init.c         | 52
>>>>  ++
>>>>   >>   testsuites/sptests/spfatal36/spfatal36.doc  | 11 
>>>>   >>   testsuites/sptests/spinternalerror02/init.c |  2 +-
>>>>   >>   testsuites/sptests/sptls04/init.c           |  2 +
>>>>   >>   12 files changed, 191 insertions(+), 3 deletions(-)
>>>>   >>   create mode 100644 cpukit/sapi/src/malloctaskstackforidle.c
>>>>   >>   create mode 100644 spec/build/testsuites/sptests/spfatal36.yml
>>>>   >>   create mode 100644 testsuites/sptests/spfatal36/init.c
>>>>   >>   create mode 100644 testsuites/sptests/spfatal36/spfatal36.doc
>>>>   >>
>>>>   >> diff --git a/cpukit/doxygen/appl-config.h
>>>>  b/cpukit/doxygen/appl-config.h
>>>>   >> index aa6dbae648..ee647dc961 100644
>>>>   >> --- a/cpukit/doxygen/appl-config.h
>>>>   >> +++ b/cpukit/doxygen/appl-config.h
>>>>   >> @@ -4842,6 +4842,19 @@
>>>>   >>    * configuration options.  It is assumed that any memory
>>>>  allocated for the
>>>>   >>    * stack of an IDLE task will not be from the RTEMS Workspace
>>>>  or the memory
>>>>   >>    * statically allocated by default.
>>>>   >> + *
>>>>   >> + * For applications with a thread-local storage size which is
>>>>  completely
>>>>   >> + * unknown at the time the application configuration is
>>>>  defined, RTEMS provides
>>>>   >> + * an IDLE task stack allocator which uses rtems_malloc().
>>>>   >
>>>>   > I thought the TLS size was static and set by the linker? Has this
>>>>  changed?
>>>>
>>>>  No, this didn't change.
>>>>
>>>>   >
>>>>   > I am confused about the relationship between an unknown TLS size
>>>>  and IDLE task?
>>>>   > And the relationship of the TLS size and stack size?
>>>>
>>>>  Currently, the IDLE task storage area is statically allocated. The 
>>>> size
>>>>  of this area is defined by CONFIGURE_IDLE_TASK_STACK_SIZE. So, this
>>>>  configuration option doesn't directly specify the IDLE task stack 
>>>> size.
>>>>  This size covers also the TLS area.
>>>>
>>>>
>>>> Thanks for speaking up Chris. I also don't like the idea that something 
>>>> that
>>>> has said and meant IDLE stack size was getting other items lumped into it.
>>>>
>>>>
>>>>   >
>>>>   >> * * The size of the
>>>>   >> + * allocated thread storage area is the sum of stack size
>>>>  defined by the
>>>>   >> + * #CONFIGURE_IDLE_TASK_STACK_SIZE configuration option and the
>>>>  actual
>>>>   >> + * thread-local storage size of the application.
>>>>   >
>>>>   > The label CONFIGURE_IDLE_TASK_STACK_SIZE provides no insight in

Re: Git master/main/trunk/current/best...

2022-10-05 Thread Chris Johns
On 6/10/2022 6:14 am, Sebastian Huber wrote:
> On 05/10/2022 20:37, Joel Sherrill wrote:
>> On Thu, Sep 29, 2022 at 4:24 PM Chris Johns > <mailto:chr...@rtems.org>> wrote:
>>
>>     On 30/9/22 4:00 am, Joel Sherrill wrote:
>>  > I'd like to propose that short term we change lwip main to master for
>>  > consistency with existing repos. This helps avoid stupid mistakes
>>     because lwip
>>  > is the odd case.
>>
>>     I propose we use devel. I prefer it over main.
>>
>>
>> I'm ok with that. But no one else has spoken up.
> 
> I don't care that much about the name, however, github.com, gitlab.com, and
> bitbucket.org use "main" for the primary branch.

That is good to know. Happy to follow their lead and use main.

Timing for a switch?

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

Re: [PATCH] gsed.cfg: Add check for gsed

2022-10-05 Thread Chris Johns
On 6/10/2022 5:29 am, Ryan Long wrote:
> On 10/4/2022 4:31 PM, Chris Johns wrote:
>> On 5/10/2022 12:52 am, Ryan Long wrote:
>>> It looks like gcc checks for gsed if sed is not the GNU version.
>> Thanks for checking this.
>>
>>> I've installed it on FreeBSD and MacOS. I had to install it via Homebrew on
>>> MacOS, but that's because it fails to build gsed.
>> Homebrew complicates your work. I make sure my test Macs have never had 
>> Homebrew
>> or Macports installed. When I played with this a long time ago the install
>> prefix was /usr/local and after a while I found I had no idea what was 
>> installed
>> and what was provided by the OS and if the base OS versions were 
>> overwritten. I
>> believe Macports is not doing this these days (if it ever did) but I have not
>> looked.
> 
> On the m1 macs, Homebrew installs under /opt/homebrew/bin. The prefix for 
> Intel
> macs is /usr/local, so I assume anything installed would be under
> /usr/local/homebrew/bin.

That helps but I am not sure my point has been made that RTEMS as a project
depending on homebrew or macports complicates our builds and how we maintain
them long term. If either are rolling releases it is hard. There has been no
need for homebrew or macports up to now and I still do not see a need.

And I think they are great and useful projects so this is about how we maintain
our tools and not a reflection on them.

> I don't know when the packages in Homebrew may overwrite the programs used by
> the systems, but at least in the case of gsed, it didn't overwrite the 
> system's
> sed.>
>>
>>> The error is "machine `arm64-apple' not recognized".
>> Does the GNU sed upstream project have a fix?
> 
> I looked into how Homebrew builds it. All that they do is
> 
>   def install
>     args = %W[
>   --prefix=#{prefix}
>   --disable-dependency-tracking
>     ]
> 
>     args << if OS.mac?
>   "--program-prefix=g"
>     else
>   "--without-selinux"
>     end
>     system "./configure", *args
>     system "make", "install"
> 
> I experimented with the building of gsed with the RSB. I just removed the 
> --host
> flag, and I was able to get around the error. However, it then reports

What was `--host` set to?

Without the option what does sed'w configure detect the host to be?

> sizes: gsed-4.8-arm64-apple-darwin21.6.0-1: 16.874MB (installed: 0.000B)

Is this the latest RSB?

If it is I suggest you put the RSB aside and manually untar the source,
configure it and run make. Once you know how to build the package run the RSB
with --dry-run to get the options you need then remove the --dry-run option.
Always use --trace when adding a new build and look at the log file for the 
details.

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

Re: [docs 1/5] c-user: Add CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE

2022-10-04 Thread Chris Johns
Hi,

Can we please wait until the patches are sorted before this is merged?

Thanks
Chris

On 30/9/2022 7:15 pm, Sebastian Huber wrote:
> ---
>  c-user/config/idle-task.rst| 95 --
>  c-user/config/task-stack-alloc.rst | 39 ++--
>  2 files changed, 124 insertions(+), 10 deletions(-)
> 
> diff --git a/c-user/config/idle-task.rst b/c-user/config/idle-task.rst
> index 359f862..d7b43ae 100644
> --- a/c-user/config/idle-task.rst
> +++ b/c-user/config/idle-task.rst
> @@ -1,6 +1,6 @@
>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>  
> -.. Copyright (C) 2020, 2021 embedded brains GmbH 
> (http://www.embedded-brains.de)
> +.. Copyright (C) 2020, 2022 embedded brains GmbH 
> (http://www.embedded-brains.de)
>  .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
>  
>  .. This file is part of the RTEMS quality process and was automatically
> @@ -134,6 +134,74 @@ options
>  
>  otherwise a compile time error in the configuration file will occur.
>  
> +.. Generated from spec:/acfg/if/idle-task-min-stack-size
> +
> +.. raw:: latex
> +
> +\clearpage
> +
> +.. index:: CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE
> +.. index:: minimum task stack size
> +
> +.. _CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE:
> +
> +CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE
> +--
> +
> +.. rubric:: CONSTANT:
> +
> +``CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE``
> +
> +.. rubric:: OPTION TYPE:
> +
> +This configuration option is an integer define.
> +
> +.. rubric:: DEFAULT VALUE:
> +
> +:c:macro:`CPU_STACK_MINIMUM_SIZE` / 4
> +
> +.. rubric:: DESCRIPTION:
> +
> +The value of this configuration option defines the minimum stack size in
> +bytes for every :term:`IDLE task` in the system.
> +
> +.. rubric:: NOTES:
> +
> +Adjusting this parameter should be done with caution.  Examining the actual
> +stack usage using the stack checker usage reporting facility is recommended
> +(see also :ref:`CONFIGURE_STACK_CHECKER_ENABLED`).
> +
> +This parameter can be used to increase the minimum from that
> +recommended. This can be used in higher memory systems to reduce the risk
> +of stack overflow without performing analysis on actual consumption.
> +
> +By default, the IDLE task storage areas are statically allocated.  The size
> +of the task storage area is defined by the 
> :ref:`CONFIGURE_IDLE_TASK_STACK_SIZE`
> +configuration option.  The task storage area contains the task stack, the
> +thread-local storage, and the floating-point context on architectures with a
> +separate floating-point context.  The size of the thread-local storage area
> +is defined at link time or by the 
> :ref:`CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE`
> +configuration option.  This configuration option is used to ensure that the
> +IDLE task stack size has at least the configured minimum size.  If the IDLE
> +task stack size is too small, for example because the thread-local storage
> +size is too large, then the system terminates with the
> +:ref:`INTERNAL_ERROR_CORE ` fatal source and the
> +:ref:`INTERNAL_ERROR_IDLE_THREAD_STACK_TOO_SMALL ` fatal 
> code during
> +system initialization.
> +
> +.. rubric:: CONSTRAINTS:
> +
> +The value of the configuration option shall be large enough so that
> +
> +* the thread handler can call the thread switch extensions for the IDLE task,
> +
> +* the thread handler can call the thread begin extensions for the IDLE task,
> +
> +* the thread handler can call the IDLE task body (see
> +  :ref:`CONFIGURE_IDLE_TASK_BODY`), and
> +
> +* the IDLE task can be interrupted by interrupt services.
> +
>  .. Generated from spec:/acfg/if/idle-task-stack-size
>  
>  .. raw:: latex
> @@ -165,13 +233,30 @@ defined by the :ref:`CONFIGURE_MINIMUM_TASK_STACK_SIZE` 
> configuration option.
>  
>  .. rubric:: DESCRIPTION:
>  
> -The value of this configuration option defines the task stack size for an
> -IDLE task.
> +The value of this configuration option defines the task storage area size for
> +an IDLE task.
>  
>  .. rubric:: NOTES:
>  
> -In SMP configurations, there is one IDLE task per configured processor, see
> -:ref:`CONFIGURE_MAXIMUM_PROCESSORS`.
> +Where the system was built with SMP support enabled, there is one IDLE task
> +for each configured processor, see :ref:`CONFIGURE_MAXIMUM_PROCESSORS`.
> +
> +By default, the IDLE task storage areas are statically allocated.  The size
> +of the task storage area for each IDLE task is defined by this configuration
> +option.  The task storage area contains the task stack, the thread-local
> +storage, and the floating-point context on architectures with a separate
> +floating-point context.  The size of the thread-local storage area is defined
> +at link time or by the :ref:`CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE` 
> configuration
> +option.  The :ref:`CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE` configuration 
> option is used
> +to ensure that the IDLE task stack size has at least the configured minimum
> +size.  

Re: [PATCH v3] bsp/aarch64: Add new Raspberry Pi 4B BSP

2022-10-04 Thread Chris Johns
On 5/10/2022 5:39 am, Joel Sherrill wrote:
> Once Alan says it's OK, I will merge this.
> 
> Great work! Please make sure code, docs, tester configuration, etc gets 
> merged.

Looks great, well done for all the hard work.

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


Re: [PATCH] gsed.cfg: Add check for gsed

2022-10-04 Thread Chris Johns
On 5/10/2022 12:52 am, Ryan Long wrote:
> It looks like gcc checks for gsed if sed is not the GNU version.

Thanks for checking this.

> I've installed it on FreeBSD and MacOS. I had to install it via Homebrew on
> MacOS, but that's because it fails to build gsed.

Homebrew complicates your work. I make sure my test Macs have never had Homebrew
or Macports installed. When I played with this a long time ago the install
prefix was /usr/local and after a while I found I had no idea what was installed
and what was provided by the OS and if the base OS versions were overwritten. I
believe Macports is not doing this these days (if it ever did) but I have not
looked.

> The error is "machine `arm64-apple' not recognized".

Does the GNU sed upstream project have a fix?

> So I added this check to get around that, and it built successfully.

Sorry, I see Homebrew and Macports as user options and not a project option. We
need repeatable builds and not builds based on a local checkout of some 
packages.

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


Re: [PATCH 06/13] config: Add rtems_malloc_task_stack_for_idle()

2022-10-04 Thread Chris Johns
On 5/10/2022 12:41 am, Sebastian Huber wrote:
> On 04/10/2022 15:21, Joel Sherrill wrote:
>> On Tue, Oct 4, 2022 at 12:40 AM Sebastian Huber
>> > <mailto:sebastian.hu...@embedded-brains.de>> wrote:
>>
>>     On 30/09/2022 23:39, Chris Johns wrote:
>>  > On 30/9/2022 7:21 pm, Sebastian Huber wrote:
>>  >> Update #4524.
>>  >> ---
>>  >>   cpukit/doxygen/appl-config.h                | 13 +
>>  >>   cpukit/include/rtems/rtems/config.h         | 29 +-
>>  >>   cpukit/include/rtems/score/interr.h         |  1 +
>>  >>   cpukit/sapi/src/interrtext.c                |  3 +-
>>  >>   cpukit/sapi/src/malloctaskstackforidle.c    | 59
>>     +
>>  >>   spec/build/cpukit/librtemscpu.yml           |  1 +
>>  >>   spec/build/testsuites/sptests/grp.yml       |  2 +
>>  >>   spec/build/testsuites/sptests/spfatal36.yml | 19 +++
>>  >>   testsuites/sptests/spfatal36/init.c         | 52
>>     ++
>>  >>   testsuites/sptests/spfatal36/spfatal36.doc  | 11 
>>  >>   testsuites/sptests/spinternalerror02/init.c |  2 +-
>>  >>   testsuites/sptests/sptls04/init.c           |  2 +
>>  >>   12 files changed, 191 insertions(+), 3 deletions(-)
>>  >>   create mode 100644 cpukit/sapi/src/malloctaskstackforidle.c
>>  >>   create mode 100644 spec/build/testsuites/sptests/spfatal36.yml
>>  >>   create mode 100644 testsuites/sptests/spfatal36/init.c
>>  >>   create mode 100644 testsuites/sptests/spfatal36/spfatal36.doc
>>  >>
>>  >> diff --git a/cpukit/doxygen/appl-config.h
>>     b/cpukit/doxygen/appl-config.h
>>  >> index aa6dbae648..ee647dc961 100644
>>  >> --- a/cpukit/doxygen/appl-config.h
>>  >> +++ b/cpukit/doxygen/appl-config.h
>>  >> @@ -4842,6 +4842,19 @@
>>  >>    * configuration options.  It is assumed that any memory
>>     allocated for the
>>  >>    * stack of an IDLE task will not be from the RTEMS Workspace
>>     or the memory
>>  >>    * statically allocated by default.
>>  >> + *
>>  >> + * For applications with a thread-local storage size which is
>>     completely
>>  >> + * unknown at the time the application configuration is
>>     defined, RTEMS provides
>>  >> + * an IDLE task stack allocator which uses rtems_malloc().
>>  >
>>  > I thought the TLS size was static and set by the linker? Has this
>>     changed?
>>
>>     No, this didn't change.
>>
>>  >
>>  > I am confused about the relationship between an unknown TLS size
>>     and IDLE task?
>>  > And the relationship of the TLS size and stack size?
>>
>>     Currently, the IDLE task storage area is statically allocated. The size
>>     of this area is defined by CONFIGURE_IDLE_TASK_STACK_SIZE. So, this
>>     configuration option doesn't directly specify the IDLE task stack size.
>>     This size covers also the TLS area.
>>
>>
>> Thanks for speaking up Chris. I also don't like the idea that something that
>> has said and meant IDLE stack size was getting other items lumped into it.
>>
>>
>>  >
>>  >> * * The size of the
>>  >> + * allocated thread storage area is the sum of stack size
>>     defined by the
>>  >> + * #CONFIGURE_IDLE_TASK_STACK_SIZE configuration option and the
>>     actual
>>  >> + * thread-local storage size of the application.
>>  >
>>  > The label CONFIGURE_IDLE_TASK_STACK_SIZE provides no insight into
>>     it being
>>  > effected by the TLS size.
>>  >
>>  >> * * Define this configuration
>>  >> + * option to ``rtems_malloc_task_stack_for_idle`` to use this
>>     allocator.  If
>>  >> + * the memory allocation fails, then the system terminates with the
>>  >> + * INTERNAL_ERROR_CORE fatal source and the
>>  >> + * INTERNAL_ERROR_NO_MEMORY_FOR_IDLE_TASK_STACK fatal code
>>     during system
>>  >> + * initialization.
>>  >> + * @endparblock
>>  >
>>  > I am confused about the how and why I would use this change?
>>
>>     With the statically allocated storage area for the IDLE task you
>>     need at
>>     least

Re: [PATCH] c-user: Add application config info directives

2022-10-04 Thread Chris Johns


On 1/10/2022 12:25 am, Sebastian Huber wrote:
> On 17/09/2022 09:31, Chris Johns wrote:
>>> diff --git a/c-user/config/introduction.rst b/c-user/config/introduction.rst
>>> new file mode 100644
>>> index 000..d06662a
>>> --- /dev/null
>>> +++ b/c-user/config/introduction.rst
>>> @@ -0,0 +1,221 @@
>>> +.. SPDX-License-Identifier: CC-BY-SA-4.0
>>> +
>>> +.. Copyright (C) 2009, 2021 embedded brains GmbH
>>> (http://www.embedded-brains.de)
>>> +.. Copyright (C) 1988, 2021 On-Line Applications Research Corporation (OAR)
>> Is this right? I see in the diff fragments Gedare?
> 
> Yes, I think so. Gedare has a copyright in the unlimited objects section.
> 

Great and thanks

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


Re: [PATCH] c-user: Add application config info directives

2022-10-04 Thread Chris Johns
On 30/9/2022 11:43 pm, Sebastian Huber wrote:
> On 17/09/2022 09:31, Chris Johns wrote:
>>> +rtems_configuration_get_milliseconds_per_tick()
>>> +---
>>> +
>>> +Gets the number of milliseconds per clock tick configured for this 
>>> application.
>> There are other API calls that return this value. What should a user do?
> 
> I don't know another API function to get this value.

Yes there is not. It may have been 5 or 4.11 I was thinking about. I have been
working with those version.

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


Re: [PATCH] c-user: Add application config info directives

2022-10-04 Thread Chris Johns
On 30/9/2022 11:34 pm, Sebastian Huber wrote:
> On 17/09/2022 09:31, Chris Johns wrote:
>>> +rtems_get_version_string()
>>> +--
>>> +
>>> +Gets the RTEMS version string.
>>> +
>>> +.. rubric:: CALLING SEQUENCE:
>>> +
>>> +.. code-block:: c
>>> +
>>> +    const char *rtems_get_version_string( void );
>>> +
>>> +.. rubric:: RETURN VALUES:
>>> +
>>> +Returns the pointer to the RTEMS version string.
>> Is the version string subject to change across releases or do as set this 
>> string
>> format?
>>
>> Is it worth discussing the revision values and what they mean?
> 
> The version string contains a lot of stuff:
> 
> const char _RTEMS_version[] =
>   "rtems-" RTEMS_VERSION " (" CPU_NAME "/" CPU_MODEL_NAME "/"
>   RTEMS_XSTRING( RTEMS_BSP ) ")";
> 
> I don't know if we should specify a particular format.
> 

I agree. We should say it may change and parsing it may break.

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

Re: [PATCH] gsed.cfg: Add check for gsed

2022-10-03 Thread Chris Johns
On 4/10/2022 2:52 am, Ryan Long wrote:
> ---
>  bare/config/textproc/gsed.cfg | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/bare/config/textproc/gsed.cfg b/bare/config/textproc/gsed.cfg
> index 8287c74..b4aaf4f 100644
> --- a/bare/config/textproc/gsed.cfg
> +++ b/bare/config/textproc/gsed.cfg
> @@ -2,7 +2,7 @@
>  # GNU sed has a version option, check for it.
>  # If not found build it.
>  #
> -%define has_gnu_sed %(sed --version > /dev/null 2>&1; echo $?)
> +%define has_gnu_sed %(sed --version > /dev/null 2>&1 || gsed --version > 
> /dev/null 2>&1; echo $?)
>  %if %{has_gnu_sed} != 0
>   %include %{_configdir}/textproc/gsed-4.8.cfg
>  %endif

What does gcc require sed be as a command? Is it sed or gsed?

Which host has gsed installed?

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


Re: Libexpat missing when using Python from python.org

2022-10-03 Thread Chris Johns
On 4/10/2022 2:32 am, Ryan Long wrote:
> Hello,
> 
> Following Chris's advice, I installed Python 3.10.6 from Python's website. It
> gets me past the header check for gdb,

Great.

> but then it reports
> 
> 
> checking whether to use expat... yes
> 
> checking for libexpat... no
> 
> configure: error: expat is missing or unusable
> 
> make[1]: *** [configure-gdb] Error 1
> 
> make: *** [all] Error 2
> 
> 
> What's the best way to get Libexpat on macOS?
> 
> I was able to successfully build it with the python installed from Homebrew
> after disabling the building of gsed.

It should build for the Xcode (MacOS) python so I something is wrong in the GDB
common build script.

gsed has to be built if sed is not the GNU version

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


Re: [PATCH 06/13] config: Add rtems_malloc_task_stack_for_idle()

2022-09-30 Thread Chris Johns
On 30/9/2022 7:21 pm, Sebastian Huber wrote:
> Update #4524.
> ---
>  cpukit/doxygen/appl-config.h| 13 +
>  cpukit/include/rtems/rtems/config.h | 29 +-
>  cpukit/include/rtems/score/interr.h |  1 +
>  cpukit/sapi/src/interrtext.c|  3 +-
>  cpukit/sapi/src/malloctaskstackforidle.c| 59 +
>  spec/build/cpukit/librtemscpu.yml   |  1 +
>  spec/build/testsuites/sptests/grp.yml   |  2 +
>  spec/build/testsuites/sptests/spfatal36.yml | 19 +++
>  testsuites/sptests/spfatal36/init.c | 52 ++
>  testsuites/sptests/spfatal36/spfatal36.doc  | 11 
>  testsuites/sptests/spinternalerror02/init.c |  2 +-
>  testsuites/sptests/sptls04/init.c   |  2 +
>  12 files changed, 191 insertions(+), 3 deletions(-)
>  create mode 100644 cpukit/sapi/src/malloctaskstackforidle.c
>  create mode 100644 spec/build/testsuites/sptests/spfatal36.yml
>  create mode 100644 testsuites/sptests/spfatal36/init.c
>  create mode 100644 testsuites/sptests/spfatal36/spfatal36.doc
> 
> diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
> index aa6dbae648..ee647dc961 100644
> --- a/cpukit/doxygen/appl-config.h
> +++ b/cpukit/doxygen/appl-config.h
> @@ -4842,6 +4842,19 @@
>   * configuration options.  It is assumed that any memory allocated for the
>   * stack of an IDLE task will not be from the RTEMS Workspace or the memory
>   * statically allocated by default.
> + *
> + * For applications with a thread-local storage size which is completely
> + * unknown at the time the application configuration is defined, RTEMS 
> provides
> + * an IDLE task stack allocator which uses rtems_malloc(). 

I thought the TLS size was static and set by the linker? Has this changed?

I am confused about the relationship between an unknown TLS size and IDLE task?
And the relationship of the TLS size and stack size?

> * * The size of the
> + * allocated thread storage area is the sum of stack size defined by the
> + * #CONFIGURE_IDLE_TASK_STACK_SIZE configuration option and the actual
> + * thread-local storage size of the application.

The label CONFIGURE_IDLE_TASK_STACK_SIZE provides no insight into it being
effected by the TLS size.

> * * Define this configuration
> + * option to ``rtems_malloc_task_stack_for_idle`` to use this allocator.  If
> + * the memory allocation fails, then the system terminates with the
> + * INTERNAL_ERROR_CORE fatal source and the
> + * INTERNAL_ERROR_NO_MEMORY_FOR_IDLE_TASK_STACK fatal code during system
> + * initialization.
> + * @endparblock

I am confused about the how and why I would use this change?

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


Re: [PATCH] spec/pkgconfig: Allow builds to override headers

2022-09-30 Thread Chris Johns
On 1/10/2022 6:30 am, Kinsey Moore wrote:
> On 9/29/2022 16:19, Chris Johns wrote:
>> On 29/9/22 11:24 pm, Kinsey Moore wrote:
>>> On 9/28/2022 19:03, Chris Johns wrote:
>>>> On 29/9/2022 7:13 am, Kinsey Moore wrote:
>>>>> This allows any builds targeting an installed RTEMS BSP to override
>>>>> headers in the installed BSP reliably, including headers previously
>>>>> installed by that or other builds. This includes applications, network
>>>>> stacks, libraries, and any other builds.
>>>> I am a little confused by these comments. This change effects the 
>>>> generated .pc
>>>> file for a BSP so it is only used once it is installed.
>>> Correct, this is a fix for things like rtems-libbsd and rtems-lwip that 
>>> allows
>>> them to build correctly even if there are existing conflicting 
>>> installations of
>>> that library already installed in the BSP install.
>> So this is a change to aid developers of these packages who use a single 
>> prefix
>> for the tools, BSP and packages? I split the install paths up and that avoids
>> the problem.
> I guess I'm conflating a couple of different problems here. I'll take a closer
> look at how things behave when there is a separate installation path.

I just delete the effect piece. This is not the only reason to separate the
paths. Cleaning the builds away is an important test. We have been caught a few
times over the years.

>>>> An install should update
>>>> the headers at the same time the .pc is installed and made available so 
>>>> what is
>>>> old or previous? What are the "builds targeting" you refer too?
>>> "builds targeting an installed RTEMS BSP" refers to any external build that 
>>> uses
>>> installed RTEMS headers and libraries. These external builds can install 
>>> their
>>> own files in the BSP install.
>> Is this install or reinstall?
> The issues happen on reinstall since there is an existing header that has a
> higher priority in the include search paths than the local search paths.

OK

>>>> I think defining the include search of RTEMS BSP and any vertical stack
>>>> packages
>>>> headers installed under the same prefix as system headers seems like the 
>>>> right
>>>> thing to do. However this change will silence warnings from RTEMS (and
>>>> installed
>>>> packages). Is that want we want?
>>> What warnings will this silence?
>> https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html
>>
>> This changes the level of warnings we currently have for a specific but
>> important group of packages that are based on rtems_waf or use .pc files. I
>> think this is important to consider.
> 
> It changes the warning level when used from the installed BSP, but we should
> still see these warnings when compiling RTEMS itself and packages compiled
> against an installed BSP using the .pc files (via rtems_waf or otherwise) will
> still display these warnings in their own headers since they will be used
> locally pre-installation.
> 
> There is still the issue of using existing headers in novel ways that could
> generate warnings which would be missed due to this change, but even then the
> documentation linked claims that macros instanced in non-system-header 
> locations
> are only immune to a small subset of warnings. I think it's worth the change
> given that installing additional packages into the installed BSP is common
> practice from what I've seen.

Yes there is a chance a warning is missed and I cannot answer if that is OK.
Maybe Joel would like to comment about this?

>>> It shouldn't affect RTEMS builds because RTEMS
>>> doesn't use the pkgconfg while building. It still places installed headers
>>> before actual system/tools headers in the include hierarchy, so any build 
>>> errors
>>> generated that way should be preserved.
>> Is Makefile.inc also updated? It effects some users of RTEMS but not all. Is
>> that important?
> I hunted for this earlier and missed it. It's apparently in make/custom and
> would need to be tweaked as well for consistency.

It should be consistent.

>> Is this something we should document as mandated for all users of BSP 
>> installed
>> headers?
> 
> It's worth putting it somewhere. Users of the .pc and Makefile.inc won't 
> notice
> or need to care for the most part, but anyone using non-standard external 
> build
> systems will need to know.

Agreed

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


Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build

2022-09-30 Thread Chris Johns
On 30/9/2022 5:01 pm, Christian MAUDERER wrote:
>  The rtems-deployment repo doesn't have a .gitlab-ci.yml. Did you keep that 
> separate?

Sorry missed this. The plumbing is outside of that repo.

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


Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build

2022-09-30 Thread Chris Johns
On 30/9/2022 5:01 pm, Christian MAUDERER wrote:
> Am 30.09.22 um 08:48 schrieb Chris Johns:
>> On 30/9/2022 4:08 pm, Christian MAUDERER wrote:
>>> Am 30.09.22 um 07:37 schrieb Chris Johns:
>>>> On 30/9/2022 3:33 pm, Christian MAUDERER wrote:
>>>>> Am 30.09.22 um 05:49 schrieb Chris Johns:
>>>>>> On 29/9/2022 9:50 pm, Chris Johns wrote:
>>>>>>> On 29/9/22 9:45 pm, Christian MAUDERER wrote:
>>>>>>>> Hello Chris,
>>>>>>>>
>>>>>>>> thanks for the quick patch. With this qemu and microblaze work again 
>>>>>>>> like
>>>>>>>> expected.
>>>>>>>>
>>>>>>>> I tested all tools starting with devel/* and from the ones that work 
>>>>>>>> only
>>>>>>>> devel/autotools-internal didn't generate a tar archive. But that one 
>>>>>>>> has a
>>>>>>>> comment "Do not use via the command line" in the bset file so that is 
>>>>>>>> most
>>>>>>>> likely fine.
>>>>>>>>
>>>>>>>> Some of other devel/* packages didn't build in my test setup, but I 
>>>>>>>> have
>>>>>>>> never
>>>>>>>> tested or used them before so that is probably a problem of my build
>>>>>>>> environment
>>>>>>>> or maybe a known bug.
>>>>>>>
>>>>>>> Thanks for the testing. I will push to the devel branch and 5.
>>>>>>>
>>>>>>
>>>>>> Tarfile creation is working however installing is not. I am working on 
>>>>>> fixing
>>>>>> this.
>>>>>>
>>>>>> Chris
>>>>>
>>>>> Sorry that I missed that. I only tried to generate the tar archives.
>>>>
>>>> Same. Testing a fix but it takes time to check properly.
>>>>
>>>> I am wondering if I can create a test mode in the deployment repo. The hard
>>>> part
>>>> is how to automatically check the build has worked.
>>>>
>>>> Chris
>>>
>>> I'm currently trying to create a basic CI/CD setup for testing our embedded
>>> brains patches using GitHub. At the moment it's still quite experimental and
>>> still a bit thrown together but it basically runs:
>>>
>>> https://github.com/embedded-brains/rtems-source-builder/actions/runs/3151126889
>>
>> Nice.
>>
>>> It didn't catch that bug because it doesn't use installed tools for the
>>> simulator runs, but maybe I can change that.
>>>
>>> If it works well enough, we maybe could re-use some scripts or work flows 
>>> to set
>>> up an official RTEMS CI/CD with whatever community preferred CI system. It
>>> shouldn't be too big of a problem to port the logic to Gitlab CI, Cirrus CI 
>>> or
>>> any other modern CI system.
>>
>> I have started https://git.rtems.org/chrisj/rtems-deployment.git/. I would 
>> like
>> it to be the landing place for this type of stuff if it fits. The repo is 
>> being
>> actively worked on by me.
> 
> I have seen that repo after you mentioned it recently, but I have to admit I
> haven't looked at it yet. From the name I have guessed that it is more for
> building release versions and not for continuous checks. I'll take a more
> detailed look.

CI is something that would come under deployment, it is the same process. In
your case the output is not used, it is for testing.

The repo can build buildsets that will fail and show them as a pass.

>> I can build RPMs on Rocky 8 and 9. These RPMs are the base for EPICS RPMs 
>> built
>> into docker containers used to build Gemini's EPICS based systems. All 
>> handled
>> via CI in gitlab.
> 
> That's quite interesting. Do you have a public GitLab instance where you build
> these or is that a private instance?

https://gitlab.com/nsf-noirlab/gemini/rtsw/epics-base/epics-base

> The rtems-deployment repo doesn't have a .gitlab-ci.yml. Did you keep that 
> separate?
$ ./waf configure --prefix=/opt/rtems --rsb=../rtems-source-builder
$ ./waf rpmspec
$ rpmbuild -bb out/test/dtc.spec

$ rpm -qi \
 out/buildroot/RPMS/x86_64/rtems-dtc-5-ddfcc320ab74_modified.el9.x86_64.rpm
Name: rtems-dtc
Version : 5
Release : ddfcc320ab74_modified.el9
Architecture: x86_64
Install Date: (not installed)
Group   : Unspecified
Size: 1191613
License : GPLv2, GPLv3, BSD-2
Signature   : (none)
Source RPM  : rtems-dtc-5-ddfcc320ab74_modified.el9.src.rpm
Build Date  : Friday 30 September 2022 05:24:31 PM
Build Host  : rocky.contemporary.net.au
Summary : RTEMS tools and board support package
Description :
This RPM is development tools and BSP for RTEMS

If you switch the RSB branch from 6 to 5 the same process works. That is really
important because users do not need to update their plumbing.

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


Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build

2022-09-30 Thread Chris Johns
On 30/9/2022 4:08 pm, Christian MAUDERER wrote:
> Am 30.09.22 um 07:37 schrieb Chris Johns:
>> On 30/9/2022 3:33 pm, Christian MAUDERER wrote:
>>> Am 30.09.22 um 05:49 schrieb Chris Johns:
>>>> On 29/9/2022 9:50 pm, Chris Johns wrote:
>>>>> On 29/9/22 9:45 pm, Christian MAUDERER wrote:
>>>>>> Hello Chris,
>>>>>>
>>>>>> thanks for the quick patch. With this qemu and microblaze work again like
>>>>>> expected.
>>>>>>
>>>>>> I tested all tools starting with devel/* and from the ones that work only
>>>>>> devel/autotools-internal didn't generate a tar archive. But that one has 
>>>>>> a
>>>>>> comment "Do not use via the command line" in the bset file so that is 
>>>>>> most
>>>>>> likely fine.
>>>>>>
>>>>>> Some of other devel/* packages didn't build in my test setup, but I have
>>>>>> never
>>>>>> tested or used them before so that is probably a problem of my build
>>>>>> environment
>>>>>> or maybe a known bug.
>>>>>
>>>>> Thanks for the testing. I will push to the devel branch and 5.
>>>>>
>>>>
>>>> Tarfile creation is working however installing is not. I am working on 
>>>> fixing
>>>> this.
>>>>
>>>> Chris
>>>
>>> Sorry that I missed that. I only tried to generate the tar archives.
>>
>> Same. Testing a fix but it takes time to check properly.
>>
>> I am wondering if I can create a test mode in the deployment repo. The hard 
>> part
>> is how to automatically check the build has worked.
>>
>> Chris
> 
> I'm currently trying to create a basic CI/CD setup for testing our embedded
> brains patches using GitHub. At the moment it's still quite experimental and
> still a bit thrown together but it basically runs:
> 
> https://github.com/embedded-brains/rtems-source-builder/actions/runs/3151126889

Nice.

> It didn't catch that bug because it doesn't use installed tools for the
> simulator runs, but maybe I can change that.
> 
> If it works well enough, we maybe could re-use some scripts or work flows to 
> set
> up an official RTEMS CI/CD with whatever community preferred CI system. It
> shouldn't be too big of a problem to port the logic to Gitlab CI, Cirrus CI or
> any other modern CI system.

I have started https://git.rtems.org/chrisj/rtems-deployment.git/. I would like
it to be the landing place for this type of stuff if it fits. The repo is being
actively worked on by me.

I can build RPMs on Rocky 8 and 9. These RPMs are the base for EPICS RPMs built
into docker containers used to build Gemini's EPICS based systems. All handled
via CI in gitlab.

To build an RPM you configure with the path to the RSB and then run `./waf
rpmspec`. A spec file is created you can use with `rpmbuild` to make an RPM. I
am keeping the generation and building of the RPM separate. By default the repo
builds a tarfile.

Once this repo stabilises I would like to see if it can move to the top level. I
am working on better documentation for it and with that some constraints about
what is offered.

Deployment is something varies and I hope this repo can grow to make common
solutions widely available. I am fine for organisation to send in specific
configurations if they are open to having them in the repo.

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


Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build

2022-09-29 Thread Chris Johns
On 30/9/2022 3:33 pm, Christian MAUDERER wrote:
> Am 30.09.22 um 05:49 schrieb Chris Johns:
>> On 29/9/2022 9:50 pm, Chris Johns wrote:
>>> On 29/9/22 9:45 pm, Christian MAUDERER wrote:
>>>> Hello Chris,
>>>>
>>>> thanks for the quick patch. With this qemu and microblaze work again like
>>>> expected.
>>>>
>>>> I tested all tools starting with devel/* and from the ones that work only
>>>> devel/autotools-internal didn't generate a tar archive. But that one has a
>>>> comment "Do not use via the command line" in the bset file so that is most
>>>> likely fine.
>>>>
>>>> Some of other devel/* packages didn't build in my test setup, but I have 
>>>> never
>>>> tested or used them before so that is probably a problem of my build
>>>> environment
>>>> or maybe a known bug.
>>>
>>> Thanks for the testing. I will push to the devel branch and 5.
>>>
>>
>> Tarfile creation is working however installing is not. I am working on fixing
>> this.
>>
>> Chris
> 
> Sorry that I missed that. I only tried to generate the tar archives.

Same. Testing a fix but it takes time to check properly.

I am wondering if I can create a test mode in the deployment repo. The hard part
is how to automatically check the build has worked.

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


  1   2   3   4   5   6   7   8   9   10   >