Re: [PATCH rtems-libbsd] rtemsbsd: Use a separate header for test devices

2021-07-06 Thread Chris Johns 
On 7/7/21 12:03 pm, Kinsey Moore wrote:
> On 7/6/2021 20:57, Chris Johns wrote:
>> On 7/7/21 11:05 am, Kinsey Moore wrote:
>>> The need for the difference on ZynqMP is that there are 4 different CGEM
>>> interfaces of which dev boards primarily make use of CGEM3.
>> RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM0(ZYNQMP_IRQ_ETHERNET_0);
>> RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM1(ZYNQMP_IRQ_ETHERNET_1);
>> RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM2(ZYNQMP_IRQ_ETHERNET_2);
>> RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM3(ZYNQMP_IRQ_ETHERNET_3);
>>
>> ?
> 
> Yes, this does technically work

Hmm, I suggest this is what we should support as a default.

> if you can read the shell output past the log
> spam. The other interfaces trying and failing to come up throw a gargantuan
> amount of messages to the console.

Why do these interfaces fail to initialise? What are the errors?

The removed probe check is based around FDT and so I suspect is the reason
Sebastian suggested FDT support. Needing FDT support would break existing Zynq
users.

Maybe we need something more in the probe conditional for RTEMS to see if clocks
or other related pieces of the hardware are set up? There maybe a relationship
between the FSBL and the errors you are seeing.

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

Re: [PATCH rtems-libbsd] rtemsbsd: Use a separate header for test devices

2021-07-06 Thread Kinsey Moore 



On 7/6/2021 20:57, Chris Johns wrote:

On 7/7/21 11:05 am, Kinsey Moore wrote:

The need for the difference on ZynqMP is that there are 4 different CGEM
interfaces of which dev boards primarily make use of CGEM3.

RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM0(ZYNQMP_IRQ_ETHERNET_0);
RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM1(ZYNQMP_IRQ_ETHERNET_1);
RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM2(ZYNQMP_IRQ_ETHERNET_2);
RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM3(ZYNQMP_IRQ_ETHERNET_3);

?


Yes, this does technically work if you can read the shell output past 
the log spam. The other interfaces trying and failing to come up throw a 
gargantuan amount of messages to the console.



Kinsey


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

Re: [PATCH rtems-libbsd] rtemsbsd: Use a separate header for test devices

2021-07-06 Thread Chris Johns 
On 7/7/21 11:05 am, Kinsey Moore wrote:
> The need for the difference on ZynqMP is that there are 4 different CGEM
> interfaces of which dev boards primarily make use of CGEM3. 

RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM0(ZYNQMP_IRQ_ETHERNET_0);
RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM1(ZYNQMP_IRQ_ETHERNET_1);
RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM2(ZYNQMP_IRQ_ETHERNET_2);
RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM3(ZYNQMP_IRQ_ETHERNET_3);

?

> I have a custom
> board in hand that uses CGEM2 which I can't run the network tests on without
> modifying nexus-devices.h manually.

NET_CFG_INTERFACE_0 "cgem2"

> Zynq7000 boards that use CGEM1 instead of
> CGEM0 could make use of the same mechanism for testing.

NET_CFG_INTERFACE_0 "cgem1"

FYI I am not sure how I will solve testing the MRMAC on the Versal chip. It may
require something extra and new to be done. What that is I do not know as the
MRMAC and the Versal presents a new level of complication.

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

Re: [PATCH rtems-libbsd] rtemsbsd: Use a separate header for test devices

2021-07-06 Thread Kinsey Moore 



On 7/6/2021 18:55, Chris Johns wrote:

On 7/7/21 5:46 am, Kinsey Moore wrote:

This is an alternate patch to solve the issue of test-related information being 
included in an installed application-targeted header.

Why is the ZYNQMP different to the zync BSP? I have been running the tests on
the zynq for years and the CGEM hard IP is also almost the same.

As I said in the other thread I have lost the reason for needing this special
case for the ZYNQMP.

The need for the difference on ZynqMP is that there are 4 different CGEM 
interfaces of which dev boards primarily make use of CGEM3. I have a 
custom board in hand that uses CGEM2 which I can't run the network tests 
on without modifying nexus-devices.h manually. Zynq7000 boards that use 
CGEM1 instead of CGEM0 could make use of the same mechanism for testing.



Kinsey

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

Re: [PATCH] covoar: Fix errors building on FreeBSD and clang

