Update to waf 2.0.19?

[Sebastian Huber]

Hello,

in order to close this bug:

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

I would like to update waf to the latest version 2.0.19 in:

rtems-docs
rtems-tools
rtems-libbsd
rtems-examples

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
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] tester: Use prefix for rtems_tools by default

[Sebastian Huber]

Hello Chris,

On 14/02/2020 07:14, Sebastian Huber wrote:

On 14/02/2020 03:54, Chris Johns wrote:


On 2020-02-12 17:27, Sebastian Huber wrote:

Commit 72c684eff2cd932b4948e21902680a93473340c3 removed the default
value of rtems_tools.  If the --rtems--tools option was omitted the
rtems-test command printed lots of

error: run.cfg:61: macro '%{rtems_tools}' not found

error messages.


I will need to think about this. I am wondering id removing the prefix 
code allowed the PATH to be used. 
I have rtems-test in the $PATH and calling it without --rtems-tools 
doesn't work without this patch.


could you please have a look at this. Since the %{rtems_tools} macros 
needed it should be defined:


grep -r rtems_tools --include '*.cfg'
tester/rtems/testing/gdb.cfg:%define gdb_cmd 
%{rtems_tools}/%{bsp_arch}-rtems%{rtems_version}-gdb


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
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: Update to waf 2.0.19?

[Andrew BUTTERFIELD]

Hi Sebastian,
 this is fine by me.

Regards, Andrew

Sent from my iPad

> On 25 Feb 2020, at 08:02, Sebastian Huber 
>  wrote:
> 
> Hello,
> 
> in order to close this bug:
> 
> https://devel.rtems.org/ticket/3569
> 
> I would like to update waf to the latest version 2.0.19 in:
> 
> rtems-docs
> rtems-tools
> rtems-libbsd
> rtems-examples
> 
> -- 
> Sebastian Huber, embedded brains GmbH
> 
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> 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

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

Re: RTEMS test

[Cláudio Maia]

Hi John,

You need to add the toolchain binaries to your path in the shell in order for 
them to be found by your shell when you invoke them.

Thus, after you build and install the toolchain (in this case for ARM 
architectures) with the following command (where $RTEMS is given by, for 
instance, "export RTEMS=~/rtems/"):

$ ../source-builder/sb-set-builder --prefix=$RTEMS/5 5/rtems-arm

You can add the toolchain binaries to the path by typing the following in the 
shell: 

$ export PATH=$RTEMS/5/bin:$PATH  

After that you should be able to use "rtems-test" and all the other binaries in 
"$RTEMS/5/bin".

Hope this helps.

Regards,
Cláudio 

On 25/02/20 06:19, John kongtcheu wrote:
> Hello,
> I'm trying to run the rtems-test after closing my computer and switching 
> operating systems(dual booted computer), but weirdly enough, I received the 
> message 
> rtems-test: command not found
> So I attempted running the command for rtems-tools, but then the message I 
> received was 
>  ./rtems-test --lists-bsps
> error: RTEMS Toolkit python wrapper not found, plrease report
> Understand, I had previously been able to run the rtems-test command fine 
> before, this was only after I turned off ubuntu, turned on Windows, and then 
> turned off Windows and turned on ubuntu that this error occurred.
> I'd greatly appreciate help in this mater.
> Thank you,
> 
> ___
> 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: Waf Build System Status in RTEMS?

[Hesham Almatary]

On Mon, 24 Feb 2020 at 22:50, Chris Johns  wrote:
>
> On 21/2/20 11:11 pm, Sebastian Huber wrote:
> > On 21/02/2020 12:26, Hesham Almatary wrote:
> >> On Fri, 21 Feb 2020 at 11:07, Sebastian Huber
> >>   wrote:
> >>> Hello Hesham,
> >>>
> >>> On 20/02/2020 16:40, Hesham Almatary wrote:
>  Hello,
> 
>  Are there any progress updates to the Waf build system integration in 
>  RTEMS?
> 
>  I have pulled [1] and it seems like it hasn't got many updates since
>  December. I wonder what's still remaining/blocking to merge it, or at
>  least push it as a development branch (without re-writing history)
>  that others, including me, can use it and submit patches against.
> 
>  [1] git://git.rtems.org/sebh/rtems.git
> >>> technically, the new build system is ready for integration into the
> >>> master branch. I would need about one day to rebase and test it before
> >>> the push. The integration is currently blocked since Chris and Joel had
> >>> no time to look at it.
> >>>
> >> Thanks for your input, Sebastian. Is there a recommended branch I
> >> should be based on? I noticed there's "build" and "build-next".
> >
> > The "build" branch contains the state of the first review. I updated
> > "build-next" a couple of times to integrate the changes on the RTEMS master.
> >
> >> Do you intend to re-write git history in either?
> >
> > Yes, when I started with the build system work I didn't expect a more than 
> > two
> > months review period.
>
> I have discussed this merge with Joel. We have decided to release RTEMS 5 
> before
> we merge a new build system. A release with parallel build systems is 
> confusing
> and distracting.
>
That makes sense to me. I think we should both try to push for an
RTEMS release soon, and make the waf/build
branch more stable and/or in the view (e.g., push as an experimental
branch) for developer to use until a release comes out. I understand
another branch would incur more maintaibility efforts, but it will
also help make the the new build system more usable.

> I think we are close to a release if master can stay stable. The milestone
> ticket page ...
>
>  https://devel.rtems.org/milestone/5.1
>
> ... shows 43 in progress and 2 closed. Help with the tickets will help 
> progress
> things.
>
> I am working on moving the libbsd release to the 5-freebsd-12 branch and the
> side effects that causes. I will need reports of a libbsd release snapshort
> running on ...
>
>  beagleboneblack, imx7, xilinx_zynq_zedboard, qoriq_e500
>
> I can do this for the beagleboneblack and xilinx_zynq_zedboard.
>
I recently got libbsd working with RISC-V on QEMU. On my TODO list,
I'll create a soft SoC with DTB/FDT and devices for testing on an FPGA
board, I will report about that if I got some apps/tests reasonably
working.

> Finally there is the FDT file managements, I would like a resolution on a
> suitable path to get FDT files into a release and at least one BSP to support
> this. I have selected the BeagleBone Black because I have one to test on.
>
I can pitch in with RISC-V (QEMU and/or FPGA SoCs/board). I'd like for
FDT management to be as generic as could be across different
BSPs/architectures.

> Chris


On Mon, 24 Feb 2020 at 22:50, Chris Johns  wrote:
>
> On 21/2/20 11:11 pm, Sebastian Huber wrote:
> > On 21/02/2020 12:26, Hesham Almatary wrote:
> >> On Fri, 21 Feb 2020 at 11:07, Sebastian Huber
> >>   wrote:
> >>> Hello Hesham,
> >>>
> >>> On 20/02/2020 16:40, Hesham Almatary wrote:
>  Hello,
> 
>  Are there any progress updates to the Waf build system integration in 
>  RTEMS?
> 
>  I have pulled [1] and it seems like it hasn't got many updates since
>  December. I wonder what's still remaining/blocking to merge it, or at
>  least push it as a development branch (without re-writing history)
>  that others, including me, can use it and submit patches against.
> 
>  [1] git://git.rtems.org/sebh/rtems.git
> >>> technically, the new build system is ready for integration into the
> >>> master branch. I would need about one day to rebase and test it before
> >>> the push. The integration is currently blocked since Chris and Joel had
> >>> no time to look at it.
> >>>
> >> Thanks for your input, Sebastian. Is there a recommended branch I
> >> should be based on? I noticed there's "build" and "build-next".
> >
> > The "build" branch contains the state of the first review. I updated
> > "build-next" a couple of times to integrate the changes on the RTEMS master.
> >
> >> Do you intend to re-write git history in either?
> >
> > Yes, when I started with the build system work I didn't expect a more than 
> > two
> > months review period.
>
> I have discussed this merge with Joel. We have decided to release RTEMS 5 
> before
> we merge a new build system. A release with parallel build systems is 
> confusing
> and distracting.
>
> I think we are close to a release if master can stay stable. The milestone
> ticket page 

Re: [PATCH v2 00/44] Split up confdefs.h

[Sebastian Huber]

Hello,

I checked in this patch set. The new header files use the new header 
file template:


https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#c-c-header-file-template

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
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: SPDX License Identifier Only and Full Copy?

[Sebastian Huber]

Hello Gedare,

On 24/02/2020 16:58, Gedare Bloom wrote:

On Mon, Feb 24, 2020 at 12:53 AM Sebastian Huber
  wrote:

Hello,

I updated the File Template section:

https://docs.rtems.org/branches/master/eng/coding-file-hdr.html

Please have a look at it and check if it is all right for you.


Thanks. A few notes:


thanks for the review.


* licence -> license


Fixed.


* Do we have rules yet for using pydoc in python source? Should we? if
so, should we also specify a header block for Python files? This might
be a discussion for a separate thread.


The Python development in general has no guidelines at the moment. We 
are currently stuck with the Python code formatter tool 
selection/configuration. It is also an open issue if the Python 
development guidelines should affect existing code.



* Any file headers for rst documents? I guess the CC-BY-SA-4.0 is sufficient.


https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#restructuredtext-file-template

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
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: Waf Build System Status in RTEMS?

[Sebastian Huber]

On 25/02/2020 11:00, Hesham Almatary wrote:

On Mon, 24 Feb 2020 at 22:50, Chris Johns  wrote:

On 21/2/20 11:11 pm, Sebastian Huber wrote:

On 21/02/2020 12:26, Hesham Almatary wrote:

On Fri, 21 Feb 2020 at 11:07, Sebastian Huber
   wrote:

Hello Hesham,

On 20/02/2020 16:40, Hesham Almatary wrote:

Hello,

Are there any progress updates to the Waf build system integration in RTEMS?

I have pulled [1] and it seems like it hasn't got many updates since
December. I wonder what's still remaining/blocking to merge it, or at
least push it as a development branch (without re-writing history)
that others, including me, can use it and submit patches against.

[1] git://git.rtems.org/sebh/rtems.git

technically, the new build system is ready for integration into the
master branch. I would need about one day to rebase and test it before
the push. The integration is currently blocked since Chris and Joel had
no time to look at it.


Thanks for your input, Sebastian. Is there a recommended branch I
should be based on? I noticed there's "build" and "build-next".

The "build" branch contains the state of the first review. I updated
"build-next" a couple of times to integrate the changes on the RTEMS master.


Do you intend to re-write git history in either?

Yes, when I started with the build system work I didn't expect a more than two
months review period.

I have discussed this merge with Joel. We have decided to release RTEMS 5 before
we merge a new build system. A release with parallel build systems is confusing
and distracting.


That makes sense to me. I think we should both try to push for an
RTEMS release soon, and make the waf/build
branch more stable and/or in the view (e.g., push as an experimental
branch) for developer to use until a release comes out. I understand
another branch would incur more maintaibility efforts, but it will
also help make the the new build system more usable.


