Re: About Beaglebone Black device tree

2020-02-10 Thread Christian Mauderer 
On 09/02/2020 23:56, Chris Johns wrote:
> On 9/2/20 9:33 pm, Christian Mauderer wrote:
>> On 07/02/2020 18:23, Vijay Kumar Banerjee wrote:
>> On Mon, Feb 3, 2020 at 7:21 PM Christian Mauderer
>>> >> > wrote:
>>> On 02/02/2020 18:34, Vijay Kumar Banerjee wrote:
>>> > On Sun, Feb 2, 2020 at 9:49 PM Christian Mauderer
>>> mailto:l...@c-mauderer.de>
>>> > >> wrote:
>>> >     On 31/01/2020 17:43, Vijay Kumar Banerjee wrote:
>>> >     > On Fri, Jan 31, 2020 at 9:59 PM Christian Mauderer
>>> >     mailto:l...@c-mauderer.de>
>>> >
>>> >     > 
>>> >> >     >     On 31/01/2020 17:25, Christian Mauderer wrote:
>>> >     >     > On 31/01/2020 16:04, Vijay Kumar Banerjee wrote:
>>> >     >
>>> >     > How about rtemsbsd/sys/dts/arm/overlays ?
>>> >     > Following the freebsd tree freebsd/sys/dts/arm/overlays/
>>> >
>>> >     Following the FreeBSD tree is a good point. But would they be
>>> visible
>>> >     there? Beneath that: We currently don't have support for
>>> building the
>>> >     overlays. Do you have an idea how that could look like?
>>> >
>>> > keeping it visible will be a problem. For building the overlay, we can
>>> > use dtc
>>> > and add a script to build the overlay. I see that rsb has a build
>>> > package for
>>> > devel/dtc.bset as well.
>>>
>>> Hm. Optimal would be an integration into waf. Something like "waf
>>> fdt-overlay". Even better would be if we could build the original fdt
>>> too. But I'm sure that both would be quite a bit tricky to integrate
>>> (the waf scripts in libbsd are not really easy to understand). So I'm
>>> not insisting on that.
>>>
>>> Sounds like it can become a good small project. Do we want a ticket
>>> for this? 
>>
>> I think it's a bit too small for a GSoC project but it could be a
>> starting point for someone who wants to get knowledge about the libbsd
>> build system. So: Yes, a ticket sounds good.
> 
> The rtems-boot-image handles loading FDT files onto an SD card and I plan to 
> add
> overlay support when I find time to get back to this tool.
> 
> I am not sure if this is the right place to add what you are discussing. I 
> raise
> this because getting these files on to an SD card and having u-boot load them 
> is
> another issue so may be this tool can help solve this problem as well.
> 
> Chris
> 

Hello Chris,

thanks for your input. I'm still not entirely happy with the location
too. But I also don't know a better one. Currently I know of the
following necessary cases:

- Build a dtb from FreeBSD sources (or some other source).

- Build an overlay from some RTEMS source (for example: Using an i2c
adaption layer for libbsd instead of using the i2c hardware directly).

- For some targets with a simple bootloader that can only load one
device tree binary: Merge the overlays with the base tree.

The dts from FreeBSD could either be imported in libbsd or pulled from a
download (note: either many files for all dts, dtsi and headers or one
big file for the complete FreeBSD source tree). The overlays for RTEMS
are a bit less easy: There should be a place for them in RTEMS
somewhere. And I really don't know where would be a good one. Do you
have any suggestions?

Best regards

Christian
-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: About Beaglebone Black device tree

2020-02-10 Thread Chris Johns 

On 2020-02-10 19:18, Christian Mauderer wrote:


Hello Chris,

thanks for your input. I'm still not entirely happy with the location
too. But I also don't know a better one. Currently I know of the
following necessary cases:

- Build a dtb from FreeBSD sources (or some other source).

- Build an overlay from some RTEMS source (for example: Using an i2c
adaption layer for libbsd instead of using the i2c hardware directly).


Thank you the summary. I see the issue.


- For some targets with a simple bootloader that can only load one
device tree binary: Merge the overlays with the base tree.


OK. Can this be done in a tool like rtems-boot-image to merge them.


The dts from FreeBSD could either be imported in libbsd or pulled from a
download (note: either many files for all dts, dtsi and headers or one
big file for the complete FreeBSD source tree). The overlays for RTEMS
are a bit less easy: There should be a place for them in RTEMS
somewhere. And I really don't know where would be a good one. Do you
have any suggestions?


It is tricky.

I suppose FDT is used to describe the hardware and we should be using it 
in RTEMS for drivers. If we locate them outside the rtems.git repo it 
will create an awkward relationship. I agree we do need to capture them 
somehow.


I am not sure what we need to do to handle these files.

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

[PATCH] c-user: Document CONFIGURE_DIRTY_MEMORY

2020-02-10 Thread Sebastian Huber 
Close #3843.
---
 c-user/configuring_a_system.rst | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/c-user/configuring_a_system.rst b/c-user/configuring_a_system.rst
index 81bc9bb..00584c1 100644
--- a/c-user/configuring_a_system.rst
+++ b/c-user/configuring_a_system.rst
@@ -425,6 +425,38 @@ General System Configuration
 This section defines the general system configuration options supported by
 .
 
+.. index:: CONFIGURE_DIRTY_MEMORY
+
+.. _CONFIGURE_DIRTY_MEMORY:
+
+CONFIGURE_DIRTY_MEMORY
+--
+
+CONSTANT:
+``CONFIGURE_DIRTY_MEMORY``
+
+DATA TYPE:
+Boolean feature macro.
+
+RANGE:
+Defined or undefined.
+
+DEFAULT VALUE:
+By default, the memory used by the RTEMS Workspace and the C Program Heap
+is uninitialized memory.
+
+DESCRIPTION:
+This macro indicates whether RTEMS should dirty the memory used by the
+RTEMS Workspace and the C Program Heap as part of its initialization.  If
+defined, the memory areas are dirtied with a ``0xCF`` byte pattern.
+Otherwise, they are not.
+
+NOTES:
+Dirtying memory can add significantly to system boot time.  It may assist
+in finding code that assumes memory starts set to zero.  In case
+:ref:`CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY` is also defined, then the
+memory is first dirtied and then zeroed.
+
 .. index:: CONFIGURE_EXTRA_TASK_STACKS
 .. index:: memory for task tasks
 
@@ -1006,7 +1038,9 @@ DESCRIPTION:
 
 NOTES:
 Zeroing memory can add significantly to system boot time. It is not
-necessary for RTEMS but is often assumed by support libraries.
+necessary for RTEMS but is often assumed by support libraries.  In case
+:ref:`CONFIGURE_DIRTY_MEMORY` is also defined, then the memory is first
+dirtied and then zeroed.
 
 Classic API Configuration
 =
-- 
2.16.4

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

[PATCH 4/7] bsp/imx: Use muxed mode for serials.

2020-02-10 Thread Christian Mauderer 
Update #3869.
---
 bsps/arm/imx/console/console-config.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bsps/arm/imx/console/console-config.c 
