date:20200211

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

I understand. As soon as I find some time I'll try to take a look at the
FreeBSD history. Somewhere should be a commit that takes the adapted
structure into account.

Best regards

Christian

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

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

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

Thanks. Pushed.

> 
>>
>> On Mon, Feb 10, 2020 at 2:35 AM Christian Mauderer
>>  wrote:
>>>
>>> Hello,
>>>
>>> this is a first patch set to allow the imx-BSP to support i.MX6UL as
>>> well as i.MX7. Note that the support isn't complete yet. But Peter
>>> want's to work on the BSP too and therefore I try to commit them early
>>> so that we don't have double work and merge conflicts.
>>>
>>> Best regards
>>>
>>> Christian
>>>
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>

-- 

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

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

Tool Roadmap for the RTEMS Pre-Qualification

Hello,

this email tries to give an overview of the tool roadmap for the RTEMS
pre-qualification activity and things to decide for the RTEMS Project.

The tools used for the RTEMS pre-qualification will be command line
tools only.
We will not use GUIs. New tools will be written in Python. The aim is to
reuse
and improve existing tools of the RTEMS Project. The tools will be
configured

via command line options and configuration files. The tool inputs will be
command line options, configuration files, source files, output from other
tools, and bug tracker databases.

The tools fall roughly in three categories. Firstly, there will be
compiler-like tools which generate output files from input files. For
example,

one tool could generate document-specific glossaries from a project-wide
glossary. Secondly, there will be client/server tools. For example,
there could
be a tool which receives test programs, runs them on a target system and
sends

back the result. Thirdly, there will be builder tools. For example, the
creation of an RTEMS pre-qualification data package for a particular target
which can be handed over to an end user.

=== Important Decisions to Make ===

* Where to place the specification items?

* What should be in the specification (master data set)?

* Which content is generated?

* Which generated content is version controlled?

* How is the content generation integrated in the build system?

* How is the Python development organized?

=== Repository Overview ===

We have currently four main repositories in the RTEMS Project:

* rtems

* rtems-tools

* rtems-docs

* rtems-source-builder (RSB)

The RSB is a self-contained component and we will use it as is for the
pre-qualification activity.

There are dependencies between the rtems, rtems-tools, and rtems-docs
repositories. Inconsistencies must be currently resolved manually
without any

tool support.

For example, we have documentation of API functions in Doxygen and the
Classic API Guide:

https://docs.rtems.org/doxygen/branches/master/group__ClassicTasks.html#gabffda1c2301962f0ae5af042ac0bba62

https://docs.rtems.org/branches/master/c-user/task_manager.html#task-create-create-a-task

One goal of the pre-qualification activity is to introduce a master data set
(specification) and use tools to generate content in the right format
from it.

For example, currently a human needs to edit

https://git.rtems.org/rtems/tree/cpukit/include/rtems/rtems/tasks.h

and

https://git.rtems.org/rtems-docs/tree/c-user/task_manager.rst

to declare and document the Classic Tasks API. This should be replaced by an
API specification which includes documentation elements and a generator tool
which produces the header file with Doxygen markup and the reST files
for the

Classic API Guide. Specifically for the pre-qualification activity, the API
specification can be used to also generate an interface specification
document

(Interface Control Document in ECSS terms).

For the generated files, we have two options:

1. They are version controlled. Specification changes and the generated
changes

are sent for review to the mailing list and then checked in or not. This
means a normal user of the repository has no need to install the
generator
tools. Also in case the generator tools stop to work, we are back
to the

current situation (with a dead specification in the repository).

2. They are not version controlled and the build system generates them on
demand.

=== Location of the Specification ===

This seems to be a hot topic. The specification could be located in the
rtems,

the rtems-docs, or a separate repository. The new build system is based on
specification items which are located in the "spec/build" directory in the
RTEMS sources. It is desirable to not split up the specification.

We could split up the specification and add specification items more
related to
the documentation to the rtems-docs repository. This may end up in
discussions

if a particular item goes into rtems or rtems-docs. I don't think this helps
and makes things easier.

We could add a new repository which contains the specification and the other
repositories as Git submodules along with tools and scripts and whatever. I
think we already have more than enough repositories in the RTEMS Project
and we

should only introduce new repositories then there is a real need. However, I
also acknowledge that the impact of the pre-qualification activity should be
manageable. Splitting up the specification into a build related part
which is
contained in the RTEMS sources repository and the rest could be a way
forward

to get started. Thanks to Chris for bringing up this approach.

What do you think about this:

1. The new build system will remain as is and uses the build specification
items located in "spec/build" in the RTEMS sources.

2. We add a new empty rtems-qual repository.

2.1. In this repository we add a "spec" directory for the non-build
specificatio

[PATCH v3 0/3] [rtems-libbsd] Fix compilation for amd64

Similar to the previous patchset for i386 this one enables compilation for the 
amd64 BSP
with the following limitations:
- dev_nic_e1000 needs to be off
- debugger01.exe does not link because the amd64 bsp has no libdebugger support

I tried to use the lessons learned from the last patch set.
It does not seem to affect arm, sparc and i386 compilation.

Best regards,

Jan

Jan Sommer (3):
  amd64: Add missing files from FreeBSD
  amd64: Add to build
  amd64: Port to RTEMS

 freebsd/sys/amd64/amd64/in_cksum.c|  245 
 freebsd/sys/amd64/include/machine/_bus.h  |   48 +
 freebsd/sys/amd64/include/machine/cpufunc.h   | 1053 +
 freebsd/sys/amd64/include/machine/efi.h   |   78 ++
 freebsd/sys/amd64/include/machine/in_cksum.h  |   86 ++
 freebsd/sys/amd64/include/machine/md_var.h|   90 ++
 .../sys/amd64/include/machine/specialreg.h|6 +
 freebsd/sys/sys/efi.h |  198 
 libbsd.py |   14 +
 rtemsbsd/amd64/include/machine/clock.h|2 +
 waf_libbsd.py |4 +
 11 files changed, 1824 insertions(+)
 create mode 100644 freebsd/sys/amd64/amd64/in_cksum.c
 create mode 100644 freebsd/sys/amd64/include/machine/_bus.h
 create mode 100644 freebsd/sys/amd64/include/machine/cpufunc.h
 create mode 100644 freebsd/sys/amd64/include/machine/efi.h
 create mode 100644 freebsd/sys/amd64/include/machine/in_cksum.h
 create mode 100644 freebsd/sys/amd64/include/machine/md_var.h
 create mode 100644 freebsd/sys/amd64/include/machine/specialreg.h
 create mode 100644 freebsd/sys/sys/efi.h
 create mode 100644 rtemsbsd/amd64/include/machine/clock.h