I can do a forced update of the "build" branch with my latest version 
based on rebase of the current master by the end of the week. 
Afterwards, I can do merges from the master instead of forced pushes. 
This should enable you to base your work on this branch. You can also 
send me patches.


Before the new build system is integrated in the master, I will do a 
final rebase to the master and squash commits.





I think we are close to a release if master can stay stable. The milestone
ticket page ...

  https://devel.rtems.org/milestone/5.1

... shows 43 in progress and 2 closed. Help with the tickets will help progress
things.

I am working on moving the libbsd release to the 5-freebsd-12 branch and the
side effects that causes. I will need reports of a libbsd release snapshort
running on ...

  beagleboneblack, imx7, xilinx_zynq_zedboard, qoriq_e500

I can do this for the beagleboneblack and xilinx_zynq_zedboard.


I recently got libbsd working with RISC-V on QEMU. On my TODO list,
I'll create a soft SoC with DTB/FDT and devices for testing on an FPGA
board, I will report about that if I got some apps/tests reasonably
working.


Finally there is the FDT file managements, I would like a resolution on a
suitable path to get FDT files into a release and at least one BSP to support
this. I have selected the BeagleBone Black because I have one to test on.


I can pitch in with RISC-V (QEMU and/or FPGA SoCs/board). I'd like for
FDT management to be as generic as could be across different
BSPs/architectures.


The FreeBSD device tree support should be fairly architecture 
independent. However, it is not as good/complete/robust as the Linux 
device tree support. I am not in favour of adding an RTEMS-specific 
device tree support.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
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 test

[G. S. Niteesh]

>
>
> Hello,
> I'm trying to run the rtems-test after closing my computer and switching
> operating systems(dual booted computer), but weirdly enough, I received the
> message
> rtems-test: command not found
> So I attempted running the command for rtems-tools, but then the message I
> received was
>  ./rtems-test --lists-bsps
> error: RTEMS Toolkit python wrapper not found, plrease report
> Understand, I had previously been able to run the rtems-test command fine
> before, this was only after I turned off ubuntu, turned on Windows, and
> then turned off Windows and turned on ubuntu that this error occurred.
> I'd greatly appreciate help in this mater.
> Thank you,
>

hii,

This is most probably a path issue. If you used *export *to set your path
it would only be valid temporarily.
For permanently setting up the path you must add it to your ~/.profile.
This can be done using
echo "$PATH:" > ~/.profile

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

Re: RTEMS test

[John kongtcheu]

Thank you very much!  Appreciate it.

On Tue, Feb 25, 2020 at 4:47 AM Cláudio Maia  wrote:

> Hi John,
>
> You need to add the toolchain binaries to your path in the shell in order
> for them to be found by your shell when you invoke them.
>
> Thus, after you build and install the toolchain (in this case for ARM
> architectures) with the following command (where $RTEMS is given by, for
> instance, "export RTEMS=~/rtems/"):
>
> $ ../source-builder/sb-set-builder --prefix=$RTEMS/5 5/rtems-arm
>
> You can add the toolchain binaries to the path by typing the following in
> the shell:
>
> $ export PATH=$RTEMS/5/bin:$PATH
>
> After that you should be able to use "rtems-test" and all the other
> binaries in "$RTEMS/5/bin".
>
> Hope this helps.
>
> Regards,
> Cláudio
>
> On 25/02/20 06:19, John kongtcheu wrote:
> > Hello,
> > I'm trying to run the rtems-test after closing my computer and switching
> operating systems(dual booted computer), but weirdly enough, I received the
> message
> > rtems-test: command not found
> > So I attempted running the command for rtems-tools, but then the message
> I received was
> >  ./rtems-test --lists-bsps
> > error: RTEMS Toolkit python wrapper not found, plrease report
> > Understand, I had previously been able to run the rtems-test command
> fine before, this was only after I turned off ubuntu, turned on Windows,
> and then turned off Windows and turned on ubuntu that this error occurred.
> > I'd greatly appreciate help in this mater.
> > Thank you,
> >
> > ___
> > 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

[PATCH 1/1] bsp/pc386: Fix interrupt enable to make debug option work again

[Jan Sommer]

---
 bsps/i386/pc386/clock/ckinit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsps/i386/pc386/clock/ckinit.c b/bsps/i386/pc386/clock/ckinit.c
index 478a37f5d7..d6e4b4 100644
--- a/bsps/i386/pc386/clock/ckinit.c
+++ b/bsps/i386/pc386/clock/ckinit.c
@@ -170,7 +170,7 @@ static void clockOn(void)
   outport_byte(TIMER_CNTR0, pc386_clock_click_count >> 8 & 0xff);
   rtems_interrupt_lock_release(&rtems_i386_i8254_access_lock, &lock_context);
 
-  bsp_interrupt_vector_enable( BSP_PERIODIC_TIMER - BSP_IRQ_VECTOR_BASE );
+  bsp_interrupt_vector_enable( BSP_PERIODIC_TIMER );
 
   /*
* Now calibrate cycles per tick. Do this every time we
-- 
2.12.3

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

[PATCH 0/1] [bsp/pc386] Fix --enable-rtems-debug

[Jan Sommer]

Hello,

I just noticed that the patch with the suggestions from Joel
(https://lists.rtems.org/pipermail/users/2019-April/033151.html) never made it 
into the repository.

Since I have now git send-email configured, here it is again.

Cheers,

   Jan

Jan Sommer (1):
  bsp/pc386: Fix interrupt enable to make debug option work again

 bsps/i386/pc386/clock/ckinit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.12.3

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

[PATCH] config: Initialize IO drivers on demand

[Sebastian Huber]

---
 cpukit/Makefile.am|  1 +
 cpukit/include/rtems/confdefs/iodrivers.h | 29 
 cpukit/sapi/src/exinit.c  | 13 -
 cpukit/sapi/src/iodefault.c   | 45 +++
 4 files changed, 75 insertions(+), 13 deletions(-)
 create mode 100644 cpukit/sapi/src/iodefault.c

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index 9ed260addb..298580e20d 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -1056,6 +1056,7 @@ librtemscpu_a_SOURCES += sapi/src/getconfigmax.c
 librtemscpu_a_SOURCES += sapi/src/getversionstring.c
 librtemscpu_a_SOURCES += sapi/src/interrtext.c
 librtemscpu_a_SOURCES += sapi/src/io.c
+librtemscpu_a_SOURCES += sapi/src/iodefault.c
 librtemscpu_a_SOURCES += sapi/src/ioclose.c
 librtemscpu_a_SOURCES += sapi/src/iocontrol.c
 librtemscpu_a_SOURCES += sapi/src/ioinitialize.c
diff --git a/cpukit/include/rtems/confdefs/iodrivers.h 
b/cpukit/include/rtems/confdefs/iodrivers.h
index 1e7b8c4e13..7ebe2ed474 100644
--- a/cpukit/include/rtems/confdefs/iodrivers.h
+++ b/cpukit/include/rtems/confdefs/iodrivers.h
@@ -42,7 +42,19 @@
 
 #ifdef CONFIGURE_INIT
 
+#if defined(CONFIGURE_APPLICATION_EXTRA_DRIVERS) \
+  || defined(CONFIGURE_APPLICATION_NEEDS_ATA_DRIVER) \
+  || defined(CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER) \
+  || defined(CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER) \
+  || defined(CONFIGURE_APPLICATION_NEEDS_IDE_DRIVER) \
+  || defined(CONFIGURE_APPLICATION_NEEDS_NULL_DRIVER) \
+  || defined(CONFIGURE_APPLICATION_NEEDS_RTC_DRIVER) \
+  || defined(CONFIGURE_APPLICATION_NEEDS_STUB_DRIVER) \
+  || defined(CONFIGURE_APPLICATION_NEEDS_ZERO_DRIVER) \
+  || CONFIGURE_MAXIMUM_DRIVERS > 0
+
 #include 
+#include 
 
 #ifdef CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
   #if defined(CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER) \
@@ -150,6 +162,12 @@ _IO_Driver_address_table[ CONFIGURE_MAXIMUM_DRIVERS ] = {
 const size_t _IO_Number_of_drivers =
   RTEMS_ARRAY_SIZE( _IO_Driver_address_table );
 
+RTEMS_SYSINIT_ITEM(
+  _IO_Initialize_all_drivers,
+  RTEMS_SYSINIT_DEVICE_DRIVERS,
+  RTEMS_SYSINIT_ORDER_MIDDLE
+);
+
 #ifdef CONFIGURE_APPLICATION_NEEDS_ATA_DRIVER
   #ifndef CONFIGURE_ATA_DRIVER_TASK_PRIORITY
 #define CONFIGURE_ATA_DRIVER_TASK_PRIORITY ATA_DRIVER_TASK_DEFAULT_PRIORITY
@@ -163,6 +181,17 @@ const size_t _IO_Number_of_drivers =
 }
 #endif
 
+#endif /* CONFIGURE_APPLICATION_EXTRA_DRIVERS
+  || CONFIGURE_APPLICATION_NEEDS_ATA_DRIVER
+  || CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
+  || CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER
+  || CONFIGURE_APPLICATION_NEEDS_IDE_DRIVER
+  || CONFIGURE_APPLICATION_NEEDS_NULL_DRIVER
+  || CONFIGURE_APPLICATION_NEEDS_RTC_DRIVER
+  || CONFIGURE_APPLICATION_NEEDS_STUB_DRIVER
+  || CONFIGURE_APPLICATION_NEEDS_ZERO_DRIVER
+  || CONFIGURE_MAXIMUM_DRIVERS */
+
 #endif /* CONFIGURE_INIT */
 
 #endif /* _RTEMS_CONFDEFS_IODRIVERS_H */
diff --git a/cpukit/sapi/src/exinit.c b/cpukit/sapi/src/exinit.c
index 196c9be576..e29b364806 100644
--- a/cpukit/sapi/src/exinit.c
+++ b/cpukit/sapi/src/exinit.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -120,18 +119,6 @@ RTEMS_SYSINIT_ITEM(
   RTEMS_SYSINIT_ORDER_MIDDLE
 );
 