b/bsps/arm/imx/console/console-config.c
index 04bec993ae..caebc6bc39 100644
--- a/bsps/arm/imx/console/console-config.c
+++ b/bsps/arm/imx/console/console-config.c
@@ -253,6 +253,7 @@ static bool imx_uart_first_open(
   regs->ucr1 = IMX_UART_UCR1_UARTEN;
   regs->ucr2 = IMX_UART_UCR2_IRTS | IMX_UART_UCR2_WS | IMX_UART_UCR2_RXEN
 | IMX_UART_UCR2_TXEN | IMX_UART_UCR2_SRST;
+  regs->ucr3 |= IMX_UART_UCR3_ADNIMP | IMX_UART_UCR3_RXDMUXSEL;
 
   rtems_termios_set_initial_baud(tty, 115200);
   imx_uart_set_attributes(base, term);
-- 
2.16.4

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

[PATCH 7/7] bsp/imx: Parse fdt pinctrl values and setup iomux

2020-02-10 Thread Christian Mauderer 
Update #3869.
---
 bsps/arm/imx/start/imx_iomux.c | 44 ++
 1 file changed, 44 insertions(+)

diff --git a/bsps/arm/imx/start/imx_iomux.c b/bsps/arm/imx/start/imx_iomux.c
index f6235d3cf4..d97e35deef 100644
--- a/bsps/arm/imx/start/imx_iomux.c
+++ b/bsps/arm/imx/start/imx_iomux.c
@@ -109,6 +109,47 @@ static struct iomux_softc iomux_sc_instance;
 
 #define iomux_sc (&iomux_sc_instance);
 
+/* Return true if there is no status or status is "okay" or "ok". */
+static bool
+imx_fdt_node_status_okay(const void *fdt, int node)
+{
+   const void *status;
+   int len;
+
+   status = fdt_getprop(fdt, node, "status", &len);
+   if ((status == NULL) ||
+   (strncmp(status, "okay", MIN(5, len)) == 0) ||
+   (strncmp(status, "ok", MIN(3, len)) == 0)) {
+   return true;
+   }
+
+   return false;
+}
+
+/*
+ * Walk through all subnodes and handle "pinctrl-0" if the node is enabled. 
This
+ * does roughly the same as FreeBSDs fdt_pinctrl_configure_tree but without the
+ * whole open firmware (OF*) functions.
+ */
+static void
+imx_pinctrl_configure_children(const void *fdt, int parent)
+{
+   int node;
+   const uint32_t *phandle;
+   int len;
+
+   fdt_for_each_subnode(node, fdt, parent) {
+   if (imx_fdt_node_status_okay(fdt, node)) {
+   imx_pinctrl_configure_children(fdt, node);
+   phandle = fdt_getprop(fdt, node, "pinctrl-0", &len);
+   if (phandle != NULL && len == sizeof(*phandle)) {
+   imx_iomux_configure_pins(fdt,
+   fdt32_to_cpu(*phandle));
+   }
+   }
+   }
+}
+
 static void
 imx_iomux_init(void)
 {
@@ -124,6 +165,9 @@ imx_iomux_init(void)
}
sc = iomux_sc;
sc->regs = imx_get_reg_of_node(fdt, node);
+
+   node = fdt_path_offset(fdt, "/");
+   imx_pinctrl_configure_children(fdt, node);
 }
 
 RTEMS_SYSINIT_ITEM(imx_iomux_init, RTEMS_SYSINIT_BSP_START,
-- 
2.16.4

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

[PATCH 1/7] bsp/imx: Avoid hard-coded GIC base address

2020-02-10 Thread Christian Mauderer 
From: Sebastian Huber 

Update #3869.
---
 bsps/arm/imx/include/bsp.h|  6 --
 bsps/arm/imx/start/bspstart.c | 11 +++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/bsps/arm/imx/include/bsp.h b/bsps/arm/imx/include/bsp.h
index 4ed35c68fe..134b3fd858 100644
--- a/bsps/arm/imx/include/bsp.h
+++ b/bsps/arm/imx/include/bsp.h
@@ -47,9 +47,11 @@
 extern "C" {
 #endif /* __cplusplus */
 
-#define BSP_ARM_GIC_DIST_BASE 0x31001000
+extern uintptr_t imx_gic_dist_base;
 
-#define BSP_ARM_GIC_CPUIF_BASE 0x31002000
+#define BSP_ARM_GIC_DIST_BASE imx_gic_dist_base
+
+#define BSP_ARM_GIC_CPUIF_BASE (BSP_ARM_GIC_DIST_BASE + 0x1000)
 
 #define BSP_ARM_A9MPCORE_GT_BASE 0
 
diff --git a/bsps/arm/imx/start/bspstart.c b/bsps/arm/imx/start/bspstart.c
index 046336655b..3a87c437d2 100644
--- a/bsps/arm/imx/start/bspstart.c
+++ b/bsps/arm/imx/start/bspstart.c
@@ -82,8 +82,19 @@ void arm_generic_timer_get_config(
   *irq = imx_get_irq_of_node(fdt, node, 0) - 16;
 }
 
+uintptr_t imx_gic_dist_base;
+
+static void imx_find_gic(const void *fdt)
+{
+  int node;
+
+  node = fdt_path_offset(fdt, "/interrupt-controller");
+  imx_gic_dist_base = (uintptr_t) imx_get_reg_of_node(fdt, node);
+}
+
 void bsp_start(void)
 {
+  imx_find_gic(bsp_fdt_get());
   bsp_interrupt_initialize();
   rtems_cache_coherent_add_area(
 bsp_section_nocacheheap_begin,
-- 
2.16.4

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

[PATCH 0/7] bsp/imx: Add support for i.MX6UL

2020-02-10 Thread Christian Mauderer 
Hello,

this is a first patch set to allow the imx-BSP to support i.MX6UL as
well as i.MX7. Note that the support isn't complete yet. But Peter
want's to work on the BSP too and therefore I try to commit them early
so that we don't have double work and merge conflicts.

Best regards

Christian

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

[PATCH 6/7] bsp/imx: Support imx6ul iomux.

2020-02-10 Thread Christian Mauderer 
Update #3869.
---
 bsps/arm/imx/start/imx_iomux.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/bsps/arm/imx/start/imx_iomux.c b/bsps/arm/imx/start/imx_iomux.c
index cd4591fa6f..f6235d3cf4 100644
--- a/bsps/arm/imx/start/imx_iomux.c
+++ b/bsps/arm/imx/start/imx_iomux.c
@@ -118,6 +118,10 @@ imx_iomux_init(void)
 
fdt = bsp_fdt_get();
node = fdt_node_offset_by_compatible(fdt, -1, "fsl,imx7d-iomuxc");
+   if (node < 0) {
+   node = fdt_node_offset_by_compatible(fdt, -1,
+   "fsl,imx6ul-iomuxc");
+   }
sc = iomux_sc;
sc->regs = imx_get_reg_of_node(fdt, node);
 }
-- 
2.16.4

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

[PATCH 2/7] bsp/imx: Allow GIC in different device tree node.

2020-02-10 Thread Christian Mauderer 
Update #3869.
---
 bsps/arm/imx/start/bspstart.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/bsps/arm/imx/start/bspstart.c b/bsps/arm/imx/start/bspstart.c
index 3a87c437d2..36f62993a6 100644
--- a/bsps/arm/imx/start/bspstart.c
+++ b/bsps/arm/imx/start/bspstart.c
@@ -89,6 +89,9 @@ static void imx_find_gic(const void *fdt)
   int node;
 
   node = fdt_path_offset(fdt, "/interrupt-controller");
+  if (node < 0) {
+node = fdt_path_offset(fdt, "/soc/interrupt-controller");
+  }
   imx_gic_dist_base = (uintptr_t) imx_get_reg_of_node(fdt, node);
 }
 
-- 
2.16.4

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

[PATCH 5/7] bsp/imx: Allow gapless SPI transfers.

2020-02-10 Thread Christian Mauderer 
This uses the tx-threshold to reduce gaps in SPI transmissions.

Update #3869.
---
 bsps/arm/imx/spi/imx-ecspi.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/bsps/arm/imx/spi/imx-ecspi.c b/bsps/arm/imx/spi/imx-ecspi.c
index 9a232c53e9..4c4978cdac 100644
--- a/bsps/arm/imx/spi/imx-ecspi.c
+++ b/bsps/arm/imx/spi/imx-ecspi.c
@@ -174,12 +174,14 @@ static void imx_ecspi_config(
   uint32_t conreg;
   uint32_t testreg;
   uint32_t configreg;
+  uint32_t dmareg;
   uint32_t cs_bit;
 
   conreg = IMX_ECSPI_CONREG_CHANNEL_MODE(0xf)
 | IMX_ECSPI_CONREG_SMC | IMX_ECSPI_CONREG_EN;
   testreg = regs->testreg;
   configreg = regs->configreg;
+  dmareg = regs->dmareg;
   cs_bit = 1U << cs;
 
   conreg |= imx_ecspi_conreg_divider(bus, speed_hz);
@@ -213,8 +215,11 @@ static void imx_ecspi_config(
 testreg &= ~IMX_ECSPI_TESTREG_LBC;
   }
 
+  dmareg = IMX_ECSPI_DMAREG_TX_THRESHOLD_SET(dmareg, IMX_ECSPI_FIFO_SIZE/2);
+
   regs->conreg = conreg;
   regs->testreg = testreg;
+  regs->dmareg = dmareg;
   regs->configreg = configreg;
 
   bus->conreg = conreg;
@@ -287,7 +292,7 @@ static void imx_ecspi_next_msg(imx_ecspi_bus *bus, volatile 
imx_ecspi *regs)
 bus->tx_buf = msg->tx_buf;
 imx_ecspi_set_push_pop(bus, msg->len, msg->bits_per_word);
 imx_ecspi_push(bus, regs);
-regs->intreg = IMX_ECSPI_TE;
+regs->intreg = IMX_ECSPI_TE | IMX_ECSPI_TDR;
   } else {
 regs->intreg = 0;
 imx_ecspi_done(bus);
-- 
2.16.4

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

[PATCH 3/7] bsp/imx: Increase device memory area

2020-02-10 Thread Christian Mauderer 
From: Sebastian Huber 

The new area is used by the i.MX 6UltraLite for example.

Update #3869.
---
 bsps/arm/imx/start/bspstarthooks.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsps/arm/imx/start/bspstarthooks.c 
b/bsps/arm/imx/start/bspstarthooks.c
index 868da5a192..d35374e360 100644
--- a/bsps/arm/imx/start/bspstarthooks.c
+++ b/bsps/arm/imx/start/bspstarthooks.c
@@ -30,7 +30,7 @@ BSP_START_DATA_SECTION static arm_cp15_start_section_config
 imx_mmu_config_table[] = {
   ARMV7_CP15_START_DEFAULT_SECTIONS,
   {
-.begin = 0x0700U,
+.begin = 0x00a0U,
 .end = 0x7000U,
 .flags = ARMV7_MMU_DEVICE
   }
-- 
2.16.4

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

Re: About Beaglebone Black device tree

2020-02-10 Thread Christian Mauderer 
On 10/02/2020 10:24, Chris Johns wrote:
> On 2020-02-10 19:18, Christian Mauderer wrote:
>>
>> Hello Chris,
>>
>> thanks for your input. I'm still not entirely happy with the location
>> too. But I also don't know a better one. Currently I know of the
>> following necessary cases:
>>
>> - Build a dtb from FreeBSD sources (or some other source).
>>
>> - Build an overlay from some RTEMS source (for example: Using an i2c
>> adaption layer for libbsd instead of using the i2c hardware directly).
> 
> Thank you the summary. I see the issue.
> 
>> - For some targets with a simple bootloader that can only load one
>> device tree binary: Merge the overlays with the base tree.
> 
> OK. Can this be done in a tool like rtems-boot-image to merge them.
> 
>> The dts from FreeBSD could either be imported in libbsd or pulled from a
>> download (note: either many files for all dts, dtsi and headers or one
>> big file for the complete FreeBSD source tree). The overlays for RTEMS
>> are a bit less easy: There should be a place for them in RTEMS
>> somewhere. And I really don't know where would be a good one. Do you
>> have any suggestions?
> 
> It is tricky.
> 
> I suppose FDT is used to describe the hardware and we should be using it
> in RTEMS for drivers. If we locate them outside the rtems.git repo it
> will create an awkward relationship. I agree we do need to capture them
> somehow.
> 
> I am not sure what we need to do to handle these files.

Same problem here. What makes it worse is that there can be a dependency
between the libbsd version, RTEMS version and device tree files. So it's
three parts that have dependencies.

In the past discussions my approach was to document "use fdt from
FreeBSD in the same version as libbsd and use this overlay" (for example
I suggested that for last years GSoC project). But sooner or later that
won't work anymore. And it's definitively not automation friendly.

Best regards

Christian

> 
> Chris

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3 0/3] [rtems-libbsd] Fix compilation fo i386

2020-02-10 Thread Sebastian Huber 

Hello Jan,

thanks for the patch set. I checked it in with some white space 
corrections. It is important to not change white space in the original 
FreeBSD code to avoid merge conflicts during updates.


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

Re: About Beaglebone Black device tree

2020-02-10 Thread Vijay Kumar Banerjee 
On Sun, Feb 9, 2020 at 4:03 PM Christian Mauderer 
wrote:

>
> > Hi!
> >
> > I looked into it in more detail, the issue isn't with the overlay, I
> > verified it
> > using u-boot fdt tool as well. Looks like the base dts file is producing
> > a lot
> > of "target-module" and during startup, the driver probes are looping over
> > these target modules for the device tree values instead of looking at the
> > device node under the target module.
> >
> > For example, in case of i2c the device tree looks like this:
> > ```
> > target-module@b000 {
> > status = "okay";
> > compatible = "ti,sysc-omap2\0ti,sysc";
> > 
> >
> > i2c@0 {
> > rtems-pinctrl-0 = < 0x2e >;
> > rtems,i2c-path = "/dev/i2c-0";
> > compatible = "rtems,bsp-i2c\0ti,omap4-i2c";
> > .
> > ```
> >
> > In the above snippet, the probe function expects the compat value to be
> > "rtems,bsp-i2c" but is getting "ti,sysc-omap2" from the target-module
> > and returning ENXIO. This is true for all the values, not just compat.
> >
> > When I added all the required values of i2c into the target-module
> through
> > overlay, the iicbus worked. As you said in the thread, looks like i2c
> > isn't the
> > only device that's affected looks like a lot of devices are failing
> > because of
> > this dts issue. Here's a dump
> >  of start messages
> > after applying the overlay
> > hack for i2c and lcd probe. (Note that this is an issue with the
> > tda19988 as well,
> > because of which framebuffer isn't working)
>
> Did something in the FreeBSD device tree sources change to cause that
> issue?
>

The FreeBSD device tree was updated with the DTS from Linux 5.0 in
this commit: 1b4c7d421757 . This changed the structure of the device tree
and the issue is coming up since this commit.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: About Beaglebone Black device tree

2020-02-10 Thread Christian Mauderer 
On 10/02/2020 10:58, Vijay Kumar Banerjee wrote:
> On Sun, Feb 9, 2020 at 4:03 PM Christian Mauderer  > wrote:
> 
> 
> > Hi!
> >
> > I looked into it in more detail, the issue isn't with the overlay, I
> > verified it
> > using u-boot fdt tool as well. Looks like the base dts file is
> producing
> > a lot
> > of "target-module" and during startup, the driver probes are
> looping over
> > these target modules for the device tree values instead of looking
> at the
> > device node under the target module.
> >
> > For example, in case of i2c the device tree looks like this:
> > ```
> >                 target-module@b000 {
> >                     status = "okay";
> >                     compatible = "ti,sysc-omap2\0ti,sysc";
> >                     
> >
> >                     i2c@0 {
> >                         rtems-pinctrl-0 = < 0x2e >;
> >                         rtems,i2c-path = "/dev/i2c-0";
> >                         compatible = "rtems,bsp-i2c\0ti,omap4-i2c";
> >                         .
> > ```
> >
> > In the above snippet, the probe function expects the compat value
> to be
> > "rtems,bsp-i2c" but is getting "ti,sysc-omap2" from the target-module
> > and returning ENXIO. This is true for all the values, not just compat.
> >
> > When I added all the required values of i2c into the target-module
> through
> > overlay, the iicbus worked. As you said in the thread, looks like i2c
> > isn't the
> > only device that's affected looks like a lot of devices are failing
> > because of
> > this dts issue. Here's a dump
> >  of start messages
> > after applying the overlay
> > hack for i2c and lcd probe. (Note that this is an issue with the
> > tda19988 as well,
> > because of which framebuffer isn't working)
> 
> Did something in the FreeBSD device tree sources change to cause
> that issue?
> 
> 
> The FreeBSD device tree was updated with the DTS from Linux 5.0 in
> this commit: 1b4c7d421757 . This changed the structure of the device tree
> and the issue is coming up since this commit.

Sorry: I asked the wrong question. It's quite clear that the DTS
changed. But it sounds like FreeBSD should have the same problems,
shouldn't they? So I'm a bit astonished that the drivers haven't been
adapted. Is there something that we missed during an update or would you
expect that FreeBSD in that version don't work either?

Best regards

Christian
-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Watch Solar Orbiter Launch

2020-02-10 Thread Gedare Bloom 
Maybe ask on users@

On Sun, Feb 9, 2020 at 9:44 PM Joel Sherrill  wrote:
>
> And it looks like the launch went well. Let's keep an eye on the mission.
>
> Still hoping for more information on it.
>
> --joel
>
> On Sun, Feb 9, 2020, 9:17 PM Vaibhav Gupta  wrote:
>>
>> This is very exciting!
>>
>> --Vaibhav
>>
>> On Mon, Feb 10, 2020, 8:32 AM Joel Sherrill  wrote:
>>>
>>> Hi
>>>
>>> If all goes well, the Solar Orbiter will launch late tonight New York time 
>>> or early Monday Europe time.
>>>
>>> https://www.space.com/solar-orbiter-cygnus-ng-13-rocket-launch-double-header-webcasts.html
>>>
>>> This has RTEMS based software onboard and I am hoping that someone from one 
>>> of those projects can share some details.
>>>
>>> Congratulations!
>>>
>>> --joel
>>>
>>> ___
>>> 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 0/7] bsp/imx: Add support for i.MX6UL

2020-02-10 Thread dufault 



> On Feb 10, 2020, at 04:35 , Christian Mauderer 
>  wrote:
> 
> Hello,
> 
> this is a first patch set to allow the imx-BSP to support i.MX6UL as
> well as i.MX7. Note that the support isn't complete yet. But Peter
> want's to work on the BSP too and therefore I try to commit them early
> so that we don't have double work and merge conflicts.
> 
> Best regards
> 
> Christian
> 

Thank you, Christian.

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering

This email is delivered through the public internet using protocols subject to 
interception and tampering.

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

Re: [PATCH] c-user: Document CONFIGURE_DIRTY_MEMORY

2020-02-10 Thread Gedare Bloom 
Looks good, thank you

On Mon, Feb 10, 2020 at 2:32 AM Sebastian Huber
 wrote:
>
> Close #3843.
> ---
>  c-user/configuring_a_system.rst | 36 +++-
>  1 file changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/c-user/configuring_a_system.rst b/c-user/configuring_a_system.rst
> index 81bc9bb..00584c1 100644
> --- a/c-user/configuring_a_system.rst
> +++ b/c-user/configuring_a_system.rst
> @@ -425,6 +425,38 @@ General System Configuration
>  This section defines the general system configuration options supported by
>  .
>
> +.. index:: CONFIGURE_DIRTY_MEMORY
> +
> +.. _CONFIGURE_DIRTY_MEMORY:
> +
> +CONFIGURE_DIRTY_MEMORY
> +--
> +
> +CONSTANT:
> +``CONFIGURE_DIRTY_MEMORY``
> +
> +DATA TYPE:
> +Boolean feature macro.
> +
> +RANGE:
> +Defined or undefined.
> +
> +DEFAULT VALUE:
> +By default, the memory used by the RTEMS Workspace and the C Program Heap
> +is uninitialized memory.
> +
> +DESCRIPTION:
> +This macro indicates whether RTEMS should dirty the memory used by the
> +RTEMS Workspace and the C Program Heap as part of its initialization.  If
> +defined, the memory areas are dirtied with a ``0xCF`` byte pattern.
> +Otherwise, they are not.
> +
> +NOTES:
> +Dirtying memory can add significantly to system boot time.  It may assist
> +in finding code that assumes memory starts set to zero.  In case
> +:ref:`CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY` is also defined, then the
> +memory is first dirtied and then zeroed.
> +
>  .. index:: CONFIGURE_EXTRA_TASK_STACKS
>  .. index:: memory for task tasks
>
> @@ -1006,7 +1038,9 @@ DESCRIPTION:
>
>  NOTES:
>  Zeroing memory can add significantly to system boot time. It is not
> -necessary for RTEMS but is often assumed by support libraries.
> +necessary for RTEMS but is often assumed by support libraries.  In case
> +:ref:`CONFIGURE_DIRTY_MEMORY` is also defined, then the memory is first
> +dirtied and then zeroed.
>
>  Classic API Configuration
>  =
> --
> 2.16.4
>
> ___
> 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 1/2] eng: Document test framework formatted output

2020-02-10 Thread Gedare Bloom 
On Sun, Feb 9, 2020 at 3:20 AM Sebastian Huber
 wrote:
>
> Update #3199.
> ---
>  eng/test-framework.rst | 30 +++---
>  1 file changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/eng/test-framework.rst b/eng/test-framework.rst
> index 50745df..6380f7e 100644
> --- a/eng/test-framework.rst
> +++ b/eng/test-framework.rst
> @@ -982,10 +982,10 @@ fails.
>  P:0:0:UI1:test-psx.c:13
>  E:stat:N:1:F:0
>
> -Custom Log Messages
> 
> +Log Messages and Formatted Output
> +-
>
> -You can print custom log messages with the `T_log()` function:
> +You can print log messages with the `T_log()` function:
>
>  .. code-block:: c
>
> @@ -994,24 +994,40 @@ You can print custom log messages with the `T_log()` 
> function:
>  A newline is automatically added to terminate the log message line.
>
>  .. code-block:: c
> -:caption: Custom Log Message Example
> +:caption: Log Message Example
>
>  #include 
>
>  T_TEST_CASE(log)
>  {
> -T_log(T_NORMAL, "a custom message %i, %i, %i", 1, 2, 3);
> +T_log(T_NORMAL, "a log message %i, %i, %i", 1, 2, 3);
>  T_set_verbosity(T_QUIET);
>  T_log(T_NORMAL, "not verbose enough");
>  }
>
>  .. code-block:: none
> -:caption: Custom Log Message Report
> +:caption: Log Message Report
>
>  B:log
> -L:a custom message 1, 2, 3
> +L:a log message 1, 2, 3
>  E:log:N:0:F:0
>
> +You can use the following functions to print formatted output:
> +
> +.. code-block:: c
> +
> +int T_printf(char const *, ...);
> +
> +int T_vprintf(char const *, va_list);
> +
> +int T_snprintf(char *, size_t, const char *, ...);
> +
> +In contrast to the corresponding standard C library functions, floating-point
> +and exotic formats may be not supported.  On some architectures supported by

Minor English grammar: "may not be" is the correct way to express the
possibility something is not.

"may be not" is used infrequently and implies certainty something is
not, usually combined with a contrasting statement, e.g., "Exotic
formats may be not supported, but primitive C types will work." Again,
this is a rare grammatical form; one would usually say "are not" in
these cases.


> +RTEMS, floating-point operations are only supported in special tasks and may 
> be
> +forbidden in interrupt context.  These formatted output functions work in 
> every
> +context.
> +
>  Time Services
>  -
>
> --
> 2.16.4
>
> ___
> 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 0/7] bsp/imx: Add support for i.MX6UL

2020-02-10 Thread Gedare Bloom 
It's all in bsps*imx. Go ahead.

On Mon, Feb 10, 2020 at 2:35 AM Christian Mauderer
 wrote:
>
> Hello,
>
> this is a first patch set to allow the imx-BSP to support i.MX6UL as
> well as i.MX7. Note that the support isn't complete yet. But Peter
> want's to work on the BSP too and therefore I try to commit them early
> so that we don't have double work and merge conflicts.
>
> Best regards
>
> Christian
>
> ___
> 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 1/2] eng: Document test framework formatted output