-- 
2.17.1

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

[PATCH v3 3/3] amd64: Port to RTEMS

---
 freebsd/sys/amd64/include/machine/cpufunc.h | 6 ++
 rtemsbsd/amd64/include/machine/clock.h  | 2 ++
 2 files changed, 8 insertions(+)
 create mode 100644 rtemsbsd/amd64/include/machine/clock.h

diff --git a/freebsd/sys/amd64/include/machine/cpufunc.h 
b/freebsd/sys/amd64/include/machine/cpufunc.h
index cf514cb6..d96f9702 100644
--- a/freebsd/sys/amd64/include/machine/cpufunc.h
+++ b/freebsd/sys/amd64/include/machine/cpufunc.h
@@ -164,6 +164,7 @@ enable_intr(void)
 
 #defineHAVE_INLINE_FFSL
 
+#ifndef __rtems__
 static __inline __pure2 int
 ffsl(long mask)
 {
@@ -201,6 +202,7 @@ flsll(long long mask)
 {
return (flsl((long)mask));
 }
+#endif /* __rtems__ */
 
 #endif /* _KERNEL */
 
@@ -357,6 +359,7 @@ read_rflags(void)
return (rf);
 }
 
+#ifndef __rtems__
 static __inline uint64_t
 rdmsr(u_int msr)
 {
@@ -365,6 +368,7 @@ rdmsr(u_int msr)
__asm __volatile("rdmsr" : "=a" (low), "=d" (high) : "c" (msr));
return (low | ((uint64_t)high << 32));
 }
+#endif /* __rtems__ */
 
 static __inline uint32_t
 rdmsr32(u_int msr)
@@ -423,6 +427,7 @@ write_rflags(u_long rf)
__asm __volatile("pushq %0;  popfq" : : "r" (rf));
 }
 
+#ifndef __rtems__
 static __inline void
 wrmsr(u_int msr, uint64_t newval)
 {
@@ -432,6 +437,7 @@ wrmsr(u_int msr, uint64_t newval)
high = newval >> 32;
__asm __volatile("wrmsr" : : "a" (low), "d" (high), "c" (msr));
 }
+#endif /* __rtems__ */
 
 static __inline void
 load_cr0(u_long data)
diff --git a/rtemsbsd/amd64/include/machine/clock.h 
b/rtemsbsd/amd64/include/machine/clock.h
new file mode 100644
index ..415e2b55
--- /dev/null
+++ b/rtemsbsd/amd64/include/machine/clock.h
@@ -0,0 +1,2 @@
+extern int tsc_is_invariant;
+extern uint64_t tsc_freq;
-- 
2.17.1

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

[PATCH v3 2/3] amd64: Add to build

---
 libbsd.py | 14 ++
 waf_libbsd.py |  4 
 2 files changed, 18 insertions(+)

diff --git a/libbsd.py b/libbsd.py
index 3823c03f..15d3da86 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -1548,6 +1548,7 @@ class dev_nic(builder.Module):
 'sys/sys/buf.h',
 'sys/sys/mqueue.h',
 'sys/sys/user.h',
+'sys/sys/efi.h',
 ]
 )
 self.addCPUDependentFreeBSDHeaderFiles(
@@ -1559,6 +1560,11 @@ class dev_nic(builder.Module):
 'sys/x86/include/intr_machdep.h',
 'sys/x86/include/metadata.h',
 'sys/i386/include/cpufunc.h',
+'sys/amd64/include/specialreg.h',
+'sys/amd64/include/md_var.h',
+'sys/amd64/include/efi.h',
+'sys/amd64/include/_bus.h',
+'sys/amd64/include/cpufunc.h',
 'sys/mips/include/cpufunc.h',
 'sys/mips/include/cpuregs.h',
 'sys/powerpc/include/cpufunc.h',
@@ -4993,6 +4999,7 @@ class in_cksum(builder.Module):
 self.addCPUDependentFreeBSDHeaderFiles(
 [
 'sys/i386/include/in_cksum.h',
+'sys/amd64/include/in_cksum.h',
 'sys/mips/include/in_cksum.h',
 'sys/powerpc/include/in_cksum.h',
 'sys/sparc64/include/in_cksum.h',
@@ -5013,6 +5020,13 @@ class in_cksum(builder.Module):
 ],
 mm.generator['source']()
 )
+self.addCPUDependentFreeBSDSourceFiles(
+[ 'x86_64' ],
+[
+'sys/amd64/amd64/in_cksum.c',
+],
+mm.generator['source']()
+)
 self.addCPUDependentFreeBSDSourceFiles(
 [ 'powerpc' ],
 [
diff --git a/waf_libbsd.py b/waf_libbsd.py
index 84f22b76..3b1f2d16 100644
--- a/waf_libbsd.py
+++ b/waf_libbsd.py
@@ -197,6 +197,10 @@ class Builder(builder.ModuleManager):
 if 'cpu-include-paths' in config:
 cpu = bld.get_env()['RTEMS_ARCH']
 if cpu == "i386":
+cpu = 'i386'
+includes += ['freebsd/sys/x86/include']
+if cpu == "x86_64":
+cpu = 'amd64'
 includes += ['freebsd/sys/x86/include']
 for i in config['cpu-include-paths']:
 includes += [i.replace('@CPU@', cpu)]
-- 
2.17.1

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

[PATCH v3 1/3] amd64: Add missing files from FreeBSD

---
 freebsd/sys/amd64/amd64/in_cksum.c|  245 
 freebsd/sys/amd64/include/machine/_bus.h  |   48 +
 freebsd/sys/amd64/include/machine/cpufunc.h   | 1047 +
 freebsd/sys/amd64/include/machine/efi.h   |   78 ++
 freebsd/sys/amd64/include/machine/in_cksum.h  |   86 ++
 freebsd/sys/amd64/include/machine/md_var.h|   90 ++
 .../sys/amd64/include/machine/specialreg.h|6 +
 freebsd/sys/sys/efi.h |  198 
 8 files changed, 1798 insertions(+)
 create mode 100644 freebsd/sys/amd64/amd64/in_cksum.c
 create mode 100644 freebsd/sys/amd64/include/machine/_bus.h
 create mode 100644 freebsd/sys/amd64/include/machine/cpufunc.h
 create mode 100644 freebsd/sys/amd64/include/machine/efi.h
 create mode 100644 freebsd/sys/amd64/include/machine/in_cksum.h
 create mode 100644 freebsd/sys/amd64/include/machine/md_var.h
 create mode 100644 freebsd/sys/amd64/include/machine/specialreg.h
 create mode 100644 freebsd/sys/sys/efi.h

diff --git a/freebsd/sys/amd64/amd64/in_cksum.c 
b/freebsd/sys/amd64/amd64/in_cksum.c
new file mode 100644
index ..b06f4425
--- /dev/null
+++ b/freebsd/sys/amd64/amd64/in_cksum.c
@@ -0,0 +1,245 @@
+#include 
+
+/* $NetBSD: in_cksum.c,v 1.7 1997/09/02 13:18:15 thorpej Exp $ */
+
+/*-
+ * SPDX-License-Identifier: BSD-4-Clause
+ *
+ * Copyright (c) 1988, 1992, 1993
+ * The Regents of the University of California.  All rights reserved.
+ * Copyright (c) 1996
+ * Matt Thomas 
+ *
+ * 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.
+ * 3. All advertising materials mentioning features or use of this software
+ *must display the following acknowledgement:
+ * This product includes software developed by the University of
+ * California, Berkeley and its contributors.
+ * 4. Neither the name of the University nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS 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 REGENTS 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.
+ *
+ * @(#)in_cksum.c  8.1 (Berkeley) 6/10/93
+ */
+
+#include  /* RCS ID & Copyright macro defns */
+__FBSDID("$FreeBSD$");
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Checksum routine for Internet Protocol family headers
+ *(Portable Alpha version).
+ *
+ * This routine is very heavily used in the network
+ * code and should be modified for each CPU to be as fast as possible.
+ */
+
+#define ADDCARRY(x)  (x > 65535 ? x -= 65535 : x)
+#define REDUCE32 \
+{\
+   q_util.q = sum;   \
+   sum = q_util.s[0] + q_util.s[1] + q_util.s[2] + q_util.s[3];  \
+}
+#define REDUCE16 \
+{\
+   q_util.q = sum;   \
+   l_util.l = q_util.s[0] + q_util.s[1] + q_util.s[2] + q_util.s[3]; \
+   sum = l_util.s[0] + l_util.s[1];  \
+   ADDCARRY(sum);\
+}
+
+static const u_int32_t in_masks[] = {
+   /*0 bytes*/ /*1 byte*/  /*2 bytes*/ /*3 bytes*/
+   0x, 0x00FF, 0x, 0x00FF, /* offset 0 */
+   0x, 0xFF00, 0x0000, 0xFF00, /* offset 1 */
+   0x, 0x00FF, 0x, 0x, /* offset 2 */
+   0x, 0xFF00, 0xFF00, 0xFF00, /* offset 3 */
+};
+
+union l_util {
+   u_int16_t s[2];
+   u_int32_t l;
+};
+union q_util {
+

Re: [PATCH v3 2/3] amd64: Add to build


On 11/02/2020 13:06, Jan Sommer wrote:


diff --git a/waf_libbsd.py b/waf_libbsd.py
index 84f22b76..3b1f2d16 100644
--- a/waf_libbsd.py
+++ b/waf_libbsd.py
@@ -197,6 +197,10 @@ class Builder(builder.ModuleManager):
  if 'cpu-include-paths' in config:
  cpu = bld.get_env()['RTEMS_ARCH']
  if cpu == "i386":
+cpu = 'i386'

What is the purpose of this assignment?

+includes += ['freebsd/sys/x86/include']
+if cpu == "x86_64":
+cpu = 'amd64'
  includes += ['freebsd/sys/x86/include']
  for i in config['cpu-include-paths']:
  includes += [i.replace('@CPU@', cpu)]
I am not sure what this should do. Here cpu x86_64 seems to be renamed 
to amd64? Should it be named amd64 in general?

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

AW: [PATCH v3 2/3] amd64: Add to build

2020-02-11 Thread Jan.Sommer

> -Ursprüngliche Nachricht-
> Von: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
> Gesendet: Dienstag, 11. Februar 2020 13:22
> An: Sommer, Jan; devel@rtems.org
> Betreff: Re: [PATCH v3 2/3] amd64: Add to build
> 
> On 11/02/2020 13:06, Jan Sommer wrote:
> 
> > diff --git a/waf_libbsd.py b/waf_libbsd.py
> > index 84f22b76..3b1f2d16 100644
> > --- a/waf_libbsd.py
> > +++ b/waf_libbsd.py
> > @@ -197,6 +197,10 @@ class Builder(builder.ModuleManager):
> >   if 'cpu-include-paths' in config:
> >   cpu = bld.get_env()['RTEMS_ARCH']
> >   if cpu == "i386":
> > +cpu = 'i386'
> What is the purpose of this assignment?

Sorry, I deleted this, but must have recovered it when preparing the patchset.

> > +includes += ['freebsd/sys/x86/include']
> > +if cpu == "x86_64":
> > +cpu = 'amd64'
> >   includes += ['freebsd/sys/x86/include']
> >   for i in config['cpu-include-paths']:
> >   includes += [i.replace('@CPU@', cpu)]
> I am not sure what this should do. Here cpu x86_64 seems to be renamed
> to amd64? Should it be named amd64 in general?

The problem is that the RTEMS_ARCH and the compiler prefix is x86_64, however 
in FreeBSD the related files are in amd64 subdirectories.
libbsd.py uses @CPU@ to create the architecture specific include directories 
which then yields sys/x86_64/include for example, but should create 
sys/amd64/include.

Before my last patch set,  cpu was overridden to x86 for i386, so I thought 
doing something similar saves me the trouble with the include directories here.
Do you maybe have a more elegant solution?

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

Re: [PATCH v3 2/3] amd64: Add to build

2020-02-11 Thread Joel Sherrill

On Tue, Feb 11, 2020, 7:21 AM  wrote:

>
>
> > -Ursprüngliche Nachricht-
> > Von: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
> > Gesendet: Dienstag, 11. Februar 2020 13:22
> > An: Sommer, Jan; devel@rtems.org
> > Betreff: Re: [PATCH v3 2/3] amd64: Add to build
> >
> > On 11/02/2020 13:06, Jan Sommer wrote:
> >
> > > diff --git a/waf_libbsd.py b/waf_libbsd.py
> > > index 84f22b76..3b1f2d16 100644
> > > --- a/waf_libbsd.py
> > > +++ b/waf_libbsd.py
> > > @@ -197,6 +197,10 @@ class Builder(builder.ModuleManager):
> > >   if 'cpu-include-paths' in config:
> > >   cpu = bld.get_env()['RTEMS_ARCH']
> > >   if cpu == "i386":
> > > +cpu = 'i386'
> > What is the purpose of this assignment?
>
> Sorry, I deleted this, but must have recovered it when preparing the
> patchset.
>
> > > +includes += ['freebsd/sys/x86/include']
> > > +if cpu == "x86_64":
> > > +cpu = 'amd64'
> > >   includes += ['freebsd/sys/x86/include']
> > >   for i in config['cpu-include-paths']:
> > >   includes += [i.replace('@CPU@', cpu)]
> > I am not sure what this should do. Here cpu x86_64 seems to be renamed
> > to amd64? Should it be named amd64 in general?
>
> The problem is that the RTEMS_ARCH and the compiler prefix is x86_64,
> however in FreeBSD the related files are in amd64 subdirectories.
> libbsd.py uses @CPU@ to create the architecture specific include
> directories which then yields sys/x86_64/include for example, but should
> create sys/amd64/include.
>
> Before my last patch set,  cpu was overridden to x86 for i386, so I
> thought doing something similar saves me the trouble with the include
> directories here.
> Do you maybe have a more elegant solution?
>

The GNU target for the toolchain is x86_64 for 64 but tools. I didn't
invent that. This looks like a reasonable accommodation.

I want to make sure I understand. This is still the 32 bit pcx86 BSP and
toolchain but it has to use the amd64 Freebsd directory for some support
code in libbsd.

This sounds like the same type of unfortunate hack required if we
integrated code that use x86 or ppc for directory names.

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

RTEMS Manuals: Single Page HTML version doesn't work

Hello,

on docs.rtems.org we have a table with the manuals. There are three
views: Online, PDF and Single Page. It seems that Online and PDF work
fine. But Single Page doesn't work at all. Only a blank page is displayed.

Should we fix it or remove it?

I think I know where I could remove it. But I have no idea where it
should have been generated and therefore I'm a bit lost how to fix it.

Best regards

Christian
-- 

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

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

AW: [PATCH v3 2/3] amd64: Add to build

2020-02-11 Thread Jan.Sommer



> -Ursprüngliche Nachricht-
> Von: Joel Sherrill [mailto:j...@rtems.org]
> Gesendet: Dienstag, 11. Februar 2020 14:29
> An: Sommer, Jan
> Cc: Sebastian Huber; rtems-de...@rtems.org
> Betreff: Re: [PATCH v3 2/3] amd64: Add to build
> 
> 
> 
> On Tue, Feb 11, 2020, 7:21 AM  wrote:
> 
> 
> 
> 
>   > -Ursprüngliche Nachricht-
>   > Von: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
>   > Gesendet: Dienstag, 11. Februar 2020 13:22
>   > An: Sommer, Jan; devel@rtems.org
>   > Betreff: Re: [PATCH v3 2/3] amd64: Add to build
>   >
>   > On 11/02/2020 13:06, Jan Sommer wrote:
>   >
>   > > diff --git a/waf_libbsd.py b/waf_libbsd.py
>   > > index 84f22b76..3b1f2d16 100644
>   > > --- a/waf_libbsd.py
>   > > +++ b/waf_libbsd.py
>   > > @@ -197,6 +197,10 @@ class Builder(builder.ModuleManager):
>   > >   if 'cpu-include-paths' in config:
>   > >   cpu = bld.get_env()['RTEMS_ARCH']
>   > >   if cpu == "i386":
>   > > +cpu = 'i386'
>   > What is the purpose of this assignment?
> 
>   Sorry, I deleted this, but must have recovered it when preparing the
> patchset.
> 
>   > > +includes += ['freebsd/sys/x86/include']
>   > > +if cpu == "x86_64":
>   > > +cpu = 'amd64'
>   > >   includes += ['freebsd/sys/x86/include']
>   > >   for i in config['cpu-include-paths']:
>   > >   includes += [i.replace('@CPU@', cpu)]
>   > I am not sure what this should do. Here cpu x86_64 seems to be
> renamed
>   > to amd64? Should it be named amd64 in general?
> 
>   The problem is that the RTEMS_ARCH and the compiler prefix is
> x86_64, however in FreeBSD the related files are in amd64 subdirectories.
>   libbsd.py uses @CPU@ to create the architecture specific include
> directories which then yields sys/x86_64/include for example, but should 
> create
> sys/amd64/include.
> 
>   Before my last patch set,  cpu was overridden to x86 for i386, so I
> thought doing something similar saves me the trouble with the include
> directories here.
>   Do you maybe have a more elegant solution?
> 
> 
> 
> The GNU target for the toolchain is x86_64 for 64 but tools. I didn't invent 
> that.
> This looks like a reasonable accommodation.
> 
> I want to make sure I understand. This is still the 32 bit pcx86 BSP and 
> toolchain
> but it has to use the amd64 Freebsd directory for some support code in libbsd.

Sorry for the confusion. No, this is a patch for the rtems-libbsd library for 
the RTEMS amd64 BSP.
Of course, given that the amd64 BSP is currently in a very rudimentary state, 
the created binaries won't run.
I just had some time over the Christmas break and followed the guide to setup a 
development toolchain for the amd64 BSP and played around with rtems-libbsd.
So I thought it would be a waste to wait until I have forgotten everything 
again, hence this patch set.

The previous patch set for i386 is the one which is targeted for the pcx86 BSP 
family and should be a bit more relevant.
Figuring out the include directory situation of FreeBSD was a bit tricky a 
first as it collects shared files for i386 and x86_64 in "x86" subdirectories, 
but once this worked for i386 getting support for amd64 was then quite straight 
forward.

For me it was also a tutorial to get familiar with rtems-libbsd.

> This sounds like the same type of unfortunate hack required if we integrated
> code that use x86 or ppc for directory names.
> 
> --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: [PATCH] bsp/raspberrypi: Fix linker command file

2020-02-11 Thread Alan Cudmore

I believe we can discard this. I am running all of my recent tests
with the 0x20 RAM origin.
Thanks,
Alan

On Tue, Feb 11, 2020 at 2:06 AM Sebastian Huber
 wrote:
>
> Hello,
>
> I guess that after all the Raspberry Pi changes this patch can be discarded?
>
> On 20/12/2019 07:32, Sebastian Huber wrote:
> > The RTEMS entry point must be at 0x8000.
> >
> > Update #3774.
> > ---
> >   bsps/arm/raspberrypi/start/linkcmds.in | 13 ++---
> >   1 file changed, 6 insertions(+), 7 deletions(-)
> >
> > diff --git a/bsps/arm/raspberrypi/start/linkcmds.in 
> > b/bsps/arm/raspberrypi/start/linkcmds.in
> > index d99b4fe23e..fde75877e7 100644
> > --- a/bsps/arm/raspberrypi/start/linkcmds.in
> > +++ b/bsps/arm/raspberrypi/start/linkcmds.in
> > @@ -15,11 +15,12 @@
> >*/
> >
> >   MEMORY {
> > -  RAM_MMU (AIW) : ORIGIN = 0x0010, LENGTH = @RPI_RAM_MMU_LENGTH@
> > -  RAM (AIW) : ORIGIN = 0x0020, LENGTH = @RPI_RAM_LENGTH_AVAILABLE@ 
> > - @RPI_RAM_NOCACHE_LENGTH@
> > +  START (AIW) : ORIGIN = 0x8000, LENGTH = 0xf8000
> > +  MMU   (AIW) : ORIGIN = 0x0010, LENGTH = @RPI_RAM_MMU_LENGTH@
> > +  RAM   (AIW) : ORIGIN = 0x0020, LENGTH = @RPI_RAM_LENGTH_AVAILABLE@ - 
> > @RPI_RAM_NOCACHE_LENGTH@
> >   }
> >
> > -REGION_ALIAS ("REGION_START",  RAM);
> > +REGION_ALIAS ("REGION_START",  START);
> >   REGION_ALIAS ("REGION_VECTOR", RAM);
> >   REGION_ALIAS ("REGION_TEXT",   RAM);
> >   REGION_ALIAS ("REGION_TEXT_LOAD",  RAM);
> > @@ -41,9 +42,7 @@ bsp_stack_abt_size = DEFINED (bsp_stack_abt_size) ? 
> > bsp_stack_abt_size : 1024;
> >
> >   bsp_section_rwbarrier_align = DEFINED (bsp_section_rwbarrier_align) ? 
> > bsp_section_rwbarrier_align : 1M;
> >
> > -bsp_vector_table_in_start_section = 1;
> > -
> > -bsp_translation_table_base = ORIGIN (RAM_MMU);
> > -bsp_translation_table_end = ORIGIN (RAM_MMU) + LENGTH (RAM_MMU);
> > +bsp_translation_table_base = ORIGIN (MMU);
> > +bsp_translation_table_end = ORIGIN (MMU) + LENGTH (MMU);
> >
> >   INCLUDE linkcmds.armv4
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS_FATAL_SOURCE_EXCEPTION on booting PRU for beagleboneblack

2020-02-11 Thread Utkarsh Rai

While trying to boot the PRU app from this
 repo. I
encounter RTEMS_FATAL_SOURCE_EXCEPTION. The complete log goes
something like this:-

media listener: event = PARTITION ATTACH, state = INQUIRY, src =
/dev/mmcsd-0
media listener: event = PARTITION ATTACH, state = SUCCESS, src =
/dev/mmcsd-0, dest = /dev/mmcsd-0-0
media listener: event = MOUNT, state = INQUIRY, src = /dev/mmcsd-0-0
media listener: event = MOUNT, state = SUCCESS, src = /dev/mmcsd-0-0, dest
= /media/mmcsd-0-0
SD: OK
rc.conf: loading: /etc/rc.conf
rc.conf: start: /etc/rc.conf size:165, timeout: 10

*** FATAL ***
fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)

R0   = 0x8064d5a8 R8  = 0x010100ae
R1   = 0x808081c6 R9  = 0x000d
R2   = 0x80807ef0 R10 = 0x0001
R3   = 0x R11 = 0x80807ee8
R4   = 0x8064d5a8 R12 = 0x6113
R5   = 0x80807ee8 SP  = 0x806502e0
R6   = 0x80807ee8 LR  = 0x8020eb3c
R7   = 0x000d PC  = 0x8020e824
CPSR = 0xa113 VEC = 0x0004
RTEMS version: 5.0.0.e22554535796fc29a7ed7c5e2338128e324a621d
RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (599c4d7c87fa), Newlib
d14714c69)
executing thread ID: 0x08a010001
executing thread name: UI1
U-Boot SPL 2019.04-2-gbb4af0f50f (Jul 08 2019 - 11:44:39 -0500)
Trying to boot from MMC2
Loading Environment from EXT4...
** Unable to use mmc 0:1 for loading the env **

I have used the binary of this
 overlay
and the relevant commands in uEnv.txt are:-
load mmc 0 0x8200 pru.exe.img;
load mmc 0 0x8800 am335x-boneblack.dtb;
load mmc 0 0x880f AM335X-PRU-UIO-00A0.dtbo;
fdt addr 0x8800; fdt resize 65536; fdt apply 0x880f; bootm
0x8200 - 0x8800;

Now since the booting timeout occurs at the /etc/rc.conf I suppose the
problem is with the device tree files. Can someone please help me out with
this one?

Regards,
Utkarsh Rai
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS_FATAL_SOURCE_EXCEPTION on booting PRU for beagleboneblack

2020-02-11 Thread Nils Hölscher

Hi Utkarsh,

It looks like your device tree is fine, since libbsd (using the device
tree) initializes before the network is configured.
The network config starts here
 and libbsd
initializes here
.

The app is failing in this function
, since the
shell has not started.
I am sorry, Inever encountered that problem, nor do I know what is causing
your kernel to crash.
Hopefully my hints will help.

Best,
Nils


On Tue, 11 Feb 2020 at 19:38, Utkarsh Rai  wrote:

> While trying to boot the PRU app from this
>  repo. I
> encounter RTEMS_FATAL_SOURCE_EXCEPTION. The complete log goes
> something like this:-
>
> media listener: event = PARTITION ATTACH, state = INQUIRY, src =
> /dev/mmcsd-0
> media listener: event = PARTITION ATTACH, state = SUCCESS, src =
> /dev/mmcsd-0, dest = /dev/mmcsd-0-0
> media listener: event = MOUNT, state = INQUIRY, src = /dev/mmcsd-0-0
> media listener: event = MOUNT, state = SUCCESS, src = /dev/mmcsd-0-0, dest
> = /media/mmcsd-0-0
> SD: OK
> rc.conf: loading: /etc/rc.conf
> rc.conf: start: /etc/rc.conf size:165, timeout: 10
>
> *** FATAL ***
> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
>
> R0   = 0x8064d5a8 R8  = 0x010100ae
> R1   = 0x808081c6 R9  = 0x000d
> R2   = 0x80807ef0 R10 = 0x0001
> R3   = 0x R11 = 0x80807ee8
> R4   = 0x8064d5a8 R12 = 0x6113
> R5   = 0x80807ee8 SP  = 0x806502e0
> R6   = 0x80807ee8 LR  = 0x8020eb3c
> R7   = 0x000d PC  = 0x8020e824
> CPSR = 0xa113 VEC = 0x0004
> RTEMS version: 5.0.0.e22554535796fc29a7ed7c5e2338128e324a621d
> RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (599c4d7c87fa), Newlib
> d14714c69)
> executing thread ID: 0x08a010001
> executing thread name: UI1
> U-Boot SPL 2019.04-2-gbb4af0f50f (Jul 08 2019 - 11:44:39 -0500)
> Trying to boot from MMC2
> Loading Environment from EXT4...
> ** Unable to use mmc 0:1 for loading the env **
>
> I have used the binary of this
> 
> overlay and the relevant commands in uEnv.txt are:-
> load mmc 0 0x8200 pru.exe.img;
> load mmc 0 0x8800 am335x-boneblack.dtb;
> load mmc 0 0x880f AM335X-PRU-UIO-00A0.dtbo;
> fdt addr 0x8800; fdt resize 65536; fdt apply 0x880f; bootm
> 0x8200 - 0x8800;
>
> Now since the booting timeout occurs at the /etc/rc.conf I suppose the
> problem is with the device tree files. Can someone please help me out with
> this one?
>
> Regards,
> Utkarsh Rai
>
> ___
> 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_FATAL_SOURCE_EXCEPTION on booting PRU for beagleboneblack


Hello,

one idea to debug problems like this is to

* compile libbsd with --finstrument-functions,

* enable the event recording,

* dump the event records in base64 encoding in the fatal error handler,

* add support for base64 encoded data to the rtems-record-lttng 
converter, and


* view the trace with babeltrace or Trace Compass.

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

Re: RTEMS_FATAL_SOURCE_EXCEPTION on booting PRU for beagleboneblack


Sorry, forgot to mention the function entry/exit profiler:

__attribute__((__no_instrument_function__)) void 
__cyg_profile_func_enter(void* this_fn, void* call_site)

{

  rtems_record_produce_2(RTEMS_RECORD_CALLER,
 (rtems_record_data)call_site, 
RTEMS_RECORD_FUNCTION_ENTRY,

 (rtems_record_data)this_fn);

}



__attribute__((__no_instrument_function__)) void 
__cyg_profile_func_exit(void* this_fn, void* call_site)

{

  rtems_record_produce(RTEMS_RECORD_FUNCTION_EXIT, 
(rtems_record_data)this_fn);


}

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

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

Hello Sebastian,

yes, discard that patch.

Best regards

Christian

On 11/02/2020 16:22, Alan Cudmore wrote:
> I believe we can discard this. I am running all of my recent tests
> with the 0x20 RAM origin.
> Thanks,
> Alan
> 
> On Tue, Feb 11, 2020 at 2:06 AM Sebastian Huber
>  wrote:
>>
>> Hello,
>>
>> I guess that after all the Raspberry Pi changes this patch can be discarded?
>>
>> On 20/12/2019 07:32, Sebastian Huber wrote:
>>> The RTEMS entry point must be at 0x8000.
>>>
>>> Update #3774.
>>> ---
>>>   bsps/arm/raspberrypi/start/linkcmds.in | 13 ++---
>>>   1 file changed, 6 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/bsps/arm/raspberrypi/start/linkcmds.in 
>>> b/bsps/arm/raspberrypi/start/linkcmds.in
>>> index d99b4fe23e..fde75877e7 100644
>>> --- a/bsps/arm/raspberrypi/start/linkcmds.in
>>> +++ b/bsps/arm/raspberrypi/start/linkcmds.in
>>> @@ -15,11 +15,12 @@
>>>*/
>>>
>>>   MEMORY {
>>> -  RAM_MMU (AIW) : ORIGIN = 0x0010, LENGTH = @RPI_RAM_MMU_LENGTH@
>>> -  RAM (AIW) : ORIGIN = 0x0020, LENGTH = @RPI_RAM_LENGTH_AVAILABLE@ 
>>> - @RPI_RAM_NOCACHE_LENGTH@
>>> +  START (AIW) : ORIGIN = 0x8000, LENGTH = 0xf8000
>>> +  MMU   (AIW) : ORIGIN = 0x0010, LENGTH = @RPI_RAM_MMU_LENGTH@
>>> +  RAM   (AIW) : ORIGIN = 0x0020, LENGTH = @RPI_RAM_LENGTH_AVAILABLE@ - 
>>> @RPI_RAM_NOCACHE_LENGTH@
>>>   }
>>>
>>> -REGION_ALIAS ("REGION_START",  RAM);
>>> +REGION_ALIAS ("REGION_START",  START);
>>>   REGION_ALIAS ("REGION_VECTOR", RAM);
>>>   REGION_ALIAS ("REGION_TEXT",   RAM);
>>>   REGION_ALIAS ("REGION_TEXT_LOAD",  RAM);
>>> @@ -41,9 +42,7 @@ bsp_stack_abt_size = DEFINED (bsp_stack_abt_size) ? 
>>> bsp_stack_abt_size : 1024;
>>>
>>>   bsp_section_rwbarrier_align = DEFINED (bsp_section_rwbarrier_align) ? 
>>> bsp_section_rwbarrier_align : 1M;
>>>
>>> -bsp_vector_table_in_start_section = 1;
>>> -
>>> -bsp_translation_table_base = ORIGIN (RAM_MMU);
>>> -bsp_translation_table_end = ORIGIN (RAM_MMU) + LENGTH (RAM_MMU);
>>> +bsp_translation_table_base = ORIGIN (MMU);
>>> +bsp_translation_table_end = ORIGIN (MMU) + LENGTH (MMU);
>>>
>>>   INCLUDE linkcmds.armv4
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> ___
> 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 on BBB hardware (was Re: Enabling Buildbot 'responsible user' emails.)

2020-02-11 Thread Amar Takhar

On 2020-02-10 13:05 +1100, Chris Johns wrote:
> On 8/2/20 11:13 am, Amar Takhar wrote:
> > I was going to start with the Beaglebone and do TFTP to load the tests.  
> 
> I suggest you start with getting rtems-run to run any of the built tests. You
> will need ...
> 
> 1. An SD card image with u-boot configured to TFTP netboot. The 
> rtems-boot-image
> tool can make this. You u-boot for the BBB.

Okay I'll check that out.


> 2. The TFTP proxy tool running. This avoids all the tests and rtems-test 
> having
> to be on the same host plus with some changes rtems-test could run parallel 
> jobs
> on real hardware (currently not a priority for me to work on).

I can do parallel tests within Buildbot.  It's what I would do anyway so we can 
get proper results printed out and capture logs It's always a linear run in 
each 
'builder'.


> 3. Serial console connections using ser2net. I have a RPi on a USB hub with a
> quick power port that can run the RPi and all my consoles.

Okay thanks.


> > I do 
> > have a board design using p-channel mosfets to be able to disconnect the 
> > power 
> > to each board out of band to handle hard locks.  That's why I went with a 
> > custom 
> > power supply.  Wish I had the 5-10k for the digital switchable power 
> > supplies 
> > I'm used to using. :)
> 
> I got a cheap one but they still cost. Sorting out the power control can be 
> once
> you can run an executable.

Yeah I know I've looked at my options I'm not going to worry about it for now.  
I have my PDU on my rack which an power cycle remotely for now it's just not 
silent heh.  I should change the relays in it.


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

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

On 12/2/20 9:37 am, Amar Takhar wrote:
> On 2020-02-10 13:05 +1100, Chris Johns wrote:
>> On 8/2/20 11:13 am, Amar Takhar wrote:
>>> I was going to start with the Beaglebone and do TFTP to load the tests.  
>>
>> I suggest you start with getting rtems-run to run any of the built tests. You
>> will need ...
>>
>> 1. An SD card image with u-boot configured to TFTP netboot. The 
>> rtems-boot-image
>> tool can make this. You u-boot for the BBB.
> 
> Okay I'll check that out.
> 
>> 2. The TFTP proxy tool running. This avoids all the tests and rtems-test 
>> having
>> to be on the same host plus with some changes rtems-test could run parallel 
>> jobs
>> on real hardware (currently not a priority for me to work on).
> 
> I can do parallel tests within Buildbot.  It's what I would do anyway so we 
> can 
> get proper results printed out and capture logs It's always a linear run in 
> each 
> 'builder'.

The issue rtems-test faces is the relationship between a specific instance of
hardware and the management of the TFTP and console telnet session. This is
where there is a conflict, ie the same type of board with the same u-boot set up
all boot at once and request the same image. You need a way to manage the
relationships. I manage this with the tftp proxy tool I placed in rtems-tools.

>> 3. Serial console connections using ser2net. I have a RPi on a USB hub with a
>> quick power port that can run the RPi and all my consoles.
> 
> Okay thanks.
> 
>>> I do 
>>> have a board design using p-channel mosfets to be able to disconnect the 
>>> power 
>>> to each board out of band to handle hard locks.  That's why I went with a 
>>> custom 
>>> power supply.  Wish I had the 5-10k for the digital switchable power 
>>> supplies 
>>> I'm used to using. :)
>>
>> I got a cheap one but they still cost. Sorting out the power control can be 
>> once
>> you can run an executable.
> 
> Yeah I know I've looked at my options I'm not going to worry about it for 
> now.  
> I have my PDU on my rack which an power cycle remotely for now it's just not 
> silent heh.  I should change the relays in it.

Mine make a click noise. The boards, RPi ser2net box, switch and power control
are all in a cupboard.

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

Re: RTEMS Manuals: Single Page HTML version doesn't work

On 12/2/20 12:41 am, Christian Mauderer wrote:
> 
> on docs.rtems.org we have a table with the manuals. There are three
> views: Online, PDF and Single Page. It seems that Online and PDF work
> fine. But Single Page doesn't work at all. Only a blank page is displayed.
> 
> Should we fix it or remove it?

If it is fixable I think we should. Amar added single page support when the
original shift from texinfo was done. I have kept it ever since.

> I think I know where I could remove it.

Are you referring to rtems-docs or rtems-admin (my personal repo)?

Does rtems-docs build with --singlehtml for you?

> But I have no idea where it should have been generated

It is generated via a con job under my account on sync.rtems.org and copied to a
spot on the ftp server where it is picked up by the docs.rtems.org jail and
installed.

The build or generate line is ...

https://git.rtems.org/chrisj/rtems-admin.git/tree/docs/builder/rtems-docs-build-branches#n135

Note:
1. The docs.rtems.org has no resources to perform a build
2. Using the ftp server avoids special keys etc with ssh to copy the files from
sync to docs.

> and therefore I'm a bit lost how to fix it.

Asking here is a good place to start. :)

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