-/* Initialize I/O drivers.
- *
- * Driver Manager note:
- * All drivers may not be registered yet. Drivers will dynamically
- * be initialized when registered in level 2,3 and 4.
- */
-RTEMS_SYSINIT_ITEM(
-  _IO_Initialize_all_drivers,
-  RTEMS_SYSINIT_DEVICE_DRIVERS,
-  RTEMS_SYSINIT_ORDER_MIDDLE
-);
-
 void rtems_initialize_executive(void)
 {
   const rtems_sysinit_item *item;
diff --git a/cpukit/sapi/src/iodefault.c b/cpukit/sapi/src/iodefault.c
new file mode 100644
index 00..114a419d19
--- /dev/null
+++ b/cpukit/sapi/src/iodefault.c
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup ClassicIO
+ *
+ * @brief This file contains definitions of IO drivers data structures for the
+ * default application configuration.
+ */
+
+/*
+ * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY D

Re: Waf Build System Status in RTEMS?

[Hesham Almatary]

On Tue, 25 Feb 2020 at 11:54, Sebastian Huber
 wrote:
>
> On 25/02/2020 11:00, Hesham Almatary wrote:
> > On Mon, 24 Feb 2020 at 22:50, Chris Johns  wrote:
> >> On 21/2/20 11:11 pm, Sebastian Huber wrote:
> >>> On 21/02/2020 12:26, Hesham Almatary wrote:
>  On Fri, 21 Feb 2020 at 11:07, Sebastian Huber
> wrote:
> > Hello Hesham,
> >
> > On 20/02/2020 16:40, Hesham Almatary wrote:
> >> Hello,
> >>
> >> Are there any progress updates to the Waf build system integration in 
> >> RTEMS?
> >>
> >> I have pulled [1] and it seems like it hasn't got many updates since
> >> December. I wonder what's still remaining/blocking to merge it, or at
> >> least push it as a development branch (without re-writing history)
> >> that others, including me, can use it and submit patches against.
> >>
> >> [1] git://git.rtems.org/sebh/rtems.git
> > technically, the new build system is ready for integration into the
> > master branch. I would need about one day to rebase and test it before
> > the push. The integration is currently blocked since Chris and Joel had
> > no time to look at it.
> >
>  Thanks for your input, Sebastian. Is there a recommended branch I
>  should be based on? I noticed there's "build" and "build-next".
> >>> The "build" branch contains the state of the first review. I updated
> >>> "build-next" a couple of times to integrate the changes on the RTEMS 
> >>> master.
> >>>
>  Do you intend to re-write git history in either?
> >>> Yes, when I started with the build system work I didn't expect a more 
> >>> than two
> >>> months review period.
> >> I have discussed this merge with Joel. We have decided to release RTEMS 5 
> >> before
> >> we merge a new build system. A release with parallel build systems is 
> >> confusing
> >> and distracting.
> >>
> > That makes sense to me. I think we should both try to push for an
> > RTEMS release soon, and make the waf/build
> > branch more stable and/or in the view (e.g., push as an experimental
> > branch) for developer to use until a release comes out. I understand
> > another branch would incur more maintaibility efforts, but it will
> > also help make the the new build system more usable.
>
> I can do a forced update of the "build" branch with my latest version
> based on rebase of the current master by the end of the week.
> Afterwards, I can do merges from the master instead of forced pushes.
> This should enable you to base your work on this branch. You can also
> send me patches.
>
That will be great, thanks! I have WIP patches to both LLVM and
rtems/waf to build
for RISC-V BSPs. I'd like to move to rtems/waf in our local CI system
with our RTEMS
fork. Once I feel confident about those patches and tested them, I'll
submit them.

> Before the new build system is integrated in the master, I will do a
> final rebase to the master and squash commits.
>
OK, sounds good.

> >
> >> I think we are close to a release if master can stay stable. The milestone
> >> ticket page ...
> >>
> >>   https://devel.rtems.org/milestone/5.1
> >>
> >> ... shows 43 in progress and 2 closed. Help with the tickets will help 
> >> progress
> >> things.
> >>
> >> I am working on moving the libbsd release to the 5-freebsd-12 branch and 
> >> the
> >> side effects that causes. I will need reports of a libbsd release snapshort
> >> running on ...
> >>
> >>   beagleboneblack, imx7, xilinx_zynq_zedboard, qoriq_e500
> >>
> >> I can do this for the beagleboneblack and xilinx_zynq_zedboard.
> >>
> > I recently got libbsd working with RISC-V on QEMU. On my TODO list,
> > I'll create a soft SoC with DTB/FDT and devices for testing on an FPGA
> > board, I will report about that if I got some apps/tests reasonably
> > working.
> >
> >> Finally there is the FDT file managements, I would like a resolution on a
> >> suitable path to get FDT files into a release and at least one BSP to 
> >> support
> >> this. I have selected the BeagleBone Black because I have one to test on.
> >>
> > I can pitch in with RISC-V (QEMU and/or FPGA SoCs/board). I'd like for
> > FDT management to be as generic as could be across different
> > BSPs/architectures.
>
> The FreeBSD device tree support should be fairly architecture
> independent. However, it is not as good/complete/robust as the Linux
> device tree support. I am not in favour of adding an RTEMS-specific
> device tree support.
>
I might be more biased  to FreeBSD here, but I don't have strong
opinions about it yet.

> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.



--
Hesham
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/l

Coverity Scan broken?

[Sebastian Huber]

Hello,

the site

https://scan.coverity.com/projects/rtems

says the last scan was done on Jan 21, 2020. When I click on the View 
Defects page I see nothing.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
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: Coverity Scan broken?

[suyash singh]

After clicking view defects there is a loading bar then a webpage loads.
Select rtems from drop down on top left.

On Tue, Feb 25, 2020 at 7:49 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> the site
>
> https://scan.coverity.com/projects/rtems
>
> says the last scan was done on Jan 21, 2020. When I click on the View
> Defects page I see nothing.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] test for fegetround and fesetround

[Eshan dhawan]

---
 testsuites/psxtests/psxfenv01/init.c | 42 +++-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/testsuites/psxtests/psxfenv01/init.c 
b/testsuites/psxtests/psxfenv01/init.c
index 05f3cdc880..4339139c58 100644
--- a/testsuites/psxtests/psxfenv01/init.c
+++ b/testsuites/psxtests/psxfenv01/init.c
@@ -106,7 +106,47 @@ rtems_task Init(rtems_task_argument ignored)
   printf("fesetexceptflag ==> 0x%x\n", r);
 rtems_test_assert(r == 0);
 
- 
+
+/*test for fegetround() and fesetround()*/
+/*they have four main macros to be tested seperated by ifdef*/
+/* since all the architectures dont support them */
+/*the test cases gets and sets the rounding directions */
+#ifdef FE_TONEAREST
+
+r=fegetround();
+if(r)
+   printf("fegetround ==> 0x%x\n", r);
+rtems_test_assert(r == FE_TONEAREST) ;   
+#endif
+#ifdef FE_TOWARDZERO
+
+  r=fesetround(FE_TOWARDZERO);
+  if(r)
+   printf("fesetround ==> 0x%x\n", r); 
+  rtems_test_assert(r == 0) ;
+  rtems_test_assert(fegetround() == FE_TOWARDZERO) ;
+#endif
+#ifdef FE_DOWNWARD
+  
+  r=fesetround(FE_DOWNWARD);
+  if(r)
+   printf("fesetround ==> 0x%x\n", r); 
+  rtems_test_assert(r == 0) ;
+  rtems_test_assert(fegetround() == FE_DOWNWARD) ;
+#endif
+#ifdef FE_UPWARD
+  r=fesetround(FE_UPWARD);
+  if(r)
+   printf("fesetround ==> 0x%x\n", r); 
+  rtems_test_assert(r == 0) ;
+  rtems_test_assert(fegetround() == FE_UPWARD) ;
+#endif
+#ifdef FE_TONEAREST
+  r=fesetround(FE_TONEAREST);
+  if(r)
+   printf("fesetround ==> 0x%x\n", r); 
+  rtems_test_assert(r == 0) ;
+#endif
 
 
 #ifdef FE_DIVBYZERO
-- 
2.17.1

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

Coverity false positive pattern

[suyash singh]

Coverity shows value_overwrite errors for variables which are reassigned
new values. What should be the procedure to prevent these?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Coverity Scan broken?

[Joel Sherrill]

Coverity Scan builds are not done automatically. If you ever need a new
one, just ask.

I just did a Coverity build and submitted it. It may take a while for the
Scan machinery to
see it after it completes for me. I have seen them take minutes and days.

--joel

On Tue, Feb 25, 2020 at 8:54 AM suyash singh 
wrote:

> After clicking view defects there is a loading bar then a webpage loads.
> Select rtems from drop down on top left.
>
> On Tue, Feb 25, 2020 at 7:49 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Hello,
>>
>> the site
>>
>> https://scan.coverity.com/projects/rtems
>>
>> says the last scan was done on Jan 21, 2020. When I click on the View
>> Defects page I see nothing.
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone   : +49 89 189 47 41-16
>> Fax : +49 89 189 47 41-09
>> E-Mail  : sebastian.hu...@embedded-brains.de
>> 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
>
> ___
> 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: Coverity false positive pattern

[Joel Sherrill]

On Tue, Feb 25, 2020 at 9:47 AM suyash singh 
wrote:

> Coverity shows value_overwrite errors for variables which are reassigned
> new values. What should be the procedure to prevent these?
>

When I have seen these in the past, they indicate a case where a variable
is assigned
and assigned later without the first value being used. Is this what you are
seeing?

What file and line?

We sometimes assign a variable 0 when declaring it to avoid gcc warning
about used
before initialized. It wouldn't surprise me if Scan didn't always like that.

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

Bump Newlib?

[Joel Sherrill]

Hi

Corinna just pushed my patch to resolve the newlib symlink on MSYS2 issue.
I think Chris had found a way to work around this in the RSB.

Anyway, there is at least one other patch of interest. Is it time to bump
the
newlib version?

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

Re: Coverity Scan broken?

[Sebastian Huber]

- Am 25. Feb 2020 um 15:54 schrieb suyash singh suyashsingh...@gmail.com:

> After clicking view defects there is a loading bar then a webpage loads.
> Select rtems from drop down on top left.

My projects list is empty.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Coverity false positive pattern

[suyash singh]

Yes it is showing for unused values

For example at line 262 in
https://scan5.coverity.com/reports.htm#v53137/p10069/fileInstanceId=164938787&defectInstanceId=45953284&mergedDefectId=1399751

On Tue, Feb 25, 2020 at 9:21 PM Joel Sherrill  wrote:

>
>
> On Tue, Feb 25, 2020 at 9:47 AM suyash singh 
> wrote:
>
>> Coverity shows value_overwrite errors for variables which are reassigned
>> new values. What should be the procedure to prevent these?
>>
>
> When I have seen these in the past, they indicate a case where a variable
> is assigned
> and assigned later without the first value being used. Is this what you
> are seeing?
>
> What file and line?
>
> We sometimes assign a variable 0 when declaring it to avoid gcc warning
> about used
> before initialized. It wouldn't surprise me if Scan didn't always like
> that.
>
> --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

Re: Coverity Scan broken?

[suyash singh]

As far as I know you may need to get yourself added to the project. Sign
up/Sign in then go to https://scan.coverity.com/projects/rtems and get
yourself added. I think a button will say "add me to the project".

On Tue, Feb 25, 2020 at 9:36 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> - Am 25. Feb 2020 um 15:54 schrieb suyash singh
> suyashsingh...@gmail.com:
>
> > After clicking view defects there is a loading bar then a webpage loads.
> > Select rtems from drop down on top left.
>
> My projects list is empty.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] test for fegetround and fesetround

[Eshan Dhawan]

added tests for fegetround and fesetround in psxtests / psxfenv01