2020-02-10 Thread Sebastian Huber 

Hello Gedare,

On 10/02/2020 13:39, Gedare Bloom wrote:

+In contrast to the corresponding standard C library functions, floating-point
+and exotic formats may be not supported.  On some architectures supported by

Minor English grammar: "may not be" is the correct way to express the
possibility something is not.

"may be not" is used infrequently and implies certainty something is
not, usually combined with a contrasting statement, e.g., "Exotic
formats may be not supported, but primitive C types will work." Again,
this is a rare grammatical form; one would usually say "are not" in
these cases.

thanks for the review. I hopefully fixed it.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: About Beaglebone Black device tree

2020-02-10 Thread Vijay Kumar Banerjee 
On Mon, Feb 10, 2020 at 5:21 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> On 10/02/2020 10:58, Vijay Kumar Banerjee wrote:
> > On Sun, Feb 9, 2020 at 4:03 PM Christian Mauderer  > > wrote:
> >
> >
> > > Hi!
> > >
> > > I looked into it in more detail, the issue isn't with the overlay,
> I
> > > verified it
> > > using u-boot fdt tool as well. Looks like the base dts file is
> > producing
> > > a lot
> > > of "target-module" and during startup, the driver probes are
> > looping over
> > > these target modules for the device tree values instead of looking
> > at the
> > > device node under the target module.
> > >
> > > For example, in case of i2c the device tree looks like this:
> > > ```
> > > target-module@b000 {
> > > status = "okay";
> > > compatible = "ti,sysc-omap2\0ti,sysc";
> > > 
> > >
> > > i2c@0 {
> > > rtems-pinctrl-0 = < 0x2e >;
> > > rtems,i2c-path = "/dev/i2c-0";
> > > compatible = "rtems,bsp-i2c\0ti,omap4-i2c";
> > > .
> > > ```
> > >
> > > In the above snippet, the probe function expects the compat value
> > to be
> > > "rtems,bsp-i2c" but is getting "ti,sysc-omap2" from the
> target-module
> > > and returning ENXIO. This is true for all the values, not just
> compat.
> > >
> > > When I added all the required values of i2c into the target-module
> > through
> > > overlay, the iicbus worked. As you said in the thread, looks like
> i2c
> > > isn't the
> > > only device that's affected looks like a lot of devices are failing
> > > because of
> > > this dts issue. Here's a dump
> > >  of start
> messages
> > > after applying the overlay
> > > hack for i2c and lcd probe. (Note that this is an issue with the
> > > tda19988 as well,
> > > because of which framebuffer isn't working)
> >
> > Did something in the FreeBSD device tree sources change to cause
> > that issue?
> >
> >
> > The FreeBSD device tree was updated with the DTS from Linux 5.0 in
> > this commit: 1b4c7d421757 . This changed the structure of the device tree
> > and the issue is coming up since this commit.
>
> Sorry: I asked the wrong question. It's quite clear that the DTS
> changed. But it sounds like FreeBSD should have the same problems,
> shouldn't they? So I'm a bit astonished that the drivers haven't been
> adapted. Is there something that we missed during an update or would you
> expect that FreeBSD in that version don't work either?
>
> Best regards
>
> Christian
> --
> 
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> PGP: Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: About Beaglebone Black device tree

2020-02-10 Thread Vijay Kumar Banerjee 
On Mon, Feb 10, 2020 at 9:43 PM Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

>
>
> On Mon, Feb 10, 2020 at 5:21 PM Christian Mauderer <
> christian.maude...@embedded-brains.de> wrote:
>
>> On 10/02/2020 10:58, Vijay Kumar Banerjee wrote:
>> > On Sun, Feb 9, 2020 at 4:03 PM Christian Mauderer > > > wrote:
>> >
>> >
>> > > Hi!
>> > >
>> > > I looked into it in more detail, the issue isn't with the
>> overlay, I
>> > > verified it
>> > > using u-boot fdt tool as well. Looks like the base dts file is
>> > producing
>> > > a lot
>> > > of "target-module" and during startup, the driver probes are
>> > looping over
>> > > these target modules for the device tree values instead of looking
>> > at the
>> > > device node under the target module.
>> > >
>> > > For example, in case of i2c the device tree looks like this:
>> > > ```
>> > > target-module@b000 {
>> > > status = "okay";
>> > > compatible = "ti,sysc-omap2\0ti,sysc";
>> > > 
>> > >
>> > > i2c@0 {
>> > > rtems-pinctrl-0 = < 0x2e >;
>> > > rtems,i2c-path = "/dev/i2c-0";
>> > > compatible =
>> "rtems,bsp-i2c\0ti,omap4-i2c";
>> > > .
>> > > ```
>> > >
>> > > In the above snippet, the probe function expects the compat value
>> > to be
>> > > "rtems,bsp-i2c" but is getting "ti,sysc-omap2" from the
>> target-module
>> > > and returning ENXIO. This is true for all the values, not just
>> compat.
>> > >
>> > > When I added all the required values of i2c into the target-module
>> > through
>> > > overlay, the iicbus worked. As you said in the thread, looks like
>> i2c
>> > > isn't the
>> > > only device that's affected looks like a lot of devices are
>> failing
>> > > because of
>> > > this dts issue. Here's a dump
>> > >  of start
>> messages
>> > > after applying the overlay
>> > > hack for i2c and lcd probe. (Note that this is an issue with the
>> > > tda19988 as well,
>> > > because of which framebuffer isn't working)
>> >
>> > Did something in the FreeBSD device tree sources change to cause
>> > that issue?
>> >
>> >
>> > The FreeBSD device tree was updated with the DTS from Linux 5.0 in
>> > this commit: 1b4c7d421757 . This changed the structure of the device
>> tree
>> > and the issue is coming up since this commit.
>>
>> Sorry: I asked the wrong question. It's quite clear that the DTS
>> changed. But it sounds like FreeBSD should have the same problems,
>> shouldn't they? So I'm a bit astonished that the drivers haven't been
>> adapted. Is there something that we missed during an update or would you
>> expect that FreeBSD in that version don't work either?
>>
>> Saying without checking with the FreeBSD build:
Looks like the fdt drivers should be looking for the child of the
target-module
node, instead of the the target-module, I have checked this approach with an
overlay hack where I modified the target-module to have all the
device-related
values. The issue is from the FDT framework it seems. I'm not sure if the
issue
is from our side or not but I suspect that the FreeBSD build of the same
version
will not work either, I couldn't verify this because of slow downloads.

> Best regards
>>
>> Christian
>> --
>> 
>> embedded brains GmbH
>> Herr Christian Mauderer
>> Dornierstr. 4
>> D-82178 Puchheim
>> Germany
>> email: christian.maude...@embedded-brains.de
>> Phone: +49-89-18 94 741 - 18
>> Fax:   +49-89-18 94 741 - 08
>> PGP: Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-docs PATCH v2] user/testing: Add coverage analysis instructions

2020-02-10 Thread Christian Mauderer 
On 07/02/2020 18:29, Vijay Kumar Banerjee wrote:
> 
> 
> 
> On Tue, Feb 4, 2020 at 5:41 AM Chris Johns  > wrote:
> 
> On 4/2/20 10:26 am, Gedare Bloom wrote:
> > looks OK to me.
> 
> +1 from me.
> 
> Thanks
> Chris
> 
> 
> Thanks for the reviews! Can you please push this :)
> 