Re: AW: [PATCH v3 2/3] amd64: Add to build

On 12/2/20 12:21 am, jan.som...@dlr.de wrote:
>> Von: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
>> Gesendet: Dienstag, 11. Februar 2020 13:22
>> An: Sommer, Jan; devel@rtems.org
>> Betreff: Re: [PATCH v3 2/3] amd64: Add to build
>>> +includes += ['freebsd/sys/x86/include']
>>> +if cpu == "x86_64":
>>> +cpu = 'amd64'
>>>   includes += ['freebsd/sys/x86/include']
>>>   for i in config['cpu-include-paths']:
>>>   includes += [i.replace('@CPU@', cpu)]
>> I am not sure what this should do. Here cpu x86_64 seems to be renamed
>> to amd64? Should it be named amd64 in general?
> 
> The problem is that the RTEMS_ARCH and the compiler prefix is x86_64, however 
> in FreeBSD the related files are in amd64 subdirectories.

Yes, this is fixed and cannot change. As Joel points out it is from the tools
and we a long standing policy of following the tool names.

> libbsd.py uses @CPU@ to create the architecture specific include directories 
> which then yields sys/x86_64/include for example, but should create 
> sys/amd64/include.

Yes. The i386 has a hidden case as a hack in the generator code. It should also
be removed and cleaned up, see below.

