date:20200209

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
+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

[PATCH 2/2] eng: Mention test framework buffer configuration

Update #3199.
---
 eng/test-framework.rst | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/eng/test-framework.rst b/eng/test-framework.rst
index 6380f7e..3b73a21 100644
--- a/eng/test-framework.rst
+++ b/eng/test-framework.rst
@@ -1431,6 +1431,8 @@ must be persistent throughout the test run.
 
 typedef struct {
 const char *name;
+char *buf;
+size_t buf_size;
 T_putchar putchar;
 void *putchar_arg;
 T_verbosity verbosity;
@@ -1441,8 +1443,11 @@ must be persistent throughout the test run.
 
 With the test suite configuration you can specifiy the test suite name, the put
 character handler used the output the test report, the initial verbosity, the
-monotonic time provider and an optional set of test suite actions.  The test
-suite actions are called with the test suite name for test suite run events
+monotonic time provider and an optional set of test suite actions.  Only the
+test runner calls the put character handler, other tasks or interrupt handlers
+write to a buffer which is emptied by the test runner on demand.  You have to
+specifiy this buffer in the test configuration.  The test suite actions are
+called with the test suite name for test suite run events
 (`T_EVENT_RUN_INITIALIZE` and `T_EVENT_RUN_FINALIZE`) and the test case name
 for the test case events (`T_EVENT_CASE_EARLY`, `T_EVENT_CASE_BEGIN`,
 `T_EVENT_CASE_END` and `T_EVENT_CASE_LATE`).
-- 
2.16.4

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

Re: About Beaglebone Black device tree



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:
> >     >     >> Hi,
> >     >     >>
> >     >     >> While trying to run an rtems-littlevgl app on BBB, I
> found that
> >     >     the device
> >     >     >> tree generated from the freebsd source matching the
> freebsd-org
> >     >     >> HEAD commit doesn't work with the app and framebuffer
> >     device fails
> >     >     >> to open. This is most likely due to the changes in the
> >     freebsd dts
> >     >     >> sources because of which the overlay isn't working as
> expected.
> >     >     >
> >     >     > If I remember correctly, SD card doesn't work either
> with a FDT
> >     >     that is
> >     >     > too new.
> >     >     >
> >     >     >>
> >     >     >> I haven't had a detailed look at what's missing and the
> >     u-boot isn't
> >     >     >> reporting any error in applying the overlay either. I
> checked
> >     >     that the
> >     >     >> device tree built from freebsd tree matching the
> >     following commit
> >     >     >> works:
> >     >     >> 19a6ceb89dbacf74697d493e48c388767126d418
> >     >     >
> >     >     > At the moment that's the right one. But that can change if
> >     someone
> >     >     > updates libbsd again.
> >     >
> >     >     And I have to correct myself: That is not the right one. The
> >     current
> >     >     libbsd HEAD should work with
> >     6b0307a0a5184339393f555d5d424190d8a8277a.
> >     >
> >     > I meant to say that the framebuffer doesn't work with the
> current HEAD
> >     > (6b0307).
> >     > I checked with a previous commit, which is 19a6ce and found it
> >     working.
> >     > I should have been clear in the problem statement, sorry
> about that.
> >
> >     Thats not good. But the correct way would be to find out
> what's wrong
> >     and fix it. Did they add a fix in a future FreeBSD version?
> >
> > Most likely the overlay isn't working as expected. I'll have to have a
> > detailed
> > look to figure out what's going on there. 
> >
> 
> 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?

> 
> >     > 
> 
> >     >     >
> >     >     >>
> >     >     >> This brings up two questions:
> >     >     >> 1. Should we add the commit hash i

Re: Beginning work on BSP for i.MX RT 10xx (1052 specifically)

Hello Peter,

On 08/02/2020 21:16, Peter Dufault wrote:
> I will begin working on a BSP for the i.MX RT 10xx family.  I require support 
> for a 1052 but will be developing on a 1064 so those two variants will have 
> some test coverage.
> 
> I plan to start my work by making this a variant of the "imx" BSP.  That 
> currently supports the "i.MX7D Applications Processor".
> 
> I think that the network support provided by the "libbsd" "if_ffec" driver 
> will work with the ENET interface on the i.MX RT.
> I think that initial support will be a straight-forward collection of already 
> working pieces.
> 
> - If anyone has any warnings or "heads-up"s then let me know.

Note that we (embedded brains) are currently working on the imx BSP too.
Our target is imx6ul/ull support (for some Phytec modules). I'll try to
clean up the patches that are already nearly ready and send them to the
list as soon as possible. For the ones that are not ready yet I'll try
to give early warnings. Would be good if you could do the same thing.

> - I haven't been working with "device trees".  These are required for the 
> "imx" BSP.  Is this the preferred direction for a BSP?

>From my point of view it would be good to use the device tree for all
targets that use a device tree for Linux or FreeBSD too. Especially if
you want to use libbsd you can save a lot of necessary adaptions.

> - If anyone has any suggestions for how to ultimately arrange things then let 
> me know.  Right now, before I've gotten started, I plan to make this BSP a 
> variant in the "imx" BSP and to try to either re-use existing "chip" library 
> routines or add new ones.

For the imx6 I still hope that no variant is necessary. But I planned to
discuss this with Sebastian.

> 
> Unfortunately this will definitely be a BSP supporting only what I need for 
> the current application.

Like a lot of the BSPs that we have in RTEMS. Most of them grow whenever
someone needs something new.

Best regards

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
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Beginning work on BSP for i.MX RT 10xx (1052 specifically)

2020-02-09 Thread dufault




> On Feb 9, 2020, at 09:33 , Christian Mauderer  wrote:
> 
> Hello Peter,
> 
> On 08/02/2020 21:16, Peter Dufault wrote:
>> I will begin working on a BSP for the i.MX RT 10xx family.  I require 
>> support for a 1052 but will be developing on a 1064 so those two variants 
>> will have some test coverage.
>> 
>> I plan to start my work by making this a variant of the "imx" BSP.  That 
>> currently supports the "i.MX7D Applications Processor".
>> 
>> I think that the network support provided by the "libbsd" "if_ffec" driver 
>> will work with the ENET interface on the i.MX RT.
>> I think that initial support will be a straight-forward collection of 
>> already working pieces.
>> 
>> - If anyone has any warnings or "heads-up"s then let me know.
> 
> Note that we (embedded brains) are currently working on the imx BSP too.
> Our target is imx6ul/ull support (for some Phytec modules). I'll try to
> clean up the patches that are already nearly ready and send them to the
> list as soon as possible. For the ones that are not ready yet I'll try
> to give early warnings. Would be good if you could do the same thing.

This sure is convenient.  Looking at the data sheet I see many of the same 
peripherals.
- The same 10/100 ENET module;
- The same ADC module, but apparently without the external trigger module on 
the imx6ul.
etc.  It looks like the imx6  uses the same "smart DMA" as the imx7, while the 
imx-rt uses the "enhanced DMA" which I think is what was on the MPC5554.  
Again, I'm just starting to review the manuals. 

> 
>> - I haven't been working with "device trees".  These are required for the 
>> "imx" BSP.  Is this the preferred direction for a BSP?
> 
> From my point of view it would be good to use the device tree for all
> targets that use a device tree for Linux or FreeBSD too. Especially if
> you want to use libbsd you can save a lot of necessary adaptions.
> 
>> - If anyone has any suggestions for how to ultimately arrange things then 
>> let me know.  Right now, before I've gotten started, I plan to make this BSP 
>> a variant in the "imx" BSP and to try to either re-use existing "chip" 
>> library routines or add new ones.
> 
> For the imx6 I still hope that no variant is necessary. But I planned to
> discuss this with Sebastian.

I'm not sure if "variant" is the correct term.  I look forward to seeing what 
your approach is.

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: Beginning work on BSP for i.MX RT 10xx (1052 specifically)

On 09/02/2020 17:24, dufa...@hda.com wrote:
> 
> 
>> On Feb 9, 2020, at 09:33 , Christian Mauderer  wrote:
>>
>> Hello Peter,
>>
>> On 08/02/2020 21:16, Peter Dufault wrote:
>>> I will begin working on a BSP for the i.MX RT 10xx family.  I require 
>>> support for a 1052 but will be developing on a 1064 so those two variants 
>>> will have some test coverage.
>>>
>>> I plan to start my work by making this a variant of the "imx" BSP.  That 
>>> currently supports the "i.MX7D Applications Processor".
>>>
>>> I think that the network support provided by the "libbsd" "if_ffec" driver 
>>> will work with the ENET interface on the i.MX RT.
>>> I think that initial support will be a straight-forward collection of 
>>> already working pieces.
>>>
>>> - If anyone has any warnings or "heads-up"s then let me know.
>>
>> Note that we (embedded brains) are currently working on the imx BSP too.
>> Our target is imx6ul/ull support (for some Phytec modules). I'll try to
>> clean up the patches that are already nearly ready and send them to the
>> list as soon as possible. For the ones that are not ready yet I'll try
>> to give early warnings. Would be good if you could do the same thing.
> 
> This sure is convenient.  Looking at the data sheet I see many of the same 
> peripherals.
> - The same 10/100 ENET module;
> - The same ADC module, but apparently without the external trigger module on 
> the imx6ul.
> etc.  It looks like the imx6  uses the same "smart DMA" as the imx7, while 
> the imx-rt uses the "enhanced DMA" which I think is what was on the MPC5554.  
> Again, I'm just starting to review the manuals. 

Yes, the i.mx6ul and 7 are quite similar. I don't think that big
adaptions are necessary.

> 
>>
>>> - I haven't been working with "device trees".  These are required for the 
>>> "imx" BSP.  Is this the preferred direction for a BSP?
>>
>> From my point of view it would be good to use the device tree for all
>> targets that use a device tree for Linux or FreeBSD too. Especially if
>> you want to use libbsd you can save a lot of necessary adaptions.
>>
>>> - If anyone has any suggestions for how to ultimately arrange things then 
>>> let me know.  Right now, before I've gotten started, I plan to make this 
>>> BSP a variant in the "imx" BSP and to try to either re-use existing "chip" 
>>> library routines or add new ones.
>>
>> For the imx6 I still hope that no variant is necessary. But I planned to
>> discuss this with Sebastian.
> 
> I'm not sure if "variant" is the correct term.  I look forward to seeing what 
> your approach is.

Yes sorry. I didn't look up the established term. From what I can tell
now, I don't think that there will be any conditional compiling
necessary. That would mean that imx6ul and imx7 can use the same BSP.
There are differences for the clocks but these are already covered by
configure variables.

> 
> 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

[PATCH] 5: Update to Binutils 2.34

---
 rtems/config/5/rtems-default.bset  |  2 +-
 rtems/config/5/rtems-epiphany.bset |  2 +-
 rtems/config/5/rtems-or1k.bset |  2 +-
 rtems/config/5/rtems-riscv.bset|  2 +-
 rtems/config/5/rtems-x86_64.bset   |  2 +-
 rtems/config/tools/rtems-binutils-2.34.cfg | 27 +++
 6 files changed, 32 insertions(+), 5 deletions(-)
 create mode 100644 rtems/config/tools/rtems-binutils-2.34.cfg

diff --git a/rtems/config/5/rtems-default.bset 
b/rtems/config/5/rtems-default.bset
index 97c4ede..d4e1ce8 100644
--- a/rtems/config/5/rtems-default.bset
+++ b/rtems/config/5/rtems-default.bset
@@ -17,6 +17,6 @@
 devel/expat-2.1.0-1
 tools/rtems-gdb-8.3-1
 
-tools/rtems-binutils-2.33.1
+tools/rtems-binutils-2.34
 tools/rtems-gcc-7.5.0-newlib-d14714c69
 tools/rtems-tools-5-1
diff --git a/rtems/config/5/rtems-epiphany.bset 
b/rtems/config/5/rtems-epiphany.bset
index bb937b1..13351e4 100644
--- a/rtems/config/5/rtems-epiphany.bset
+++ b/rtems/config/5/rtems-epiphany.bset
@@ -33,7 +33,7 @@
 #
 5/rtems-autotools
 devel/expat-2.1.0-1
-tools/rtems-binutils-2.33.1
+tools/rtems-binutils-2.34
 tools/rtems-gcc-7.5.0-newlib-d14714c69
 tools/rtems-gdb-7.8.1-1
 tools/rtems-tools-5-1
diff --git a/rtems/config/5/rtems-or1k.bset b/rtems/config/5/rtems-or1k.bset
index 73e068c..c68cfc9 100644
--- a/rtems/config/5/rtems-or1k.bset
+++ b/rtems/config/5/rtems-or1k.bset
@@ -10,6 +10,6 @@
 
 devel/expat-2.1.0-1
 tools/rtems-gdb-8.2.1-1
-tools/rtems-binutils-2.33.1
+tools/rtems-binutils-2.34
 tools/rtems-gcc-9.2.0-newlib-d14714c69
 tools/rtems-tools-5-1
diff --git a/rtems/config/5/rtems-riscv.bset b/rtems/config/5/rtems-riscv.bset
index 716c236..a982411 100644
--- a/rtems/config/5/rtems-riscv.bset
+++ b/rtems/config/5/rtems-riscv.bset
@@ -11,7 +11,7 @@
 
 devel/expat-2.1.0-1
 tools/rtems-gdb-8.3-1
-tools/rtems-binutils-2.33.1
+tools/rtems-binutils-2.34
 tools/rtems-gcc-9.2.0-newlib-d14714c69
 tools/rtems-tools-5-1
 devel/sis-2-1
diff --git a/rtems/config/5/rtems-x86_64.bset b/rtems/config/5/rtems-x86_64.bset
index 8662cd0..e859ddf 100644
--- a/rtems/config/5/rtems-x86_64.bset
+++ b/rtems/config/5/rtems-x86_64.bset
@@ -8,6 +8,6 @@
 
 devel/expat-2.1.0-1
 tools/rtems-gdb-8.2.1-1
-tools/rtems-binutils-2.33.1
+tools/rtems-binutils-2.34
 tools/rtems-gcc-9.2.0-newlib-d14714c69
 tools/rtems-tools-5-1
diff --git a/rtems/config/tools/rtems-binutils-2.34.cfg 
b/rtems/config/tools/rtems-binutils-2.34.cfg
new file mode 100644
index 000..1c83c89
--- /dev/null
+++ b/rtems/config/tools/rtems-binutils-2.34.cfg
@@ -0,0 +1,27 @@
+#
+# Binutils 2.34
+#
+
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+%define binutils_version 2.34
+
+%hash sha512 binutils-%{binutils_version}.tar.bz2 
f47e7304e102c7bbc97958a08093e27796b9051d1567ce4fbb723d39ef3e29efa325ee14a1bdcc462a925a7f9bbbc9aee28294c6dc23850f371030f3835a8067
+
+#
+# Enable deterministic archives by default. This will be the default
+# there all tools using this binutils will create deterministic
+# archives.
+#
+%define with_deterministic_archives 1
+
+#
+# Enable 64-bit BFD support
+#
+%define with_64_bit_bfd 1
+
+#
+# The binutils build instructions. We use 2.xx Release 1.
+#
+%include %{_configdir}/binutils-2-1.cfg
-- 
2.16.4

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

Re: Beginning work on BSP for i.MX RT 10xx (1052 specifically)

On 09/02/2020 17:36, Christian Mauderer wrote:

On 09/02/2020 17:24, dufa...@hda.com wrote:

On Feb 9, 2020, at 09:33 , Christian Mauderer wrote:

Hello Peter,

On 08/02/2020 21:16, Peter Dufault wrote:

I will begin working on a BSP for the i.MX RT 10xx family. I require support
for a 1052 but will be developing on a 1064 so those two variants will have
some test coverage.

I plan to start my work by making this a variant of the "imx" BSP. That currently
supports the "i.MX7D Applications Processor".

I think that the network support provided by the "libbsd" "if_ffec" driver will
work with the ENET interface on the i.MX RT.
I think that initial support will be a straight-forward collection of already
working pieces.

- If anyone has any warnings or "heads-up"s then let me know.

Note that we (embedded brains) are currently working on the imx BSP too.
Our target is imx6ul/ull support (for some Phytec modules). I'll try to
clean up the patches that are already nearly ready and send them to the
list as soon as possible. For the ones that are not ready yet I'll try
to give early warnings. Would be good if you could do the same thing.

This sure is convenient. Looking at the data sheet I see many of the same
peripherals.
- The same 10/100 ENET module;
- The same ADC module, but apparently without the external trigger module on
the imx6ul.
etc. It looks like the imx6 uses the same "smart DMA" as the imx7, while the imx-rt
uses the "enhanced DMA" which I think is what was on the MPC5554. Again, I'm just
starting to review the manuals.

Yes, the i.mx6ul and 7 are quite similar. I don't think that big
adaptions are necessary.

- I haven't been working with "device trees". These are required for the "imx"
BSP. Is this the preferred direction for a BSP?

From my point of view it would be good to use the device tree for all
targets that use a device tree for Linux or FreeBSD too. Especially if
you want to use libbsd you can save a lot of necessary adaptions.

- If anyone has any suggestions for how to ultimately arrange things then let me know. Right now,
before I've gotten started, I plan to make this BSP a variant in the "imx" BSP and to try
to either re-use existing "chip" library routines or add new ones.

For the imx6 I still hope that no variant is necessary. But I planned to
discuss this with Sebastian.

I'm not sure if "variant" is the correct term. I look forward to seeing what
your approach is.

Yes sorry. I didn't look up the established term. From what I can tell
now, I don't think that there will be any conditional compiling
necessary. That would mean that imx6ul and imx7 can use the same BSP.
There are differences for the clocks but these are already covered by
configure variables.

I only had a brief look at the i.MX RT series:

https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/i.mx-rt-crossover-mcus:IMX-RT-SERIES

They are Cortex-M based. I think for the RT series we need a new BSP
family due to the different processor architecture (i.MX 6/7 is
Cortex-A). In case device trees are available for these chips, then I
would use them instead of hard coded values. Device driver code should
be shared if possible. I don't want new copy and paste drivers.

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

Re: Beginning work on BSP for i.MX RT 10xx (1052 specifically)

2020-02-09 Thread dufault

> On Feb 9, 2020, at 12:05 , Sebastian Huber 
>  wrote:
> 
>>> I'm not sure if "variant" is the correct term.  I look forward to seeing 
>>> what your approach is.
>> Yes sorry. I didn't look up the established term. From what I can tell
>> now, I don't think that there will be any conditional compiling
>> necessary. That would mean that imx6ul and imx7 can use the same BSP.
>> There are differences for the clocks but these are already covered by
>> configure variables.
> 
> I only had a brief look at the i.MX RT series:
> 
> https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/i.mx-rt-crossover-mcus:IMX-RT-SERIES
> 
> They are Cortex-M based. I think for the RT series we need a new BSP family 
> due to the different processor architecture (i.MX 6/7 is Cortex-A). In case 
> device trees are available for these chips, then I would use them instead of 
> hard coded values. Device driver code should be shared if possible. I don't 
> want new copy and paste drivers.

Yes, they are Cortex-M and not Cortex-A.  My plan, before realizing EB was 
extending the "imx" driver, was to start in the "imx" tree to get started but 
probably move to an "imx-rt" BSP once I knew what could be shared and what 
couldn't.  I don't want new copy and paste drivers.

I haven't been using device trees, it's been background noise. I'll need to 
review.

This brings me to a second important question regarding copy and paste: I 
installed the NXP MCUXpresso IDE to start reviewing the code available from NXP 
for the platform.

The plus:  The NXP code is BSD licensed.
The minus: This IDE supports computer assisted copy and paste.
- Any project I select that includes ethernet will install yet another copy of 
the ethernet driver C code.
- Everything that's installed appears to be specific to the i.MX 1064, at least 
as far as the names are.  I decided to use the i.MX RT 1064 development board 
to get started.
- I haven't located a download repository to bypass this nonsense and download 
the software in a reasonable layout.

I'd like to be able to pull down an NXP software repository for e.g. the i.MX 
RT family, import and label it, and then work from that, bugt I don't see that 
it's available.

It's hard for me to believe that this is how NXP internal SW development works. 
 This must be what's exported to be convenient for the pointers and clickers.

Does anyone know of a source of NXP code for recent platforms other than 
installing the IDE?

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

[PATCH v3 1/2] libchip/ns16550: Allow user calculate baud divisor

2020-02-09 Thread G S Niteesh

This patch will allow the user to pass a function to calculate
the baud divisor.
This will allow for more flexibility, since for some BSPs
like raspberrypi, the calculation of baud divisor is different
from what is in the current driver.
---
 bsps/include/libchip/ns16550.h   | 9 +++--
 bsps/shared/dev/serial/ns16550-context.c | 2 ++
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/bsps/include/libchip/ns16550.h b/bsps/include/libchip/ns16550.h
index f053c8767f..b45331a403 100644
--- a/bsps/include/libchip/ns16550.h
+++ b/bsps/include/libchip/ns16550.h
@@ -60,7 +60,11 @@ typedef uint8_t (*ns16550_get_reg)(uintptr_t port, uint8_t 
reg);
 
 typedef void (*ns16550_set_reg)(uintptr_t port, uint8_t reg, uint8_t value);
 
-typedef struct {
+typedef struct ns16550_context ns16550_context;
+
+typedef uint32_t (*ns16550_calculate_baud_divisor)(ns16550_context *ctx, 
uint32_t baud);
+
+struct ns16550_context{
   rtems_termios_device_context base;
   ns16550_get_reg get_reg;
   ns16550_set_reg set_reg;
@@ -78,7 +82,8 @@ typedef struct {
   size_t out_current;
   const char *out_buf;
   rtems_termios_tty *tty;
-} ns16550_context;
+  ns16550_calculate_baud_divisor calculate_baud_divisor;
+};
 
 extern const rtems_termios_device_handler ns16550_handler_interrupt;
 extern const rtems_termios_device_handler ns16550_handler_polled;
diff --git a/bsps/shared/dev/serial/ns16550-context.c 
b/bsps/shared/dev/serial/ns16550-context.c
index ce55b8309c..dbf6c64af4 100644
--- a/bsps/shared/dev/serial/ns16550-context.c
+++ b/bsps/shared/dev/serial/ns16550-context.c
@@ -112,6 +112,8 @@ static uint32_t NS16550_GetBaudDivisor(ns16550_context 
*ctx, uint32_t baud)
   NS16550_FRACTIONAL_DIVIDER,
   fractionalDivider
 );
+  } else if (ctx->calculate_baud_divisor != NULL) {
+baudDivisor = ctx->calculate_baud_divisor(ctx, baud);
   }
 
   return baudDivisor;