Hello Vijay,

Gedare and Chris acknowledged it. I tested it and it builds fine. So I
pushed it. Thanks for the contribution.

Best regards

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

[PATCH 1/2] rtems/5: Update to gdb-9.1

2020-02-10 Thread chrisj 
From: Chris Johns 

- This version fixes build issues on Windows (MinGW64)
---
 rtems/config/5/rtems-default.bset  |  2 +-
 rtems/config/tools/rtems-gdb-9.1-1.cfg | 12 
 2 files changed, 13 insertions(+), 1 deletion(-)
 create mode 100644 rtems/config/tools/rtems-gdb-9.1-1.cfg

diff --git a/rtems/config/5/rtems-default.bset 
b/rtems/config/5/rtems-default.bset
index 97c4ede..9f74502 100644
--- a/rtems/config/5/rtems-default.bset
+++ b/rtems/config/5/rtems-default.bset
@@ -15,7 +15,7 @@
 #
 
 devel/expat-2.1.0-1
-tools/rtems-gdb-8.3-1
+tools/rtems-gdb-9.1-1
 
 tools/rtems-binutils-2.33.1
 tools/rtems-gcc-7.5.0-newlib-d14714c69
diff --git a/rtems/config/tools/rtems-gdb-9.1-1.cfg 
b/rtems/config/tools/rtems-gdb-9.1-1.cfg
new file mode 100644
index 000..fe4b511
--- /dev/null
+++ b/rtems/config/tools/rtems-gdb-9.1-1.cfg
@@ -0,0 +1,12 @@
+#
+# GDB 9.1
+#
+
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+%define gdb_version 9.1
+%define gdb_src_ext xz
+#%hash sha512 gdb-%{gdb_version}.tar.xz 
47ac074d20a09a3fac8f4a41dce0a0cbe6ef702f7dc21ba8b7d650d306128dcae481e9a16bf65e596b3a541dc82ae57c02bcbb786d551b4ef3e2917b9b6f0ae1
+
+%include %{_configdir}/gdb-common-1.cfg
-- 
2.24.0

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