2021-07-06 Thread Chris Johns 
On 3/7/21 5:56 am, Alex White wrote:
> On Wed, Jun 30, 2021 at 11:40 PM  wrote:
>>
>> From: Chris Johns 
>>
>> - The member variable `path_` cannot be a reference and initialised to
>>   a const char* type input. To do so would require there is a temporary with
>>   an unspecified life time.
>> ---
>>  tester/covoar/AddressToLineMapper.h | 2 +-
>>  tester/covoar/Target_aarch64.h      | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/tester/covoar/AddressToLineMapper.h
> b/tester/covoar/AddressToLineMapper.h
>> index 88bf475..c78aef7 100644
>> --- a/tester/covoar/AddressToLineMapper.h
>> +++ b/tester/covoar/AddressToLineMapper.h
>> @@ -84,7 +84,7 @@ namespace Coverage {
>>       *  An iterator pointing to the location in the set that contains the
>>       *  source file path of the address.
>>       */
>> -    const std::string& path_;
>> +    const std::string path_;
> 
> Ryan alerted me about this issue a couple weeks back. This patch would fix the
> problem, but it would lead to a second copy of every file path string being
> stored in memory. This would also take away the usefulness of the set of file
> path strings maintained by the AddressLineRange class.
> 
> Instead, I propose we change the empty SourceLine constructor to take a `const
> std::string&`. This would allow the addition of something like this to the top
> of AddressToLineMapper::getSource():
> const std::string unknown = "unknown";
> const SourceLine default_sourceline = SourceLine(unknown);
> 
> That should eliminate the issue and preserve the memory conservation efforts 
> of
> the original design.

Yes it would but for some reason, that I cannot put my finger on, it seems like
a breach of boundaries between classes.

How much data are we talking about? Are you able to see the memory foot print
with the strings being contained vs what you have now?

If the figures show the strings need to be shared to avoid a memory blow out
would a std::shared_ptr be something to look at where all
references are a shared pointer? A shared pointer means any changes do not flow
from one class to other.

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

Re: [PATCH] Reports: Convert to C++

2021-07-06 Thread Chris Johns 
On 7/7/21 1:53 am, Ryan Long wrote:
> Made formatting consistent and converted C code to C++.
> ---
>  tester/covoar/ReportsBase.cc |  525 +--
>  tester/covoar/ReportsBase.h  |  156 +++---
>  tester/covoar/ReportsHtml.cc | 1183 
> +-
>  tester/covoar/ReportsHtml.h  |  141 ++---
>  tester/covoar/ReportsText.cc |  348 ++---
>  tester/covoar/ReportsText.h  |   75 ++-
>  6 files changed, 1041 insertions(+), 1387 deletions(-)
> 
> diff --git a/tester/covoar/ReportsBase.cc b/tester/covoar/ReportsBase.cc
> index 328980d..3041df2 100644
> --- a/tester/covoar/ReportsBase.cc
> +++ b/tester/covoar/ReportsBase.cc
> @@ -4,6 +4,9 @@
>  #include 
>  #include 
>  
> +#include 
> +#include 
> +
>  #include "ReportsBase.h"
>  #include "app_common.h"
>  #include "CoverageRanges.h"
> @@ -20,10 +23,12 @@
>  
>  namespace Coverage {
>  
> -ReportsBase::ReportsBase( time_t timestamp, std::string symbolSetName ):
> -  reportExtension_m(""),
> -  symbolSetName_m(symbolSetName),
> -  timestamp_m( timestamp )
> +ReportsBase::ReportsBase(
> +  time_t timestamp,
> +  const std::string& symbolSetName
> +): reportExtension_m( "" ),
> +   symbolSetName_m( symbolSetName ),
> +   timestamp_m(  timestamp  )
>  {
>  }
>  
> @@ -31,14 +36,14 @@ ReportsBase::~ReportsBase()
>  {
>  }
>  
> -FILE* ReportsBase::OpenFile(
> -  const char* const fileName,
> -  const char* const symbolSetName
> +std::ofstream* ReportsBase::OpenFile(

A raw pointer anywhere is a possible source of a leak and with exceptions it is
hard to track all possible paths.

> +  const std::string& fileName,
> +  const std::string& symbolSetName

Would having ...

 std::ostream& aFile

as a referenced arguement work?

>  )
>  {
> -  int  sc;
> -  FILE*aFile;
> -  std::string  file;
> +  intsc;
> +  std::ofstream* aFile = new std::ofstream;

Please consider std::shared_ptr<> or std::unique_ptr<> for pointers or just
avoid using them which I find simpler.

> +  std::stringfile;
>  
>std::string symbolSetOutputDirectory;
>rld::path::path_join(
> @@ -51,136 +56,110 @@ FILE* ReportsBase::OpenFile(
>  #ifdef _WIN32
>sc = _mkdir( symbolSetOutputDirectory );
>  #else
> -  sc = mkdir( symbolSetOutputDirectory.c_str(),0755 );
> +  sc = mkdir( symbolSetOutputDirectory.c_str(), 0755 );
>  #endif
> -  if ( (sc == -1) && (errno != EEXIST) ) {
> -fprintf(
> -  stderr,
> -  "Unable to create output directory %s\n",
> -  symbolSetOutputDirectory.c_str()
> -);
> +  if ( ( sc == -1 ) && ( errno != EEXIST ) ) {
> +std::cerr << "Unable to create output directory "
> +  << symbolSetOutputDirectory << "\n";

Please do not use "\n", please use std::endl.

Why not throw an exception?

>  return NULL;

NULL should be nullptr in C++ but if this becomes 'void' it can be removed.

>}
>  
>file = symbolSetOutputDirectory;
> -  rld::path::path_join(file, fileName, file);
> +  rld::path::path_join( file, fileName, file );
>  
>// Open the file.
> -  aFile = fopen( file.c_str(), "w" );
> -  if ( !aFile ) {
> -fprintf( stderr, "Unable to open %s\n", file.c_str() );
> +  aFile->open( file );
> +  if ( !aFile->is_open() ) {
> +std::cerr << "Unable to open " << file << "\n";
>}
> +
>return aFile;
>  }
>  
> -void ReportsBase::WriteIndex(
> -  const char* const fileName
> -)
> +void ReportsBase::WriteIndex( const std::string& fileName )
>  {
>  }
>  
> -FILE* ReportsBase::OpenAnnotatedFile(
> -  const char* const fileName
> -)
> +std::ofstream* ReportsBase::OpenAnnotatedFile( const std::string& fileName )

.. and here ..

>  {
> -  return OpenFile(fileName, symbolSetName_m.c_str());
> +  return OpenFile( fileName, symbolSetName_m );
>  }
>  
> -FILE* ReportsBase::OpenBranchFile(
> -  const char* const fileName,
> -  bool  hasBranches
> +std::ofstream* ReportsBase::OpenBranchFile(

... and here ...

> +  const std::string& fileName,
> +  bool   hasBranches
>  )
>  {
> -  return OpenFile(fileName, symbolSetName_m.c_str());
> +  return OpenFile( fileName, symbolSetName_m );
>  }
>  
> -FILE* ReportsBase::OpenCoverageFile(
> -  const char* const fileName
> -)
> +std::ofstream* ReportsBase::OpenCoverageFile( const std::string& fileName )
>  {
> -  return OpenFile(fileName, symbolSetName_m.c_str());
> +  return OpenFile( fileName, symbolSetName_m );
>  }
>  
> -FILE* ReportsBase::OpenNoRangeFile(
> -  const char* const fileName
> -)
> +std::ofstream* ReportsBase::OpenNoRangeFile( const std::string& fileName )
>  {
> -  return OpenFile(fileName, symbolSetName_m.c_str());
> +  return OpenFile( fileName, symbolSetName_m );
>  }
>  
>  
> -FILE* ReportsBase::OpenSizeFile(
> -  const char* const fileName
> -)
> +std::ofstream* ReportsBase::OpenSizeFile( const std::string& fileName )
>  {
> -  return OpenFile(fileName, symbolSetName_m.c_str());
> +  return OpenFile( fileName, symbolSetName_m );
>  }
>  
> -FILE* Re

Re: [PATCH rtems-libbsd] rtemsbsd: Use a separate header for test devices

2021-07-06 Thread Chris Johns 
On 7/7/21 5:46 am, Kinsey Moore wrote:
> This is an alternate patch to solve the issue of test-related information 
> being included in an installed application-targeted header.

Why is the ZYNQMP different to the zync BSP? I have been running the tests on
the zynq for years and the CGEM hard IP is also almost the same.

As I said in the other thread I have lost the reason for needing this special
case for the ZYNQMP.

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

Re: [PATCH] waf: Ensure network-config.h gets installed

2021-07-06 Thread Chris Johns 
On 6/7/21 11:52 pm, Kinsey Moore wrote:
> On 7/6/2021 04:45, Chris Johns wrote:
>> On 3/7/21 11:16 am, Kinsey Moore wrote:
>>> network-config.h is now required for application compilation when using
>>> nexus-devices.h. This makes sure that it gets installed to resolve build
>>> errors.
>> I think it is a mistake to install this file. It is an internal file 
>> generated
>> by config.inc to ease creating the tests.
>>
>> I am concerned the internals of how tests are built will leaking to 
>> applications
>> and this creates a new set interfaces.
>>
>> I need to look at Peter's question that created this request. The preferred 
>> way
>> of doing this is to use rc.conf or craft your set of calls using BSd 
>> interfaces.
>>
>> Chris
> 
> I had that thought as well which leads me to the question: Is nexus-devices.h
> meant for test configuration or for application usage?

It is but indirectly used. See rtemsbsd/include/machine/rtems-bsd-config.h. All
I do in an application is:

/*
 * Configure LibBSD.
 */
#define RTEMS_BSD_CONFIG_DOMAIN_PAGE_MBUFS_SIZE (32 * 1024 * 1024)
#define RTEMS_BSD_CONFIG_BSP_CONFIG
#define RTEMS_BSD_CONFIG_INIT

#include 

int start(int iface)
{
  rtems_bsd_initialize();
  FILE* rc_conf = fopen("/etc/rc.conf", "w");
  fprintf(rc_conf, "hostname=\"test\"\n");
  fprintf(rc_conf, "ifconfig_cgem%d=\"DHCP rxcsum txcsum\"\n", iface);
  fclose(rc_conf);
  return rtems_bsd_run_etc_rc_conf(30, true);
}

> It is very clearly being used by applications as a place to store default
> configurations that should work for most hardware and I'm not sure we can (or
> should) change that.

You can provide special cases in your own code, for example in the section
above. his may be needed for a PC BSP where the card in the PCI bus is not one
listed.

> It would likely also be painful to change and raise the
> barrier to entry. On the other hand, recent conversations on this subject have
> pointed me toward nexus-devices.h being primarily for test usage while
> applications should provide their own set of definitions similar to 
> nexus-devices.h

The including of network-config.h is a mistake. A grep shows the
network-config.h is only included by the tests.

> Maybe it would be better to have a test-specific include that goes into all
> tests and supplements nexus-devices.h. This would force things to be left out 
> of
> the default-application-configuration-style nexus-devices.h to accomodate test
> needs, but would still provide a good starter configuration for applications.

I am not sure. What is in nexus-devices.h you need network-config.h for? I have
lost track of the problem you are wanting to solve?

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

RTEMS Net Services Repository Ready

2021-07-06 Thread gerberhe11 
Hi all,

 

We have been working on adding support for the net-services within the
rtems-net-legacy project. In the current state, we are successfully able to
build and test the net-services as a submodule within the net-legacy
repository for telnetd and tftpfs.

 

Next, we will be working on adding ftpfs as well in this net-services
submodule. Afterwards we will be getting the net-demos included and working
in this project as well, for that, we are planning on adding waf support for
the net configurations into the net-demos.

 

Here is a link for this net-services submodule:

https://github.com/kingneo77/net_services

 

Also is a link to the most recent commit in the net-legacy repository that
adapts this submodule:

https://github.com/kingneo77/rtems-net-legacy/commit/f1b8234fe683b1d4b772bfe
3f4c3512f31536436

 

We want this net-services to be added to the top RTEMS repository soon, and
any feedback and suggestions on the repository as well as the implementation
of the net-services would be greatly appreciated! We are hoping to move
forward in this direction for the net services, and support will be added to
libbsd as well.

 

Thanks,

 

Harrison Gerber

  gerberh...@gmail.com

720-288-7308

 



-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH rtems-libbsd] rtemsbsd: Use a separate header for test devices

2021-07-06 Thread Kinsey Moore 
This is an alternate patch to solve the issue of test-related information being 
included in an installed application-targeted header.

-Original Message-
From: Kinsey Moore  
Sent: Tuesday, July 6, 2021 14:45
To: devel@rtems.org
Cc: Kinsey Moore 
Subject: [PATCH rtems-libbsd] rtemsbsd: Use a separate header for test devices

Devices used specifically for testing are now contained in a separate
nexus-test-devices.h so as not to pollute default hardware
configurations with test-specific information. This header is currently
only used for network tests.
---
 rtemsbsd/include/bsp/nexus-devices.h  | 24 
 rtemsbsd/include/bsp/nexus-test-devices.h | 59 +++
 .../rtems/bsd/test/default-network-init.h |  3 +
 3 files changed, 62 insertions(+), 24 deletions(-)
 create mode 100644 rtemsbsd/include/bsp/nexus-test-devices.h

diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index cbb3f48b..3a5f9155 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -38,7 +38,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 
@@ -106,30 +105,7 @@ RTEMS_BSD_DRIVER_MMC;
 
 #elif defined(LIBBSP_AARCH64_XILINX_ZYNQMP_BSP_H)
 
-#include 
-
 RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SLCR;
-/* Qemu only applies user-mode networking to the first interface by default, so
- * all 4 CGEM instances must be configured in the Qemu arguments using
- * "-nic user,model=cadence_gem" for each nic.
- *
- * CGEM3 is used for LibBSD because all Zynq Ultrascale+ MPSoC dev boards treat
- * the highest-mapped CGEM as the primary interface.
- */
-#if NET_CFG_ZYNQMP_USE_CGEM0 == '1'
-RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM0(ZYNQMP_IRQ_ETHERNET_0);
-#endif
-#if NET_CFG_ZYNQMP_USE_CGEM1 == '1'
-RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM1(ZYNQMP_IRQ_ETHERNET_1);
-#endif
-#if NET_CFG_ZYNQMP_USE_CGEM2 == '1'
-RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM2(ZYNQMP_IRQ_ETHERNET_2);
-#endif
-#if NET_CFG_ZYNQMP_USE_CGEM3 == '1'
-RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM3(ZYNQMP_IRQ_ETHERNET_3);
-#endif
-RTEMS_BSD_DRIVER_E1000PHY;
-RTEMS_BSD_DRIVER_UKPHY;
 
 #elif defined(LIBBSP_ARM_ATSAM_BSP_H)
 
diff --git a/rtemsbsd/include/bsp/nexus-test-devices.h 
b/rtemsbsd/include/bsp/nexus-test-devices.h
new file mode 100644
index ..798d9eef
--- /dev/null
+++ b/rtemsbsd/include/bsp/nexus-test-devices.h
@@ -0,0 +1,59 @@
+/*
+ * Copyright (c) 2021 On-Line Applications Research
+ *
+ * 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 AUTHOR 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 AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#if !defined(BSP_NEXUS_TEST_DEVICES_h)
+#define BSP_NEXUS_TEST_DEVICES_h
+
+#include 
+
+#if defined(LIBBSP_AARCH64_XILINX_ZYNQMP_BSP_H)
+
+#include 
+
+/* Qemu only applies user-mode networking to the first interface by default, so
+ * all 4 CGEM instances must be configured in the Qemu arguments using
+ * "-nic user,model=cadence_gem" for each nic.
+ *
+ * CGEM3 is used for LibBSD because all Zynq Ultrascale+ MPSoC dev boards treat
+ * the highest-mapped CGEM as the primary interface.
+ */
+#if NET_CFG_ZYNQMP_USE_CGEM0 == '1'
+RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM0(ZYNQMP_IRQ_ETHERNET_0);
+#endif
+#if NET_CFG_ZYNQMP_USE_CGEM1 == '1'
+RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM1(ZYNQMP_IRQ_ETHERNET_1);
+#endif
+#if NET_CFG_ZYNQMP_USE_CGEM2 == '1'
+RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM2(ZYNQMP_IRQ_ETHERNET_2);
+#endif
+#if NET_CFG_ZYNQMP_USE_CGEM3 == '1'
+RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM3(ZYNQMP_IRQ_ETHERNET_3);
+#endif
+RTEMS_BSD_DRIVER_E1000PHY;
+RTEMS_BSD_DRIVER_UKPHY;
+
+#endif /* LIBBSP_AARCH64_XILINX_ZYNQMP_BSP_H */
+
+#endif
diff --git a/testsuite/include/rtems/bsd/test/default-network-init.h 
b/testsuite/include/rtems/bsd/test/default-network-init.h
index ce1fc015..3bd59f42 100644
--- a/testsuite/include/rtems/bsd/te

[PATCH rtems-libbsd] rtemsbsd: Use a separate header for test devices

2021-07-06 Thread Kinsey Moore 
Devices used specifically for testing are now contained in a separate
nexus-test-devices.h so as not to pollute default hardware
configurations with test-specific information. This header is currently
only used for network tests.
---
 rtemsbsd/include/bsp/nexus-devices.h  | 24 
 rtemsbsd/include/bsp/nexus-test-devices.h | 59 +++
 .../rtems/bsd/test/default-network-init.h |  3 +
 3 files changed, 62 insertions(+), 24 deletions(-)
 create mode 100644 rtemsbsd/include/bsp/nexus-test-devices.h

diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index cbb3f48b..3a5f9155 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -38,7 +38,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 
@@ -106,30 +105,7 @@ RTEMS_BSD_DRIVER_MMC;
 
 #elif defined(LIBBSP_AARCH64_XILINX_ZYNQMP_BSP_H)
 
-#include 
-
 RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SLCR;
-/* Qemu only applies user-mode networking to the first interface by default, so
- * all 4 CGEM instances must be configured in the Qemu arguments using
- * "-nic user,model=cadence_gem" for each nic.
- *
- * CGEM3 is used for LibBSD because all Zynq Ultrascale+ MPSoC dev boards treat
- * the highest-mapped CGEM as the primary interface.
- */
-#if NET_CFG_ZYNQMP_USE_CGEM0 == '1'
-RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM0(ZYNQMP_IRQ_ETHERNET_0);
-#endif
-#if NET_CFG_ZYNQMP_USE_CGEM1 == '1'
-RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM1(ZYNQMP_IRQ_ETHERNET_1);
-#endif
-#if NET_CFG_ZYNQMP_USE_CGEM2 == '1'
-RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM2(ZYNQMP_IRQ_ETHERNET_2);
-#endif
-#if NET_CFG_ZYNQMP_USE_CGEM3 == '1'
-RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM3(ZYNQMP_IRQ_ETHERNET_3);
-#endif
-RTEMS_BSD_DRIVER_E1000PHY;
-RTEMS_BSD_DRIVER_UKPHY;
 
 #elif defined(LIBBSP_ARM_ATSAM_BSP_H)
 
diff --git a/rtemsbsd/include/bsp/nexus-test-devices.h 
b/rtemsbsd/include/bsp/nexus-test-devices.h
new file mode 100644
index ..798d9eef
--- /dev/null
+++ b/rtemsbsd/include/bsp/nexus-test-devices.h
@@ -0,0 +1,59 @@
+/*
+ * Copyright (c) 2021 On-Line Applications Research
+ *
+ * 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 AUTHOR 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 AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#if !defined(BSP_NEXUS_TEST_DEVICES_h)
+#define BSP_NEXUS_TEST_DEVICES_h
+
+#include 
+
+#if defined(LIBBSP_AARCH64_XILINX_ZYNQMP_BSP_H)
+
+#include 
+
+/* Qemu only applies user-mode networking to the first interface by default, so
+ * all 4 CGEM instances must be configured in the Qemu arguments using
+ * "-nic user,model=cadence_gem" for each nic.
+ *
+ * CGEM3 is used for LibBSD because all Zynq Ultrascale+ MPSoC dev boards treat
+ * the highest-mapped CGEM as the primary interface.
+ */
+#if NET_CFG_ZYNQMP_USE_CGEM0 == '1'
+RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM0(ZYNQMP_IRQ_ETHERNET_0);
+#endif
+#if NET_CFG_ZYNQMP_USE_CGEM1 == '1'
+RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM1(ZYNQMP_IRQ_ETHERNET_1);
+#endif
+#if NET_CFG_ZYNQMP_USE_CGEM2 == '1'
+RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM2(ZYNQMP_IRQ_ETHERNET_2);
+#endif
+#if NET_CFG_ZYNQMP_USE_CGEM3 == '1'
+RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM3(ZYNQMP_IRQ_ETHERNET_3);
+#endif
+RTEMS_BSD_DRIVER_E1000PHY;
+RTEMS_BSD_DRIVER_UKPHY;
+
+#endif /* LIBBSP_AARCH64_XILINX_ZYNQMP_BSP_H */
+
+#endif
diff --git a/testsuite/include/rtems/bsd/test/default-network-init.h 
b/testsuite/include/rtems/bsd/test/default-network-init.h
index ce1fc015..3bd59f42 100644
--- a/testsuite/include/rtems/bsd/test/default-network-init.h
+++ b/testsuite/include/rtems/bsd/test/default-network-init.h
@@ -268,6 +268,9 @@ Init(rtems_task_argument arg)
 
 #include 
 
+/* Include additional devices that may be required for network tests */
+#include 
+
 #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DR

DTB for BBB?

2021-07-06 Thread Shiro 
Hello,

I’m new to RTEMS (but not new to embedded RTOS deployment).  I worked through 
the BBB QuickStart and have run hello.exe on a BBB.

Question regarding the correct DTS for BBB:  in section 8.2.3.2 of the online 
docs: 

https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html?highlight=dts#beagle

I don't follow this:

We build the dtb from the FreeBSD source matching the commit hash from the 
libbsd HEAD of freebsd-org.  For example if the HEAD is at 
“19a6ceb89dbacf74697d493e48c388767126d418” …

Can anyone point me to where HEAD is determined?  And how it matched into the 
FreeBSD.org  tree?


Best regards,
-david



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

[PATCH rtems-libbsd 4/4] libbsd.py: add usb template files

2021-07-06 Thread Husni Faiz 
add the imported template files for CDC Ethernet
register the dev_usb_template module
enable usb template in default buildset

Signed-off-by: Husni Faiz 
---
 buildset/default.ini |  1 +
 buildset/minimal.ini |  3 ++-
 libbsd.py| 25 +
 3 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/buildset/default.ini b/buildset/default.ini
index 472c535d..117bacc3 100644
--- a/buildset/default.ini
+++ b/buildset/default.ini
@@ -34,6 +34,7 @@ dev_usb_net = on
 dev_usb_quirk = on
 dev_usb_serial = on
 dev_usb_storage = on
+dev_usb_template = on
 dev_usb_wlan = off
 dev_wlan_rtwn = off
 iic = on
diff --git a/buildset/minimal.ini b/buildset/minimal.ini
index 03dd96bb..060b1930 100644
--- a/buildset/minimal.ini
+++ b/buildset/minimal.ini
@@ -19,5 +19,6 @@ extends = default.ini
 
 [modules]
 crypto_openssl = off
+dev_usb_template = off
 netinet6 = off
-usr_bin_openssl = off
+usr_bin_openssl = off
\ No newline at end of file
diff --git a/libbsd.py b/libbsd.py
index c9151901..049ec7f8 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -1162,6 +1162,30 @@ class dev_usb_storage(builder.Module):
 mm.generator['source']()
 )
 
+#
+# USB Template
+#
+class dev_usb_template(builder.Module):
+
+def __init__(self, manager):
+super(dev_usb_template, self).__init__(manager, type(self).__name__)
+
+def generate(self):
+mm = self.manager
+self.addDependency('dev_usb')
+self.addKernelSpaceHeaderFiles(
+[
+'sys/dev/usb/template/usb_template.h',
+]
+)
+self.addKernelSpaceSourceFiles(
+[
+'sys/dev/usb/template/usb_template.c',
+'sys/dev/usb/template/usb_template_cdce.c',
+],
+mm.generator['source']()
+)
+
 #
 # BBB USB
 #
@@ -5480,6 +5504,7 @@ def load(mm):
 
 mm.addModule(cam(mm))
 mm.addModule(dev_usb_storage(mm))
+mm.addModule(dev_usb_template(mm))
 mm.addModule(dev_usb_controller_bbb(mm))
 
 mm.addModule(net(mm))
-- 
2.25.1

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

[PATCH rtems-libbsd 3/4] nexus-devices: Include CDC Ethernet for Beagle

2021-07-06 Thread Husni Faiz 
Configure bus for CDC Ethernet
Include CDC Ethernet in Beagle BSP

Signed-off-by: Husni Faiz 
---
 rtemsbsd/include/bsp/nexus-devices.h   |  5 +
 rtemsbsd/include/machine/rtems-bsd-nexus-bus.h | 17 +
 2 files changed, 22 insertions(+)

diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index e6487470..6a35632e 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -83,6 +83,11 @@ SYSINIT_REFERENCE(rtwn_rtl8188eufw);
 RTEMS_BSD_DRIVER_USB;
 RTEMS_BSD_DRIVER_USB_MASS;
 
+#ifdef RTEMS_BSD_MODULE_DEV_USB_TEMPLATE
+RTEMS_BSD_DRIVER_USB_TEMPLATE;
+RTEMS_BSD_DRIVER_CDCE;
+#endif
+
 #elif defined(LIBBSP_ARM_LPC32XX_BSP_H)
 
 #include 
diff --git a/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h 
b/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
index 50a43873..84f561f5 100644
--- a/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
+++ b/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
@@ -282,6 +282,15 @@ extern "C" {
 SYSINIT_DRIVER_REFERENCE(umass, uhub)
 #endif /* RTEMS_BSD_DRIVER_USB_MASS */
 
+/*
+ * USB Template base driver.
+ */
+#if !defined(RTEMS_BSD_DRIVER_USB_TEMPLATE)
+  #define RTEMS_BSD_DRIVER_USB_TEMPLATE   \
+SYSINIT_REFERENCE(usb_temp_init); \
+SYSINIT_DRIVER_REFERENCE(usb_template, usb)
+#endif /* RTEMS_BSD_DRIVER_USB_TEMPLATE */
+
 /*
  * USB SAF1761 host controller driver.
  */
@@ -490,6 +499,14 @@ extern "C" {
 SYSINIT_DRIVER_REFERENCE(re, pci);
 #endif /* RTEMS_BSD_DRIVER_PCI_RE */
 
+/*
+ * CDC Ethernet Driver.
+ */
+#if !defined(RTEMS_BSD_DRIVER_CDCE)
+  #define RTEMS_BSD_DRIVER_CDCE   \
+SYSINIT_DRIVER_REFERENCE(cdce, uhub);
+#endif /* RTEMS_BSD_DRIVER_FEC */
+
 /**
  ** MMI Physical Layer Support.
  **/
-- 
2.25.1

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

[PATCH rtems-libbsd 2/4] usb_template: Configure template driver only for CDC Ethernet

2021-07-06 Thread Husni Faiz 
Add the conditional macro to prevent the driver from referencing
the templates which are not imported yet.

Include functions which adds the hw.usb.template sysctl variable.

Signed-off-by: Husni Faiz 
---
 freebsd/sys/dev/usb/template/usb_template.c | 4 
 freebsd/sys/dev/usb/usb_device.c| 4 ++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/freebsd/sys/dev/usb/template/usb_template.c 
b/freebsd/sys/dev/usb/template/usb_template.c
index 0650da15..fe90d5b7 100644
--- a/freebsd/sys/dev/usb/template/usb_template.c
+++ b/freebsd/sys/dev/usb/template/usb_template.c
@@ -1433,12 +1433,15 @@ usb_temp_setup_by_index(struct usb_device *udev, 
uint16_t index)
usb_error_t err;
 
switch (index) {
+#ifndef __rtems__
case USB_TEMP_MSC:
err = usb_temp_setup(udev, &usb_template_msc);
break;
+#endif
case USB_TEMP_CDCE:
err = usb_temp_setup(udev, &usb_template_cdce);
break;
+#ifndef __rtems__
case USB_TEMP_MTP:
err = usb_temp_setup(udev, &usb_template_mtp);
break;
@@ -1469,6 +1472,7 @@ usb_temp_setup_by_index(struct usb_device *udev, uint16_t 
index)
case USB_TEMP_CDCEEM:
err = usb_temp_setup(udev, &usb_template_cdceem);
break;
+#endif
default:
return (USB_ERR_INVAL);
}
diff --git a/freebsd/sys/dev/usb/usb_device.c b/freebsd/sys/dev/usb/usb_device.c
index ee240949..28ef1b74 100644
--- a/freebsd/sys/dev/usb/usb_device.c
+++ b/freebsd/sys/dev/usb/usb_device.c
@@ -123,7 +123,7 @@ int usb_template = USB_TEMPLATE;
 intusb_template = -1;
 #endif
 
-#ifndef __rtems__
+#if !defined(__rtems__) || defined(RTEMS_BSD_MODULE_DEV_USB_TEMPLATE)
 SYSCTL_PROC(_hw_usb, OID_AUTO, template,
 CTLTYPE_INT | CTLFLAG_RWTUN | CTLFLAG_MPSAFE,
 NULL, 0, sysctl_hw_usb_template,
@@ -255,7 +255,7 @@ sysctl_hw_usb_template(SYSCTL_HANDLER_ARGS)
 
return (0);
 }
-#endif /* __rtems__ */
+#endif /* !__rtmes__ || RTEMS_BSD_MODULE_DEV_USB_TEMPLATE */
 
 /* English is default language */
 
-- 
2.25.1

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

[PATCH rtems-libbsd 1/4] usb_template:Import CDC Ethernet

2021-07-06 Thread Husni Faiz 
Signed-off-by: Husni Faiz 
---
 freebsd/sys/dev/usb/template/usb_template.c   | 1489 +
 freebsd/sys/dev/usb/template/usb_template.h   |  130 ++
 .../sys/dev/usb/template/usb_template_cdce.c  |  355 
 3 files changed, 1974 insertions(+)
 create mode 100644 freebsd/sys/dev/usb/template/usb_template.c
 create mode 100644 freebsd/sys/dev/usb/template/usb_template.h
 create mode 100644 freebsd/sys/dev/usb/template/usb_template_cdce.c

diff --git a/freebsd/sys/dev/usb/template/usb_template.c 
b/freebsd/sys/dev/usb/template/usb_template.c
new file mode 100644
index ..0650da15
--- /dev/null
+++ b/freebsd/sys/dev/usb/template/usb_template.c
@@ -0,0 +1,1489 @@
+#include 
+
+/* $FreeBSD$ */
+/*-
+ * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
+ *
+ * Copyright (c) 2007 Hans Petter Selasky. All rights reserved.
+ *
+ * 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 AUTHOR 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 AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * This file contains sub-routines to build up USB descriptors from
+ * USB templates.
+ */
+
+#ifdef USB_GLOBAL_INCLUDE_FILE
+#include USB_GLOBAL_INCLUDE_FILE
+#else
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#defineUSB_DEBUG_VAR usb_debug
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#endif /* USB_GLOBAL_INCLUDE_FILE */
+
+MODULE_DEPEND(usb_template, usb, 1, 1, 1);
+MODULE_VERSION(usb_template, 1);
+
+/* function prototypes */
+
+static int sysctl_hw_usb_template_power(SYSCTL_HANDLER_ARGS);
+static voidusb_make_raw_desc(struct usb_temp_setup *, const uint8_t *);
+static voidusb_make_endpoint_desc(struct usb_temp_setup *,
+   const struct usb_temp_endpoint_desc *);
+static voidusb_make_interface_desc(struct usb_temp_setup *,
+   const struct usb_temp_interface_desc *);
+static voidusb_make_config_desc(struct usb_temp_setup *,
+   const struct usb_temp_config_desc *);
+static voidusb_make_device_desc(struct usb_temp_setup *,
+   const struct usb_temp_device_desc *);
+static uint8_t usb_hw_ep_match(const struct usb_hw_ep_profile *, uint8_t,
+   uint8_t);
+static uint8_t usb_hw_ep_find_match(struct usb_hw_ep_scratch *,
+   struct usb_hw_ep_scratch_sub *, uint8_t);
+static uint8_t usb_hw_ep_get_needs(struct usb_hw_ep_scratch *, uint8_t,
+   uint8_t);
+static usb_error_t usb_hw_ep_resolve(struct usb_device *,
+   struct usb_descriptor *);
+static const struct usb_temp_device_desc *usb_temp_get_tdd(struct usb_device 
*);
+static void*usb_temp_get_device_desc(struct usb_device *);
+static void*usb_temp_get_qualifier_desc(struct usb_device *);
+static void*usb_temp_get_config_desc(struct usb_device *, uint16_t *,
+   uint8_t);
+static const void *usb_temp_get_string_desc(struct usb_device *, uint16_t,
+   uint8_t);
+static const void *usb_temp_get_vendor_desc(struct usb_device *,
+   const struct usb_device_request *, uint16_t *plen);
+static const void *usb_temp_get_hub_desc(struct usb_device *);
+static usb_error_t usb_temp_get_desc(struct usb_device *,
+   struct usb_device_request *, const void **, uint16_t *);
+static usb_error_t usb_temp_setup_by_index(struct usb_device *,
+   uint16_t index);
+static voidusb_temp_init(void *);
+
+SYSCTL_NODE(_hw_usb, OID_AUTO, templates, CTLFLAG_RW, 0,
+"USB device side templates");

[PATCH rtems-libbsd 0/4] Beagle BSP: USB Template Driver for CDC Ethernet

2021-07-06 Thread Husni Faiz 
This set of patches import the drivers from freebsd and 
configures it for the beagle bsp. 

Github Branch for the commits
https://github.com/drac98/rtems-libbsd/commits/usb-cdce

Husni Faiz (4):
  usb_template:Import CDC Ethernet
  usb_template: Configure template driver only for CDC Ethernet
  nexus-devices: Include CDC Ethernet for Beagle
  libbsd.py: add usb template files

 buildset/default.ini  |1 +
 buildset/minimal.ini  |3 +-
 freebsd/sys/dev/usb/template/usb_template.c   | 1493 +
 freebsd/sys/dev/usb/template/usb_template.h   |  130 ++
 .../sys/dev/usb/template/usb_template_cdce.c  |  355 
 freebsd/sys/dev/usb/usb_device.c  |4 +-
 libbsd.py |   25 +
 rtemsbsd/include/bsp/nexus-devices.h  |5 +
 .../include/machine/rtems-bsd-nexus-bus.h |   17 +
 9 files changed, 2030 insertions(+), 3 deletions(-)
 create mode 100644 freebsd/sys/dev/usb/template/usb_template.c
 create mode 100644 freebsd/sys/dev/usb/template/usb_template.h
 create mode 100644 freebsd/sys/dev/usb/template/usb_template_cdce.c

-- 
2.25.1

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

Re: RTEMS on uC5282

2021-07-06 Thread Vijay Kumar Banerjee 
On Tue, Jul 6, 2021 at 9:58 AM Johnson, Andrew N.  wrote:
>
> Hi Vijay,
>
> On Jul 4, 2021, at 6:08 PM, Vijay Kumar Banerjee  wrote:
>
> I have a uC5282 board running uClinux and I was wondering if someone
> has instructions for converting the RTEMS exe files into boot files
> that can be booted from the ram buffer (using `goram` from
> uCbootloader.
>
> The RTEMS documentation is empty:
> https://docs.rtems.org/branches/master/user/bsps/bsps-m68k.html#uc5282
>
> I will populate this section in the documentation once I figure out
> how to run and debug RTEMS executables on it. Any help is much
> appreciated.
>
>
> It’s likely that most if not all uC5282 devices running RTEMS to date have 
> been EPICS IOCs. We finally released EPICS 7.0.6 over the weekend which 
> contains (initial & experimental) support for RTEMS 5, but while I have 
> compiled code for our RTEMS-uC5282 target I haven’t actually run it on a real 
> device. In any case the command that we have always used to build bootable 
> EPICS IOCs with on that target is this line from our GNUmake-based build 
> system:
>
> $(RTEMS_TOOLS)/bin/$(OBJCOPY_FOR_TARGET) -O binary -R .comment -S $< $@
>
>
This worked. Thanks!

> where $@ is the bootable file and $< the file output by the link-line:
>
> An explicit example output from a build that I just ran:
>
> /usr/local/vw/rtems/rtems-5.1/bin/m68k-rtems5-g++ 
> -B/usr/local/vw/rtems/rtems-5.1/m68k-rtems5/uC5282/lib/ -specs bsp_specs 
> -qrtems   -o libComTestHarness -static 
> -L/home/phoebus4/ANJ/epics/base/7.0/lib/RTEMS-uC5282   -mcpu=5282 -u 
> POSIX_Init epicsTypesTest.o epicsInlineTest1.o epicsInlineTest2.o
>
> ... snipped ... epicsTimeZoneTest.o rtemsTestHarness.o rtemsTestData.o   
> -lCom   -lm -lrtemsCom -lCom -ltftpfs -lnfs -lz -ltelnetd -lrtemscpu -lc 
> -lm -lgcc
> /usr/local/vw/rtems/rtems-5.1/bin/m68k-rtems5-objcopy -O binary -R .comment 
> -S libComTestHarness libComTestHarness.boot
> Installing created executable ../../../../bin/RTEMS-uC5282/libComTestHarness
> Installing created executable 
> ../../../../bin/RTEMS-uC5282/libComTestHarness.boot
>
>
> We then load the libComTestHarness.boot file into the device using tftp.
>
I tried the XMODEM file transfer, which seems very slow at 9600, I'll
give it a shot with tftp as well. Thank you for mentioning.

> For EPICS applications the BSP may have to be built with the legacy network 
> stack, but if so that’s due to our initialization code which probably hasn’t 
> been updated yet.
>

I have it built with the legacy network stack.

Thank you for the commands, I will update the RTEMS side of documentation soon.


Best regards,
Vijay
> HTH,
>
> - Andrew
>
> --
> Complexity comes for free, simplicity you have to work for.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Reports: Convert to C++

2021-07-06 Thread Ryan Long 
Made formatting consistent and converted C code to C++.
---
 tester/covoar/ReportsBase.cc |  525 +--
 tester/covoar/ReportsBase.h  |  156 +++---
 tester/covoar/ReportsHtml.cc | 1183 +-
 tester/covoar/ReportsHtml.h  |  141 ++---
 tester/covoar/ReportsText.cc |  348 ++---
 tester/covoar/ReportsText.h  |   75 ++-
 6 files changed, 1041 insertions(+), 1387 deletions(-)

diff --git a/tester/covoar/ReportsBase.cc b/tester/covoar/ReportsBase.cc
index 328980d..3041df2 100644
--- a/tester/covoar/ReportsBase.cc
+++ b/tester/covoar/ReportsBase.cc
@@ -4,6 +4,9 @@
 #include 
 #include 
 
+#include 
+#include 
+
 #include "ReportsBase.h"
 #include "app_common.h"
 #include "CoverageRanges.h"
@@ -20,10 +23,12 @@
 
 namespace Coverage {
 
-ReportsBase::ReportsBase( time_t timestamp, std::string symbolSetName ):
-  reportExtension_m(""),
-  symbolSetName_m(symbolSetName),
-  timestamp_m( timestamp )
+ReportsBase::ReportsBase(
+  time_t timestamp,
+  const std::string& symbolSetName
+): reportExtension_m( "" ),
+   symbolSetName_m( symbolSetName ),
+   timestamp_m(  timestamp  )
 {
 }
 
@@ -31,14 +36,14 @@ ReportsBase::~ReportsBase()
 {
 }
 
-FILE* ReportsBase::OpenFile(
-  const char* const fileName,
-  const char* const symbolSetName
+std::ofstream* ReportsBase::OpenFile(
+  const std::string& fileName,
+  const std::string& symbolSetName
 )
 {
-  int  sc;
-  FILE*aFile;
-  std::string  file;
+  intsc;
+  std::ofstream* aFile = new std::ofstream;
+  std::stringfile;
 
   std::string symbolSetOutputDirectory;
   rld::path::path_join(
@@ -51,136 +56,110 @@ FILE* ReportsBase::OpenFile(
 #ifdef _WIN32
   sc = _mkdir( symbolSetOutputDirectory );
 #else
-  sc = mkdir( symbolSetOutputDirectory.c_str(),0755 );
+  sc = mkdir( symbolSetOutputDirectory.c_str(), 0755 );
 #endif
-  if ( (sc == -1) && (errno != EEXIST) ) {
-fprintf(
-  stderr,
-  "Unable to create output directory %s\n",
-  symbolSetOutputDirectory.c_str()
-);
+  if ( ( sc == -1 ) && ( errno != EEXIST ) ) {
+std::cerr << "Unable to create output directory "
+  << symbolSetOutputDirectory << "\n";
 return NULL;
   }
 
   file = symbolSetOutputDirectory;
-  rld::path::path_join(file, fileName, file);
+  rld::path::path_join( file, fileName, file );
 
   // Open the file.
-  aFile = fopen( file.c_str(), "w" );
-  if ( !aFile ) {
-fprintf( stderr, "Unable to open %s\n", file.c_str() );
+  aFile->open( file );
+  if ( !aFile->is_open() ) {
+std::cerr << "Unable to open " << file << "\n";
   }
+
   return aFile;
 }
 
-void ReportsBase::WriteIndex(
-  const char* const fileName
-)
+void ReportsBase::WriteIndex( const std::string& fileName )
 {
 }
 
-FILE* ReportsBase::OpenAnnotatedFile(
-  const char* const fileName
-)
+std::ofstream* ReportsBase::OpenAnnotatedFile( const std::string& fileName )
 {
-  return OpenFile(fileName, symbolSetName_m.c_str());
+  return OpenFile( fileName, symbolSetName_m );
 }
 
-FILE* ReportsBase::OpenBranchFile(
-  const char* const fileName,
-  bool  hasBranches
+std::ofstream* ReportsBase::OpenBranchFile(
+  const std::string& fileName,
+  bool   hasBranches
 )
 {
-  return OpenFile(fileName, symbolSetName_m.c_str());
+  return OpenFile( fileName, symbolSetName_m );
 }
 
-FILE* ReportsBase::OpenCoverageFile(
-  const char* const fileName
-)
+std::ofstream* ReportsBase::OpenCoverageFile( const std::string& fileName )
 {
-  return OpenFile(fileName, symbolSetName_m.c_str());
+  return OpenFile( fileName, symbolSetName_m );
 }
 
-FILE* ReportsBase::OpenNoRangeFile(
-  const char* const fileName
-)
+std::ofstream* ReportsBase::OpenNoRangeFile( const std::string& fileName )
 {
-  return OpenFile(fileName, symbolSetName_m.c_str());
+  return OpenFile( fileName, symbolSetName_m );
 }
 
 
-FILE* ReportsBase::OpenSizeFile(
-  const char* const fileName
-)
+std::ofstream* ReportsBase::OpenSizeFile( const std::string& fileName )
 {
-  return OpenFile(fileName, symbolSetName_m.c_str());
+  return OpenFile( fileName, symbolSetName_m );
 }
 
-FILE* ReportsBase::OpenSymbolSummaryFile(
-  const char* const fileName
+std::ofstream* ReportsBase::OpenSymbolSummaryFile(
+  const std::string& fileName
 )
 {
-  return OpenFile(fileName, symbolSetName_m.c_str());
+  return OpenFile( fileName, symbolSetName_m );
 }
 
-void ReportsBase::CloseFile(
-  FILE*  aFile
-)
+void ReportsBase::CloseFile( std::ofstream* aFile )
 {
-  fclose( aFile );
+  aFile->close();
 }
 
-void ReportsBase::CloseAnnotatedFile(
-  FILE*  aFile
-)
+void ReportsBase::CloseAnnotatedFile( std::ofstream* aFile )
 {
   CloseFile( aFile );
 }
 
-void ReportsBase::CloseBranchFile(
-  FILE*  aFile,
-  bool   hasBranches
-)
+void ReportsBase::CloseBranchFile( std::ofstream* aFile, bool hasBranches )
 {
   CloseFile( aFile );
 }
 
-void  ReportsBase::CloseCoverageFile(
-  FILE*  aFile
-)
+void  ReportsBase::CloseCoverageFile( std:

[PATCH] bsps/arm: Add start up support for ARMv6 RPi Models

2021-07-06 Thread pranav 
---
 bsps/arm/shared/start/start.S | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/bsps/arm/shared/start/start.S b/bsps/arm/shared/start/start.S
index bd623178ed..2ba6541405 100644
--- a/bsps/arm/shared/start/start.S
+++ b/bsps/arm/shared/start/start.S
@@ -482,16 +482,22 @@ bsp_start_hook_0_done:
 
 .Lvector_table_copy_done:
 
-#if (__ARM_ARCH >= 7 && __ARM_ARCH_PROFILE == 'A') || __ARM_ARCH >= 8
/*
 * This code path is only executed by the primary processor.  Set the
 * VBAR to the normal vector table.  For secondary processors, this is
 * done by bsp_start_hook_0().
 */
+#if (__ARM_ARCH >= 7 && __ARM_ARCH_PROFILE == 'A') || __ARM_ARCH >= 8
ldr r0, =bsp_vector_table_begin
dsb
mcr p15, 0, r0, c12, c0, 0
isb
+#elif defined __ARM_ARCH_6KZ__
+   mov r1, #0
+   ldr r0, =bsp_vector_table_begin
+   mcr p15, 0, r1, c7, c10, 4  /* DataSync */
+   mcr p15, 0, r0, c12, c0, 0  /* Load VBAR */
+   mcr p15, 0, r1, c7, c5, 4   /* Flush Prefetch */
 #endif
 
SWITCH_FROM_ARM_TO_THUMBr3
-- 
2.30.2

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

Re: [PATCH] waf: Ensure network-config.h gets installed

2021-07-06 Thread Kinsey Moore 

On 7/6/2021 04:45, Chris Johns wrote:

On 3/7/21 11:16 am, Kinsey Moore wrote:

network-config.h is now required for application compilation when using
nexus-devices.h. This makes sure that it gets installed to resolve build
errors.

I think it is a mistake to install this file. It is an internal file generated
by config.inc to ease creating the tests.

I am concerned the internals of how tests are built will leaking to applications
and this creates a new set interfaces.

I need to look at Peter's question that created this request. The preferred way
of doing this is to use rc.conf or craft your set of calls using BSd interfaces.

Chris


I had that thought as well which leads me to the question: Is 
nexus-devices.h meant for test configuration or for application usage?


It is very clearly being used by applications as a place to store 
default configurations that should work for most hardware and I'm not 
sure we can (or should) change that. It would likely also be painful to 
change and raise the barrier to entry. On the other hand, recent 
conversations on this subject have pointed me toward nexus-devices.h 
being primarily for test usage while applications should provide their 
own set of definitions similar to nexus-devices.h


Maybe it would be better to have a test-specific include that goes into 
all tests and supplements nexus-devices.h. This would force things to be 
left out of the default-application-configuration-style nexus-devices.h 
to accomodate test needs, but would still provide a good starter 
configuration for applications.



Kinsey

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

Re: Is rtems/bsd/test/network-config.h supposed to be installed?

2021-07-06 Thread Peter Dufault 


> On Jul 6, 2021, at 06:42 , Chris Johns  wrote:
> 
>> On 3 Jul 2021, at 5:14 am, Peter Dufault  wrote:
>> 
>> I updated my libbsd today and an application is failing to build because it 
>> can't find the include file "rtems/bsd/test/network-config.h".  It was added 
>> yesterday to "rtemsbsd/include/bsp/nexus-devices.h".  "nexus-devices.h" the 
>> only file outside of the testsuite directory that includes 
>> "network-config.h", and that network-config.h file is in .gitignore.  Or am 
>> I missing a build step?
> 
> I think including it in a user facing header is a mistake. It is a tool to 
> handle the tests that are internal to libbsd.
> 
> Chris
> 
That was my impression as well.


signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Is rtems/bsd/test/network-config.h supposed to be installed?

2021-07-06 Thread Chris Johns 
> On 3 Jul 2021, at 5:14 am, Peter Dufault  wrote:
> 
> I updated my libbsd today and an application is failing to build because it 
> can't find the include file "rtems/bsd/test/network-config.h".  It was added 
> yesterday to "rtemsbsd/include/bsp/nexus-devices.h".  "nexus-devices.h" the 
> only file outside of the testsuite directory that includes 
> "network-config.h", and that network-config.h file is in .gitignore.  Or am I 
> missing a build step?

I think including it in a user facing header is a mistake. It is a tool to 
handle the tests that are internal to libbsd.

Chris

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

Re: [PATCH] waf: Ensure network-config.h gets installed

2021-07-06 Thread Chris Johns 
On 3/7/21 11:16 am, Kinsey Moore wrote:
> network-config.h is now required for application compilation when using
> nexus-devices.h. This makes sure that it gets installed to resolve build
> errors.

I think it is a mistake to install this file. It is an internal file generated
by config.inc to ease creating the tests.

I am concerned the internals of how tests are built will leaking to applications
and this creates a new set interfaces.

I need to look at Peter's question that created this request. The preferred way
of doing this is to use rc.conf or craft your set of calls using BSd interfaces.

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

Re: [PATCH v7] Update test smpstrongapa01

2021-07-06 Thread Richi Dubey 
Great, thanks. I am happy it is finally merged :)

On Tue, Jul 6, 2021 at 10:54 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 29/06/2021 09:05, Richi Dubey wrote:
> > Update smpstrongapa01 to account for task shifting.
>
> Thanks, I checked it in.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel