Re: [PATCH rtems 2/2] bsps/imxrt: Simplify linkcmds and make it flexible

2021-06-07 Thread Chris Johns 
On 7/6/21 6:40 pm, Christian Mauderer wrote:> I think the Options don't need
documentation changes because the options in the
> waf based build system are now documented directly in the yaml files and 
> printed
> if you generate the default config.

Hmm I am not sure I agree with the premise the YAML is the documentation. The
user manual exists for this purpose and user wanting to explore RTEMS would look
there rather than cloning the repo, running commands etc.

I accept the current defaults etc work flow is a good place to start for the waf
conversion project but we need to do a lot more to make accessing the YAML
easier. The wscript contains the only rtems.git repo means to read the YAML and
the pickled data and that limits how we can change and evolve this.

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

Re: [PATCH v2 2/2] i386: Remove unneeded include header files

2021-06-07 Thread Chris Johns 
I agree this is the way to solve this issue.

Chris

On 8/6/21 3:09 am, Gedare Bloom wrote:
> This looks like a much better solution :) If no one complains by
> Thursday go ahead and push it.
> 
> On Mon, Jun 7, 2021 at 2:53 AM Jan Sommer  wrote:
>>
>> ---
>>  .../sys/i386/include/machine/intr_machdep.h   |6 -
>>  rtemsbsd/include/x86/bus.h| 1109 
>>  rtemsbsd/include/x86/specialreg.h | 1143 -
>>  3 files changed, 2258 deletions(-)
>>  delete mode 100644 freebsd/sys/i386/include/machine/intr_machdep.h
>>  delete mode 100644 rtemsbsd/include/x86/bus.h
>>  delete mode 100644 rtemsbsd/include/x86/specialreg.h
>>
>> diff --git a/freebsd/sys/i386/include/machine/intr_machdep.h 
>> b/freebsd/sys/i386/include/machine/intr_machdep.h
>> deleted file mode 100644
>> index a0b28387..
>> --- a/freebsd/sys/i386/include/machine/intr_machdep.h
>> +++ /dev/null
>> @@ -1,6 +0,0 @@
>> -/*-
>> - * This file is in the public domain.
>> - */
>> -/* $FreeBSD$ */
>> -
>> -#include 
>> diff --git a/rtemsbsd/include/x86/bus.h b/rtemsbsd/include/x86/bus.h
>> deleted file mode 100644
>> index 2427ae51..
>> --- a/rtemsbsd/include/x86/bus.h
>> +++ /dev/null
>> @@ -1,1109 +0,0 @@
>> -/*-
>> - * SPDX-License-Identifier: BSD-3-Clause AND BSD-2-Clause-NetBSDE
>> - *
>> - * Copyright (c) KATO Takenori, 1999.
>> - *
>> - * All rights reserved.  Unpublished rights reserved under the copyright
>> - * laws of Japan.
>> - *
>> - * 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 as
>> - *the first lines of this file unmodified.
>> - * 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. The name of the author may not be used to endorse or promote products
>> - *derived from this software without specific prior written permission.
>> - *
>> - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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 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.
>> - *
>> - * $FreeBSD$
>> - */
>> -
>> -/* $NetBSD: bus.h,v 1.12 1997/10/01 08:25:15 fvdl Exp $*/
>> -
>> -/*-
>> - * Copyright (c) 1996, 1997 The NetBSD Foundation, Inc.
>> - * All rights reserved.
>> - *
>> - * This code is derived from software contributed to The NetBSD Foundation
>> - * by Jason R. Thorpe of the Numerical Aerospace Simulation Facility,
>> - * NASA Ames Research Center.
>> - *
>> - * 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 NETBSD FOUNDATION, INC. 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 FOUNDATION 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.
>> - */
>> -
>> -/*-
>> - * Copyright (c) 1996 Charles M. Hannum.  All rights reserved.
>> - * Copyright (c) 1996 Christopher G. Demetriou.  All rights

Re: Selection of ethernet peripheral by application

2021-06-07 Thread Chris Johns 


On 7/6/21 10:05 pm, Kinsey Moore wrote:
> On 6/6/2021 17:42, Chris Johns wrote:
>> On 4/6/21 11:26 pm, Joel Sherrill wrote:
>>> On Fri, Jun 4, 2021 at 7:59 AM Kinsey Moore >> > wrote:
>>>
>>>  On 6/4/2021 02:32, Christian MAUDERER wrote:
>>>  > Am 02.06.21 um 20:37 schrieb Kinsey Moore:
>>>  >> Hello,
>>>  >>
>>>  >>  From what I’ve seen of the various BSPs supported by LibBSD that
>>>  >> have multiple ethernet peripherals,
>>>  >>
>>>  >> only one tends to be chosen and supported. I’ve encountered a
>>>  >> situation where the majority of platform
>>>  >>
>>>  >> examples (Zynq Ultrascale+ MPSoC dev boards) use CGEM3 as the
>>>  >> only/primary ethernet interface and I
>>>  >>
>>>  >> need to have the option of selecting a different peripheral as the
>>>  >> primary interface.
>>>  >>
>>>  >> Unfortunately, the current configuration of LibBSD/RTEMS does not
>>>  >> allow for easy switching among the
>>>  >>
>>>  >> available interfaces. The easy one-off option is to just create a 
>>> BSP
>>>  >> variant with a little bit of extra logic
>>>  >>
>>>  >> to select the correct interface in LibBSD, but this problem seems
>>>  >> more generally applicable than just
>>>  >>
>>>  >> ethernet and just this one BSP. Is the best alternative to configure
>>>  >> all available devices in
>>>  >>
>>>  >> nexus-devices.h and let LibBSD figure it out?
>>>  >>
>>>  >> Thanks,
>>>  >> Kinsey
>>>  >>
>>>  >
>>>  > If the problem is with "nexus-devices.h": You can always just add
>>>  > further devices or a completely own set of devices in your
>>>  > application. For example it should be no problem to use
>>>  >
>>>  > 
>>>  > SYSINIT_MODULE_REFERENCE(wlan_ratectl_none);
>>>  > SYSINIT_MODULE_REFERENCE(wlan_sta);
>>>  > SYSINIT_MODULE_REFERENCE(wlan_amrr);
>>>  > SYSINIT_MODULE_REFERENCE(wlan_wep);
>>>  > SYSINIT_MODULE_REFERENCE(wlan_tkip);
>>>  > SYSINIT_MODULE_REFERENCE(wlan_ccmp);
>>>  > SYSINIT_DRIVER_REFERENCE(rtwn_usb, uhub);
>>>  > SYSINIT_REFERENCE(rtwn_rtl8188eufw);
>>>  >
>>>  > #define RTEMS_BSD_CONFIG_BSP_CONFIG
>>>  > #define RTEMS_BSD_CONFIG_TERMIOS_KQUEUE_AND_POLL
>>>  > #define RTEMS_BSD_CONFIG_INIT
>>>  >
>>>  > #include 
>>>  > 
>>>  >
>>>  > in your application to add WLAN support. You could also remove the
>>>  > RTEMS_BSD_CONFIG_BSP_CONFIG (which has the effect that 
>>> nexus-devices.h
>>>  > is not included in the rtems-bsd-config.h) and define a different set
>>>  > of modules for your application.
>>>  >
>>>  > Best regards
>>>  >
>>>  > Christian
>>>
>>>  I guess this is a misunderstanding on my part. It might still be nice 
>>> to
>>>  have something switchable for testing purposes, but I see that it can 
>>> be
>>>  altered relatively easily on the application side of things.
>>>
>>>
>>> I think what you want is like what some of the BSPs do which have a
>>> second ifdef inside the LIBBSP conditional. This is an example from
>>> the QORIQ. Perhaps an option in the BSP?
>> Is the Ultrascale's interface different to the Zync, ie same driver?
> It's the same driver after some upgrades went in to LibBSD to pull in the
> changes from 13 with some additional modifications.

Excellent. The Versal has the same MAC in the hard IP as the Ultra. The Versal
also has a MRMAC and MCDMA glue for the PL but that is a different topic.

>>> https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/bsp/nexus-devices.h#n212
>>> 
>>>
>>>
>>> Would this qualify as a BSP variant?
>> If the hardware exists then I suggest adding both interfaces. This does not
>> effect how or why they are configured (see the config INI file). I would 
>> prefer
>> we do not add more variants for hardware that is present, ie 2 NICs.
> Every ultrascale+ chip has all 4 ethernet interfaces. What varies is where the
> PHY(s) are attached.

I suggest you add the MACs and some PHY drivers the eval boards use and let the
stack sort it out. The unknown PHY may work in some cases.

>>> If you can probe for each, you could configure both but I suspect that's
>>> likely undesirable for many applications. A configure option might be
>>> the cleanest thing. Probably not worth a BSP variant.
>> If this is for testing then I suggest you extend or look at the INI file
>> configure option. You should be able to select the interface to use for 
>> testing.
> 
> I'll add an option for testing purposes for use in config.ini.

Great and thanks.

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

Re: [PATCH v2] covoar: Store address-to-line info outside of DWARF

2021-06-07 Thread Chris Johns 
On 8/6/21 1:44 am, Joel Sherrill wrote:
> 
> 
> On Mon, Jun 7, 2021 at 7:00 AM Alex White  > wrote:
> 
> 
> On Wed, Jun 2, 2021 at 7:37 PM Chris Johns  > wrote:
> >
> > Looking good with a single comment below ...
> >
> > On 3/6/21 6:08 am, Alex White wrote:
> > > This adds the AddressToLineMapper class and supporting classes to
> > > assume responsibility of tracking address-to-line information.
> > >
> > > This allows the DWARF library to properly cleanup all of its resources
> > > and leads to significant memory savings.
> > >
> > > Closes #4383
> > > ---
> > >  rtemstoolkit/rld-dwarf.cpp           |   5 +
> > >  rtemstoolkit/rld-dwarf.h             |   5 +
> > >  tester/covoar/AddressToLineMapper.cc | 104 +
> > >  tester/covoar/AddressToLineMapper.h  | 211 
> +++
> > >  tester/covoar/ExecutableInfo.cc      |  73 +
> > >  tester/covoar/ExecutableInfo.h       |  11 +-
> > >  tester/covoar/wscript                |   1 +
> > >  7 files changed, 368 insertions(+), 42 deletions(-)
> > >  create mode 100644 tester/covoar/AddressToLineMapper.cc
> > >  create mode 100644 tester/covoar/AddressToLineMapper.h
> > >
> > > diff --git a/rtemstoolkit/rld-dwarf.cpp b/rtemstoolkit/rld-dwarf.cpp
> > > index 2fce0e4..1eae50c 100644
> > > --- a/rtemstoolkit/rld-dwarf.cpp
> > > +++ b/rtemstoolkit/rld-dwarf.cpp
> > > @@ -1893,6 +1893,11 @@ namespace rld
> > >        return false;
> > >      }
> > >
> > > +    const addresses& compilation_unit::get_addresses () const
> > > +    {
> > > +      return addr_lines_;
> > > +    }
> > > +
> > >      functions&
> > >      compilation_unit::get_functions ()
> > >      {
> > > diff --git a/rtemstoolkit/rld-dwarf.h b/rtemstoolkit/rld-dwarf.h
> > > index 1210813..eadb50d 100644
> > > --- a/rtemstoolkit/rld-dwarf.h
> > > +++ b/rtemstoolkit/rld-dwarf.h
> > > @@ -707,6 +707,11 @@ namespace rld
> > >         */
> > >        unsigned int pc_high () const;
> > >
> > > +      /**
> > > +       * The addresses associated with this compilation unit.
> > > +       */
> > > +      const addresses& get_addresses () const;
> > > +
> > >        /**
> > >         * Get the source and line for an address. If the address does
> not match
> > >         * false is returned the file is set to 'unknown' and the line 
> is
> set to
> > > diff --git a/tester/covoar/AddressToLineMapper.cc
> b/tester/covoar/AddressToLineMapper.cc
> > > new file mode 100644
> > > index 000..c305e3b
> > > --- /dev/null
> > > +++ b/tester/covoar/AddressToLineMapper.cc
> > > @@ -0,0 +1,104 @@
> > > +/*! @file AddressToLineMapper.cc
> > > + *  @brief AddressToLineMapper Implementation
> > > + *
> > > + *  This file contains the implementation of the functionality
> > > + *  of the AddressToLineMapper class.
> > > + */
> > > +
> > > +#include "AddressToLineMapper.h"
> > > +
> > > +namespace Coverage {
> > > +
> > > +  uint64_t SourceLine::location() const
> > > +  {
> > > +    return address;
> > > +  }
> > > +
> > > +  bool SourceLine::is_an_end_sequence() const
> > > +  {
> > > +    return is_end_sequence;
> > > +  }
> > > +
> > > +  const std::string& SourceLine::path() const
> > > +  {
> > > +    return path_;
> > > +  }
> > > +
> > > +  int SourceLine::line() const
> > > +  {
> > > +    return line_num;
> > > +  }
> > > +
> > > +  void AddressLineRange::addSourceLine(const rld::dwarf::address& 
> address)
> > > +  {
> > > +    auto insertResult = sourcePaths.insert(address.path());
> > > +
> > > +    sourceLines.emplace_back(
> > > +      SourceLine (
> > > +        address.location(),
> > > +        *insertResult.first,
> > > +        address.line(),
> > > +        address.is_an_end_sequence()
> > > +      )
> > > +    );
> > > +  }
> > > +
> > > +  const SourceLine& AddressLineRange::getSourceLine(uint32_t 
> address) const
> > > +  {
> > > +    if (address < lowAddress || address > highAddress) {
> > > +      throw SourceNotFoundError(std::to_string(address));
> > > +    }
> > > +
> > > +    const SourceLine* last_line = nullptr;
> > > +    for (const auto  : sourceLines) {
> > > +      if (address <= line.location())
> > > +      {
> > > +        if (address == line.location())
> > > +          last_line = 
> > > +        break;
> > > +      }
> > > +      last_line = 
> > > +    }
> > > +
> > > +    if (last_line == nullptr) {
> > > +      throw SourceNotFoundError(std::to_string(address));
> > > +    }
>

Re: [PATCH v1] bsps/riscv: Give enough time for clock driver initialization

2021-06-07 Thread Joel Sherrill 
On Mon, Jun 7, 2021 at 1:57 PM  wrote:

>
>
> > -Original Message-
> > From: Gedare Bloom 
> > Sent: Monday, June 7, 2021 7:00 PM
> > To: Sommer, Jan 
> > Cc: devel@rtems.org
> > Subject: Re: [PATCH v1] bsps/riscv: Give enough time for clock driver
> > initialization
> >
> > On Mon, Jun 7, 2021 at 9:47 AM Jan Sommer  wrote:
> > >
> > > - Clock driver initialization for secondary cores had to take less
> > > than one tick
> > > - If tick time is small (i.e. <= 1ms) setting up all cores could take
> > > too long and a fatal error is thrown.
> > > - Give at least 10 ms time for clock initialization to avoid this
> > > error
> >
> > Is there a reason to pick 10?
> >
>
> In qemu I (coarsely) measured 1.5ms for 8 cores.
> So I thought this should add enough buffer to prevent a fatal error.
> I probably could also reduce it to 5 ms.
>
> > I assume this blocks/idles the system until the interval elapses, so it
> would be
> > good to minimize waste (subject to Joel's noted rant about premature
> > optimization).
> >


No. I'm more worried about boot time. :)


>
>
> If you take a look at the clock initialization of the secondary cores (
> https://git.rtems.org/rtems/tree/bsps/riscv/riscv/clock/clockdrv.c#n178):
>
> _SMP_Othercast_action(riscv_clock_secondary_action, );
>
>   if (cmpval - riscv_clock_read_mtime(>mtime) >= interval) {
> bsp_fatal(RISCV_FATAL_CLOCK_SMP_INIT);
>   }
>
> It will put the first clock tick 10ms into the future (instead of just one
> tick), but it won't block the system initialization.
> It only prevents entering the if condition by having a large enough value
> for interval, but the runtime of the clock initialization is the same.
>
>
How does this impact the timeline for boot to first application thread?

Is there a period where the system is up but only one core?

Any other oddities I might be missing?


> > > ---
> > >  bsps/riscv/riscv/clock/clockdrv.c | 8 +++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/bsps/riscv/riscv/clock/clockdrv.c
> > > b/bsps/riscv/riscv/clock/clockdrv.c
> > > index 3afe86576f..102137aeab 100644
> > > --- a/bsps/riscv/riscv/clock/clockdrv.c
> > > +++ b/bsps/riscv/riscv/clock/clockdrv.c
> > > @@ -211,7 +211,13 @@ static void riscv_clock_initialize(void)
> > >tc->interval = interval;
> > >
> > >cmpval = riscv_clock_read_mtime(>mtime);
> > > -  cmpval += interval;
> > > +  /*
> > > +   * For very short intervals the time of 1 tick is not enough to
> > > +   * set up the timer on all cores in SMP systems.
> > > +   * Give the CPU at least 10 ms.
> > > +   */
> > > +  interval = (1 / us_per_tick) * interval;  cmpval += interval;
> > >
> > >riscv_clock_clint_init(clint, cmpval, 0);
> > >riscv_clock_secondary_initialization(clint, cmpval, interval);
> > > --
> > > 2.17.1
> > >
> > > ___
> > > devel mailing list
> > > devel@rtems.org
> > > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v1] bsps/riscv: Give enough time for clock driver initialization

2021-06-07 Thread Jan.Sommer 



> -Original Message-
> From: Gedare Bloom 
> Sent: Monday, June 7, 2021 7:00 PM
> To: Sommer, Jan 
> Cc: devel@rtems.org
> Subject: Re: [PATCH v1] bsps/riscv: Give enough time for clock driver
> initialization
> 
> On Mon, Jun 7, 2021 at 9:47 AM Jan Sommer  wrote:
> >
> > - Clock driver initialization for secondary cores had to take less
> > than one tick
> > - If tick time is small (i.e. <= 1ms) setting up all cores could take
> > too long and a fatal error is thrown.
> > - Give at least 10 ms time for clock initialization to avoid this
> > error
> 
> Is there a reason to pick 10?
>

In qemu I (coarsely) measured 1.5ms for 8 cores.
So I thought this should add enough buffer to prevent a fatal error.
I probably could also reduce it to 5 ms.
 
> I assume this blocks/idles the system until the interval elapses, so it would 
> be
> good to minimize waste (subject to Joel's noted rant about premature
> optimization).
> 

If you take a look at the clock initialization of the secondary cores 
(https://git.rtems.org/rtems/tree/bsps/riscv/riscv/clock/clockdrv.c#n178):

_SMP_Othercast_action(riscv_clock_secondary_action, );

  if (cmpval - riscv_clock_read_mtime(>mtime) >= interval) {
bsp_fatal(RISCV_FATAL_CLOCK_SMP_INIT);
  }

It will put the first clock tick 10ms into the future (instead of just one 
tick), but it won't block the system initialization.
It only prevents entering the if condition by having a large enough value for 
interval, but the runtime of the clock initialization is the same.

> > ---
> >  bsps/riscv/riscv/clock/clockdrv.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/bsps/riscv/riscv/clock/clockdrv.c
> > b/bsps/riscv/riscv/clock/clockdrv.c
> > index 3afe86576f..102137aeab 100644
> > --- a/bsps/riscv/riscv/clock/clockdrv.c
> > +++ b/bsps/riscv/riscv/clock/clockdrv.c
> > @@ -211,7 +211,13 @@ static void riscv_clock_initialize(void)
> >tc->interval = interval;
> >
> >cmpval = riscv_clock_read_mtime(>mtime);
> > -  cmpval += interval;
> > +  /*
> > +   * For very short intervals the time of 1 tick is not enough to
> > +   * set up the timer on all cores in SMP systems.
> > +   * Give the CPU at least 10 ms.
> > +   */
> > +  interval = (1 / us_per_tick) * interval;  cmpval += interval;
> >
> >riscv_clock_clint_init(clint, cmpval, 0);
> >riscv_clock_secondary_initialization(clint, cmpval, interval);
> > --
> > 2.17.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 2/2] i386: Remove unneeded include header files

2021-06-07 Thread Gedare Bloom 
This looks like a much better solution :) If no one complains by
Thursday go ahead and push it.

On Mon, Jun 7, 2021 at 2:53 AM Jan Sommer  wrote:
>
> ---
>  .../sys/i386/include/machine/intr_machdep.h   |6 -
>  rtemsbsd/include/x86/bus.h| 1109 
>  rtemsbsd/include/x86/specialreg.h | 1143 -
>  3 files changed, 2258 deletions(-)
>  delete mode 100644 freebsd/sys/i386/include/machine/intr_machdep.h
>  delete mode 100644 rtemsbsd/include/x86/bus.h
>  delete mode 100644 rtemsbsd/include/x86/specialreg.h
>
> diff --git a/freebsd/sys/i386/include/machine/intr_machdep.h 
> b/freebsd/sys/i386/include/machine/intr_machdep.h
> deleted file mode 100644
> index a0b28387..
> --- a/freebsd/sys/i386/include/machine/intr_machdep.h
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -/*-
> - * This file is in the public domain.
> - */
> -/* $FreeBSD$ */
> -
> -#include 
> diff --git a/rtemsbsd/include/x86/bus.h b/rtemsbsd/include/x86/bus.h
> deleted file mode 100644
> index 2427ae51..
> --- a/rtemsbsd/include/x86/bus.h
> +++ /dev/null
> @@ -1,1109 +0,0 @@
> -/*-
> - * SPDX-License-Identifier: BSD-3-Clause AND BSD-2-Clause-NetBSDE
> - *
> - * Copyright (c) KATO Takenori, 1999.
> - *
> - * All rights reserved.  Unpublished rights reserved under the copyright
> - * laws of Japan.
> - *
> - * 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 as
> - *the first lines of this file unmodified.
> - * 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. The name of the author may not be used to endorse or promote products
> - *derived from this software without specific prior written permission.
> - *
> - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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 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.
> - *
> - * $FreeBSD$
> - */
> -
> -/* $NetBSD: bus.h,v 1.12 1997/10/01 08:25:15 fvdl Exp $*/
> -
> -/*-
> - * Copyright (c) 1996, 1997 The NetBSD Foundation, Inc.
> - * All rights reserved.
> - *
> - * This code is derived from software contributed to The NetBSD Foundation
> - * by Jason R. Thorpe of the Numerical Aerospace Simulation Facility,
> - * NASA Ames Research Center.
> - *
> - * 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 NETBSD FOUNDATION, INC. 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 FOUNDATION 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.
> - */
> -
> -/*-
> - * Copyright (c) 1996 Charles M. Hannum.  All rights reserved.
> - * Copyright (c) 1996 Christopher G. Demetriou.  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

Re: [PATCH v1] bsps/riscv: Give enough time for clock driver initialization

2021-06-07 Thread Gedare Bloom 
On Mon, Jun 7, 2021 at 9:47 AM Jan Sommer  wrote:
>
> - Clock driver initialization for secondary cores had to take less than
> one tick
> - If tick time is small (i.e. <= 1ms) setting up all cores could take
> too long and a fatal error is thrown.
> - Give at least 10 ms time for clock initialization to avoid this error

Is there a reason to pick 10?

I assume this blocks/idles the system until the interval elapses, so
it would be good to minimize waste (subject to Joel's noted rant about
premature optimization).

> ---
>  bsps/riscv/riscv/clock/clockdrv.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/bsps/riscv/riscv/clock/clockdrv.c 
> b/bsps/riscv/riscv/clock/clockdrv.c
> index 3afe86576f..102137aeab 100644
> --- a/bsps/riscv/riscv/clock/clockdrv.c
> +++ b/bsps/riscv/riscv/clock/clockdrv.c
> @@ -211,7 +211,13 @@ static void riscv_clock_initialize(void)
>tc->interval = interval;
>
>cmpval = riscv_clock_read_mtime(>mtime);
> -  cmpval += interval;
> +  /*
> +   * For very short intervals the time of 1 tick is not enough to
> +   * set up the timer on all cores in SMP systems.
> +   * Give the CPU at least 10 ms.
> +   */
> +  interval = (1 / us_per_tick) * interval;
> +  cmpval += interval;
>
>riscv_clock_clint_init(clint, cmpval, 0);
>riscv_clock_secondary_initialization(clint, cmpval, interval);
> --
> 2.17.1
>
> ___
> 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 v1] bsps/riscv: Give enough time for clock driver initialization