> Before my last patch set,  cpu was overridden to x86 for i386, so I thought 
> doing something similar saves me the trouble with the include directories 
> here.
> Do you maybe have a more elegant solution?

I think we need some form of path matching. I doubt this will be the only place
we encounter something like this and it is not the first case.

What about adding something that maps one path to another path? eg to libbsd.py
add ...

 #
 # Map paths based on RTEMS naming to FreeBSD naming.
 #
 'path-mappings' : [('freebsd/sys/i386/include', 'freebsd/sys/x64/include'),
('freebsd/sys/x86_64/include', 'freebsd/sys/amd64/include')]

The mapping code can be added here ...

https://git.rtems.org/rtems-libbsd/tree/waf_libbsd.py#n192

... and the special case of i386 removed. I would add a path_remap call so if
this is needed in other places it can be added easily.

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

Re: RSB build failed.

jameszxj,

I have pushed changes to the RSB that I hope fixes the build.

Please update and see if this fixes things for you.

Thanks
Chris

On 10/2/20 11:53 am, Chris Johns wrote:
> On 10/2/20 10:36 am, Chris Johns wrote:
>> I think clang or gcc has some links that fail but I thought I had a fix for 
>> this
>> where bsdtar is run a second time on windows. I cannot seem to find it.
> 
> I have found the fix I added when adding clang support ...
> 
> https://git.rtems.org/rtems-source-builder/commit/?id=591deae6d7411af04fd31d2a68dee9520b33c657
> 
> ... however this option does not help. It is not clear to me what is wrong 
> with
> the links in the newlib tar file.
> 
> I have raised a ticket to manage the issue ...
> 
> https://devel.rtems.org/ticket/3868
> 
> 
> Chris
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] tester: Use prefix for rtems_tools by default

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.
---
 tester/rt/test.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tester/rt/test.py b/tester/rt/test.py
index 6b45b78..16ac352 100644
--- a/tester/rt/test.py
+++ b/tester/rt/test.py
@@ -423,6 +423,8 @@ def run(args, command_path = None):
 if len(rtems_tools) != 2:
 raise error.general('invalid RTEMS tools option')
 rtems_tools = rtems_tools[1]
+else:
+rtems_tools = '%{_prefix}'
 bsp = opts.find_arg('--rtems-bsp')
 if bsp is None or len(bsp) != 2:
 raise error.general('RTEMS BSP not provided or an invalid option')
-- 
2.16.4

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

[PATCH] tester: Add qemu_opts_serial