-- 
2.17.1

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

[PATCH v3 2/2] bsp/raspberrypi: Mini UART driver

2020-02-09 Thread G S Niteesh

This patch adds driver for Mini UART present in Raspberry Pi 3
and above, this UART is currently used as the primary UART in
these models.
The Mini UART is similar to ns16550, this driver is built
upon libchip/ns16550.
---
 bsps/arm/raspberrypi/console/console-config.c | 118 --
 bsps/arm/raspberrypi/include/bsp/usart.h  |   1 +
 2 files changed, 110 insertions(+), 9 deletions(-)

diff --git a/bsps/arm/raspberrypi/console/console-config.c 
b/bsps/arm/raspberrypi/console/console-config.c
index 48c4c6a3ec..62196786dd 100644
--- a/bsps/arm/raspberrypi/console/console-config.c
+++ b/bsps/arm/raspberrypi/console/console-config.c
@@ -24,6 +24,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -34,35 +35,103 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
-
-#define UART0 "/dev/ttyS0"
+/**
+ * UART0 - PL011
+ * UART1 - Mini UART
+ */
+#define PL011 "/dev/ttyAMA0"
+#define MINIUART  "/dev/ttyS0"
 #define FBCONS"/dev/fbcons"
 
 arm_pl011_context pl011_context;