fegetround fails to send the rounding direction due to soft float and
returns to_nearest or zero  in the cases
fesetround sends zero if the rounding direction is set and sends anything
else if the function fails to set the rounding direction

can you check the patch for correctness

- Eshan

On Tue, Feb 25, 2020 at 8:26 PM Eshan dhawan 
wrote:

> ---
>  testsuites/psxtests/psxfenv01/init.c | 42 +++-
>  1 file changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/testsuites/psxtests/psxfenv01/init.c
> b/testsuites/psxtests/psxfenv01/init.c
> index 05f3cdc880..4339139c58 100644
> --- a/testsuites/psxtests/psxfenv01/init.c
> +++ b/testsuites/psxtests/psxfenv01/init.c
> @@ -106,7 +106,47 @@ rtems_task Init(rtems_task_argument ignored)
>printf("fesetexceptflag ==> 0x%x\n", r);
>  rtems_test_assert(r == 0);
>
> -
> +
> +/*test for fegetround() and fesetround()*/
> +/*they have four main macros to be tested seperated by ifdef*/
> +/* since all the architectures dont support them */
> +/*the test cases gets and sets the rounding directions */
> +#ifdef FE_TONEAREST
> +
> +r=fegetround();
> +if(r)
> +   printf("fegetround ==> 0x%x\n", r);
> +rtems_test_assert(r == FE_TONEAREST) ;
> +#endif
> +#ifdef FE_TOWARDZERO
> +
> +  r=fesetround(FE_TOWARDZERO);
> +  if(r)
> +   printf("fesetround ==> 0x%x\n", r);
> +  rtems_test_assert(r == 0) ;
> +  rtems_test_assert(fegetround() == FE_TOWARDZERO) ;
> +#endif
> +#ifdef FE_DOWNWARD
> +
> +  r=fesetround(FE_DOWNWARD);
> +  if(r)
> +   printf("fesetround ==> 0x%x\n", r);
> +  rtems_test_assert(r == 0) ;
> +  rtems_test_assert(fegetround() == FE_DOWNWARD) ;
> +#endif
> +#ifdef FE_UPWARD
> +  r=fesetround(FE_UPWARD);
> +  if(r)
> +   printf("fesetround ==> 0x%x\n", r);
> +  rtems_test_assert(r == 0) ;
> +  rtems_test_assert(fegetround() == FE_UPWARD) ;
> +#endif
> +#ifdef FE_TONEAREST
> +  r=fesetround(FE_TONEAREST);
> +  if(r)
> +   printf("fesetround ==> 0x%x\n", r);
> +  rtems_test_assert(r == 0) ;
> +#endif
>
>
>  #ifdef FE_DIVBYZERO
> --
> 2.17.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Coverity Scan broken?

[Gedare Bloom]

It's working for me. I see the results from Joel's recent run. Maybe
try again. The interface has been changed, and I don't see any results
for other projects (RTEMS-Newlib, RTEMS-Tools).

On Tue, Feb 25, 2020 at 9:06 AM Sebastian Huber
 wrote:
>
> - Am 25. Feb 2020 um 15:54 schrieb suyash singh suyashsingh...@gmail.com:
>
> > After clicking view defects there is a loading bar then a webpage loads.
> > Select rtems from drop down on top left.
>
> My projects list is empty.
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 00/44] Split up confdefs.h

[Gedare Bloom]

Thanks for the change.

On Tue, Feb 25, 2020 at 4:38 AM Sebastian Huber
 wrote:
>
> Hello,
>
> I checked in this patch set. The new header files use the new header
> file template:
>
> https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#c-c-header-file-template
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Coverity false positive pattern

[Gedare Bloom]

On Tue, Feb 25, 2020 at 9:38 AM suyash singh  wrote:
>
> Yes it is showing for unused values
>
> For example at line 262 in 
> https://scan5.coverity.com/reports.htm#v53137/p10069/fileInstanceId=164938787&defectInstanceId=45953284&mergedDefectId=1399751
>
That appears to be legitimate. Analysis now has to be made whether the
value written should have been consumed somewhere, or if it is OK to
remove the assignment.

> On Tue, Feb 25, 2020 at 9:21 PM Joel Sherrill  wrote:
>>
>>
>>
>> On Tue, Feb 25, 2020 at 9:47 AM suyash singh  
>> wrote:
>>>
>>> Coverity shows value_overwrite errors for variables which are reassigned 
>>> new values. What should be the procedure to prevent these?
>>
>>
>> When I have seen these in the past, they indicate a case where a variable is 
>> assigned
>> and assigned later without the first value being used. Is this what you are 
>> seeing?
>>
>> What file and line?
>>
>> We sometimes assign a variable 0 when declaring it to avoid gcc warning 
>> about used
>> before initialized. It wouldn't surprise me if Scan didn't always like that.
>>
>> --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: Coverity false positive pattern

[Joel Sherrill]

On Tue, Feb 25, 2020, 3:00 PM Gedare Bloom  wrote:

> On Tue, Feb 25, 2020 at 9:38 AM suyash singh 
> wrote:
> >
> > Yes it is showing for unused values
> >
> > For example at line 262 in
> https://scan5.coverity.com/reports.htm#v53137/p10069/fileInstanceId=164938787&defectInstanceId=45953284&mergedDefectId=1399751
> >
> That appears to be legitimate. Analysis now has to be made whether the
> value written should have been consumed somewhere, or if it is OK to
> remove the assignment.
>

Thanks for the analysis but please remember that Scan requires an account.
When asking about a specific piece of code, it is better to link to the
lone using git.rtems.org.

I am out of town and on my phone. I could probably comment looking at git,
but not with a scan link. That site is way too busy for a small screen. :)

--joel

>
> > On Tue, Feb 25, 2020 at 9:21 PM Joel Sherrill  wrote:
> >>
> >>
> >>
> >> On Tue, Feb 25, 2020 at 9:47 AM suyash singh 
> wrote:
> >>>
> >>> Coverity shows value_overwrite errors for variables which are
> reassigned new values. What should be the procedure to prevent these?
> >>
> >>
> >> When I have seen these in the past, they indicate a case where a
> variable is assigned
> >> and assigned later without the first value being used. Is this what you
> are seeing?
> >>
> >> What file and line?
> >>
> >> We sometimes assign a variable 0 when declaring it to avoid gcc warning
> about used
> >> before initialized. It wouldn't surprise me if Scan didn't always like
> that.
> >>
> >> --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: Coverity false positive pattern

[Chris Johns]

On 26/2/20 8:00 am, Gedare Bloom wrote:
> On Tue, Feb 25, 2020 at 9:38 AM suyash singh  wrote:
>>
>> Yes it is showing for unused values
>>
>> For example at line 262 in 
>> https://scan5.coverity.com/reports.htm#v53137/p10069/fileInstanceId=164938787&defectInstanceId=45953284&mergedDefectId=1399751
>>
> That appears to be legitimate. Analysis now has to be made whether the
> value written should have been consumed somewhere, or if it is OK to
> remove the assignment.

This is imported code. Should upstream be checked first to see if there is a
newer version?

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

Re: Coverity false positive pattern

[Joel Sherrill]

On Tue, Feb 25, 2020, 6:10 PM Chris Johns  wrote:

> On 26/2/20 8:00 am, Gedare Bloom wrote:
> > On Tue, Feb 25, 2020 at 9:38 AM suyash singh 
> wrote:
> >>
> >> Yes it is showing for unused values
> >>
> >> For example at line 262 in
> https://scan5.coverity.com/reports.htm#v53137/p10069/fileInstanceId=164938787&defectInstanceId=45953284&mergedDefectId=1399751
> >>
> > That appears to be legitimate. Analysis now has to be made whether the
> > value written should have been consumed somewhere, or if it is OK to
> > remove the assignment.
>
> This is imported code. Should upstream be checked first to see if there is
> a
> newer version?
>

Yes. That's always the first answer.

Also check we define conditionals correctly as the upstream's build system
would. I don't see how the ifdefs could cause this issue at first glance,
but...

And if the code is the same upstream, then we report it to them.


> 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: SPDX License Identifier Only and Full Copy?

[Chris Johns]

On 24/2/20 6:52 pm, Sebastian Huber wrote:
> Hello,
> 
> I updated the File Template section:
> 
> https://docs.rtems.org/branches/master/eng/coding-file-hdr.html
> 
> Please have a look at it and check if it is all right for you.
> 

Does there need to be something about code copied into the source tree?

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

Re: Waf Build System Status in RTEMS?

[Chris Johns]

On 25/2/20 10:54 pm, Sebastian Huber wrote:
> On 25/02/2020 11:00, Hesham Almatary wrote:
>> On Mon, 24 Feb 2020 at 22:50, Chris Johns  wrote:
>>> On 21/2/20 11:11 pm, Sebastian Huber wrote:
 On 21/02/2020 12:26, Hesham Almatary wrote:
> On Fri, 21 Feb 2020 at 11:07, Sebastian Huber
>    wrote:
>> Hello Hesham,
>>
>> On 20/02/2020 16:40, Hesham Almatary wrote:
>>> Hello,
>>>
>>> Are there any progress updates to the Waf build system integration in 
>>> RTEMS?
>>>
>>> I have pulled [1] and it seems like it hasn't got many updates since
>>> December. I wonder what's still remaining/blocking to merge it, or at
>>> least push it as a development branch (without re-writing history)
>>> that others, including me, can use it and submit patches against.
>>>
>>> [1] git://git.rtems.org/sebh/rtems.git
>> technically, the new build system is ready for integration into the
>> master branch. I would need about one day to rebase and test it before
>> the push. The integration is currently blocked since Chris and Joel had
>> no time to look at it.
>>
> Thanks for your input, Sebastian. Is there a recommended branch I
> should be based on? I noticed there's "build" and "build-next".
 The "build" branch contains the state of the first review. I updated
 "build-next" a couple of times to integrate the changes on the RTEMS 
 master.

> Do you intend to re-write git history in either?
 Yes, when I started with the build system work I didn't expect a more than 
 two
 months review period.