[PATCH 2/2] windows: Use GNU tar to unpack source

2020-02-10 Thread chrisj 
From: Chris Johns 

- The bsdtar command does not handle symlinks cleanly, GNU tar does

Closes #3868
---
 source-builder/sb/windows.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source-builder/sb/windows.py b/source-builder/sb/windows.py
index 199a6b8..1eb51a0 100644
--- a/source-builder/sb/windows.py
+++ b/source-builder/sb/windows.py
@@ -127,7 +127,7 @@ def load():
 '__rm':  ('exe', 'required', 'rm'),
 '__sed': ('exe', 'required', 'sed'),
 '__sh':  ('exe', 'required', 'sh'),
-'__tar': ('exe', 'required', 'bsdtar'),
+'__tar': ('exe', 'required', 'tar'),
 '__touch':   ('exe', 'required', 'touch'),
 '__unzip':   ('exe', 'required', 'unzip'),
 '__xz':  ('exe', 'required', 'xz'),
-- 
2.24.0

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

Re: [PATCH 0/7] bsp/imx: Add support for i.MX6UL

2020-02-10 Thread Chris Johns 
On 10/2/20 11:45 pm, Gedare Bloom wrote:
> It's all in bsps*imx. Go ahead.

+1

> 
> On Mon, Feb 10, 2020 at 2:35 AM Christian Mauderer
>  wrote:
>>
>> Hello,
>>
>> this is a first patch set to allow the imx-BSP to support i.MX6UL as
>> well as i.MX7. Note that the support isn't complete yet. But Peter
>> want's to work on the BSP too and therefore I try to commit them early
>> so that we don't have double work and merge conflicts.
>>
>> Best regards
>>
>> Christian
>>
>> ___
>> 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] c-user: Document CONFIGURE_DIRTY_MEMORY