+ns16550_context mini_uart_context;
 
 rpi_fb_context fb_context;
 
-static void output_char_serial(char c)
+static void output_char_pl011(char c)
 {
   arm_pl011_write_polled(&pl011_context.base, c);
 }
 
+static void output_char_mini_uart(char c)
+{
+  ns16550_polled_putchar(&mini_uart_context.base, c);
+}
+
 void output_char_fb(char c)
 {
   fbcons_write_polled(&fb_context.base, c);
 }
 
+static uint8_t mini_uart_get_reg(uintptr_t port, uint8_t index)
+{
+  volatile uint32_t *val = (volatile uint32_t *)port + index;
+  return (uint8_t) *val;
+}
+
+static void mini_uart_set_reg(uintptr_t port, uint8_t index, uint8_t val)
+{
+  volatile uint32_t *reg = (volatile uint32_t *)port + index;
+  *reg = val;
+}
+
 static void init_ctx_arm_pl011(
   const void *fdt,
   int node
 )
 {
   arm_pl011_context *ctx = &pl011_context;
-  rtems_termios_device_context_initialize(&ctx->base, "UART");
+  rtems_termios_device_context_initialize(&ctx->base, "PL011UART");
   ctx->regs = raspberrypi_get_reg_of_node(fdt, node);
 }
 