>>> I have discussed this merge with Joel. We have decided to release RTEMS 5 
>>> before
>>> we merge a new build system. A release with parallel build systems is 
>>> confusing
>>> and distracting.
>>>
>> That makes sense to me. I think we should both try to push for an
>> RTEMS release soon, and make the waf/build
>> branch more stable and/or in the view (e.g., push as an experimental
>> branch) for developer to use until a release comes out. I understand
>> another branch would incur more maintaibility efforts, but it will
>> also help make the the new build system more usable.
> 
> I can do a forced update of the "build" branch with my latest version based on
> rebase of the current master by the end of the week. Afterwards, I can do 
> merges
> from the master instead of forced pushes. This should enable you to base your
> work on this branch. You can also send me patches.
> 
> Before the new build system is integrated in the master, I will do a final
> rebase to the master and squash commits.
> 
>>
>>> I think we are close to a release if master can stay stable. The milestone
>>> ticket page ...
>>>
>>>   https://devel.rtems.org/milestone/5.1
>>>
>>> ... shows 43 in progress and 2 closed. Help with the tickets will help 
>>> progress
>>> things.
>>>
>>> I am working on moving the libbsd release to the 5-freebsd-12 branch and the
>>> side effects that causes. I will need reports of a libbsd release snapshort
>>> running on ...
>>>
>>>   beagleboneblack, imx7, xilinx_zynq_zedboard, qoriq_e500
>>>
>>> I can do this for the beagleboneblack and xilinx_zynq_zedboard.
>>>
>> I recently got libbsd working with RISC-V on QEMU. On my TODO list,
>> I'll create a soft SoC with DTB/FDT and devices for testing on an FPGA
>> board, I will report about that if I got some apps/tests reasonably
>> working.
>>
>>> Finally there is the FDT file managements, I would like a resolution on a
>>> suitable path to get FDT files into a release and at least one BSP to 
>>> support
>>> this. I have selected the BeagleBone Black because I have one to test on.
>>>
>> I can pitch in with RISC-V (QEMU and/or FPGA SoCs/board). I'd like for
>> FDT management to be as generic as could be across different
>> BSPs/architectures.
> 
> The FreeBSD device tree support should be fairly architecture independent.
> However, it is not as good/complete/robust as the Linux device tree support. I
> am not in favour of adding an RTEMS-specific device tree support.

What do you mean by "RTEMS-specific device tree support"? We have RTEMS support
for FDT in the kernel code and libbsd.

So again in case I was not making myself clear, I feel FDT support as it stands
is partially implemented and I regret not raising this before now. Having code
to load blobs and drivers that reference blobs is only one part of using FDT,
you need matching and valid FDT sources and blobs and this means we need to
manage the FDT source and maybe create blobs our code references (ie overlays).
As stated I am not in favor of documented URLs etc because they disappear or
change plus it breaks releases as it does not meet our long time requirement for
releases having all files contained in the release held on our servers.

This is blocking a release.

I am looking for solutions to this issue that we can work worth.

Chris
___
devel mailing lis

Re: Update to waf 2.0.19?

[Chris Johns]

On 25/2/20 7:02 pm, Sebastian Huber wrote:
> Hello,
> 
> in order to close this bug:
> 
> https://devel.rtems.org/ticket/3569
> 
> I would like to update waf to the latest version 2.0.19 in:
> 
> rtems-docs
> rtems-tools
> rtems-libbsd
> rtems-examples
> 

What testing have you done and which hosts?

I do this by using a version in my path or with an absolute path.

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

Re: Project query

[Chris Johns]

On 21/2/20 3:51 am, Hesham Almatary wrote:
> On Wed, 19 Feb 2020 at 21:38, Joel Sherrill  wrote:
>> On Wed, Feb 19, 2020, 12:58 PM Gedare Bloom  wrote:
>>>
>>> On Wed, Feb 19, 2020 at 9:45 AM suyash singh  
>>> wrote:

 sorry clicked reply instead of "reply all"


 I don't have any boards and experience. What interests me about this 
 project is that microblaze is used in FPGA which are used in a variety of 
 fields like science, medicine and defence. Porting an os to it would be a 
 great contribution

>>> Hi Suyash,
>>>
>>> For any BSP/port development project we require students to have
>>> access ahead of time to the hardware they would need to successfully
>>> complete the project.  So I don't think the microblaze would be a good
>>> project idea for you. I hope you can look for some more ideas that
>>> might interest you.
>>>
>>> Gedare
>>>
 On Tue, Feb 18, 2020 at 9:30 PM Gedare Bloom  wrote:
>
> Hello Suyash,
>
> On Tue, Feb 18, 2020 at 8:07 AM suyash singh  
> wrote:
>>
>> Hello,
>>
>> I am interested in "Port RTEMS to MicroBlaze"
>> https://devel.rtems.org/ticket/2902
>>
>> How do I start understanding the previous work done and understanding 
>> what else needs to be done?
>>
> Hopefully Hesham or Joel will chime in on their effort.
>
> Do you have one or more Xilinx FPGA boards that you can use? Do you
> have any experience with Microblaze? If not, what interests you about
> this project?
>>
>>
>> Just to toss some info in. Qemu and gdb both have Microblaze simulation. The 
>> Qemu should be close enough to real hardware to be suitable for a complete 
>> port.
>>
>> Graham has a repo somewhere with the port in its current state.
>>
> https://github.com/heshamelmatary/rtems-microblaze
> 
>> I think this is likely a viable project with the Qemu simulator.
>>
> AFAIR, there were licence issues merging this project which copies some of
> Xilinx's drivers/code to RTEMS.

The latest Xilinx SDKs have an acceptable license. Maybe updating the drivers
you have will let us merge the work.

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

Re: Update sphinx_rtd_theme to 68a19ca / 0.4.3.dev0.

[Chris Johns]

On 23/2/20 12:39 pm, Amar Takhar wrote:
> I've been running this version for a while now.  It should fix any issues 
> we're 
> having I tested it and it works fine.
> 
> See here for a ticket the patch is rather large:
> 
>   https://devel.rtems.org/ticket/3880
> 

Does this work on sync.rtems.org with a suitable virtualenv?

This is how I build the online docs. :)

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

Re: Waf Build System Status in RTEMS?

[Amar Takhar]

I've been working on setting up hardware testing in my lab at home.  The Device 
Tree documentation we have currently is horrible:

  https://docs.rtems.org/branches/master/user/exe/device-tree.html

It's a list of command and descriptions about what it is but not what they do.

For instance look at section 8.8.1.  The 'dtc' command?  Where do I get it?  I 
have one on FreeBSD .. what if I'm running Linux is it the same 'dtc' command?  
I have FreeBSD from 6 years ago will that work or what about the CURRENT 
machine 
I have.  There is no minimum version.

Also, I'm aware this command exists on Linux.  except:

root@beer:~# dtc
bash: dtc: command not found

root@beer:~# apt-get install dtc
Reading package lists... Done
Building dependency tree   
Reading state information... Done
E: Unable to locate package dtc

This on a Debian 10 machine.

So let me search for it:

root@beer:~# aptitude search dtc
p   ddtc   - Deal with ddts mails   
p   dtc-xen- SOAP daemon and scripts to allow contr 
p   dtc-xen-firewall   - small firewall script for your dom0
p   python-dtcwt   - Dual-Tree Complex Wavelet Transform li 
p   python-dtcwt-doc   - documentation for dtcwt
p   python3-dtcwt  - Dual-Tree Complex Wavelet Transform li 
p   sbox-dtc   - CGI chroot wrapper script for safer ho 

Nope, nothing, but of course *I* know what it is the documentation doesn't tell 
me, though:

root@beer:~# aptitude search device|grep -i tree
p  device-tree-compiler - Device Tree Compiler for Flat Device Trees

[install]

root@beer:~# dtc -v
Version: DTC 1.5.0

Finally.. but now I'm not so sure I'm there because on FreeBSD:

verm@peach# dtc -v 
Version: dtc 0.5.0 compatible with gpl dtc 1.4.7

Are these really the same tool?  Which one do I use?  What version?  How do I 
even know that the output is correct do I just run the commands blindly and 
hope 
it works?


FreeBSD is another story.  It does have a package called 'dtc' which I had to 
install to get 'fdtoverlay'...which is interesting because the 'dtc' command 
exists in FreeBSD as part of the base:

root@peach# which dtc
/usr/bin/dtc

Yet there is no 'fdtoverlay'.  I had to install the 'dtc' package -- a command 
I 
already have mind you to get 'fdtoverlay'.  Again these are things I know how 
to 
find but a new user has no chance.. also:

root@peach# fdtoverlay -V
Version: DTC 1.4.7

It's not even 1.5.. and now I have two 'dtc' commands one in /usr/bin/dtc and 
another in /usr/local/bin/dtc.  Which one do I use and what version.


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

Re: rtems-boot-image tool: Raspberry Pi

[Chris Johns]

On 22/2/20 1:45 am, G. S. Niteesh wrote:
> Hi,
> 
> This is regarding adding RPi support to the boot image generation tool.
> 
> The boot process for Raspberry Pi is very unconventional. The GPU starts
> first, initializes RAM, other hardware, loads the bootloaders and then starts
> the ARM CPU.
> 
> The minimum files that are required to boot an RPi are
> bootcode.bin, startx.elf, fixup.dat, kernel.img, config.txt
> There are also other variants of startx.elf and fixup.dat.
> Please have a look
> at https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md
> for information on the variants.
> 
> From what I have tried on my Rpi3 model b v1.2 the minimum files that are
> required are start_x.elf, fixup_x.dat, bootcode.bin, kernel.img, config.txt
> But for this to work, we must add start_x=1 to config.txt because by default
> start.elf is loaded.

I would have look at how the tool maps to RPi to know if it needs more work :)

> 
> So, what should be the values for the first and second stages in 
> rtems-boot.ini
> for Rpi?

Would this be bootcode.bin?

> And also wouldn't it be nice if we could add a files field, which will copy 
> the
> specified files to the image? This would save a lot of typing in case of RPi

Do you have an example?

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

Re: tar/psx/bsdtar on CentOS 8

[Chris Johns]

On 25/2/20 5:09 am, Joel Sherrill wrote:
> Hi
> 
> CentOS 8 does not have a package for pax. It does have a package for bsdtar. 
> 
> Is bsdtar sufficient for the tests? I don't call the precise issue we favored
> pax over
> GNU tar.
> 
> If so, could testsuites/libtests/configure.ac  accept 
> both?
> 
> Pax appears to be used only for the dl* and tar* tests. I had thought about it
> not being a hard fail but those seem like bad tests to drop out.

Does RTEMS understand the standard tar format? If PAX format is needed does your
tar accept `--posix` or `--format pax`. I am happy for a change like this but it
may only work on FreeBSD ;)

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

Re: [PATCH] Fix typo in error message

[Chris Johns]

Pushed.

Thanks
Chris

On 25/2/20 6:09 am, cl...@isep.ipp.pt wrote:
> From: Cláudio Maia 
> 
> ---
>  tester/rtems-test | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tester/rtems-test b/tester/rtems-test
> index 3eb5701..520366a 100755
> --- a/tester/rtems-test
> +++ b/tester/rtems-test
> @@ -39,4 +39,4 @@ elif test -f ${base}/share/rtems/${PYTHON_WRAPPER}; then
>PYTHON_CMD=${base}/share/rtems/${cmd}
>. ${base}/share/rtems/${PYTHON_WRAPPER}
>  fi
> -echo "error: RTEMS Toolkit python wrapper not found, plrease report"
> +echo "error: RTEMS Toolkit python wrapper not found, please report"
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Device Tree Blob for Beaglebone Black?

[Chris Johns]

On 25/2/20 5:30 pm, Christian Mauderer wrote:
> On 24/02/2020 23:26, Chris Johns wrote:
>>> On 24 Feb 2020, at 7:39 pm, Christian Mauderer 
>>>  wrote:
>>>
>>> On 24/02/2020 07:01, Chris Johns wrote:


>> On 24 Feb 2020, at 5:32 am, Christian Mauderer  
>> wrote:
>
> On 23/02/2020 17:07, Alan Cudmore wrote:
>> I have been trying to bring up RTEMS with rtems-libbsd on the
>> beaglebone black (latest master).
>>
>> I can run the regular RTEMS samples on the board, and a couple of the
>> rtems-libbsd testsuite examples run as well.
>>
>> The samples such as ping01 and usb01 get a fatal exception in the
>> function fdt_ro_probe_ , leading me to believe that maybe I am not
>> using the correct device tree blob.
>>
>> I'm using the instructions here:
>> https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
>>
>> And I have am loading am335x-boneblack.dtb that I copied from a linux
>> u-boot build. The instructions talk about getting the one from the
>> FreeBSD repository, but there are many other files included in that
>> dts source.
>>
>> What dtb is normally used for the Beaglebone black RTEMS libbsd testing?
>>
>> Is the dtb needed for the non-libbsd BSP?
>>
>> Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
>> libbsd to get ethernet?
>>
>> Thanks,
>> Alan
>
> Hello Alan,
>
> I recommend to use the FreeBSD device trees. libbsd is FreeBSD based and
> therefore works best with them. Normally I would suggest to use the
> version matching the FreeBSD commit used in libbsd. But unfortunately in
> the last commit that doesn't seem to work. Vijay had some problems with
> it and noted that the version from FreeBSD commit
> 19a6ceb89dbacf74697d493e48c388767126d418 works fine.

 Is this with 5 branch in Libbsd?

 I am a little confused about the branch to package in a release and also 
 which FDT files we need for which branch. If different I feel a release 
 will makes things more complicated. This flies into the BSP  vertical 
 stack building in the RSB. 

 I am working on releasing and I hope this does not block things. 

 Chris
>>>
>>> Hello Chris,
>>>
>>> the non-working device tree is for the master branch from a few weeks
>>> back. I didn't tested it with the 5-freebsd-12 branch.
>>
>> Which FDT files are needed for the 5-freebsd-12 branch? I could assume the
>> 12-release branch in the FreeBSD repo however this is a guess, unfriendly on 
>> our
>> part and time consuming to sort out. I am not sure how we improve this and 
>> how
>> we should manage FDT source but we need to address the issue.
> 
> Same problem here. The topic already popped up multiple times and I
> can't really answer it.

I know but we have too.

> Like I said multiple time: My approach is to use the fdt that matches
> the FreeBSD commit used in libbsd. So for the 5-freebsd-12 branch that
> is the one from FreeBSD commit 0d1c391321b34b3025cf0e72f2231d836ff76da8.
> But it's not a rule that works for all BSPs. Some BSPs are adapted to
> use a board manufacturers DTB or some random Linux one.

This means users need a clone of the FreeBSD repo  and that means a bigger
disk array and a larger net pipe ;)

> 
>>
>> There are long time RTEMS users including myself struggling with this so it 
>> is a
>> clear indication in my mind we have an issue we need to improve.
>>
 Again: In the normal case I would just suggest to use the FDT sources
>>> that match the FreeBSD commit we use for libbsd. That worked best for me
>>> in the past. But in the current referenced commit FreeBSD has updated
>>> the device tree sources to the ones from a recent Linux version and the
>>> drivers haven't been adapted yet (on master - I expect that it works
>>> better on 5-freebsd-12).
>>>
>>> Regarding the release: I don't think you pack the FDT files (yet), do
>>> you? 
>>
>> No I do not but then should I be the one doing this in a release. I would 
>> have
>> thought this is a core issue for the BSPs that depend on FDT blobs at 
>> runtime.
>>
>> I am up to libbsd with the release packaging. I can build a beagleboneblack 
>> as a
>> vertical stack up to libbsd and then I hit the issue of using master and not 
>> the
>> 5-freebsd-12 branch and after that is the rtems_waf submodule naming. I would
>> like to resolve this in the RSB however before I do this I would like to 
>> resolve
>> the FDT files so I make a single pass over this.
>>
>>> So I don't see why there should be a reason for this topic to block
>>> the release.
>>
>> I do. To not handle this is to create a release where the files in the 
>> release
>> package crash a beagleboneblack with libbsd unless you manually get the 
>> correct
>> set of FDT files. This is unhelpful for users in a release context.
>>
>> Consider a release called rtems-libbsd-5.0.5.tar.xz 

Re: RTEMS 5 libdl bugs

[Chris Johns]

On 25/2/20 6:38 pm, Sebastian Huber wrote:
> Hello,
> 
> there are six libdl bugs reported for RTEMS 5:
> 
> https://devel.rtems.org/query?status=accepted&status=assigned&status=reopened&component=lib%2Fdl&milestone=5.1&group=status&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version&order=priority
> 
> 
> Are they release blockers or can they move to a new milestone?
> 

There is one I would like to merge .. #3693

> Chris, if you don't want to work on them please re-assign the tickets to Needs
> Funding.

Done.

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

Re: [PATCH] tester: Use prefix for rtems_tools by default

[Chris Johns]

On 25/2/20 7:33 pm, Sebastian Huber wrote:
> Hello Chris,
> 
> On 14/02/2020 07:14, Sebastian Huber wrote:
>> On 14/02/2020 03:54, Chris Johns wrote:
>>
>>> On 2020-02-12 17:27, Sebastian Huber wrote:
 Commit 72c684eff2cd932b4948e21902680a93473340c3 removed the default
 value of rtems_tools.  If the --rtems--tools option was omitted the
 rtems-test command printed lots of

 error: run.cfg:61: macro '%{rtems_tools}' not found

 error messages.
>>>
>>> I will need to think about this. I am wondering id removing the prefix code
>>> allowed the PATH to be used. 
>> I have rtems-test in the $PATH and calling it without --rtems-tools doesn't
>> work without this patch.
> 
> could you please have a look at this. Since the %{rtems_tools} macros needed 
> it
> should be defined:
> 
> grep -r rtems_tools --include '*.cfg'
> tester/rtems/testing/gdb.cfg:%define gdb_cmd
> %{rtems_tools}/%{bsp_arch}-rtems%{rtems_version}-gdb
> 

Please push this change. I thought I had responded but something must have gone
wrong. I am sorry about that.

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

Re: Update sphinx_rtd_theme to 68a19ca / 0.4.3.dev0.

[Amar Takhar]

On 2020-02-26 13:59 +1100, Chris Johns wrote:
> 
> Does this work on sync.rtems.org with a suitable virtualenv?
> 
> This is how I build the online docs. :)

Shouldn't be an issue at all it's in-source no new dependencies.  Try the patch 
and see if it works? :)  Works here!


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

Re: SPDX License Identifier Only and Full Copy?

[Gedare Bloom]

On Tue, Feb 25, 2020 at 6:57 PM Chris Johns  wrote:
>
> On 24/2/20 6:52 pm, Sebastian Huber wrote:
> > Hello,
> >
> > I updated the File Template section:
> >
> > https://docs.rtems.org/branches/master/eng/coding-file-hdr.html
> >
> > Please have a look at it and check if it is all right for you.
> >
>
> Does there need to be something about code copied into the source tree?
>
> Chris
Do you mean 3rd party code / code that is not licensed with 2-BSD?

> ___
> 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: SPDX License Identifier Only and Full Copy?

[Chris Johns]

On 26/2/20 3:06 pm, Gedare Bloom wrote:
> On Tue, Feb 25, 2020 at 6:57 PM Chris Johns  wrote:
>>
>> On 24/2/20 6:52 pm, Sebastian Huber wrote:
>>> Hello,
>>>
>>> I updated the File Template section:
>>>
>>> https://docs.rtems.org/branches/master/eng/coding-file-hdr.html
>>>
>>> Please have a look at it and check if it is all right for you.
>>>
>>
>> Does there need to be something about code copied into the source tree?
>>
>> Chris
> Do you mean 3rd party code / code that is not licensed with 2-BSD?
> 

Take this file ...

https://git.rtems.org/rtems/tree/cpukit/dtc/README.license

Does the procedure need to manage the process a user follows to add a file like
this? The procedure in the link covers code written by the user which is great
but not code that is imported. Should it?

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

Re: Update sphinx_rtd_theme to 68a19ca / 0.4.3.dev0.

[Chris Johns]

On 26/2/20 3:03 pm, Amar Takhar wrote:
> On 2020-02-26 13:59 +1100, Chris Johns wrote:
>>
>> Does this work on sync.rtems.org with a suitable virtualenv?
>>
>> This is how I build the online docs. :)
> 
> Shouldn't be an issue at all it's in-source no new dependencies.  Try the 
> patch 
> and see if it works? :)  Works here!

Great, I am OK with the patch being pused. If it breaks on sync it will show in
the build not updating and I am sure we can sort it out.

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

Re: Update sphinx_rtd_theme to 68a19ca / 0.4.3.dev0.

[Amar Takhar]

On 2020-02-26 15:27 +1100, Chris Johns wrote:
> 
> Great, I am OK with the patch being pused. If it breaks on sync it will show 
> in
> the build not updating and I am sure we can sort it out.

Okay great I'll do that now then thank you!


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

Re: SPDX License Identifier Only and Full Copy?

[Gedare Bloom]

On Tue, Feb 25, 2020 at 9:18 PM Chris Johns  wrote:
>
>
>
> On 26/2/20 3:06 pm, Gedare Bloom wrote:
> > On Tue, Feb 25, 2020 at 6:57 PM Chris Johns  wrote:
> >>
> >> On 24/2/20 6:52 pm, Sebastian Huber wrote:
> >>> Hello,
> >>>
> >>> I updated the File Template section:
> >>>
> >>> https://docs.rtems.org/branches/master/eng/coding-file-hdr.html
> >>>
> >>> Please have a look at it and check if it is all right for you.
> >>>
> >>
> >> Does there need to be something about code copied into the source tree?
> >>
> >> Chris
> > Do you mean 3rd party code / code that is not licensed with 2-BSD?
> >
>
> Take this file ...
>
> https://git.rtems.org/rtems/tree/cpukit/dtc/README.license
>
> Does the procedure need to manage the process a user follows to add a file 
> like
> this? The procedure in the link covers code written by the user which is great
> but not code that is imported. Should it?
>
> Chris
OK, I think of this as 3rd party code. This case is important to
capture in our processes, and I'm glad you pointed it out. We always
strive to minimize changes to 3rd party code to enhance
maintainability. However, I could see there are benefits to adding our
own header information to 3rd party source files, in order to capture
their license information in SPDX for automated compliance checking,
if nothing else.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: SPDX License Identifier Only and Full Copy?

[Chris Johns]