2020-02-10 Thread Chris Johns 



On 10/2/20 8:32 pm, Sebastian Huber wrote:
> Close #3843.
> ---
>  c-user/configuring_a_system.rst | 36 +++-
>  1 file changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/c-user/configuring_a_system.rst b/c-user/configuring_a_system.rst
> index 81bc9bb..00584c1 100644
> --- a/c-user/configuring_a_system.rst
> +++ b/c-user/configuring_a_system.rst
> @@ -425,6 +425,38 @@ General System Configuration
>  This section defines the general system configuration options supported by
>  .
>  
> +.. index:: CONFIGURE_DIRTY_MEMORY
> +
> +.. _CONFIGURE_DIRTY_MEMORY:
> +
> +CONFIGURE_DIRTY_MEMORY
> +--
> +
> +CONSTANT:
> +``CONFIGURE_DIRTY_MEMORY``
> +
> +DATA TYPE:
> +Boolean feature macro.
> +
> +RANGE:
> +Defined or undefined.
> +
> +DEFAULT VALUE:
> +By default, the memory used by the RTEMS Workspace and the C Program Heap
> +is uninitialized memory.
> +
> +DESCRIPTION:
> +This macro indicates whether RTEMS should dirty the memory used by the
> +RTEMS Workspace and the C Program Heap as part of its initialization.  If
> +defined, the memory areas are dirtied with a ``0xCF`` byte pattern.
> +Otherwise, they are not.
> +
> +NOTES:
> +Dirtying memory can add significantly to system boot time.  It may assist
> +in finding code that assumes memory starts set to zero.  In case