+static uint32_t calculate_baud_divisor(
+  ns16550_context *ctx,
+  uint32_t baud
+)
+{
+  uint32_t baudDivisor = (ctx->clock / (8 * baud)) - 1;
+  return baudDivisor;
+}
+
+static void init_ctx_mini_uart(
+  const void *fdt,
+  int node
+)
+{
+  const char *status;
+  int len;
+  ns16550_context *ctx;
+
+  memset(&mini_uart_context, 0, sizeof(mini_uart_context));
+  ctx = &mini_uart_context;
+
+  rtems_termios_device_context_initialize(&ctx->base, "MiniUART");
+
+  status = fdt_getprop(fdt, node, "status", &len);
+  if ( status == NULL || strcmp(status, "disabled" ) == 0){
+return ;
+  }
+
+  ctx->port = (uintptr_t) raspberrypi_get_reg_of_node(fdt, node);
+  ctx->initial_baud = MINI_UART_DEFAULT_BAUD;
+  ctx->clock = BCM2835_CLOCK_FREQ;
+  ctx->calculate_baud_divisor = calculate_baud_divisor;
+  ctx->get_reg = mini_uart_get_reg;
+  ctx->set_reg = mini_uart_set_reg;
+
+  rtems_gpio_bsp_select_specific_io(0, 14, RPI_ALT_FUNC_5, NULL);
+  rtems_gpio_bsp_select_specific_io(0, 15, RPI_ALT_FUNC_5, NULL);
+  rtems_gpio_bsp_set_resistor_mode(0, 14, NO_PULL_RESISTOR);
+  rtems_gpio_bsp_set_resistor_mode(0, 15, NO_PULL_RESISTOR);
+
+  BCM2835_REG(AUX_ENABLES) |= 0x1;
+  ns16550_probe(&ctx->base);
+}
+
 static void register_fb( void )
 {
   if (fbcons_probe(&fb_context.base) == true) {
@@ -87,16 +156,28 @@ static void console_select( void )
 link(FBCONS, CONSOLE_DEVICE_NAME);
 return ;
   }
+} else if ( strncmp( opt, MINIUART, sizeof(MINIUART) - 1 ) == 0) {
+  BSP_output_char = output_char_mini_uart;
+  link(MINIUART, CONSOLE_DEVICE_NAME);
+} else if ( strncmp( opt, PL011, sizeof(PL011) - 1 ) == 0) {
+  BSP_output_char = output_char_pl011;
+  link(PL011, CONSOLE_DEVICE_NAME);
 }