2021-06-07 Thread Jan Sommer 
- Clock driver initialization for secondary cores had to take less than
one tick
- If tick time is small (i.e. <= 1ms) setting up all cores could take
too long and a fatal error is thrown.
- Give at least 10 ms time for clock initialization to avoid this error
---
 bsps/riscv/riscv/clock/clockdrv.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/bsps/riscv/riscv/clock/clockdrv.c 
b/bsps/riscv/riscv/clock/clockdrv.c
index 3afe86576f..102137aeab 100644
--- a/bsps/riscv/riscv/clock/clockdrv.c
+++ b/bsps/riscv/riscv/clock/clockdrv.c
@@ -211,7 +211,13 @@ static void riscv_clock_initialize(void)
   tc->interval = interval;
 
   cmpval = riscv_clock_read_mtime(>mtime);
-  cmpval += interval;
+  /*
+   * For very short intervals the time of 1 tick is not enough to
+   * set up the timer on all cores in SMP systems.
+   * Give the CPU at least 10 ms.
+   */
+  interval = (1 / us_per_tick) * interval;
+  cmpval += interval; 
 
   riscv_clock_clint_init(clint, cmpval, 0);
   riscv_clock_secondary_initialization(clint, cmpval, interval);
-- 
2.17.1

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

Re: [PATCH v2] covoar: Store address-to-line info outside of DWARF

2021-06-07 Thread Joel Sherrill 
On Mon, Jun 7, 2021 at 7:00 AM Alex White  wrote:

>
> On Wed, Jun 2, 2021 at 7:37 PM Chris Johns  wrote:
> >
> > Looking good with a single comment below ...
> >
> > On 3/6/21 6:08 am, Alex White wrote:
> > > This adds the AddressToLineMapper class and supporting classes to
> > > assume responsibility of tracking address-to-line information.
> > >
> > > This allows the DWARF library to properly cleanup all of its resources
> > > and leads to significant memory savings.
> > >
> > > Closes #4383
> > > ---
> > >  rtemstoolkit/rld-dwarf.cpp   |   5 +
> > >  rtemstoolkit/rld-dwarf.h |   5 +
> > >  tester/covoar/AddressToLineMapper.cc | 104 +
> > >  tester/covoar/AddressToLineMapper.h  | 211 +++
> > >  tester/covoar/ExecutableInfo.cc  |  73 +
> > >  tester/covoar/ExecutableInfo.h   |  11 +-
> > >  tester/covoar/wscript|   1 +
> > >  7 files changed, 368 insertions(+), 42 deletions(-)
> > >  create mode 100644 tester/covoar/AddressToLineMapper.cc
> > >  create mode 100644 tester/covoar/AddressToLineMapper.h
> > >
> > > diff --git a/rtemstoolkit/rld-dwarf.cpp b/rtemstoolkit/rld-dwarf.cpp
> > > index 2fce0e4..1eae50c 100644
> > > --- a/rtemstoolkit/rld-dwarf.cpp
> > > +++ b/rtemstoolkit/rld-dwarf.cpp
> > > @@ -1893,6 +1893,11 @@ namespace rld
> > >return false;
> > >  }
> > >
> > > +const addresses& compilation_unit::get_addresses () const
> > > +{
> > > +  return addr_lines_;
> > > +}
> > > +
> > >  functions&
> > >  compilation_unit::get_functions ()
> > >  {
> > > diff --git a/rtemstoolkit/rld-dwarf.h b/rtemstoolkit/rld-dwarf.h
> > > index 1210813..eadb50d 100644
> > > --- a/rtemstoolkit/rld-dwarf.h
> > > +++ b/rtemstoolkit/rld-dwarf.h
> > > @@ -707,6 +707,11 @@ namespace rld
> > > */
> > >unsigned int pc_high () const;
> > >
> > > +  /**
> > > +   * The addresses associated with this compilation unit.
> > > +   */
> > > +  const addresses& get_addresses () const;
> > > +
> > >/**
> > > * Get the source and line for an address. If the address does
> not match
> > > * false is returned the file is set to 'unknown' and the line
> is set to
> > > diff --git a/tester/covoar/AddressToLineMapper.cc
> b/tester/covoar/AddressToLineMapper.cc
> > > new file mode 100644
> > > index 000..c305e3b
> > > --- /dev/null
> > > +++ b/tester/covoar/AddressToLineMapper.cc
> > > @@ -0,0 +1,104 @@
> > > +/*! @file AddressToLineMapper.cc
> > > + *  @brief AddressToLineMapper Implementation
> > > + *
> > > + *  This file contains the implementation of the functionality
> > > + *  of the AddressToLineMapper class.
> > > + */
> > > +
> > > +#include "AddressToLineMapper.h"
> > > +
> > > +namespace Coverage {
> > > +
> > > +  uint64_t SourceLine::location() const
> > > +  {
> > > +return address;
> > > +  }
> > > +
> > > +  bool SourceLine::is_an_end_sequence() const
> > > +  {
> > > +return is_end_sequence;
> > > +  }
> > > +
> > > +  const std::string& SourceLine::path() const
> > > +  {
> > > +return path_;
> > > +  }
> > > +
> > > +  int SourceLine::line() const
> > > +  {
> > > +return line_num;
> > > +  }
> > > +
> > > +  void AddressLineRange::addSourceLine(const rld::dwarf::address&
> address)
> > > +  {
> > > +auto insertResult = sourcePaths.insert(address.path());
> > > +
> > > +sourceLines.emplace_back(
> > > +  SourceLine (
> > > +address.location(),
> > > +*insertResult.first,
> > > +address.line(),
> > > +address.is_an_end_sequence()
> > > +  )
> > > +);
> > > +  }
> > > +
> > > +  const SourceLine& AddressLineRange::getSourceLine(uint32_t address)
> const
> > > +  {
> > > +if (address < lowAddress || address > highAddress) {
> > > +  throw SourceNotFoundError(std::to_string(address));
> > > +}
> > > +
> > > +const SourceLine* last_line = nullptr;
> > > +for (const auto  : sourceLines) {
> > > +  if (address <= line.location())
> > > +  {
> > > +if (address == line.location())
> > > +  last_line = 
> > > +break;
> > > +  }
> > > +  last_line = 
> > > +}
> > > +
> > > +if (last_line == nullptr) {
> > > +  throw SourceNotFoundError(std::to_string(address));
> > > +}
> > > +
> > > +return *last_line;
> > > +  }
> >
> > How often is this function being called? If it is a hot spot are there
> other
> > ways to search for the address? I suppose it depends on the number of
> lines in
> > the vector.
>
> According to a quick gprof run, this function is being called a decent
> amount, somewhere around 1.5 million times for a full ARM coverage run.
>
> But it only takes up a very small amount (less than 0.02%) of cumulative
> execution time so I don't believe it is an issue.
>

Glad we have profiling data to guide optimizations. I also suspect that as
the code is c-plus-plus-ified more, some performance

Re: Selection of ethernet peripheral by application

2021-06-07 Thread Kinsey Moore 

On 6/6/2021 17:42, Chris Johns wrote:

On 4/6/21 11:26 pm, Joel Sherrill wrote:

On Fri, Jun 4, 2021 at 7:59 AM Kinsey Moore mailto:kinsey.mo...@oarcorp.com>> wrote:

 On 6/4/2021 02:32, Christian MAUDERER wrote:
 > Am 02.06.21 um 20:37 schrieb Kinsey Moore:
 >> Hello,
 >>
 >>  From what I’ve seen of the various BSPs supported by LibBSD that
 >> have multiple ethernet peripherals,
 >>
 >> only one tends to be chosen and supported. I’ve encountered a
 >> situation where the majority of platform
 >>
 >> examples (Zynq Ultrascale+ MPSoC dev boards) use CGEM3 as the
 >> only/primary ethernet interface and I
 >>
 >> need to have the option of selecting a different peripheral as the
 >> primary interface.
 >>
 >> Unfortunately, the current configuration of LibBSD/RTEMS does not
 >> allow for easy switching among the
 >>
 >> available interfaces. The easy one-off option is to just create a BSP
 >> variant with a little bit of extra logic
 >>
 >> to select the correct interface in LibBSD, but this problem seems
 >> more generally applicable than just
 >>
 >> ethernet and just this one BSP. Is the best alternative to configure
 >> all available devices in
 >>
 >> nexus-devices.h and let LibBSD figure it out?
 >>
 >> Thanks,
 >> Kinsey
 >>
 >
 > If the problem is with "nexus-devices.h": You can always just add
 > further devices or a completely own set of devices in your
 > application. For example it should be no problem to use
 >
 > 
 > SYSINIT_MODULE_REFERENCE(wlan_ratectl_none);
 > SYSINIT_MODULE_REFERENCE(wlan_sta);
 > SYSINIT_MODULE_REFERENCE(wlan_amrr);
 > SYSINIT_MODULE_REFERENCE(wlan_wep);
 > SYSINIT_MODULE_REFERENCE(wlan_tkip);
 > SYSINIT_MODULE_REFERENCE(wlan_ccmp);
 > SYSINIT_DRIVER_REFERENCE(rtwn_usb, uhub);
 > SYSINIT_REFERENCE(rtwn_rtl8188eufw);
 >
 > #define RTEMS_BSD_CONFIG_BSP_CONFIG
 > #define RTEMS_BSD_CONFIG_TERMIOS_KQUEUE_AND_POLL
 > #define RTEMS_BSD_CONFIG_INIT
 >
 > #include 
 > 
 >
 > in your application to add WLAN support. You could also remove the
 > RTEMS_BSD_CONFIG_BSP_CONFIG (which has the effect that nexus-devices.h
 > is not included in the rtems-bsd-config.h) and define a different set
 > of modules for your application.
 >
 > Best regards
 >
 > Christian

 I guess this is a misunderstanding on my part. It might still be nice to
 have something switchable for testing purposes, but I see that it can be
 altered relatively easily on the application side of things.


I think what you want is like what some of the BSPs do which have a
second ifdef inside the LIBBSP conditional. This is an example from
the QORIQ. Perhaps an option in the BSP?

Is the Ultrascale's interface different to the Zync, ie same driver?
It's the same driver after some upgrades went in to LibBSD to pull in 
the changes from 13 with some additional modifications.



https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/bsp/nexus-devices.h#n212 


Would this qualify as a BSP variant?

If the hardware exists then I suggest adding both interfaces. This does not
effect how or why they are configured (see the config INI file). I would prefer
we do not add more variants for hardware that is present, ie 2 NICs.
Every ultrascale+ chip has all 4 ethernet interfaces. What varies is 
where the PHY(s) are attached.



If you can probe for each, you could configure both but I suspect that's
likely undesirable for many applications. A configure option might be
the cleanest thing. Probably not worth a BSP variant.

If this is for testing then I suggest you extend or look at the INI file
configure option. You should be able to select the interface to use for testing.


I'll add an option for testing purposes for use in config.ini.


Thanks,

Kinsey

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

Re: [PATCH v2] covoar: Store address-to-line info outside of DWARF

2021-06-07 Thread Alex White 

On Wed, Jun 2, 2021 at 7:37 PM Chris Johns  wrote:
>
> Looking good with a single comment below ...
>
> On 3/6/21 6:08 am, Alex White wrote:
> > This adds the AddressToLineMapper class and supporting classes to
> > assume responsibility of tracking address-to-line information.
> >
> > This allows the DWARF library to properly cleanup all of its resources
> > and leads to significant memory savings.
> >
> > Closes #4383
> > ---
> >  rtemstoolkit/rld-dwarf.cpp   |   5 +
> >  rtemstoolkit/rld-dwarf.h |   5 +
> >  tester/covoar/AddressToLineMapper.cc | 104 +
> >  tester/covoar/AddressToLineMapper.h  | 211 +++
> >  tester/covoar/ExecutableInfo.cc  |  73 +
> >  tester/covoar/ExecutableInfo.h   |  11 +-
> >  tester/covoar/wscript|   1 +
> >  7 files changed, 368 insertions(+), 42 deletions(-)
> >  create mode 100644 tester/covoar/AddressToLineMapper.cc
> >  create mode 100644 tester/covoar/AddressToLineMapper.h
> >
> > diff --git a/rtemstoolkit/rld-dwarf.cpp b/rtemstoolkit/rld-dwarf.cpp
> > index 2fce0e4..1eae50c 100644
> > --- a/rtemstoolkit/rld-dwarf.cpp
> > +++ b/rtemstoolkit/rld-dwarf.cpp
> > @@ -1893,6 +1893,11 @@ namespace rld
> >return false;
> >  }
> >
> > +const addresses& compilation_unit::get_addresses () const
> > +{
> > +  return addr_lines_;
> > +}
> > +
> >  functions&
> >  compilation_unit::get_functions ()
> >  {
> > diff --git a/rtemstoolkit/rld-dwarf.h b/rtemstoolkit/rld-dwarf.h
> > index 1210813..eadb50d 100644
> > --- a/rtemstoolkit/rld-dwarf.h
> > +++ b/rtemstoolkit/rld-dwarf.h
> > @@ -707,6 +707,11 @@ namespace rld
> > */
> >unsigned int pc_high () const;
> >
> > +  /**
> > +   * The addresses associated with this compilation unit.
> > +   */
> > +  const addresses& get_addresses () const;
> > +
> >/**
> > * Get the source and line for an address. If the address does not 
> > match
> > * false is returned the file is set to 'unknown' and the line is 
> > set to
> > diff --git a/tester/covoar/AddressToLineMapper.cc 
> > b/tester/covoar/AddressToLineMapper.cc
> > new file mode 100644
> > index 000..c305e3b
> > --- /dev/null
> > +++ b/tester/covoar/AddressToLineMapper.cc
> > @@ -0,0 +1,104 @@
> > +/*! @file AddressToLineMapper.cc
> > + *  @brief AddressToLineMapper Implementation
> > + *
> > + *  This file contains the implementation of the functionality
> > + *  of the AddressToLineMapper class.
> > + */
> > +
> > +#include "AddressToLineMapper.h"
> > +
> > +namespace Coverage {
> > +
> > +  uint64_t SourceLine::location() const
> > +  {
> > +return address;
> > +  }
> > +
> > +  bool SourceLine::is_an_end_sequence() const
> > +  {
> > +return is_end_sequence;
> > +  }
> > +
> > +  const std::string& SourceLine::path() const
> > +  {
> > +return path_;
> > +  }
> > +
> > +  int SourceLine::line() const
> > +  {
> > +return line_num;
> > +  }
> > +
> > +  void AddressLineRange::addSourceLine(const rld::dwarf::address& address)
> > +  {
> > +auto insertResult = sourcePaths.insert(address.path());
> > +
> > +sourceLines.emplace_back(
> > +  SourceLine (
> > +address.location(),
> > +*insertResult.first,
> > +address.line(),
> > +address.is_an_end_sequence()
> > +  )
> > +);
> > +  }
> > +
> > +  const SourceLine& AddressLineRange::getSourceLine(uint32_t address) const
> > +  {
> > +if (address < lowAddress || address > highAddress) {
> > +  throw SourceNotFoundError(std::to_string(address));
> > +}
> > +
> > +const SourceLine* last_line = nullptr;
> > +for (const auto  : sourceLines) {
> > +  if (address <= line.location())
> > +  {
> > +if (address == line.location())
> > +  last_line = 
> > +break;
> > +  }
> > +  last_line = 
> > +}
> > +
> > +if (last_line == nullptr) {
> > +  throw SourceNotFoundError(std::to_string(address));
> > +}
> > +
> > +return *last_line;
> > +  }
>
> How often is this function being called? If it is a hot spot are there other
> ways to search for the address? I suppose it depends on the number of lines in
> the vector.

According to a quick gprof run, this function is being called a decent amount, 
somewhere around 1.5 million times for a full ARM coverage run.

But it only takes up a very small amount (less than 0.02%) of cumulative 
execution time so I don't believe it is an issue.

Alex

>
> If the sourcesLines vector was sorted can this loop be replaced with some form
> of std::upper_bound? That is ...
>
>  auto last_line =
> std::upper_bound(sourceLines.begin(),
>  sourceLines.end(),
>  address,
>  [](const SourceLine& sl) {
>return address < sl.location();
>  });
>
> [ not sure if the code I posted would work and if I got

[PATCH v2 2/2] i386: Remove unneeded include header files

2021-06-07 Thread Jan Sommer 
---
 .../sys/i386/include/machine/intr_machdep.h   |6 -
 rtemsbsd/include/x86/bus.h| 1109 
 rtemsbsd/include/x86/specialreg.h | 1143 -
 3 files changed, 2258 deletions(-)
 delete mode 100644 freebsd/sys/i386/include/machine/intr_machdep.h
 delete mode 100644 rtemsbsd/include/x86/bus.h
 delete mode 100644 rtemsbsd/include/x86/specialreg.h

diff --git a/freebsd/sys/i386/include/machine/intr_machdep.h 
b/freebsd/sys/i386/include/machine/intr_machdep.h
deleted file mode 100644
index a0b28387..
--- a/freebsd/sys/i386/include/machine/intr_machdep.h
+++ /dev/null
@@ -1,6 +0,0 @@
-/*-
- * This file is in the public domain.
- */
-/* $FreeBSD$ */
-
-#include 
diff --git a/rtemsbsd/include/x86/bus.h b/rtemsbsd/include/x86/bus.h
deleted file mode 100644
index 2427ae51..
--- a/rtemsbsd/include/x86/bus.h
+++ /dev/null
@@ -1,1109 +0,0 @@
-/*-
- * SPDX-License-Identifier: BSD-3-Clause AND BSD-2-Clause-NetBSDE
- *
- * Copyright (c) KATO Takenori, 1999.
- *
- * All rights reserved.  Unpublished rights reserved under the copyright
- * laws of Japan.
- *
- * 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 as
- *the first lines of this file unmodified.
- * 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. The name of the author may not be used to endorse or promote products
- *derived from this software without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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 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.
- *
- * $FreeBSD$
- */
-
-/* $NetBSD: bus.h,v 1.12 1997/10/01 08:25:15 fvdl Exp $*/
-
-/*-
- * Copyright (c) 1996, 1997 The NetBSD Foundation, Inc.
- * All rights reserved.
- *
- * This code is derived from software contributed to The NetBSD Foundation
- * by Jason R. Thorpe of the Numerical Aerospace Simulation Facility,
- * NASA Ames Research Center.
- *
- * 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 NETBSD FOUNDATION, INC. 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 FOUNDATION 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.
- */
-
-/*-
- * Copyright (c) 1996 Charles M. Hannum.  All rights reserved.
- * Copyright (c) 1996 Christopher G. Demetriou.  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.
- * 3. All advertising

[PATCH v2 1/2] waf_libbsd.py: Apply path-mappings to header-paths

2021-06-07 Thread Jan Sommer 
---
 libbsd.py |  2 +-
 waf_libbsd.py | 27 +--
 2 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/libbsd.py b/libbsd.py
index add91e5a..c9151901 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -144,6 +144,7 @@ _defaults = {
  ('freebsd/sys/dev/pci','**/*.h',  
'dev/pci'),
  ('freebsd/sys/dev/nvme',   '**/*.h',  
'dev/nvme'),
  ('freebsd/sys/dev/evdev',  '**/*.h',  
'dev/evdev'),
+ ('freebsd/sys/@CPU@/include',  '**/*.h',  
''),
  ('linux/include',  '**/*.h',  
''),
  ('mDNSResponder/mDNSCore', 'mDNSDebug.h', 
''),
  ('mDNSResponder/mDNSCore', 'mDNSEmbeddedAPI.h',   
''),
@@ -1585,7 +1586,6 @@ class dev_nic(builder.Module):
 'sys/arm64/include/cpu.h',
 'sys/arm/include/cpufunc.h',
 'sys/i386/include/md_var.h',
-'sys/i386/include/intr_machdep.h',
 'sys/x86/include/intr_machdep.h',
 'sys/i386/include/cpufunc.h',
 'sys/x86/include/intr_machdep.h',
diff --git a/waf_libbsd.py b/waf_libbsd.py
index 070d3eac..0bd4fd3d 100644
--- a/waf_libbsd.py
+++ b/waf_libbsd.py
@@ -538,17 +538,24 @@ class Builder(builder.ModuleManager):
 if 'header-paths' in config:
 headerPaths = config['header-paths']
 cpu = bld.get_env()['RTEMS_ARCH']
-if cpu == "i386":
-cpu = 'x86'
 for headers in headerPaths:
-# Get the dest path
-ipath = os.path.join(arch_inc_path, headers[2])
-start_dir = bld.path.find_dir(headers[0].replace('@CPU@', cpu))
-if start_dir != None:
-bld.install_files("${PREFIX}/" + ipath,
-  start_dir.ant_glob(headers[1]),
-  cwd=start_dir,
-  relative_trick=True)
+paths = [headers[0].replace('@CPU@', cpu)]
+# Apply the path mappings
+for source, targets in config['path-mappings']:
+if source in paths:
+i = paths.index(source)
+paths.remove(source)
+paths[i:i] = targets
+
+for hp in paths:
+# Get the dest path
+ipath = os.path.join(arch_inc_path, headers[2])
+start_dir = bld.path.find_dir(hp)
+if start_dir != None:
+bld.install_files("${PREFIX}/" + ipath,
+start_dir.ant_glob(headers[1]),
+cwd=start_dir,
+relative_trick=True)
 
 bld.install_files(os.path.join("${PREFIX}", arch_inc_path,
module_header_path),
-- 
2.17.1

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

[PATCH v2 0/2] [libbsd] i386: Install correct machine include headers

2021-06-07 Thread Jan Sommer 
Second version for fixing the include header problem for i386.
This time not much changes for other BSPs. For i386 no
functional header are needed in the rtemsbsd directory anymore.
Only headers which redirect.

It essentially adds the path mapping feature also to the
header-paths of libbsd.py, to fix the issues with the duality
of the include paths for i386/x86.

Best regards,

Jan

Jan Sommer (2):
  waf_libbsd.py: Apply path-mappings to header-paths
  i386: Remove unneeded include header files

 .../sys/i386/include/machine/intr_machdep.h   |6 -
 libbsd.py |2 +-
 rtemsbsd/include/x86/bus.h| 1109 
 rtemsbsd/include/x86/specialreg.h | 1143 -
 waf_libbsd.py |   27 +-
 5 files changed, 18 insertions(+), 2269 deletions(-)
 delete mode 100644 freebsd/sys/i386/include/machine/intr_machdep.h
 delete mode 100644 rtemsbsd/include/x86/bus.h
 delete mode 100644 rtemsbsd/include/x86/specialreg.h

-- 
2.17.1

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

Re: [PATCH rtems 2/2] bsps/imxrt: Simplify linkcmds and make it flexible

2021-06-07 Thread Christian Mauderer 

Hello Gedare,

I think the Options don't need documentation changes because the options 
in the waf based build system are now documented directly in the yaml 
files and printed if you generate the default config. But I think I 
should add a documentation for the ARM PLL. I'll send a patch as soon as 
I get back to work on this after my vacation (about two weeks).


Best regards

Christian

On 04/06/2021 19:45, Gedare Bloom wrote:

does this one need doco update for the option changes?

On Fri, Jun 4, 2021 at 1:48 AM Christian Mauderer
 wrote:


Calling the memory FLASH and EXTRAM instead of FLEXSPI and SDRAM makes
it simpler to support other types of external RAM. This patch also
removes some of the calculations and improves names and documentation to
avoid pitfalls. It removes a unnecessary memory definition.

Update #4180
---
  bsps/arm/imxrt/include/imxrt/memory.h | 34 ++
  bsps/arm/imxrt/start/flash-boot-data.c|  4 +-
  ...{flash-config.c => flash-flexspi-config.c} |  2 +-
  bsps/arm/imxrt/start/linkcmds.flexspi | 38 +++
  bsps/arm/imxrt/start/linkcmds.sdram   | 34 +++---
  bsps/arm/imxrt/start/mpu-config.c | 12 ++---
  spec/build/bsps/arm/imxrt/bspimxrt.yml| 20 
  spec/build/bsps/arm/imxrt/linkcmdsmemory.yml  | 47 +--
  ...ocachesz.yml => optmemextramnocachesz.yml} |  5 +-
  ...emsdrambase.yml => optmemextramorigin.yml} |  5 +-
  spec/build/bsps/arm/imxrt/optmemextramsz.yml  | 19 
  ...ptmemsdramsz.yml => optmemflashorigin.yml} |  9 ++--
  spec/build/bsps/arm/imxrt/optmemflashsz.yml   | 20 
  spec/build/bsps/arm/imxrt/optmemflexspisz.yml | 17 ---
  spec/build/bsps/arm/imxrt/optmemitcmsz.yml|  7 +--
  spec/build/bsps/arm/imxrt/optmemnullsz.yml|  5 +-
  .../bsps/arm/imxrt/optmemocramnocachesz.yml   |  3 +-
  spec/build/bsps/arm/imxrt/optmemocramsz.yml   |  6 ++-
  18 files changed, 156 insertions(+), 131 deletions(-)
  rename bsps/arm/imxrt/start/{flash-config.c => flash-flexspi-config.c} (98%)
  rename spec/build/bsps/arm/imxrt/{optmemsdramnocachesz.yml => 
optmemextramnocachesz.yml} (66%)
  rename spec/build/bsps/arm/imxrt/{optmemsdrambase.yml => 
optmemextramorigin.yml} (65%)
  create mode 100644 spec/build/bsps/arm/imxrt/optmemextramsz.yml
  rename spec/build/bsps/arm/imxrt/{optmemsdramsz.yml => optmemflashorigin.yml} 
(53%)
  create mode 100644 spec/build/bsps/arm/imxrt/optmemflashsz.yml
  delete mode 100644 spec/build/bsps/arm/imxrt/optmemflexspisz.yml

diff --git a/bsps/arm/imxrt/include/imxrt/memory.h 
b/bsps/arm/imxrt/include/imxrt/memory.h
index 8185f713cc..47bb10f41e 100644
--- a/bsps/arm/imxrt/include/imxrt/memory.h
+++ b/bsps/arm/imxrt/include/imxrt/memory.h
@@ -56,29 +56,25 @@ extern char imxrt_memory_peripheral_begin[];
  extern char imxrt_memory_peripheral_end[];
  extern char imxrt_memory_peripheral_size[];

-extern char imxrt_memory_flexspi_config_begin[];
-extern char imxrt_memory_flexspi_config_end[];
-extern char imxrt_memory_flexspi_config_size[];
+extern char imxrt_memory_flash_config_begin[];
+extern char imxrt_memory_flash_config_end[];
+extern char imxrt_memory_flash_config_size[];

-extern char imxrt_memory_flexspi_ivt_begin[];
-extern char imxrt_memory_flexspi_ivt_end[];
-extern char imxrt_memory_flexspi_ivt_size[];
+extern char imxrt_memory_flash_ivt_begin[];
+extern char imxrt_memory_flash_ivt_end[];
+extern char imxrt_memory_flash_ivt_size[];

-extern char imxrt_memory_flexspi_begin[];
-extern char imxrt_memory_flexspi_end[];
-extern char imxrt_memory_flexspi_size[];
+extern char imxrt_memory_flash_begin[];
+extern char imxrt_memory_flash_end[];
+extern char imxrt_memory_flash_size[];

-extern char imxrt_memory_flexspi_fifo_begin[];
-extern char imxrt_memory_flexspi_fifo_end[];
-extern char imxrt_memory_flexspi_fifo_size[];
+extern char imxrt_memory_extram_begin[];
+extern char imxrt_memory_extram_end[];
+extern char imxrt_memory_extram_size[];

-extern char imxrt_memory_sdram_begin[];
-extern char imxrt_memory_sdram_end[];
-extern char imxrt_memory_sdram_size[];
-
-extern char imxrt_memory_sdram_nocache_begin[];
-extern char imxrt_memory_sdram_nocache_end[];
-extern char imxrt_memory_sdram_nocache_size[];
+extern char imxrt_memory_extram_nocache_begin[];
+extern char imxrt_memory_extram_nocache_end[];
+extern char imxrt_memory_extram_nocache_size[];

  #ifdef __cplusplus
  }
diff --git a/bsps/arm/imxrt/start/flash-boot-data.c 
b/bsps/arm/imxrt/start/flash-boot-data.c
index cf0430af72..a1877f4d26 100644
--- a/bsps/arm/imxrt/start/flash-boot-data.c
+++ b/bsps/arm/imxrt/start/flash-boot-data.c
@@ -30,8 +30,8 @@
  #include 

  const BOOT_DATA_T imxrt_boot_data = {
-  .start = (uint32_t) imxrt_memory_flexspi_config_begin,
-  .size = IMXRT_MEMORY_FLEXSPI_FLASH_SIZE,
+  .start = (uint32_t) imxrt_memory_flash_config_begin,
+  .size = IMXRT_MEMORY_FLASH_SIZE,
.plugin = PLUGIN_FLAG,
.placeholder = 0x,
  };
diff --git