.. "assumes memory starts set to zero" does not look right to me?

Chris

> +:ref:`CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY` is also defined, then the
> +memory is first dirtied and then zeroed.
> +
>  .. index:: CONFIGURE_EXTRA_TASK_STACKS
>  .. index:: memory for task tasks
>  
> @@ -1006,7 +1038,9 @@ DESCRIPTION:
>  
>  NOTES:
>  Zeroing memory can add significantly to system boot time. It is not
> -necessary for RTEMS but is often assumed by support libraries.
> +necessary for RTEMS but is often assumed by support libraries.  In case
> +:ref:`CONFIGURE_DIRTY_MEMORY` is also defined, then the memory is first
> +dirtied and then zeroed.
>  
>  Classic API Configuration
>  =
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] c-user: Document CONFIGURE_DIRTY_MEMORY

2020-02-10 Thread Gedare Bloom 
On Mon, Feb 10, 2020 at 2:14 PM Chris Johns  wrote:
>
>
>
> On 10/2/20 8:32 pm, Sebastian Huber wrote:
> > Close #3843.
> > ---
> >  c-user/configuring_a_system.rst | 36 +++-
> >  1 file changed, 35 insertions(+), 1 deletion(-)
> >
> > diff --git a/c-user/configuring_a_system.rst 
> > b/c-user/configuring_a_system.rst
> > index 81bc9bb..00584c1 100644
> > --- a/c-user/configuring_a_system.rst
> > +++ b/c-user/configuring_a_system.rst
> > @@ -425,6 +425,38 @@ General System Configuration
> >  This section defines the general system configuration options supported by
> >  .
> >
> > +.. index:: CONFIGURE_DIRTY_MEMORY
> > +
> > +.. _CONFIGURE_DIRTY_MEMORY:
> > +
> > +CONFIGURE_DIRTY_MEMORY
> > +--
> > +
> > +CONSTANT:
> > +``CONFIGURE_DIRTY_MEMORY``
> > +
> > +DATA TYPE:
> > +Boolean feature macro.
> > +
> > +RANGE:
> > +Defined or undefined.
> > +
> > +DEFAULT VALUE:
> > +By default, the memory used by the RTEMS Workspace and the C Program 
> > Heap
> > +is uninitialized memory.
> > +
> > +DESCRIPTION:
> > +This macro indicates whether RTEMS should dirty the memory used by the
> > +RTEMS Workspace and the C Program Heap as part of its initialization.  
> > If
> > +defined, the memory areas are dirtied with a ``0xCF`` byte pattern.
> > +Otherwise, they are not.
> > +
> > +NOTES:
> > +Dirtying memory can add significantly to system boot time.  It may 
> > assist
> > +in finding code that assumes memory starts set to zero.  In case
>
> .. "assumes memory starts set to zero" does not look right to me?
>
At first I disagreed, but then it does seem ambiguous, whether it
means the starting address is 0 or the value is 0.

It should be clarified, "memory values start set to zero" or "set to
all zeroes" to make it clear memory is meant in the plural sense.

Gedare

> Chris
>
> > +:ref:`CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY` is also defined, then the
> > +memory is first dirtied and then zeroed.
> > +
> >  .. index:: CONFIGURE_EXTRA_TASK_STACKS
> >  .. index:: memory for task tasks
> >
> > @@ -1006,7 +1038,9 @@ DESCRIPTION:
> >
> >  NOTES:
> >  Zeroing memory can add significantly to system boot time. It is not
> > -necessary for RTEMS but is often assumed by support libraries.
> > +necessary for RTEMS but is often assumed by support libraries.  In case
> > +:ref:`CONFIGURE_DIRTY_MEMORY` is also defined, then the memory is first
> > +dirtied and then zeroed.
> >
> >  Classic API Configuration
> >  =
> >
> ___
> 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] c-user: Document CONFIGURE_DIRTY_MEMORY

2020-02-10 Thread Sebastian Huber 

On 10/02/2020 22:30, Gedare Bloom wrote:


On Mon, Feb 10, 2020 at 2:14 PM Chris Johns  wrote:



On 10/2/20 8:32 pm, Sebastian Huber wrote:

Close #3843.
---
  c-user/configuring_a_system.rst | 36 +++-
  1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/c-user/configuring_a_system.rst b/c-user/configuring_a_system.rst
index 81bc9bb..00584c1 100644
--- a/c-user/configuring_a_system.rst
+++ b/c-user/configuring_a_system.rst
@@ -425,6 +425,38 @@ General System Configuration
  This section defines the general system configuration options supported by
  .

+.. index:: CONFIGURE_DIRTY_MEMORY
+
+.. _CONFIGURE_DIRTY_MEMORY:
+
+CONFIGURE_DIRTY_MEMORY
+--
+
+CONSTANT:
+``CONFIGURE_DIRTY_MEMORY``
+
+DATA TYPE:
+Boolean feature macro.
+
+RANGE:
+Defined or undefined.
+
+DEFAULT VALUE:
+By default, the memory used by the RTEMS Workspace and the C Program Heap
+is uninitialized memory.
+
+DESCRIPTION:
+This macro indicates whether RTEMS should dirty the memory used by the
+RTEMS Workspace and the C Program Heap as part of its initialization.  If
+defined, the memory areas are dirtied with a ``0xCF`` byte pattern.
+Otherwise, they are not.
+
+NOTES:
+Dirtying memory can add significantly to system boot time.  It may assist
+in finding code that assumes memory starts set to zero.  In case

.. "assumes memory starts set to zero" does not look right to me?


At first I disagreed, but then it does seem ambiguous, whether it
means the starting address is 0 or the value is 0.