+  }else {
+/**
+ * If no command line option was given, default to PL011.
+ */
+BSP_output_char = output_char_pl011;
+link(PL011, CONSOLE_DEVICE_NAME);
   }
-  BSP_output_char = output_char_serial;
-  link(UART0, CONSOLE_DEVICE_NAME);
 }
 
 static void uart_probe(void)
 {
   static bool initialized = false;
   const void *fdt;
+  const char *console;
+  int len;
   int node;
 
   if ( initialized ) {
@@ -104,17 +185,29 @@ static void uart_probe(void)
   }
 
   fdt = bsp_fdt_get();
-  node = fdt_node_offset_by_compatible(fdt, -1, "brcm,bcm2835-pl011");
 
+  node = fdt_node_offset_by_compatible(fdt, -1, "brcm,bcm2835-pl011");
   init_ctx_arm_pl011(fdt, node);
 
+  node = fdt_node_offset_by_compatible(fdt, -1, "brcm,bcm2835-aux-uart");
+  init_ctx_mini_uart(fdt, node);
+
+  node = fdt_path_offset(fdt, "/aliases");
+  console = fdt_getprop(fdt, node, "serial0", &len);
+
+  if ( strcmp(console, "/soc/serial@7e215040" ) == 0) {
+BSP_output_char = output_char_mini_uart;
+  }else {
+BSP_output_char = output_char_pl011;
+  }
+
   initialized = true;
 }
 
 static void output_char(char c)
 {
   uart_probe();
-  output_char_serial(c);
+  (*BSP_output_char)(c);
 }