On 26/2/20 3:46 pm, Gedare Bloom wrote:
> On Tue, Feb 25, 2020 at 9:18 PM Chris Johns  wrote:
>>
>>
>>
>> On 26/2/20 3:06 pm, Gedare Bloom wrote:
>>> On Tue, Feb 25, 2020 at 6:57 PM Chris Johns  wrote:

 On 24/2/20 6:52 pm, Sebastian Huber wrote:
> Hello,
>
> I updated the File Template section:
>
> https://docs.rtems.org/branches/master/eng/coding-file-hdr.html
>
> Please have a look at it and check if it is all right for you.
>

 Does there need to be something about code copied into the source tree?

 Chris
>>> Do you mean 3rd party code / code that is not licensed with 2-BSD?
>>>
>>
>> Take this file ...
>>
>> https://git.rtems.org/rtems/tree/cpukit/dtc/README.license
>>
>> Does the procedure need to manage the process a user follows to add a file 
>> like
>> this? The procedure in the link covers code written by the user which is 
>> great
>> but not code that is imported. Should it?
>>
>> Chris
> OK, I think of this as 3rd party code. This case is important to
> capture in our processes, and I'm glad you pointed it out. We always
> strive to minimize changes to 3rd party code to enhance
> maintainability. However, I could see there are benefits to adding our
> own header information to 3rd party source files, in order to capture
> their license information in SPDX for automated compliance checking,
> if nothing else.

Yes there are conflicting requirements here. Maybe the procedure could suggest
working with the upstream project adding the head?

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

Re: Device Tree Blob for Beaglebone Black?

[Amar Takhar]

I've had to deal with this issue quite a lot in the past it can be really 
annoying having to maintain separate repositories where we have to 'pin' a 
version to the main repo.  We don't really have a choice here however I would 
suggest we do a mix of the two.


  1. Any source/permissive files be kept within the RTEMS repository.
  2. Binary blobs get ejected to a separate repository lets say 'rtems-fdt'.
  3. Source files with strict licensing gets the boot, too -- though we can 
 discuss how much we care about this.

How it would work is simple.  During configure if the required FDT files exist 
that's great we look for the two binaries we need and build them all as part of 
the normal building process.

If they are not found print a notice to the user to get the 'rtems-fdt' 
repository and point to it with a --rtems-fdt-path=  This is where it gets 
annoying because there are several steps to get the right file.  Generally we 
have to:

  1. Read a file stored within RTEMS that says what version of the FDT 
 repository to checkout.
  2. As part of configure this file needs to be loaded and the 'rtems-fdt'
 repository checked to see if it's at the right revision.
  3. If it as not at the right revision then the user will have to fix this 
 manually and re-run configure.
  4. Some BSPs may not even have the FDT files until you purchase a board.  Do 
 we have any of these cases?  Now we have a situation where we have no 
 revision *or* files and no way to test this code or ensure it even works.

Regardless for case #4 it's going to be a user issue to get the FDT files and 
our issue to suck these in.

It makes sense to do it this way for RTEMS as I don't see a reason to "punish" 
the BSPs where everything is free and open it would be great to have these 
'just 
work' and it is less maintenance for us longterm.


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

Re: [PATCH] RTEMS Docs: Fix search field

[Amar Takhar]

Hi Niteesh, I have pushed the upgrade to the latest version of the theme.

Can you confirm this fixes the search box for you?

Thank you!


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

Re: Waf Build System Status in RTEMS?

[Sebastian Huber]

On 26/02/2020 03:18, Chris Johns wrote:

The FreeBSD device tree support should be fairly architecture independent.
However, it is not as good/complete/robust as the Linux device tree support. I
am not in favour of adding an RTEMS-specific device tree support.

What do you mean by "RTEMS-specific device tree support"? We have RTEMS support
for FDT in the kernel code and libbsd.


I mean the higher level device tree support which deals with device 
enumeration (e.g. finding drivers for devices):


https://lists.rtems.org/pipermail/devel/2020-February/057049.html



So again in case I was not making myself clear, I feel FDT support as it stands
is partially implemented and I regret not raising this before now. Having code
to load blobs and drivers that reference blobs is only one part of using FDT,
you need matching and valid FDT sources and blobs and this means we need to
manage the FDT source and maybe create blobs our code references (ie overlays).
As stated I am not in favor of documented URLs etc because they disappear or
change plus it breaks releases as it does not meet our long time requirement for
releases having all files contained in the release held on our servers.

This is blocking a release.

I am looking for solutions to this issue that we can work worth.


Yes, we have only a partial support for device trees. It is better than 
nothing. For now, I would just document this in the user manual section 
of the BSP and give some advice. I usually use the device tree that 
ships with the devices. If a driver cannot cope with it, then I fix the 
driver.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
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] tester: Use prefix for rtems_tools by default

[Sebastian Huber]

On 26/02/2020 04:58, Chris Johns wrote:

On 25/2/20 7:33 pm, Sebastian Huber wrote:

Hello Chris,

On 14/02/2020 07:14, Sebastian Huber wrote:

On 14/02/2020 03:54, Chris Johns wrote:


On 2020-02-12 17:27, Sebastian Huber wrote:

Commit 72c684eff2cd932b4948e21902680a93473340c3 removed the default
value of rtems_tools.  If the --rtems--tools option was omitted the
rtems-test command printed lots of

 error: run.cfg:61: macro '%{rtems_tools}' not found

error messages.


I will need to think about this. I am wondering id removing the prefix code
allowed the PATH to be used.

I have rtems-test in the $PATH and calling it without --rtems-tools doesn't
work without this patch.


could you please have a look at this. Since the %{rtems_tools} macros needed it
should be defined:

grep -r rtems_tools --include '*.cfg'
tester/rtems/testing/gdb.cfg:%define gdb_cmd
%{rtems_tools}/%{bsp_arch}-rtems%{rtems_version}-gdb



Please push this change. I thought I had responded but something must have gone
wrong. I am sorry about that.


No problem, my last statement from you was "I will need to think about 
this.".


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
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-boot-image tool: Raspberry Pi

[G. S. Niteesh]

On Wed, Feb 26, 2020 at 8:39 AM Chris Johns  wrote:

> On 22/2/20 1:45 am, G. S. Niteesh wrote:
> > Hi,
> >
> > This is regarding adding RPi support to the boot image generation tool.
> >
> > The boot process for Raspberry Pi is very unconventional. The GPU starts
> > first, initializes RAM, other hardware, loads the bootloaders and then
> starts
> > the ARM CPU.
> >
> > The minimum files that are required to boot an RPi are
> > bootcode.bin, startx.elf, fixup.dat, kernel.img, config.txt
> > There are also other variants of startx.elf and fixup.dat.
> > Please have a look
> > at
> https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md
> > for information on the variants.
> >
> > From what I have tried on my Rpi3 model b v1.2 the minimum files that are
> > required are start_x.elf, fixup_x.dat, bootcode.bin, kernel.img,
> config.txt
> > But for this to work, we must add start_x=1 to config.txt because by
> default
> > start.elf is loaded.
>
> I would have look at how the tool maps to RPi to know if it needs more
> work :)
>
> >
> > So, what should be the values for the first and second stages in
> rtems-boot.ini
> > for Rpi?
>
> Would this be bootcode.bin?

For all models of RPi except RPi4 use bootcode.bin as the first stage. But
for RPi4 the bootcode.bin
is replaced by boot code in EEPROM.
Then the second stage would be start*.elf. And we might have an extra stage
depending on whether
U-Boot is used or not.

Please note that I have mentioned start*.elf. There are variants of
start.elf, I have mentioned them
below. But I guess start_x.elf could be used as the default firmware since
it has everything that a
user needs.
start.elf: The basic firmware for the GPU
start_x.elf:  Basic firmware with camera driver and extra video codecs
start_db.elf: Debug version of the firmware (but not sure whether start.elf
or start_x,elf)
start_cd.elf: is a cut-down version with no support hardware blocks like
codecs and 3D.
And there are variants of start.elf for RPi4 ( start4.elf, start4x.elf,
start4db.elf and start4cd.elf)

There is also an additional file fixup*.dat which is required for booting.
And also it is necessary
to make sure that they are matched pairs with start*.elf.

This below site has all this mentioned very clearly.
https://www.raspberrypi.org/documentation/configuration/boot_folder.md

> And also wouldn't it be nice if we could add a files field, which will
> copy the
> > specified files to the image? This would save a lot of typing in case of
> RPi
>
> Do you have an example?

Incase of RPi we have to provide additional files like config.txt and
fixup*.dat and maybe in
the user like to provide other additional files then it would nice to make
the "file" field to support
folders instead of repeating the field again and again for every additional
file.

Thank you,
Niteesh.

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

Re: Ticket #3515: covoar failure while running for full testsuites

[Vijay Kumar Banerjee]

On Fri, Feb 21, 2020 at 1:27 PM Bran S  wrote:

> On Wed, 19 Feb 2020 at 22:51, Vijay Kumar Banerjee
>  wrote:
> >
> >
> >
> > On Mon, Feb 17, 2020 at 12:08 AM Bran S  wrote:
> >>
> >> Hi Guys,
> >>
> > Hi Bran!
> >>
> >> I am trying to understand and solve Ticket #3515.
> >> https://devel.rtems.org/ticket/3515
> >>
> >> $ /home/user45/quick-start/rtems/5/share/rtems/tester/bin/covoar -
> >> -S
> /home/user45/quick-start/rtems/5/share/rtems/tester/rtems/testing/coverage/leon3-sis-symbols.ini
> >> -O leon3-sis-coverage -E
> >>
> /home/user45/quick-start/rtems/5/share/rtems/tester/rtems/testing/coverage/Explanations.txt
> >> -p RTEMS-5
> /home/user45/quick-start/build/b-leon3/sparc-rtems5/c/leon3/testsuites/fstests/fsclose01.exe
> >>
> >> The output of the above command is at:
> >> https://gist.github.com/archsbran/7834a931d52311c7b26842c6325d8d9a
> >>
> >> On the last line it can be seen that absence of `wait` symbol causes
> the error.
> >>
> >> I made some changes in ExecutableInfo.cc to print out the symbols
> >> being added into coverageMap.
> >> Added symbols can be seen from line 636 to 7236 at the above link.
> >> In those lines we can see that `wait` is not added into coverageMap.
> >>
> > Great work in finding the possible issue.
> >>
> >> I am new so the only thing I know about covoar is that it does
> >> coverage analysis.
> >> Any ideas on how to move further into solving this ?
> >
> > I added Chris in CC, he'll be able to tell us where to look for the
> source
> > of the error you found.
> > In general, you can follow covoar.cc file, which has the main `covoar`
> > function in it. That will be a good starting point.
> >
>
>
> Yeah, I traversed through the code in covoar.cc
>
> It goes something like:
>
> In covoar.cc: covar()
> at line 382: objdumpProcessor->load( exe, objdumpFile, err );
> Here, `exe` points to the executableinfo object, the one in which the
> coverageMap was created via createCoverageMap()
>
> Now inside objdumpProcessor->load()
> at line 301: finalizeSymbol() is called which further calls
> findCoverageMap() at line 35. This is the point where error occurs, as
> `wait` symbol is not found.
>
> Hi Bran,