It should be clarified, "memory values start set to zero" or "set to
all zeroes" to make it clear memory is meant in the plural sense.


The FreeBSD man page uses "The memory is set to zero." Should I change 
it to:


"It may assist in finding code that assumes the content of free memory 
areas is cleared to zero during system initialization."


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

Re: [PATCH] c-user: Document CONFIGURE_DIRTY_MEMORY

2020-02-10 Thread Chris Johns 
On 11/2/20 4:57 pm, Sebastian Huber wrote:
> On 10/02/2020 22:30, Gedare Bloom wrote:
> 
>> On Mon, Feb 10, 2020 at 2:14 PM Chris Johns  wrote:
>>>
>>>
>>> On 10/2/20 8:32 pm, Sebastian Huber wrote:
 Close #3843.
 ---
   c-user/configuring_a_system.rst | 36 +++-
   1 file changed, 35 insertions(+), 1 deletion(-)

 diff --git a/c-user/configuring_a_system.rst 
 b/c-user/configuring_a_system.rst
 index 81bc9bb..00584c1 100644
 --- a/c-user/configuring_a_system.rst
 +++ b/c-user/configuring_a_system.rst
 @@ -425,6 +425,38 @@ General System Configuration
   This section defines the general system configuration options supported 
 by
   .

 +.. index:: CONFIGURE_DIRTY_MEMORY
 +
 +.. _CONFIGURE_DIRTY_MEMORY:
 +
 +CONFIGURE_DIRTY_MEMORY
 +--
 +
 +CONSTANT:
 +    ``CONFIGURE_DIRTY_MEMORY``
 +
 +DATA TYPE:
 +    Boolean feature macro.
 +
 +RANGE:
 +    Defined or undefined.
 +
 +DEFAULT VALUE:
 +    By default, the memory used by the RTEMS Workspace and the C Program 
 Heap
 +    is uninitialized memory.
 +
 +DESCRIPTION:
 +    This macro indicates whether RTEMS should dirty the memory used by the
 +    RTEMS Workspace and the C Program Heap as part of its initialization. 
  If
 +    defined, the memory areas are dirtied with a ``0xCF`` byte pattern.
 +    Otherwise, they are not.
 +
 +NOTES:
 +    Dirtying memory can add significantly to system boot time.  It may 
 assist
 +    in finding code that assumes memory starts set to zero.  In case
>>> .. "assumes memory starts set to zero" does not look right to me?
>>>
>> At first I disagreed, but then it does seem ambiguous, whether it
>> means the starting address is 0 or the value is 0.
>>
>> It should be clarified, "memory values start set to zero" or "set to
>> all zeroes" to make it clear memory is meant in the plural sense.
> 
> The FreeBSD man page uses "The memory is set to zero." Should I change it to:
> 
> "It may assist in finding code that assumes the content of free memory areas 
> is
> cleared to zero during system initialization."

Nice. A minor tweak ...

... incorrectly assumes the contents ... ?

?

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

Re: [PATCH] c-user: Document CONFIGURE_DIRTY_MEMORY

2020-02-10 Thread Sebastian Huber 

On 11/02/2020 07:12, Chris Johns wrote:


+NOTES:
+    Dirtying memory can add significantly to system boot time.  It may assist
+    in finding code that assumes memory starts set to zero.  In case

.. "assumes memory starts set to zero" does not look right to me?


At first I disagreed, but then it does seem ambiguous, whether it
means the starting address is 0 or the value is 0.

It should be clarified, "memory values start set to zero" or "set to
all zeroes" to make it clear memory is meant in the plural sense.

The FreeBSD man page uses "The memory is set to zero." Should I change it to:

"It may assist in finding code that assumes the content of free memory areas is
cleared to zero during system initialization."

Nice. A minor tweak ...

... incorrectly assumes the contents ... ?


Ok, I fixed it in two steps like this:

https://git.rtems.org/rtems-docs/commit/?id=0cdd4823fc05429ae834a18d8fca67594b249775

https://git.rtems.org/rtems-docs/commit/?id=c95724b793297994685804fcdaeb324a23cf1fd7

|NOTES: Dirtying memory can add significantly to system boot time. It 
may assist in finding code that incorrectly assumes the contents of free 
memory areas is cleared to zero during system initialization. In case 
:ref:`CONFIGURE_ZERO_WORKSPACE_AUTOMATICALLY` is also defined, then the 
memory is first dirtied and then zeroed. Hm, should this be now: |
||the contents of free memory areas ARE cleared to zero I probably 
should have sent this stuff for review first.| |


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

Re: [PATCH] bsp/raspberrypi: Fix linker command file

2020-02-10 Thread Sebastian Huber 

Hello,

I guess that after all the Raspberry Pi changes this patch can be discarded?

On 20/12/2019 07:32, Sebastian Huber wrote:

The RTEMS entry point must be at 0x8000.

Update #3774.
---
  bsps/arm/raspberrypi/start/linkcmds.in | 13 ++---
  1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/bsps/arm/raspberrypi/start/linkcmds.in 
b/bsps/arm/raspberrypi/start/linkcmds.in
index d99b4fe23e..fde75877e7 100644
--- a/bsps/arm/raspberrypi/start/linkcmds.in
+++ b/bsps/arm/raspberrypi/start/linkcmds.in
@@ -15,11 +15,12 @@
   */
  
  MEMORY {

-  RAM_MMU (AIW) : ORIGIN = 0x0010, LENGTH = @RPI_RAM_MMU_LENGTH@
-  RAM (AIW) : ORIGIN = 0x0020, LENGTH = @RPI_RAM_LENGTH_AVAILABLE@ - 
@RPI_RAM_NOCACHE_LENGTH@
+  START (AIW) : ORIGIN = 0x8000, LENGTH = 0xf8000
+  MMU   (AIW) : ORIGIN = 0x0010, LENGTH = @RPI_RAM_MMU_LENGTH@
+  RAM   (AIW) : ORIGIN = 0x0020, LENGTH = @RPI_RAM_LENGTH_AVAILABLE@ - 
@RPI_RAM_NOCACHE_LENGTH@
  }
  
-REGION_ALIAS ("REGION_START",  RAM);

+REGION_ALIAS ("REGION_START",  START);
  REGION_ALIAS ("REGION_VECTOR", RAM);
  REGION_ALIAS ("REGION_TEXT",   RAM);
  REGION_ALIAS ("REGION_TEXT_LOAD",  RAM);
@@ -41,9 +42,7 @@ bsp_stack_abt_size = DEFINED (bsp_stack_abt_size) ? 
bsp_stack_abt_size : 1024;
  
  bsp_section_rwbarrier_align = DEFINED (bsp_section_rwbarrier_align) ? bsp_section_rwbarrier_align : 1M;
  
-bsp_vector_table_in_start_section = 1;

-
-bsp_translation_table_base = ORIGIN (RAM_MMU);
-bsp_translation_table_end = ORIGIN (RAM_MMU) + LENGTH (RAM_MMU);
+bsp_translation_table_base = ORIGIN (MMU);
+bsp_translation_table_end = ORIGIN (MMU) + LENGTH (MMU);
  
  INCLUDE linkcmds.armv4

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