Re: Beginning work on BSP for i.MX RT 10xx (1052 specifically)




On 09/02/2020 20:09, dufa...@hda.com wrote:
> 
> 
>> On Feb 9, 2020, at 12:05 , Sebastian Huber 
>>  wrote:
>>
 I'm not sure if "variant" is the correct term.  I look forward to seeing 
 what your approach is.
>>> Yes sorry. I didn't look up the established term. From what I can tell
>>> now, I don't think that there will be any conditional compiling
>>> necessary. That would mean that imx6ul and imx7 can use the same BSP.
>>> There are differences for the clocks but these are already covered by
>>> configure variables.
>>
>> I only had a brief look at the i.MX RT series:
>>
>> https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/i.mx-rt-crossover-mcus:IMX-RT-SERIES
>>
>> They are Cortex-M based. I think for the RT series we need a new BSP family 
>> due to the different processor architecture (i.MX 6/7 is Cortex-A). In case 
>> device trees are available for these chips, then I would use them instead of 
>> hard coded values. Device driver code should be shared if possible. I don't 
>> want new copy and paste drivers.
> 
> Yes, they are Cortex-M and not Cortex-A.  My plan, before realizing EB was 
> extending the "imx" driver, was to start in the "imx" tree to get started but 
> probably move to an "imx-rt" BSP once I knew what could be shared and what 
> couldn't.  I don't want new copy and paste drivers.

Please don't hold back on extending the imx BSP too. We should just try
to keep one another up to date. Like I said: I'll try to send all
patches to the list that are already ready as soon as possible. The only
difference is that it now will be more smaller patches instead of a
collection of bigger ones at the end. I'm sure we can manage to
coordinate that and it has the advantage that finally someone will
review patches ;-)

Note that beneath the imx BSP maybe the PowerPC BSPs could have drivers
too. NXP reused some of the Freescale PowerPC peripherals. At least in
the i.MX6, 7 and 8.

> 
> I haven't been using device trees, it's been background noise. I'll need to 
> review.

What is the usual boot method on that platform? Is there an U-Boot that
loads a device tree? Would the RTEMS start right from the reset vector?

For the imx7 / imx6ul it's U-Boot or Barebox (U-Boot fork).

> 
> This brings me to a second important question regarding copy and paste: I 
> installed the NXP MCUXpresso IDE to start reviewing the code available from 
> NXP for the platform.
> 
> The plus:  The NXP code is BSD licensed.

Great.

> The minus: This IDE supports computer assisted copy and paste.

I agree: A big minus.

> - Any project I select that includes ethernet will install yet another copy 
> of the ethernet driver C code.
> - Everything that's installed appears to be specific to the i.MX 1064, at 
> least as far as the names are.  I decided to use the i.MX RT 1064 development 
> board to get started.
> - I haven't located a download repository to bypass this nonsense and 
> download the software in a reasonable layout.
> 
> I'd like to be able to pull down an NXP software repository for e.g. the i.MX 
> RT family, import and label it, and then work from that, bugt I don't see 
> that it's available.
> 
> It's hard for me to believe that this is how NXP internal SW development 
> works.  This must be what's exported to be convenient for the pointers and 
> clickers.
> 
> Does anyone know of a source of NXP code for recent platforms other than 
> installing the IDE?

I know that for the i.MX8 there have been a lot of repositories on
Codeaurora. That includes something like the NXP fork of Linux and arm
trusted firmware for i.MX8. If you are lucky, the libraries you are
searching could be there too.

https://source.codeaurora.org/

Otherwise: Maybe searching for some code snippets on github works?