Sorry, I couldn't find time to look into the details and I was hoping
someone
else will join in. You are in the right direction and found the function
that is
getting the error. Now that you have a function to follow, I will suggest
you to
run gdb on covoar and follow this function, especially where it's getting
the
symbols.
To run covoar on gdb do the following:
$gdb /path/to/covoar
(gdb) r - -S
/home/lunatic/development/rtems/rtems-tools/tester/rtems/testing/coverage/leon3-qemu-symbols.ini
 \
-O leon3-qemu-coverage \
-E
/home/lunatic/development/rtems/rtems-tools/tester/rtems/testing/coverage/Explanations.txt
\
-p RTEMS-5 /your/exe.exe

set a breakpoint at findCoverageMap() and see what it is doing.
Most likely, you'll be able to see where is it getting other symbols
from and why is "wait" not there, or if it's there, why is it skipping it.

Best regards,
Vijay

> The objdumpProcessor->load() function searches symbols in
> CoverageMap(via finalizeSymbol()) according to the symbols present in
> objdump generated at
> line 291: getFile( executableInformation->getFileName(), objdumpFile, err
> );
>
> The objdump is created using the executableinfo from which we loaded
> the symbols into CoverageMap, right ?
> Then is it so that the code missed out on the symbol while adding them
> into CoverageMap ?
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Update to waf 2.0.19?

[Sebastian Huber]

On 26/02/2020 03:22, Chris Johns wrote:

On 25/2/20 7:02 pm, Sebastian Huber wrote:

Hello,

in order to close this bug:

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

I would like to update waf to the latest version 2.0.19 in:

rtems-docs
rtems-tools
rtems-libbsd
rtems-examples



What testing have you done and which hosts?


I haven't done a lot of testing. I tried to build everything on my Linux 
machine. I checked also the rtems-tools on mingw64 and FreeBSD. I just 
hope that the change from 2.0.18 to 2.0.19 fixed only bugs.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
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: Ticket #3515: covoar failure while running for full testsuites

[Vijay Kumar Banerjee]

On Wed, Feb 26, 2020 at 12:28 PM Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

>
>
> On Fri, Feb 21, 2020 at 1:27 PM Bran S  wrote:
>
>> On Wed, 19 Feb 2020 at 22:51, Vijay Kumar Banerjee
>>  wrote:
>> >
>> >
>> >
>> > On Mon, Feb 17, 2020 at 12:08 AM Bran S  wrote:
>> >>
>> >> Hi Guys,
>> >>
>> > Hi Bran!
>> >>
>> >> I am trying to understand and solve Ticket #3515.
>> >> https://devel.rtems.org/ticket/3515
>> >>
>> >> $ /home/user45/quick-start/rtems/5/share/rtems/tester/bin/covoar -
>> >> -S
>> /home/user45/quick-start/rtems/5/share/rtems/tester/rtems/testing/coverage/leon3-sis-symbols.ini
>> >> -O leon3-sis-coverage -E
>> >>
>> /home/user45/quick-start/rtems/5/share/rtems/tester/rtems/testing/coverage/Explanations.txt
>> >> -p RTEMS-5
>> /home/user45/quick-start/build/b-leon3/sparc-rtems5/c/leon3/testsuites/fstests/fsclose01.exe
>> >>
>> >> The output of the above command is at:
>> >> https://gist.github.com/archsbran/7834a931d52311c7b26842c6325d8d9a
>> >>
>> >> On the last line it can be seen that absence of `wait` symbol causes
>> the error.
>> >>
>> >> I made some changes in ExecutableInfo.cc to print out the symbols
>> >> being added into coverageMap.
>> >> Added symbols can be seen from line 636 to 7236 at the above link.
>> >> In those lines we can see that `wait` is not added into coverageMap.
>> >>
>> > Great work in finding the possible issue.
>> >>
>> >> I am new so the only thing I know about covoar is that it does
>> >> coverage analysis.
>> >> Any ideas on how to move further into solving this ?
>> >
>> > I added Chris in CC, he'll be able to tell us where to look for the
>> source
>> > of the error you found.
>> > In general, you can follow covoar.cc file, which has the main `covoar`
>> > function in it. That will be a good starting point.
>> >
>>
>>
>> Yeah, I traversed through the code in covoar.cc
>>
>> It goes something like:
>>
>> In covoar.cc: covar()
>> at line 382: objdumpProcessor->load( exe, objdumpFile, err );
>> Here, `exe` points to the executableinfo object, the one in which the
>> coverageMap was created via createCoverageMap()
>>
>> Now inside objdumpProcessor->load()
>> at line 301: finalizeSymbol() is called which further calls
>> findCoverageMap() at line 35. This is the point where error occurs, as
>> `wait` symbol is not found.
>>
>> Hi Bran,
>
> Sorry, I couldn't find time to look into the details and I was hoping
> someone
> else will join in. You are in the right direction and found the function
> that is
> getting the error. Now that you have a function to follow, I will suggest
> you to
> run gdb on covoar and follow this function, especially where it's getting
> the
> symbols.
> To run covoar on gdb do the following:
> $gdb /path/to/covoar
> (gdb) r - -S
> /home/lunatic/development/rtems/rtems-tools/tester/rtems/testing/coverage/leon3-qemu-symbols.ini
>  \
> -O leon3-qemu-coverage \
> -E
> /home/lunatic/development/rtems/rtems-tools/tester/rtems/testing/coverage/Explanations.txt
> \
> -p RTEMS-5 /your/exe.exe
>
> The above is just an example and you can adapt it according to your exe
and bsp. Also, since you're using leon3-sis-coverage, please also add the
option -fTSIM

> set a breakpoint at findCoverageMap() and see what it is doing.
> Most likely, you'll be able to see where is it getting other symbols
> from and why is "wait" not there, or if it's there, why is it skipping it.
>
> Best regards,
> Vijay
>
>> The objdumpProcessor->load() function searches symbols in
>> CoverageMap(via finalizeSymbol()) according to the symbols present in
>> objdump generated at
>> line 291: getFile( executableInformation->getFileName(), objdumpFile, err
>> );
>>
>> The objdump is created using the executableinfo from which we loaded
>> the symbols into CoverageMap, right ?
>> Then is it so that the code missed out on the symbol while adding them
>> into CoverageMap ?
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 26/02/2020 04:50, Chris Johns wrote:
> On 25/2/20 5:30 pm, Christian Mauderer wrote:
>> On 24/02/2020 23:26, Chris Johns wrote:
 On 24 Feb 2020, at 7:39 pm, Christian Mauderer 
  wrote:

 On 24/02/2020 07:01, Chris Johns wrote:
>
>
>>> On 24 Feb 2020, at 5:32 am, Christian Mauderer  
>>> wrote:
>>
>> On 23/02/2020 17:07, Alan Cudmore wrote:
>>> I have been trying to bring up RTEMS with rtems-libbsd on the
>>> beaglebone black (latest master).
>>>
>>> I can run the regular RTEMS samples on the board, and a couple of the
>>> rtems-libbsd testsuite examples run as well.
>>>
>>> The samples such as ping01 and usb01 get a fatal exception in the
>>> function fdt_ro_probe_ , leading me to believe that maybe I am not
>>> using the correct device tree blob.
>>>
>>> I'm using the instructions here:
>>> https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
>>>
>>> And I have am loading am335x-boneblack.dtb that I copied from a linux
>>> u-boot build. The instructions talk about getting the one from the
>>> FreeBSD repository, but there are many other files included in that
>>> dts source.
>>>
>>> What dtb is normally used for the Beaglebone black RTEMS libbsd testing?
>>>
>>> Is the dtb needed for the non-libbsd BSP?
>>>
>>> Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
>>> libbsd to get ethernet?
>>>
>>> Thanks,
>>> Alan
>>
>> Hello Alan,
>>
>> I recommend to use the FreeBSD device trees. libbsd is FreeBSD based and
>> therefore works best with them. Normally I would suggest to use the
>> version matching the FreeBSD commit used in libbsd. But unfortunately in
>> the last commit that doesn't seem to work. Vijay had some problems with
>> it and noted that the version from FreeBSD commit
>> 19a6ceb89dbacf74697d493e48c388767126d418 works fine.
>
> Is this with 5 branch in Libbsd?
>
> I am a little confused about the branch to package in a release and also 
> which FDT files we need for which branch. If different I feel a release 
> will makes things more complicated. This flies into the BSP  vertical 
> stack building in the RSB. 
>
> I am working on releasing and I hope this does not block things. 
>
> Chris

 Hello Chris,

 the non-working device tree is for the master branch from a few weeks
 back. I didn't tested it with the 5-freebsd-12 branch.
>>>
>>> Which FDT files are needed for the 5-freebsd-12 branch? I could assume the
>>> 12-release branch in the FreeBSD repo however this is a guess, unfriendly 
>>> on our
>>> part and time consuming to sort out. I am not sure how we improve this and 
>>> how
>>> we should manage FDT source but we need to address the issue.
>>
>> Same problem here. The topic already popped up multiple times and I
>> can't really answer it.
> 
> I know but we have too.
> 
>> Like I said multiple time: My approach is to use the fdt that matches
>> the FreeBSD commit used in libbsd. So for the 5-freebsd-12 branch that
>> is the one from FreeBSD commit 0d1c391321b34b3025cf0e72f2231d836ff76da8.
>> But it's not a rule that works for all BSPs. Some BSPs are adapted to
>> use a board manufacturers DTB or some random Linux one.
> 
> This means users need a clone of the FreeBSD repo  and that means a bigger
> disk array and a larger net pipe ;)
> 

I agree that it's not optimal to pull the FreeBSD sources in it's
entirety. An import into libbsd (or some other solution) would be better.

>>
>>>
>>> There are long time RTEMS users including myself struggling with this so it 
>>> is a
>>> clear indication in my mind we have an issue we need to improve.
>>>
> Again: In the normal case I would just suggest to use the FDT sources
 that match the FreeBSD commit we use for libbsd. That worked best for me
 in the past. But in the current referenced commit FreeBSD has updated
 the device tree sources to the ones from a recent Linux version and the
 drivers haven't been adapted yet (on master - I expect that it works
 better on 5-freebsd-12).

 Regarding the release: I don't think you pack the FDT files (yet), do
 you? 
>>>
>>> No I do not but then should I be the one doing this in a release. I would 
>>> have
>>> thought this is a core issue for the BSPs that depend on FDT blobs at 
>>> runtime.
>>>
>>> I am up to libbsd with the release packaging. I can build a beagleboneblack 
>>> as a
>>> vertical stack up to libbsd and then I hit the issue of using master and 
>>> not the
>>> 5-freebsd-12 branch and after that is the rtems_waf submodule naming. I 
>>> would
>>> like to resolve this in the RSB however before I do this I would like to 
>>> resolve
>>> the FDT files so I make a single pass over this.
>>>
 So I don't see why there should be a reason for this topic to block
 the rel