Best regards

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: RSB build failed.

On 9/2/20 2:18 pm, jameszxj wrote:
> Hi,
>    RSB failed when build gdb on MINGW64.
> 
> error messages:
> 
> D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> ada-tasks.o: in function `memcpy':
> D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined reference
> to `__memcpy_chk'
> D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> arm-tdep.o: in function `memcpy':
> D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined reference
> to `__memcpy_chk'
> D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> breakpoint.o: in function `strcpy':
> D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:228: undefined reference
> to `__strcpy_chk'

I see this as well. I do not know what the cause it. It is documented in the LSB
code specification so am wondering if something has changed to trigger this.

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

Re: RSB build failed.

On 10/2/20 8:25 am, Chris Johns wrote:
> On 9/2/20 2:18 pm, jameszxj wrote:
>> Hi,
>>    RSB failed when build gdb on MINGW64.
>>
>> error messages:
>>
>> D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>> ada-tasks.o: in function `memcpy':
>> D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined 
>> reference
>> to `__memcpy_chk'
>> D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>> arm-tdep.o: in function `memcpy':
>> D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined 
>> reference
>> to `__memcpy_chk'
>> D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>> breakpoint.o: in function `strcpy':
>> D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:228: undefined 
>> reference
>> to `__strcpy_chk'
> 
> I see this as well. I do not know what the cause it. It is documented in the 
> LSB
> code specification so am wondering if something has changed to trigger this.

Building gdb-9.1 works for ARM. I will post a patch to move RTEMS 5 to gdb-9.1
once I have built arm, powerpc and sparc tool sets.

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

Re: About Beaglebone Black device tree

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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB build failed.

On 10/2/20 9:40 am, Chris Johns wrote:
> On 10/2/20 8:25 am, Chris Johns wrote:
>> On 9/2/20 2:18 pm, jameszxj wrote:
>>> Hi,
>>>    RSB failed when build gdb on MINGW64.
>>>
>>> error messages:
>>>
>>> D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>>> ada-tasks.o: in function `memcpy':
>>> D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined 
>>> reference
>>> to `__memcpy_chk'
>>> D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>>> arm-tdep.o: in function `memcpy':
>>> D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined 
>>> reference
>>> to `__memcpy_chk'
>>> D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>>> breakpoint.o: in function `strcpy':
>>> D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:228: undefined 
>>> reference
>>> to `__strcpy_chk'
>>
>> I see this as well. I do not know what the cause it. It is documented in the 
>> LSB
>> code specification so am wondering if something has changed to trigger this.
> 
> Building gdb-9.1 works for ARM. I will post a patch to move RTEMS 5 to gdb-9.1
> once I have built arm, powerpc and sparc tool sets.

It looks like mingw is broken 

x lrwxrwxrwx  0 root   root0 Nov 08 20:34
sourceware-mirror-newlib-cygwin-d14714c69/newlib/libm/machine/x86_64/feclearexcept.c
-> ../../fenv/fenv_stub.c: Can't create
'?\\D:\\opt\\rtems\\rsb.git\\rtems\\build\\arg7ndxwm1\\sourceware-mirror-newlib-cygwin-d14714c69\\newlib\\libm\\machine\\x86_64\\feclearexcept.c'

This is due to this change from Joel in newlib around 4 months ago...

https://github.com/RTEMS/sourceware-mirror-newlib-cygwin/blob/master/newlib/libm/machine/x86_64/fesetenv.c

I though I added logic to the RSB to handle these cases but it looks like we
have another case that needs handling.

The reason the failure happens is the destination directory for the link does
not exist and so the file copy fails. On Unix system the link is a path attached
to the node and so does not need to exist until you access it. The order in the
tar file means the link appears before the destination directory.

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

Re: RSB build failed.

2020-02-09 Thread Joel Sherrill

On Sun, Feb 9, 2020, 5:07 PM Chris Johns  wrote:

> On 10/2/20 9:40 am, Chris Johns wrote:
> > On 10/2/20 8:25 am, Chris Johns wrote:
> >> On 9/2/20 2:18 pm, jameszxj wrote:
> >>> Hi,
> >>>RSB failed when build gdb on MINGW64.
> >>>
> >>> error messages:
> >>>
> >>>
> D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >>> ada-tasks.o: in function `memcpy':
> >>> D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined
> reference
> >>> to `__memcpy_chk'
> >>>
> D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >>> arm-tdep.o: in function `memcpy':
> >>> D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined
> reference
> >>> to `__memcpy_chk'
> >>>
> D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >>> breakpoint.o: in function `strcpy':
> >>> D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:228: undefined
> reference
> >>> to `__strcpy_chk'
> >>
> >> I see this as well. I do not know what the cause it. It is documented
> in the LSB
> >> code specification so am wondering if something has changed to trigger
> this.
> >
> > Building gdb-9.1 works for ARM. I will post a patch to move RTEMS 5 to
> gdb-9.1
> > once I have built arm, powerpc and sparc tool sets.
>
> It looks like mingw is broken 
>
> x lrwxrwxrwx  0 root   root0 Nov 08 20:34
>
> sourceware-mirror-newlib-cygwin-d14714c69/newlib/libm/machine/x86_64/feclearexcept.c
> -> ../../fenv/fenv_stub.c: Can't create
>
> '?\\D:\\opt\\rtems\\rsb.git\\rtems\\build\\arg7ndxwm1\\sourceware-mirror-newlib-cygwin-d14714c69\\newlib\\libm\\machine\\x86_64\\feclearexcept.c'
>
> This is due to this change from Joel in newlib around 4 months ago...
>
>
> https://github.com/RTEMS/sourceware-mirror-newlib-cygwin/blob/master/newlib/libm/machine/x86_64/fesetenv.c
>
> I though I added logic to the RSB to handle these cases but it looks like
> we
> have another case that needs handling.
>

Weird that a link from a tar isn't working.

>
> The reason the failure happens is the destination directory for the link
> does
> not exist and so the file copy fails. On Unix system the link is a path
> attached
> to the node and so does not need to exist until you access it. The order
> in the
> tar file means the link appears before the destination directory.
>

Are there contents in the directory besides links? It no, adding a readme
may help.

Otherwise, these may need to be created at configure time.

I honestly don't know the answer. We will have to discuss this on the
newlib mailing list. There are multiple solutions and they have to buy one

>
> Chris
> ___
> 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: RSB build failed.



On 10/2/20 10:19 am, Joel Sherrill wrote:
> 
> 
> On Sun, Feb 9, 2020, 5:07 PM Chris Johns  > wrote:
> 
> On 10/2/20 9:40 am, Chris Johns wrote:
> > On 10/2/20 8:25 am, Chris Johns wrote:
> >> On 9/2/20 2:18 pm, jameszxj wrote:
> >>> Hi,
> >>>    RSB failed when build gdb on MINGW64.
> >>>
> >>> error messages:
> >>>
> >>>
> 
> D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >>> ada-tasks.o: in function `memcpy':
> >>> D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined
> reference
> >>> to `__memcpy_chk'
> >>>
> 
> D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >>> arm-tdep.o: in function `memcpy':
> >>> D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined
> reference
> >>> to `__memcpy_chk'
> >>>
> 
> D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >>> breakpoint.o: in function `strcpy':
> >>> D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:228: undefined
> reference
> >>> to `__strcpy_chk'
> >>
> >> I see this as well. I do not know what the cause it. It is documented 
> in
> the LSB
> >> code specification so am wondering if something has changed to trigger 
> this.
> >
> > Building gdb-9.1 works for ARM. I will post a patch to move RTEMS 5 to 
> gdb-9.1
> > once I have built arm, powerpc and sparc tool sets.
> 
> It looks like mingw is broken 
> 
> x lrwxrwxrwx  0 root   root        0 Nov 08 20:34
> 
> sourceware-mirror-newlib-cygwin-d14714c69/newlib/libm/machine/x86_64/feclearexcept.c
> -> ../../fenv/fenv_stub.c: Can't create
> 
> '?\\D:\\opt\\rtems\\rsb.git\\rtems\\build\\arg7ndxwm1\\sourceware-mirror-newlib-cygwin-d14714c69\\newlib\\libm\\machine\\x86_64\\feclearexcept.c'
> 
> This is due to this change from Joel in newlib around 4 months ago...
> 
> 
> https://github.com/RTEMS/sourceware-mirror-newlib-cygwin/blob/master/newlib/libm/machine/x86_64/fesetenv.c
> 
> I though I added logic to the RSB to handle these cases but it looks like 
> we
> have another case that needs handling.
> 
> 
> Weird that a link from a tar isn't working.

This is Windows and there is no such thing. It is emulated as a copy.

> The reason the failure happens is the destination directory for the link 
> does
> not exist and so the file copy fails. On Unix system the link is a path 
> attached
> to the node and so does not need to exist until you access it. The order 
> in the
> tar file means the link appears before the destination directory.
> 
> 
> Are there contents in the directory besides links? It no, adding a readme may 
> help.

There are generated files and I was wrong before the source does not exist, ie
nothing to be copied.

> Otherwise, these may need to be created at configure time.
> 
> I honestly don't know the answer. We will have to discuss this on the newlib
> mailing list. There are multiple solutions and they have to buy one 

I think clang or gcc has some links that fail but I thought I had a fix for this
where bsdtar is run a second time on windows. I cannot seem to find it.

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

Re: RSB build failed.

On 10/2/20 10:36 am, Chris Johns wrote:
> I think clang or gcc has some links that fail but I thought I had a fix for 
> this
> where bsdtar is run a second time on windows. I cannot seem to find it.

I have found the fix I added when adding clang support ...

https://git.rtems.org/rtems-source-builder/commit/?id=591deae6d7411af04fd31d2a68dee9520b33c657

... however this option does not help. It is not clear to me what is wrong with
the links in the newlib tar file.

I have raised a ticket to manage the issue ...

https://devel.rtems.org/ticket/3868

Chris

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

Suggestion about libdl's cache size

2020-02-09 Thread jameszxj

Hi
   The caches size(RTEMS_RTL_ELF_SYMBOL_CACHE ...) now are just 
define in rtl.c. One of our project should increase the cache size, so I have 
to modify the
kernel source file directly. I think if the cache size can be redefined maybe 
friendly.
   thanks. ___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Suggestion about libdl's cache size

On 10/2/20 12:14 pm, jameszxj wrote:
>    The caches size(RTEMS_RTL_ELF_SYMBOL_CACHE ...) now are just define in 
> rtl.c.

Yes.

> One of our project should increase the cache size, so I have to modify the
> kernel source file directly. I think if the cache size can be redefined maybe
> friendly.

Yes I agree. When libdl was written I provided the flexibility to set the cache
size however I never created a formal interface to do this. At the time there
were many other things that needed to be resolved before this. I felt if this
was important and needed it would be raised as an issue. It looks like that time
as come.

If you would something added please contact me offline.

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

rtems-test on BBB hardware (was Re: Enabling Buildbot 'responsible user' emails.)