date:20200402

Re: [PATCH v2] Chapter-on-need-for-RTEMS-specific-cross-compiler

2020-04-02 Thread Utkarsh Rai

On Fri, Apr 3, 2020 at 8:15 AM Chris Johns  wrote:

> On 2020-03-28 00:13, utkarsh.ra...@gmail.com wrote:
> > ---
> >   user/start/tools.rst | 34 ++
> >   1 file changed, 34 insertions(+)
> >
> > diff --git a/user/start/tools.rst b/user/start/tools.rst
> > index c3f039b..8ea1f64 100644
> > --- a/user/start/tools.rst
> > +++ b/user/start/tools.rst
> > @@ -3,6 +3,7 @@
> >   .. Copyright (C) 2019 embedded brains GmbH
> >   .. Copyright (C) 2019 Sebastian Huber
> >   .. Copyright (C) 2020 Chris Johns
> > +.. Copyright (C) 2020 Utkarsh Rai
> >
> >   .. _QuickStartTools:
> >
> > @@ -76,3 +77,36 @@ source code used.
> >
> >
> >   Add ``--verbose`` to the GCC command for the the verbose version
> details.
> > +
> > +
> > +Need for RTEMS-Specific Cross-Compiler
> > +
>
> Length of ---'s does not match the heading.
>
> > +
> > +New users are often confused as to why they cannot use their
> distribution's
> > +cross-compiler for their target on rtems, e.g., the riscv64-linux-gnu
> or the
> > +arm-none-eabi-gcc on RTEMS. Below mentioned are some of the reasons for
> using
> > +the RTEMS cross-compiler.
> > +
> > + ``Correct configuration of Newlib -``
> > + Newlib is a C standard library implementation intended for use on
> embedded
> > + systems. Most of the POSIX and libc support for RTEMS is derived
> from
> > + Newlib. The RTEMS cross-compiler configures Newlib correctly for
> RTEMS.
> > +
> > + ``Threading in GCC support libraries -``
> > + Several threading packages in GCC such as Go threads (libgo),
> OpenMP
> > + (libgomp), and OpenACC need to be customized according to RTEMS.
> This is
> > + done by the RTEMS specific cross-compiler.
> > +
> > + ``Provide preprocessor define __rtems__ -``
> > + The  ``__rtems__``  preprocessor define is used to provide
> conditional code
> > + compilation in source files that are shared with other projects
> e.g. in
> > + Newlib or imported code from FreeBSD.
> > +
> > + ``Multilib variants to match the BSP -``
> > + RTEMS configures GCC to create separate runtime libraries for each
> > + supported instruction set, floating point unit, vector unit, word
> size
> > + (e.g. 32-bit and 64-bit), endianness, ABI, processor errata
> workarounds,
> > + and so on in the architecture. These libraries are termed multilib
> variants
> > + (
> https://docs.rtems.org/branches/master/user/hardware/architectures.html?highlight=multilib
> ).
>
> Please do not add external links to internal parts of the same document.
> Please use :ref: to do this. A link like this breaks on branches and PDFs.
>
> Would it be ok to just add reference to the architecture section of the
doc?

> Chris
>
> > + Multilibs variants to match the BSP are set by selecting a
> specific set of
> > + machine options using the RTEMS cross-compiler.
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] Chapter-on-need-for-RTEMS-specific-cross-compiler

2020-04-02 Thread Chris Johns


On 2020-03-28 00:13, utkarsh.ra...@gmail.com wrote:

---
  user/start/tools.rst | 34 ++
  1 file changed, 34 insertions(+)

diff --git a/user/start/tools.rst b/user/start/tools.rst
index c3f039b..8ea1f64 100644
--- a/user/start/tools.rst
+++ b/user/start/tools.rst
@@ -3,6 +3,7 @@
  .. Copyright (C) 2019 embedded brains GmbH
  .. Copyright (C) 2019 Sebastian Huber
  .. Copyright (C) 2020 Chris Johns
+.. Copyright (C) 2020 Utkarsh Rai
  
  .. _QuickStartTools:
  
@@ -76,3 +77,36 @@ source code used.
  
  
  Add ``--verbose`` to the GCC command for the the verbose version details.

+
+
+Need for RTEMS-Specific Cross-Compiler
+


Length of ---'s does not match the heading.


+
+New users are often confused as to why they cannot use their distribution's
+cross-compiler for their target on rtems, e.g., the riscv64-linux-gnu or the
+arm-none-eabi-gcc on RTEMS. Below mentioned are some of the reasons for using
+the RTEMS cross-compiler.
+
+ ``Correct configuration of Newlib -``
+ Newlib is a C standard library implementation intended for use on embedded
+ systems. Most of the POSIX and libc support for RTEMS is derived from
+ Newlib. The RTEMS cross-compiler configures Newlib correctly for RTEMS.
+
+ ``Threading in GCC support libraries -``
+ Several threading packages in GCC such as Go threads (libgo), OpenMP
+ (libgomp), and OpenACC need to be customized according to RTEMS. This is
+ done by the RTEMS specific cross-compiler.
+
+ ``Provide preprocessor define __rtems__ -``
+ The  ``__rtems__``  preprocessor define is used to provide conditional 
code
+ compilation in source files that are shared with other projects e.g. in
+ Newlib or imported code from FreeBSD.
+
+ ``Multilib variants to match the BSP -``
+ RTEMS configures GCC to create separate runtime libraries for each
+ supported instruction set, floating point unit, vector unit, word size
+ (e.g. 32-bit and 64-bit), endianness, ABI, processor errata workarounds,
+ and so on in the architecture. These libraries are termed multilib 
variants
+ 
(https://docs.rtems.org/branches/master/user/hardware/architectures.html?highlight=multilib).


Please do not add external links to internal parts of the same document. 
Please use :ref: to do this. A link like this breaks on branches and PDFs.


Chris


+ Multilibs variants to match the BSP are set by selecting a specific set of
+ machine options using the RTEMS cross-compiler.


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

Re: sqlite build failure on BSP bsets

2020-04-02 Thread Joel Sherrill

Thank you so much Jonathon!  I have pushed this.

We are really trying to close all issues and get things ready for a
release. All help and user testing is appreciated.

--joel

On Thu, Apr 2, 2020 at 5:47 PM Jonathan Brandmeyer 
wrote:

> Try this.
>
> I changed the logic which avoids building the sqlite3 shell.  Something
> about the way it uses libtool made the old `touch`-based method fail.
> There's also a bunch of configuration notes that really ought to be more
> visible.
>
> On Thu, Apr 2, 2020 at 2:26 PM Joel Sherrill  wrote:
>
>>
>>
>> On Thu, Apr 2, 2020 at 3:00 PM Gedare Bloom  wrote:
>>
>>> On Thu, Apr 2, 2020 at 1:57 PM Jonathan Brandmeyer
>>>  wrote:
>>> >
>>> >
>>> > On Thu, Apr 2, 2020 at 1:43 PM Joel Sherrill  wrote:
>>> >>
>>> >> Thank you for the detailed feedback.
>>> >>
>>> >> I am torn between:
>>> >>
>>> >> + deleting sqlite from the BSP bset's
>>> >> + requiring tclsh to be installed
>>> >> + updating the RSB recipe for sqlite.
>>> >>
>>> >> Given the desire to get a release out the door. I am prone to the
>>> first
>>> >> option with a ticket for 5.2 to update sqlite and re-add it to the BSP
>>> >> bsets.
>>> >
>>> >
>>> > I can see where you're coming from.  That said, even having an
>>> obsolete bset in the RSB served as a helpful hint that it worked for
>>> someone once upon a time.
>>> >
>>> >>
>>> >>
>>> >> Since you obviously use sqlite, if you could tackle updating the RSB
>>> >> recipe, that would be great and avoid having to do something expedient
>>> >> to get the release out the door.
>>> >
>>> >
>>> >  I can make a pass at it.  What's the quickest way to iterate on a
>>> BSET's rules?  I'd rather not have to wait on GCC and crew to rebuild when
>>> I get it wrong the first time.
>>> >
>>> Use --dry-run option
>>>
>>
>> This is good to watch the commands quickly.  But you can just explicitly
>> build the one package.
>>
>> $ cd rtems
>> $ ../source-builder/sb-set-builder \
>>  --log=l-sqlite.txt \
>>  --prefix= \
>>   databases/sqlite
>>
>> Should be very close to working. I hacked my command for dtc so there may
>> be a typo.
>>
>> This should take seconds.
>>
>> It is interesting that you didn't know you can build a single package
>> or --dry-run. No foul to you. Just points out that we aren't letting the
>> community know the cool things the RSB can do.
>>
>> I use the source download only option to get people to download things
>> for the tools before they come to the Kick Start class. If they have
>> network
>> issues, can't fetch git, no admin, etc. then they can deal with those with
>> their IT. I can't help with someone's draconian policies. :)
>>
>>
>>>
>>> >>
>>> >> Chris will eventually wake up in Sydney and chime in. :)
>>> >>
>>> >
>>> >
>>> > --
>>> > Jonathan Brandmeyer
>>> > ___
>>> > devel mailing list
>>> > devel@rtems.org
>>> > http://lists.rtems.org/mailman/listinfo/devel
>>>
>>
>
> --
> Jonathan Brandmeyer
> Vice President of Software Engineering
> PlanetiQ
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] Chapter-on-need-for-RTEMS-specific-cross-compiler

2020-04-02 Thread Utkarsh Rai

This patch seems to have gone unnoticed, can somemone please review it?

On Fri, Mar 27, 2020 at 6:48 PM utkarsh.ra...@gmail.com <
utkarsh.ra...@gmail.com> wrote:

> ---
>  user/start/tools.rst | 34 ++
>  1 file changed, 34 insertions(+)
>
> diff --git a/user/start/tools.rst b/user/start/tools.rst
> index c3f039b..8ea1f64 100644
> --- a/user/start/tools.rst
> +++ b/user/start/tools.rst
> @@ -3,6 +3,7 @@
>  .. Copyright (C) 2019 embedded brains GmbH
>  .. Copyright (C) 2019 Sebastian Huber
>  .. Copyright (C) 2020 Chris Johns
> +.. Copyright (C) 2020 Utkarsh Rai
>
>  .. _QuickStartTools:
>
> @@ -76,3 +77,36 @@ source code used.
>
>
>  Add ``--verbose`` to the GCC command for the the verbose version details.
> +
> +
> +Need for RTEMS-Specific Cross-Compiler
> +
> +
> +New users are often confused as to why they cannot use their
> distribution's
> +cross-compiler for their target on rtems, e.g., the riscv64-linux-gnu or
> the
> +arm-none-eabi-gcc on RTEMS. Below mentioned are some of the reasons for
> using
> +the RTEMS cross-compiler.
> +
> + ``Correct configuration of Newlib -``
> + Newlib is a C standard library implementation intended for use on
> embedded
> + systems. Most of the POSIX and libc support for RTEMS is derived from
> + Newlib. The RTEMS cross-compiler configures Newlib correctly for
> RTEMS.
> +
> + ``Threading in GCC support libraries -``
> + Several threading packages in GCC such as Go threads (libgo), OpenMP
> + (libgomp), and OpenACC need to be customized according to RTEMS.
> This is
> + done by the RTEMS specific cross-compiler.
> +
> + ``Provide preprocessor define __rtems__ -``
> + The  ``__rtems__``  preprocessor define is used to provide
> conditional code
> + compilation in source files that are shared with other projects e.g.
> in
> + Newlib or imported code from FreeBSD.
> +
> + ``Multilib variants to match the BSP -``
> + RTEMS configures GCC to create separate runtime libraries for each
> + supported instruction set, floating point unit, vector unit, word
> size
> + (e.g. 32-bit and 64-bit), endianness, ABI, processor errata
> workarounds,
> + and so on in the architecture. These libraries are termed multilib
> variants
> + (
> https://docs.rtems.org/branches/master/user/hardware/architectures.html?highlight=multilib
> ).
> + Multilibs variants to match the BSP are set by selecting a specific
> set of
> + machine options using the RTEMS cross-compiler.
> --
> 2.17.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: sqlite build failure on BSP bsets

2020-04-02 Thread Jonathan Brandmeyer

Try this.

I changed the logic which avoids building the sqlite3 shell.  Something
about the way it uses libtool made the old `touch`-based method fail.
There's also a bunch of configuration notes that really ought to be more
visible.

On Thu, Apr 2, 2020 at 2:26 PM Joel Sherrill  wrote:

>
>
> On Thu, Apr 2, 2020 at 3:00 PM Gedare Bloom  wrote:
>
>> On Thu, Apr 2, 2020 at 1:57 PM Jonathan Brandmeyer
>>  wrote:
>> >
>> >
>> > On Thu, Apr 2, 2020 at 1:43 PM Joel Sherrill  wrote:
>> >>
>> >> Thank you for the detailed feedback.
>> >>
>> >> I am torn between:
>> >>
>> >> + deleting sqlite from the BSP bset's
>> >> + requiring tclsh to be installed
>> >> + updating the RSB recipe for sqlite.
>> >>
>> >> Given the desire to get a release out the door. I am prone to the first
>> >> option with a ticket for 5.2 to update sqlite and re-add it to the BSP
>> >> bsets.
>> >
>> >
>> > I can see where you're coming from.  That said, even having an obsolete
>> bset in the RSB served as a helpful hint that it worked for someone once
>> upon a time.
>> >
>> >>
>> >>
>> >> Since you obviously use sqlite, if you could tackle updating the RSB
>> >> recipe, that would be great and avoid having to do something expedient
>> >> to get the release out the door.
>> >
>> >
>> >  I can make a pass at it.  What's the quickest way to iterate on a
>> BSET's rules?  I'd rather not have to wait on GCC and crew to rebuild when
>> I get it wrong the first time.
>> >
>> Use --dry-run option
>>
>
> This is good to watch the commands quickly.  But you can just explicitly
> build the one package.
>
> $ cd rtems
> $ ../source-builder/sb-set-builder \
>  --log=l-sqlite.txt \
>  --prefix= \
>   databases/sqlite
>
> Should be very close to working. I hacked my command for dtc so there may
> be a typo.
>
> This should take seconds.
>
> It is interesting that you didn't know you can build a single package
> or --dry-run. No foul to you. Just points out that we aren't letting the
> community know the cool things the RSB can do.
>
> I use the source download only option to get people to download things
> for the tools before they come to the Kick Start class. If they have
> network
> issues, can't fetch git, no admin, etc. then they can deal with those with
> their IT. I can't help with someone's draconian policies. :)
>
>
>>
>> >>
>> >> Chris will eventually wake up in Sydney and chime in. :)
>> >>
>> >
>> >
>> > --
>> > Jonathan Brandmeyer
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>>
>

-- 
Jonathan Brandmeyer
Vice President of Software Engineering
PlanetiQ
From 45c727a780a3f52815ba3fc2c7d82fdf0eed273c Mon Sep 17 00:00:00 2001
From: Jonathan Brandmeyer 
Date: Thu, 2 Apr 2020 16:35:15 -0600
Subject: [PATCH] databases/sqlite: Update to 3.31.1

---
 rtems/config/databases/sqlite-3.31.1-1.cfg  | 23 +++
 rtems/config/databases/sqlite-3.8.8.1-1.cfg | 27 -
 rtems/config/databases/sqlite.bset  |  2 +-
 source-builder/config/sqlite-3-1.cfg| 44 -
 4 files changed, 49 insertions(+), 47 deletions(-)
 create mode 100644 rtems/config/databases/sqlite-3.31.1-1.cfg
 delete mode 100644 rtems/config/databases/sqlite-3.8.8.1-1.cfg

diff --git a/rtems/config/databases/sqlite-3.31.1-1.cfg b/rtems/config/databases/sqlite-3.31.1-1.cfg
new file mode 100644
index 000..cd2b5ef
--- /dev/null
+++ b/rtems/config/databases/sqlite-3.31.1-1.cfg
@@ -0,0 +1,23 @@
+#
+# Sqlite 3.31.1
+#
+
+%if %{release} == %{nil}
+ %define release 1
+%endif
+
+%include %{_configdir}/rtems-bsp.cfg
+
+#
+# Sqlite Version.
+#
+%define sqlite_version 3.31.1
+%define sqlite_src_version 3310100
+%define sqlite_src_year2020
+
+%hash sha512 sqlite-autoconf-%{sqlite_src_version}.tar.gz d85250ba5f78f0c918880f663741709aba662192f04888b2324a0df17affdf5b8540e8428c6c7315119806e7adad758ea281c9b403c0ad94ac6a9bd1b93fd617
+
+#
+# Sqlite configuration
+#
+%include %{_configdir}/sqlite-3-1.cfg
diff --git a/rtems/config/databases/sqlite-3.8.8.1-1.cfg b/rtems/config/databases/sqlite-3.8.8.1-1.cfg
deleted file mode 100644
index aac06be..000
--- a/rtems/config/databases/sqlite-3.8.8.1-1.cfg
+++ /dev/null
@@ -1,27 +0,0 @@
-#
-# Sqlite 3.8.8.1
-#
-
-%if %{release} == %{nil}
- %define release 1
-%endif
-
-%include %{_configdir}/rtems-bsp.cfg
-
-#
-# Sqlite Version.
-#
-# Sqlite uses a different version number label in source to the
-# actual version number. I suppose this is related to Windows.
-#
-#
-%define sqlite_version 3.8.8.1
-%define sqlite_src_version 3080801
-%define sqlite_src_year2015
-
-%hash sha512 sqlite-src-%{sqlite_src_version}.zip 4f09228cb0c9c608e492da6e480afe3d27a63e27ccdcf33a88d5e56427f0846efab8930c81026b8e608f1bbb8d63e8d937dd26571deb828617f7efa27a765950
-
-#
-# Sqlite configuration
-#
-%include %{_configdir}/sqlite-3-1.cfg
diff --git a/rtems/config/databases/sqlite.bset b/rtems/config/databases/sqlite.bset

Re: [PATCH v2] Tests for inttype.h methods

2020-04-02 Thread Joel Sherrill

You added a few test cases so they need to be added to the .doc file in the
same directory.

I don't think you changed the test output so the .scn (screen) file should
be OK.

--joel

On Thu, Apr 2, 2020 at 5:30 AM Eshan dhawan  wrote:

> ---
>  testsuites/psxtests/psxinttypes01/init.c | 25 +---
>  1 file changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/testsuites/psxtests/psxinttypes01/init.c
> b/testsuites/psxtests/psxinttypes01/init.c
> index 030aa2aa57..d86313b251 100644
> --- a/testsuites/psxtests/psxinttypes01/init.c
> +++ b/testsuites/psxtests/psxinttypes01/init.c
> @@ -6,6 +6,7 @@
>  /*
>   * SPDX-License-Identifier: BSD-2-Clause
>   *
> + * Copyright (C) 2020, Eshan Dhawan
>   * Copyright (C) 2019, Aditya Upadhyay and Vaibhav Gupta
>   *
>   * Redistribution and use in source and binary forms, with or without
> @@ -64,11 +65,29 @@ rtems_task Init(rtems_task_argument ignored)
>wchar_t  *nptr2_n_errange = L"-99";
>wchar_t  *endptr2 = NULL;
>
> -  intmax_t  result_strtoimax;
> +  intmax_t  result_strtoimax, result_imaxabs, input_1, input_2 ;
> +  imaxdiv_t result_exp, result_imaxdiv ;
>uintmax_t result_strtoumax;
>
>TEST_BEGIN();
> -
> +  /* Test for imaxabs */
> +  input_1 = -10 ;
> +  result_imaxabs = 10 ;
> +  rtems_test_assert( imaxabs(input_1) == result_imaxabs );
> +
> +  input_1 = 10 ;
> +  result_imaxabs = 10 ;
> +  rtems_test_assert( imaxabs(input_1) == result_imaxabs );
> +
> +  /* Test for imaxdiv */
> +  input_1 = 10 ;
> +  input_2 = 3 ;
> +  result_exp.quot = input_1 / input_2 ;
> +  result_exp.rem =  input_1 % input_2 ;
> +  result_imaxdiv = imaxdiv(input_1, input_2) ;
> +  rtems_test_assert( result_imaxdiv.quot == result_exp.quot &&
> +  result_imaxdiv.rem == result_exp.rem );
> +
>/* Test for strtoimax  */
>puts( "\nstrtoimax Testcases" );
>puts( "Valid Inputs - Positive Number" );
> @@ -83,7 +102,7 @@ rtems_task Init(rtems_task_argument ignored)
>rtems_test_assert( result_strtoimax == -123 );
>
>puts( "Final string pointed by endptr" );
> -  rtems_test_assert( endptr1 == ( nptr1_n + 4 ) );
> +  rtems_test_assert( endptr1 == ( nptr1_n + 4 ) );
>
>puts( "Valid Input - Positive Number - Number out of Range" );
>result_strtoimax = strtoimax( nptr1_p_errange, , base );
> --
> 2.17.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v5] doc: Moving M68K BSP Content to User Manual (#3905)

2020-04-02 Thread Joel Sherrill

Is there now a list of wiki pages that need to be deleted?

Thank you and I'm glad to see this patch. :)

--joel


On Thu, Apr 2, 2020 at 4:54 PM Chris Johns  wrote:

> Pushed and again thank you for doing this.
>
> Chris
>
> On 2020-04-02 19:49, Mritunjay wrote:
> > Fixed trailing spaces.
> > ---
> >   user/bsps/bsps-m68k.rst | 190 +++-
> >   1 file changed, 188 insertions(+), 2 deletions(-)
> >
> > diff --git a/user/bsps/bsps-m68k.rst b/user/bsps/bsps-m68k.rst
> > index 60882fb..bdb516b 100644
> > --- a/user/bsps/bsps-m68k.rst
> > +++ b/user/bsps/bsps-m68k.rst
> > @@ -53,7 +53,19 @@ TODO.
> >   mcf5329
> >   ===
> >
> > -TODO.
> > +Overview
> > +
> > +
> > +This BSP is heavily based on the MCF5235 BSP. The MCF5329EVB is a
> Motorola
> > +evaluation board (Zoom) with a LogicPD MCF5329-10 SODIMM-144 card. The
> > +development kit features the MCF5329 based Fire Engine, as well as a
> plug-in
> > +system-on-module containing 32 MB of DDR-SDRAM. The board also includes
> 2 MB of
> > +boot flash, 16 MB of NAND flash, a core frequency of 240MHz, an onboard
> 800x600
> > +LCD controller, FEC, USB, uarts, CAN bus, QSPI, I2C, and 10/100
> Ethernet.
> > +
> > +You can find the link to MCF5329 Reference Manual below:
> > +
> > +* `MCF5329 Reference Manual <
> https://www.nxp.com/docs/en/reference-manual/MCF5329RM.pdf>`_
> >
> >   mrm332
> >   ==
> > @@ -73,7 +85,181 @@ TODO.
> >   mvme162
> >   ===
> >
> > -TODO.
> > +Overview
> > +
> > +
> > +The MVME162 family provides OEMs and solution developers an ideal
> platform for
> > +embedded monitoring and control apllications it allows an OEM to
> minimize
> > +engineering expenses while integrating value-added hardware and software
> > +applications onto an off-the-shelf product. In order to provide the
> wide range
> > +of solutions, the MVME162 allows a variety of MPU, memory, and interface
> > +options such as floating-point, Ethernet, SCSI, and VME. The result is a
> > +variation of the MVME162 which most closely fits the application
> requirement.
> > +
> > +There are a large number of model variations on this board. This was
> the first
> > +user submitted BSP and continues to be a fairly popular simply because
> at one
> > +point it was the highest selling VMEBus board of all time.
> > +
> > +Board Setup
> > +---
> > +
> > +We will setup the RTEMS Lab Board initally to proceed further for the
> setup
> > +of TFTP transfer.
> > +
> > +The env settings are:
> > +
> > +.. code-block:: none
> > +
> > +MPU Clock Speed =25Mhz
> > +162-Bug>env
> > +Bug or System environment [B/S] = B?
> > +Field Service Menu Enable [Y/N] = N?
> > + Remote Start Method Switch [G/M/B/N] = B?
> > + Probe System for Supported I/O Controllers [Y/N] = Y?
> > + Negate VMEbus SYSFAIL* Always [Y/N] = N?
> > + Local SCSI Bus Reset on Debugger Startup [Y/N] = N?
> > + Local SCSI Bus Negotiations Type [A/S/N]   = A?
> > + Industry Pack Reset on Debugger Startup [Y/N]  = Y?
> > + Ignore CFGA Block on a Hard Disk Boot [Y/N]= Y?
> > + Auto Boot Enable [Y/N]   = N?
> > + Auto Boot at power-up only [Y/N] = Y?
> > + Auto Boot Controller LUN = 00?
> > + Auto Boot Device LUN = 00?
> > + Auto Boot Abort Delay= 15?
> > + Auto Boot Default String [NULL for a empty string] = ?
> > + ROM Boot Enable [Y/N]= N?
> > + ROM Boot at power-up only [Y/N]  = Y?
> > + ROM Boot Enable search of VMEbus [Y/N] = N?
> > + ROM Boot Abort Delay = 0?
> > + ROM Boot Direct Starting Address = FF80?
> > + ROM Boot Direct Ending Address   = FFDC?
> > + Network Auto Boot Enable [Y/N]   = N?
> > + Network Auto Boot at power-up only [Y/N] = Y?
> > + Network Auto Boot Controller LUN = 00?
> > + Network Auto Boot Device LUN = 00?
> > + Network Auto Boot Abort Delay= 5?
> > + Network Auto Boot Configuration Parameters Pointer (NVRAM) =
> FFE0FF00?
> > + Memory Search Starting Address   = ?
> > + Memory Search Ending Address = 0100?
> > + Memory Search Increment Size = 0001?
> > + Memory Search Delay Enable [Y/N] = N?
> > + Memory Search Delay Address  = D20F?
> > + Memory Size Enable [Y/N] = Y?
> > + Memory Size Starting Address = ?
> > + Memory Size Ending Address   = 0100?
> > + Base Address of Dynamic Memory   = ?
> > + Size of Parity Memory= ?
> > + Size of ECC Memory Board #0  = 0100?
> > + Size of ECC Memory Board #1  = ?
> > + Base Address of Static Memory= FFE0?
> > + Size of Static Memory= 0002?
> > + Slave Enable #1 [Y/N] = Y?
> > + Slave Starting Address #1 = ?
> > + Slave Ending Address #1   = 00FF?
> > + Slave Address Translation Address #1 = ?
> > + Slave

Re: [PATCH v5] doc: Moving M68K BSP Content to User Manual (#3905)

2020-04-02 Thread Chris Johns


Pushed and again thank you for doing this.

Chris

On 2020-04-02 19:49, Mritunjay wrote:

Fixed trailing spaces.
---
  user/bsps/bsps-m68k.rst | 190 +++-
  1 file changed, 188 insertions(+), 2 deletions(-)

diff --git a/user/bsps/bsps-m68k.rst b/user/bsps/bsps-m68k.rst
index 60882fb..bdb516b 100644
--- a/user/bsps/bsps-m68k.rst
+++ b/user/bsps/bsps-m68k.rst
@@ -53,7 +53,19 @@ TODO.
  mcf5329
  ===
  
-TODO.

+Overview
+
+
+This BSP is heavily based on the MCF5235 BSP. The MCF5329EVB is a Motorola
+evaluation board (Zoom) with a LogicPD MCF5329-10 SODIMM-144 card. The
+development kit features the MCF5329 based Fire Engine, as well as a plug-in
+system-on-module containing 32 MB of DDR-SDRAM. The board also includes 2 MB of
+boot flash, 16 MB of NAND flash, a core frequency of 240MHz, an onboard 800x600
+LCD controller, FEC, USB, uarts, CAN bus, QSPI, I2C, and 10/100 Ethernet.
+
+You can find the link to MCF5329 Reference Manual below:
+
+* `MCF5329 Reference Manual 
`_
  
  mrm332

  ==
@@ -73,7 +85,181 @@ TODO.
  mvme162
  ===
  
-TODO.

+Overview
+
+
+The MVME162 family provides OEMs and solution developers an ideal platform for
+embedded monitoring and control apllications it allows an OEM to minimize
+engineering expenses while integrating value-added hardware and software
+applications onto an off-the-shelf product. In order to provide the wide range
+of solutions, the MVME162 allows a variety of MPU, memory, and interface
+options such as floating-point, Ethernet, SCSI, and VME. The result is a
+variation of the MVME162 which most closely fits the application requirement.
+
+There are a large number of model variations on this board. This was the first
+user submitted BSP and continues to be a fairly popular simply because at one
+point it was the highest selling VMEBus board of all time.
+
+Board Setup
+---
+
+We will setup the RTEMS Lab Board initally to proceed further for the setup
+of TFTP transfer.
+
+The env settings are:
+
+.. code-block:: none
+
+MPU Clock Speed =25Mhz
+162-Bug>env
+Bug or System environment [B/S] = B?
+Field Service Menu Enable [Y/N] = N?
+   Remote Start Method Switch [G/M/B/N] = B?
+   Probe System for Supported I/O Controllers [Y/N] = Y?
+   Negate VMEbus SYSFAIL* Always [Y/N] = N?
+   Local SCSI Bus Reset on Debugger Startup [Y/N] = N?
+   Local SCSI Bus Negotiations Type [A/S/N]   = A?
+   Industry Pack Reset on Debugger Startup [Y/N]  = Y?
+   Ignore CFGA Block on a Hard Disk Boot [Y/N]= Y?
+   Auto Boot Enable [Y/N]   = N?
+   Auto Boot at power-up only [Y/N] = Y?
+   Auto Boot Controller LUN = 00?
+   Auto Boot Device LUN = 00?
+   Auto Boot Abort Delay= 15?
+   Auto Boot Default String [NULL for a empty string] = ?
+   ROM Boot Enable [Y/N]= N?
+   ROM Boot at power-up only [Y/N]  = Y?
+   ROM Boot Enable search of VMEbus [Y/N] = N?
+   ROM Boot Abort Delay = 0?
+   ROM Boot Direct Starting Address = FF80?
+   ROM Boot Direct Ending Address   = FFDC?
+   Network Auto Boot Enable [Y/N]   = N?
+   Network Auto Boot at power-up only [Y/N] = Y?
+   Network Auto Boot Controller LUN = 00?
+   Network Auto Boot Device LUN = 00?
+   Network Auto Boot Abort Delay= 5?
+   Network Auto Boot Configuration Parameters Pointer (NVRAM) = FFE0FF00?
+   Memory Search Starting Address   = ?
+   Memory Search Ending Address = 0100?
+   Memory Search Increment Size = 0001?
+   Memory Search Delay Enable [Y/N] = N?
+   Memory Search Delay Address  = D20F?
+   Memory Size Enable [Y/N] = Y?
+   Memory Size Starting Address = ?
+   Memory Size Ending Address   = 0100?
+   Base Address of Dynamic Memory   = ?
+   Size of Parity Memory= ?
+   Size of ECC Memory Board #0  = 0100?
+   Size of ECC Memory Board #1  = ?
+   Base Address of Static Memory= FFE0?
+   Size of Static Memory= 0002?
+   Slave Enable #1 [Y/N] = Y?
+   Slave Starting Address #1 = ?
+   Slave Ending Address #1   = 00FF?
+   Slave Address Translation Address #1 = ?
+   Slave Address Translation Select #1  = ?
+   Slave Control #1 = 03FF?
+   Slave Enable #2 [Y/N] = N?
+   Slave Starting Address #2 = ?
+   Slave Ending Address #2   = ?
+   Slave Address Translation Address #2 = ?
+   Slave Address Translation Select #2  = ?
+   Slave Control #2 = ?
+   Master Enable #1 [Y/N] = Y?
+   Master Starting Address #1 = 0100?
+   Master Ending Address #1   = EFFF?
+   Master Control #1 = 0D?
+   Master Enable

Re: applying a patch

2020-04-02 Thread Eshan Dhawan

Thanks 

-Eshan 
> On 03-Apr-2020, at 2:55 AM, Vaibhav Gupta  wrote:
> 
> 
>> 
>> At #2 I also have the option to download a file. Then you can skip to
>> 4 and provide the filename on the git-am command line and be done.
> 
> Yeah! Its just that I got used to copying to clipboard
> and providing it to git-am via stdin. We can of course
> do it both the ways.
> 
> -- Vaibhav Gupta
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v3] sb/setbuilder: do not include remotes in mailed reports

2020-04-02 Thread Gedare Bloom

Closes #3887.
---
 source-builder/sb/reports.py| 47 -
 source-builder/sb/setbuilder.py |  2 +-
 2 files changed, 29 insertions(+), 20 deletions(-)

diff --git a/source-builder/sb/reports.py b/source-builder/sb/reports.py
index ab20671..fe6c093 100644
--- a/source-builder/sb/reports.py
+++ b/source-builder/sb/reports.py
@@ -241,13 +241,16 @@ class markdown_formatter(formatter):
 self.line(self._strong('Remotes:'))
 self.line('')
 rc = 1
-for r in remotes:
-if 'url' in remotes[r]:
-text = remotes[r]['url']
-else:
-text = 'no URL found'
-self.line('%d. %s: %s' % (rc, r, text))
-rc += 1
+if not remotes:
+self.line('[ remotes removed, contact sender for details ]')
+else:
+for r in remotes:
+if 'url' in remotes[r]:
+text = remotes[r]['url']
+else:
+text = 'no URL found'
+self.line('%d. %s: %s' % (rc, r, text))
+rc += 1
 self.line('')
 self.line(self._strong('Status:'))
 self.line('')
@@ -427,14 +430,17 @@ class text_formatter(formatter):
 if valid:
 self.line('%s Remotes:' % (self.cini))
 rc = 0
-for r in remotes:
-rc += 1
-if 'url' in remotes[r]:
-text = remotes[r]['url']
-else:
-text = 'no URL found'
-text = '%s: %s' % (r, text)
-self.line('%s  %2d: %s' % (self.cini, rc, text))
+if not remotes:
+self.line('[ remotes removed, contact sender for details ]')
+else:
+for r in remotes:
+rc += 1
+if 'url' in remotes[r]:
+text = remotes[r]['url']
+else:
+text = 'no URL found'
+text = '%s: %s' % (r, text)
+self.line('%s  %2d: %s' % (self.cini, rc, text))
 self.line('%s Status:' % (self.cini))
 if dirty:
 self.line('%s  Repository is dirty' % (self.cini))
@@ -647,17 +653,20 @@ class report:
 def release_status(self):
 self.formatter.release_status(version.string())
 
-def git_status(self):
+def git_status(self, sanitize = False):
 r = git.repo('.', self.opts, self.macros)
-self.formatter.git_status(r.valid(), r.dirty(), r.head(), r.remotes())
+if sanitize:
+self.formatter.git_status(r.valid(), r.dirty(), r.head(), None)
+else:
+self.formatter.git_status(r.valid(), r.dirty(), r.head(), 
r.remotes())
 
-def introduction(self, name, intro_text = None):
+def introduction(self, name, intro_text = None, sanitize = False):
 now = datetime.datetime.now().ctime()
 self.formatter.introduction(name, now, intro_text)
 if version.released():
 self.release_status()
 else:
-self.git_status()
+self.git_status(sanitize)
 
 def epilogue(self, name):
 self.formatter.epilogue(name)
diff --git a/source-builder/sb/setbuilder.py b/source-builder/sb/setbuilder.py
index 7b80817..9367d55 100644
--- a/source-builder/sb/setbuilder.py
+++ b/source-builder/sb/setbuilder.py
@@ -201,7 +201,7 @@ class buildset:
 if mail:
 r = reports.report('text', self.configs,
copy.copy(opts), copy.copy(macros))
-r.introduction(_build.config.file_name())
+r.introduction(_build.config.file_name(), sanitize = True)
 r.generate(_build.config.file_name())
 r.epilogue(_build.config.file_name())
 self.write_mail_report(r.get_output())
-- 
2.17.1

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

Re: RTEMS Release Snapshot: 5.0.0-m2004 (02 Apr 2020)

2020-04-02 Thread Chris Johns


On 2020-04-03 01:19, Gedare Bloom wrote:

On Thu, Apr 2, 2020 at 4:17 AM Sebastian Huber
 wrote:


Hello,

in the readme file:

   cd
   mkdir -p development/rtems
   wget 
https://ftp.rtems.org/pub/rtems/releases/sources/rtems-source-builder-5.0.0-m2004.tar.xz
   tar jxf rtems-source-builder-5.0.0-m2004.tar.xz

And this j should be capital J?


It has been OK on FreeBSD (I think) but using J should not hurt.


   cd rtems-source-builder-5.0.0-m2004/rtems

there is probably a

   cd development/rtems

missing after the mkdir.


Pushed both changes. Thank you for the review and feedback.

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

[PATCH v2] sb/setbuilder: do not include remotes in mailed reports

2020-04-02 Thread Gedare Bloom

Closes #3887.
---
 source-builder/sb/reports.py| 47 -
 source-builder/sb/setbuilder.py |  2 +-
 2 files changed, 29 insertions(+), 20 deletions(-)

diff --git a/source-builder/sb/reports.py b/source-builder/sb/reports.py
index ab20671..aa01b61 100644
--- a/source-builder/sb/reports.py
+++ b/source-builder/sb/reports.py
@@ -241,13 +241,16 @@ class markdown_formatter(formatter):
 self.line(self._strong('Remotes:'))
 self.line('')
 rc = 1
-for r in remotes:
-if 'url' in remotes[r]:
-text = remotes[r]['url']
-else:
-text = 'no URL found'
-self.line('%d. %s: %s' % (rc, r, text))
-rc += 1
+if not remotes:
+self.line('[ remotes removed, contact sender for details ]')
+else:
+for r in remotes:
+if 'url' in remotes[r]:
+text = remotes[r]['url']
+else:
+text = 'no URL found'
+self.line('%d. %s: %s' % (rc, r, text))
+rc += 1
 self.line('')
 self.line(self._strong('Status:'))
 self.line('')
@@ -427,14 +430,17 @@ class text_formatter(formatter):
 if valid:
 self.line('%s Remotes:' % (self.cini))
 rc = 0
-for r in remotes:
-rc += 1
-if 'url' in remotes[r]:
-text = remotes[r]['url']
-else:
-text = 'no URL found'
-text = '%s: %s' % (r, text)
-self.line('%s  %2d: %s' % (self.cini, rc, text))
+if not remotes:
+self.line('[ removed for email, reply to sender for details ]')
+else:
+for r in remotes:
+rc += 1
+if 'url' in remotes[r]:
+text = remotes[r]['url']
+else:
+text = 'no URL found'
+text = '%s: %s' % (r, text)
+self.line('%s  %2d: %s' % (self.cini, rc, text))
 self.line('%s Status:' % (self.cini))
 if dirty:
 self.line('%s  Repository is dirty' % (self.cini))
@@ -647,17 +653,20 @@ class report:
 def release_status(self):
 self.formatter.release_status(version.string())
 
-def git_status(self):
+def git_status(self, sanitize = False):
 r = git.repo('.', self.opts, self.macros)
-self.formatter.git_status(r.valid(), r.dirty(), r.head(), r.remotes())
+if sanitize:
+self.formatter.git_status(r.valid(), r.dirty(), r.head(), None)
+else:
+self.formatter.git_status(r.valid(), r.dirty(), r.head(), 
r.remotes())
 
-def introduction(self, name, intro_text = None):
+def introduction(self, name, intro_text = None, sanitize = False):
 now = datetime.datetime.now().ctime()
 self.formatter.introduction(name, now, intro_text)
 if version.released():
 self.release_status()
 else:
-self.git_status()
+self.git_status(sanitize)
 
 def epilogue(self, name):
 self.formatter.epilogue(name)
diff --git a/source-builder/sb/setbuilder.py b/source-builder/sb/setbuilder.py
index 7b80817..9367d55 100644
--- a/source-builder/sb/setbuilder.py
+++ b/source-builder/sb/setbuilder.py
@@ -201,7 +201,7 @@ class buildset:
 if mail:
 r = reports.report('text', self.configs,
copy.copy(opts), copy.copy(macros))
-r.introduction(_build.config.file_name())
+r.introduction(_build.config.file_name(), sanitize = True)
 r.generate(_build.config.file_name())
 r.epilogue(_build.config.file_name())
 self.write_mail_report(r.get_output())
-- 
2.17.1

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

Re: applying a patch

2020-04-02 Thread Vaibhav Gupta

> At #2 I also have the option to download a file. Then you can skip to
> 4 and provide the filename on the git-am command line and be done.

Yeah! Its just that I got used to copying to clipboard
and providing it to git-am via stdin. We can of course
do it both the ways.

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

Re: applying a patch

2020-04-02 Thread Gedare Bloom

On Thu, Apr 2, 2020 at 3:08 PM Vaibhav Gupta  wrote:
>
> On Sun, 22 Mar 2020 at 01:23, Eshan Dhawan  wrote:
> >
> > Hello everyone
> > I tried to apply this patch but it fails.
> > Since I have done this before so I might be doing something wrong.
> > if you all could guide me
> >
> > patch : https://lists.rtems.org/pipermail/devel/2020-March/058516.html
> >
> Its just few simple steps:
>
> 1- As you use gmail, just open the patch-mail. Click option
> and select 'Show Original'.
> 2- Copy the content written in monospace/raw-format.
>  There is also a button 'Copy to Clipboard'.
> 3- Get to your terminal, switch to master branch.
> You might wanna 'git pull' to load recent
> changes (if any).
> 4- type 'git am' and hit enter key.
> 5- Since no mailbox given, it will read from stdin, hence
>  wait for your input.
> 6- Paste the content (ctrl+shift+v).
> 7- Press (ctrl+D)
>
> Patch will be applied
>
At #2 I also have the option to download a file. Then you can skip to
4 and provide the filename on the git-am command line and be done.

> -- Vaibhav Gupta
> ___
> 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: applying a patch

2020-04-02 Thread Vaibhav Gupta

On Sun, 22 Mar 2020 at 01:23, Eshan Dhawan  wrote:
>
> Hello everyone
> I tried to apply this patch but it fails.
> Since I have done this before so I might be doing something wrong.
> if you all could guide me
>
> patch : https://lists.rtems.org/pipermail/devel/2020-March/058516.html
>
Its just few simple steps:

1- As you use gmail, just open the patch-mail. Click option
and select 'Show Original'.
2- Copy the content written in monospace/raw-format.
 There is also a button 'Copy to Clipboard'.
3- Get to your terminal, switch to master branch.
You might wanna 'git pull' to load recent
changes (if any).
4- type 'git am' and hit enter key.
5- Since no mailbox given, it will read from stdin, hence
 wait for your input.
6- Paste the content (ctrl+shift+v).
7- Press (ctrl+D)

Patch will be applied

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

Re: [PATCH] bsps/console: Support device file system

2020-04-02 Thread Joel Sherrill

On Thu, Apr 2, 2020 at 9:47 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 02/04/2020 16:45, Gedare Bloom wrote:
>
> > Can we hold this until 6?
> Joel complained that the CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM is
> broken. For me it is not important.
>

If this fixes that, please push it.

--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: sqlite build failure on BSP bsets

2020-04-02 Thread Joel Sherrill

On Thu, Apr 2, 2020 at 3:00 PM Gedare Bloom  wrote:

> On Thu, Apr 2, 2020 at 1:57 PM Jonathan Brandmeyer
>  wrote:
> >
> >
> > On Thu, Apr 2, 2020 at 1:43 PM Joel Sherrill  wrote:
> >>
> >> Thank you for the detailed feedback.
> >>
> >> I am torn between:
> >>
> >> + deleting sqlite from the BSP bset's
> >> + requiring tclsh to be installed
> >> + updating the RSB recipe for sqlite.
> >>
> >> Given the desire to get a release out the door. I am prone to the first
> >> option with a ticket for 5.2 to update sqlite and re-add it to the BSP
> >> bsets.
> >
> >
> > I can see where you're coming from.  That said, even having an obsolete
> bset in the RSB served as a helpful hint that it worked for someone once
> upon a time.
> >
> >>
> >>
> >> Since you obviously use sqlite, if you could tackle updating the RSB
> >> recipe, that would be great and avoid having to do something expedient
> >> to get the release out the door.
> >
> >
> >  I can make a pass at it.  What's the quickest way to iterate on a
> BSET's rules?  I'd rather not have to wait on GCC and crew to rebuild when
> I get it wrong the first time.
> >
> Use --dry-run option
>

This is good to watch the commands quickly.  But you can just explicitly
build the one package.

$ cd rtems
$ ../source-builder/sb-set-builder \
 --log=l-sqlite.txt \
 --prefix= \
  databases/sqlite

Should be very close to working. I hacked my command for dtc so there may
be a typo.

This should take seconds.

It is interesting that you didn't know you can build a single package
or --dry-run. No foul to you. Just points out that we aren't letting the
community know the cool things the RSB can do.

I use the source download only option to get people to download things
for the tools before they come to the Kick Start class. If they have network
issues, can't fetch git, no admin, etc. then they can deal with those with
their IT. I can't help with someone's draconian policies. :)

>
> >>
> >> Chris will eventually wake up in Sydney and chime in. :)
> >>
> >
> >
> > --
> > Jonathan Brandmeyer
> > ___
> > 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: sqlite build failure on BSP bsets

2020-04-02 Thread Gedare Bloom

On Thu, Apr 2, 2020 at 1:57 PM Jonathan Brandmeyer
 wrote:
>
>
> On Thu, Apr 2, 2020 at 1:43 PM Joel Sherrill  wrote:
>>
>> Thank you for the detailed feedback.
>>
>> I am torn between:
>>
>> + deleting sqlite from the BSP bset's
>> + requiring tclsh to be installed
>> + updating the RSB recipe for sqlite.
>>
>> Given the desire to get a release out the door. I am prone to the first
>> option with a ticket for 5.2 to update sqlite and re-add it to the BSP
>> bsets.
>
>
> I can see where you're coming from.  That said, even having an obsolete bset 
> in the RSB served as a helpful hint that it worked for someone once upon a 
> time.
>
>>
>>
>> Since you obviously use sqlite, if you could tackle updating the RSB
>> recipe, that would be great and avoid having to do something expedient
>> to get the release out the door.
>
>
>  I can make a pass at it.  What's the quickest way to iterate on a BSET's 
> rules?  I'd rather not have to wait on GCC and crew to rebuild when I get it 
> wrong the first time.
>
Use --dry-run option

>>
>> Chris will eventually wake up in Sydney and chime in. :)
>>
>
>
> --
> Jonathan Brandmeyer
> ___
> 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: sqlite build failure on BSP bsets

2020-04-02 Thread Jonathan Brandmeyer

On Thu, Apr 2, 2020 at 1:43 PM Joel Sherrill  wrote:

> Thank you for the detailed feedback.
>
> I am torn between:
>
> + deleting sqlite from the BSP bset's
> + requiring tclsh to be installed
> + updating the RSB recipe for sqlite.
>
> Given the desire to get a release out the door. I am prone to the first
> option with a ticket for 5.2 to update sqlite and re-add it to the BSP
> bsets.
>

I can see where you're coming from.  That said, even having an obsolete
bset in the RSB served as a helpful hint that it worked for someone once
upon a time.

>
> Since you obviously use sqlite, if you could tackle updating the RSB
> recipe, that would be great and avoid having to do something expedient
> to get the release out the door.
>

 I can make a pass at it.  What's the quickest way to iterate on a BSET's
rules?  I'd rather not have to wait on GCC and crew to rebuild when I get
it wrong the first time.

> Chris will eventually wake up in Sydney and chime in. :)
>
>

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

Re: sqlite build failure on BSP bsets

2020-04-02 Thread Joel Sherrill

Thank you for the detailed feedback.

I am torn between:

+ deleting sqlite from the BSP bset's
+ requiring tclsh to be installed
+ updating the RSB recipe for sqlite.

Given the desire to get a release out the door. I am prone to the first
option with a ticket for 5.2 to update sqlite and re-add it to the BSP
bsets.

Since you obviously use sqlite, if you could tackle updating the RSB
recipe, that would be great and avoid having to do something expedient
to get the release out the door.

Chris will eventually wake up in Sydney and chime in. :)

--joel

On Thu, Apr 2, 2020 at 1:36 PM Jonathan Brandmeyer 
wrote:

> We just copied the amalgamation's single .c and .h file into our
> repository and built it as a single object into our application.  So the
> following recommendations come only from an amateur reading of the sources
> on current rtems-source-builder master.
>
> 3.8.8 is pretty old.  I'd just jump straight to 3.30.1, the current
> release.
>
> Instead of downloading the sqlite-src zip, download sqlite-amalgamation or
> sqlite-autoconf and use that as a base.  I think the bset's configuration
> invocation is OK, except that I would set different CFLAGS as described in
> the next couple of paragraphs.  See also
> https://sqlite.org/amalgamation.html
>
> By default, the SQLite write-ahead-log relies on mmap to share some of its
> index structures between multiple processes.  It looks like the current
> RTEMS bset disables the WAL entirely.  Using the WAL gives much better
> performance than the rollback journal for write-intensive use cases.  We
> used SQLite to reliably buffer up and stitch together segments of our field
> software update process, which fits the WAL very well.  We set
> `-DSQLITE_MAX_MMAP_SIZE=0 -DSQLITE_DEFAULT_LOCKING_MODE=1` at compile time
> to avoid mmap's use since RTEMS has neither a VMM nor multiple address
> spaces.  It is still up to the application to choose either the WAL or the
> rollback journal.  See also https://sqlite.org/wal.html#noshm
>
> We also added -DSQLITE_ENABLE_MEMSYS5 to our build, and used it to give
> SQLite its own memory spaces to operate on distinct from the rest of our
> application.  We explicitly provided it with its own MEMSYS5 heap, page
> cache, and lookaside pools.  RTEMS just needs to add the correct
> compile-time option to support this functionality.  It is still up to the
> application to configure and monitor those memory pools at runtime.  See
> also https://sqlite.org/malloc.html
>
> HTH,
>
> On Thu, Apr 2, 2020 at 11:16 AM Joel Sherrill  wrote:
>
>>
>>
>> On Thu, Apr 2, 2020, 12:09 PM Jonathan Brandmeyer <
>> jbrandme...@planetiq.com> wrote:
>>
>>> It depends on how you build it.  If you use the amalgamation, you aren't
>>> running the test suite, and you aren't building any of the other
>>> command-line tools that ship with sqlite, then I don't think you have to
>>> have TCL.
>>>
>>
>> If the configuration command needs to change in the bset, could you
>> suggest the command? It would be appreciated.
>>
>> --joel
>>
>>
>>> On Thu, Apr 2, 2020 at 11:01 AM Joel Sherrill  wrote:
>>>
 Hi

 It looks like tclsh is required to build sqlite. I filed this as a
 ticket since it is a bit of a broad issue. Added host dependency (docs,
 sb-check), no BSP bset builds without it installed, etc.

 + make -j 8 sqlite3.h libsqlite3.la
 tclsh
 /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/mksqlite3h.tcl
 /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801
 >sqlite3.h
 gcc  -g -o mkkeywordhash -DSQLITE_OMIT_WAL=1
 -DSQLITE_ENABLE_COLUMN_METADATA=1
  
 /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/mkkeywordhash.c
 gcc  -g -o lemon
 /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/lemon.c
 /bin/sh: tclsh: command not found

 --joel
 ___
 devel mailing list
 devel@rtems.org
 http://lists.rtems.org/mailman/listinfo/devel
>>>
>>>
>>>
>>> --
>>> Jonathan Brandmeyer
>>> Vice President of Software Engineering
>>> PlanetiQ
>>>
>>
>
> --
> Jonathan Brandmeyer
> Vice President of Software Engineering
> PlanetiQ
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] bsp/shared/clock: Reset Clock_driver_isrs to correct value

2020-04-02 Thread Jan Sommer

CLOCK_DRIVER_ISRS_PER_TICK is the configuration define,
CLOCK_DRIVER_ISRS_PER_TICK_VALUE is the actual value of ISRS per clock
tick, therefore use this one to reset the Clock_driver_isrs after each
tick.
---
 bsps/shared/dev/clock/clockimpl.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsps/shared/dev/clock/clockimpl.h 
b/bsps/shared/dev/clock/clockimpl.h
index 3c08c80859..f3b2565c56 100644
--- a/bsps/shared/dev/clock/clockimpl.h
+++ b/bsps/shared/dev/clock/clockimpl.h
@@ -182,7 +182,7 @@ rtems_isr Clock_isr(
   if ( !Clock_driver_isrs ) {
 Clock_driver_timecounter_tick();
 
-Clock_driver_isrs = CLOCK_DRIVER_ISRS_PER_TICK;
+Clock_driver_isrs = CLOCK_DRIVER_ISRS_PER_TICK_VALUE;
   }
   Clock_driver_isrs--;
 #else
-- 
2.12.3

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

Re: sqlite build failure on BSP bsets

2020-04-02 Thread Jonathan Brandmeyer

We just copied the amalgamation's single .c and .h file into our repository
and built it as a single object into our application.  So the following
recommendations come only from an amateur reading of the sources on current
rtems-source-builder master.

3.8.8 is pretty old.  I'd just jump straight to 3.30.1, the current release.

Instead of downloading the sqlite-src zip, download sqlite-amalgamation or
sqlite-autoconf and use that as a base.  I think the bset's configuration
invocation is OK, except that I would set different CFLAGS as described in
the next couple of paragraphs.  See also
https://sqlite.org/amalgamation.html

By default, the SQLite write-ahead-log relies on mmap to share some of its
index structures between multiple processes.  It looks like the current
RTEMS bset disables the WAL entirely.  Using the WAL gives much better
performance than the rollback journal for write-intensive use cases.  We
used SQLite to reliably buffer up and stitch together segments of our field
software update process, which fits the WAL very well.  We set
`-DSQLITE_MAX_MMAP_SIZE=0 -DSQLITE_DEFAULT_LOCKING_MODE=1` at compile time
to avoid mmap's use since RTEMS has neither a VMM nor multiple address
spaces.  It is still up to the application to choose either the WAL or the
rollback journal.  See also https://sqlite.org/wal.html#noshm

We also added -DSQLITE_ENABLE_MEMSYS5 to our build, and used it to give
SQLite its own memory spaces to operate on distinct from the rest of our
application.  We explicitly provided it with its own MEMSYS5 heap, page
cache, and lookaside pools.  RTEMS just needs to add the correct
compile-time option to support this functionality.  It is still up to the
application to configure and monitor those memory pools at runtime.  See
also https://sqlite.org/malloc.html

HTH,

On Thu, Apr 2, 2020 at 11:16 AM Joel Sherrill  wrote:

>
>
> On Thu, Apr 2, 2020, 12:09 PM Jonathan Brandmeyer <
> jbrandme...@planetiq.com> wrote:
>
>> It depends on how you build it.  If you use the amalgamation, you aren't
>> running the test suite, and you aren't building any of the other
>> command-line tools that ship with sqlite, then I don't think you have to
>> have TCL.
>>
>
> If the configuration command needs to change in the bset, could you
> suggest the command? It would be appreciated.
>
> --joel
>
>
>> On Thu, Apr 2, 2020 at 11:01 AM Joel Sherrill  wrote:
>>
>>> Hi
>>>
>>> It looks like tclsh is required to build sqlite. I filed this as a
>>> ticket since it is a bit of a broad issue. Added host dependency (docs,
>>> sb-check), no BSP bset builds without it installed, etc.
>>>
>>> + make -j 8 sqlite3.h libsqlite3.la
>>> tclsh
>>> /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/mksqlite3h.tcl
>>> /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801
>>> >sqlite3.h
>>> gcc  -g -o mkkeywordhash -DSQLITE_OMIT_WAL=1
>>> -DSQLITE_ENABLE_COLUMN_METADATA=1
>>>  
>>> /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/mkkeywordhash.c
>>> gcc  -g -o lemon
>>> /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/lemon.c
>>> /bin/sh: tclsh: command not found
>>>
>>> --joel
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
>>
>> --
>> Jonathan Brandmeyer
>> Vice President of Software Engineering
>> PlanetiQ
>>
>

-- 
Jonathan Brandmeyer
Vice President of Software Engineering
PlanetiQ
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-docs commit] user/start/gsoc: fix unicode error and grammar typo

2020-04-02 Thread Gedare Bloom

There was a problem with building latex pdf docs, it turned out to be
some invisible unicode that slipped in the GSoC Getting Started patch.

On Thu, Apr 2, 2020 at 12:15 PM Gedare Bloom  wrote:
>
> Module:rtems-docs
> Branch:master
> Commit:d4d30673d094e1e7c796c5a6d3de3e12ccaa1b9e
> Changeset: 
> http://git.rtems.org/rtems-docs/commit/?id=d4d30673d094e1e7c796c5a6d3de3e12ccaa1b9e
>
> Author:Gedare Bloom 
> Date:  Thu Apr  2 12:14:51 2020 -0600
>
> user/start/gsoc: fix unicode error and grammar typo
>
> ---
>
>  user/start/gsoc.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/user/start/gsoc.rst b/user/start/gsoc.rst
> index 62154ff..7f27d7b 100644
> --- a/user/start/gsoc.rst
> +++ b/user/start/gsoc.rst
> @@ -21,7 +21,7 @@ subsections under :ref:`Quick Start ` chapter 
> or ask on the
>  :r:list:`devel`.
>
>  You will be best served by using a GNU/Linux environment, which could be in a
> -virtual machine, for example that uses `Virtualbox 
> `_
> +virtual machine, for example that uses `Virtualbox 
> `_
>  and should run on most modern desktop systems. You should also be able to 
> work
>  with a MacOS or Windows system, but might encounter more difficulty than a 
> *nix
>  environment.
> @@ -129,4 +129,4 @@ Here are a few pointers to keep in mind while creating 
> the patches.
>  * Avoid trailing whitespace errors.
>  * The author name of the patch is your full name.
>  * The author email of the patch is your valid email address.
> -* Ensure that your patch builds before sending them for review.
> \ No newline at end of file
> +* Ensure that your patches build before sending them for review.
>
> ___
> vc mailing list
> v...@rtems.org
> http://lists.rtems.org/mailman/listinfo/vc
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: sqlite build failure on BSP bsets

2020-04-02 Thread Joel Sherrill

On Thu, Apr 2, 2020, 12:09 PM Jonathan Brandmeyer 
wrote:

> It depends on how you build it.  If you use the amalgamation, you aren't
> running the test suite, and you aren't building any of the other
> command-line tools that ship with sqlite, then I don't think you have to
> have TCL.
>

If the configuration command needs to change in the bset, could you suggest
the command? It would be appreciated.

--joel


> On Thu, Apr 2, 2020 at 11:01 AM Joel Sherrill  wrote:
>
>> Hi
>>
>> It looks like tclsh is required to build sqlite. I filed this as a ticket
>> since it is a bit of a broad issue. Added host dependency (docs, sb-check),
>> no BSP bset builds without it installed, etc.
>>
>> + make -j 8 sqlite3.h libsqlite3.la
>> tclsh
>> /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/mksqlite3h.tcl
>> /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801
>> >sqlite3.h
>> gcc  -g -o mkkeywordhash -DSQLITE_OMIT_WAL=1
>> -DSQLITE_ENABLE_COLUMN_METADATA=1
>>  
>> /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/mkkeywordhash.c
>> gcc  -g -o lemon
>> /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/lemon.c
>> /bin/sh: tclsh: command not found
>>
>> --joel
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
>
> --
> Jonathan Brandmeyer
> Vice President of Software Engineering
> PlanetiQ
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: sqlite build failure on BSP bsets

2020-04-02 Thread Jonathan Brandmeyer

It depends on how you build it.  If you use the amalgamation, you aren't
running the test suite, and you aren't building any of the other
command-line tools that ship with sqlite, then I don't think you have to
have TCL.

On Thu, Apr 2, 2020 at 11:01 AM Joel Sherrill  wrote:

> Hi
>
> It looks like tclsh is required to build sqlite. I filed this as a ticket
> since it is a bit of a broad issue. Added host dependency (docs, sb-check),
> no BSP bset builds without it installed, etc.
>
> + make -j 8 sqlite3.h libsqlite3.la
> tclsh
> /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/mksqlite3h.tcl
> /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801
> >sqlite3.h
> gcc  -g -o mkkeywordhash -DSQLITE_OMIT_WAL=1
> -DSQLITE_ENABLE_COLUMN_METADATA=1
>  
> /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/mkkeywordhash.c
> gcc  -g -o lemon
> /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/lemon.c
> /bin/sh: tclsh: command not found
>
> --joel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



-- 
Jonathan Brandmeyer
Vice President of Software Engineering
PlanetiQ
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

sqlite build failure on BSP bsets

2020-04-02 Thread Joel Sherrill

Hi

It looks like tclsh is required to build sqlite. I filed this as a ticket
since it is a bit of a broad issue. Added host dependency (docs, sb-check),
no BSP bset builds without it installed, etc.

+ make -j 8 sqlite3.h libsqlite3.la
tclsh
/home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/mksqlite3h.tcl
/home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801
>sqlite3.h
gcc  -g -o mkkeywordhash -DSQLITE_OMIT_WAL=1
-DSQLITE_ENABLE_COLUMN_METADATA=1
 
/home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/mkkeywordhash.c
gcc  -g -o lemon
/home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/lemon.c
/bin/sh: tclsh: command not found

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

Re: [PATCH] start/user: describe version numbers and releases

2020-04-02 Thread Gedare Bloom

I pushed this.

On Wed, Apr 1, 2020 at 9:35 PM Gedare Bloom  wrote:
>
> Closes #2562.
> ---
>  user/start/preparation.rst | 49 ++
>  1 file changed, 49 insertions(+)
>
> diff --git a/user/start/preparation.rst b/user/start/preparation.rst
> index 546a03d..eb0d56b 100644
> --- a/user/start/preparation.rst
> +++ b/user/start/preparation.rst
> @@ -1,8 +1,10 @@
>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>
> +.. Copyright (C) 2018 Shashvat Jain
>  .. Copyright (C) 2019 embedded brains GmbH
>  .. Copyright (C) 2019 Sebastian Huber
>  .. Copyright (C) 2020 Chris Johns
> +.. Copyright (C) 2020 Gedare Bloom
>
>  .. _QuickStartPreparation:
>
> @@ -62,3 +64,50 @@ If you are looking for a hardware target to run RTEMS on 
> we recommend the
>  BSP. The BeagleBone Black support includes the RTEMS BSD Library (``libbsd``)
>  and networking. The BeagleBone Black BSP is an ARM architecture BSP so the 
> tool
>  suite name is ``arm-rtems5``.
> +
> +Selecting a Version of RTEMS
> +
> +
> +In the examples of this manual we will often refer to a specific version of
> +RTEMS, which will usually be the version that accompanied the publication of
> +this documentation manual. That may not be the appropriate version for you to
> +use, for example, it may be too old (or too new) depending on what you are
> +trying to do.  If you're not sure what version to use, we generally recommend
> +using the most recent release or the development head (master), and you may
> +want to consult with the same version of the documentation. We hope that 
> newer
> +is better.
> +
> +An RTEMS *release* involves the creation of a single downloadable file,
> +normally a compressed tarball, that packages the source of all the 
> repositories
> +in a state consistent with the time the release is created.
> +A release branch is a git branch pushed to the repositories named with the
> +numeric identifier of the branch.
> +A release branch release is a git tag on a release branch with
> +the tags pushed to the repositories.
> +
> +Numbering for RTEMS versions beginning with RTEMS 5 uses a format as follows.
> +The master branch has the version **N.0.0** with N being the next major 
> release
> +number. The first release of this series has the version number **N.1.0.** 
> and
> +there is exactly one commit with this version number in the corresponding
> +repository. The first bugfix release (minor release) of this series will have
> +the version number **N.2.0**. The release branch will have the version
> +number **N.M.1** with **M** being the last minor release of this series.
> +
> +For example:
> ++ 5.0.0 is the version number of the development master for the 5 series.
> ++ 5.1.0 is the first release of the 5 series.
> ++ 5.1.1 is the version number of the 5 series release branch right after
> +  the 5.1.0 release until 5.2.0 is released.
> ++ 5.2.0 is the first bugfix release of the 5 series
> ++ 5.2.1 is the version number of the 5 series release branch right after
> +  the 5.2.0 release until 5.3.0 is released.
> ++ 6.0.0 is the version number of the development master for the 6 series.
> +
> +RTEMS development tools use **N** as the version number and are expected to
> +work with all releases and the release branch of the N series.
> +So to build tools for compiling RTEMS version number 5.1.0 for SPARC use
> +``sparc-rtems5``. Despite the number not increasing, the tools may change
> +within a release branch, for example the tools packaged with 5.1.1 still use
> +the ``sparc-rtems5`` moniker, but are likely not the same as the tools used
> +in version 5.1.0. This tool mismatch can be a source of confusion. Be sure to
> +use the toolchain that matches your release.
> --
> 2.17.1
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH docs] user/bsp-build: Fix broken cross references.

2020-04-02 Thread Gedare Bloom

pushed

On Thu, Apr 2, 2020 at 5:07 AM G S Niteesh Babu  wrote:
>
> The QuickStartBSPBuild_Manual and QuickStartBSPBuild_RSB are
> missing the underscore in front. This breaks any reference to
> them from other sections.
> ---
>  user/start/bsp-build.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/user/start/bsp-build.rst b/user/start/bsp-build.rst
> index 33ecb29..59da2fd 100644
> --- a/user/start/bsp-build.rst
> +++ b/user/start/bsp-build.rst
> @@ -29,7 +29,7 @@ use one of the listed methods to build the BSP.
>  In the output in this section the base directory :file:`$HOME/quick-start` 
> was
>  replaced by ``$BASE``.
>
> -.. QuickStartBSPBuild_RSB:
> +.. _QuickStartBSPBuild_RSB:
>
>  RSB BSP Build
>  -
> @@ -92,7 +92,7 @@ The RSB BSP build can be customised with following RSB 
> command line options:
>  If you have built a BSP with the RSB, you can move on to
>  :ref:`QuickStartBSPTest`.
>
> -.. QuickStartBSPBuild_Manual:
> +.. _QuickStartBSPBuild_Manual:
>
>  Manual BSP Build
>  
> --
> 2.17.1
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH docs] start/gsoc: GSoC Getting started instructions.

2020-04-02 Thread Gedare Bloom

Thanks for this, I pushed it, but changed the location in the index to
the end of the Getting Started Guide.

On Thu, Apr 2, 2020 at 8:05 AM G S Niteesh Babu  wrote:
>
> Added instructions to setup development environment for students
> interested in GSoC.
> ---
>  user/index.rst   |   1 +
>  user/start/gsoc.rst  | 132 +++
>  user/start/index.rst |   1 +
>  3 files changed, 134 insertions(+)
>  create mode 100644 user/start/gsoc.rst
>
> diff --git a/user/index.rst b/user/index.rst
> index 7b584c5..4e91994 100644
> --- a/user/index.rst
> +++ b/user/index.rst
> @@ -10,6 +10,7 @@ RTEMS User Manual (|version|).
>
>  .. topic:: Copyrights and License
>
> +| |copy| 2020 Niteesh Babu
>  | |copy| 2019 Vijay Kumar Banerjee
>  | |copy| 2018 Amaan Cheval
>  | |copy| 2018 Marçal Comajoan Cara
> diff --git a/user/start/gsoc.rst b/user/start/gsoc.rst
> new file mode 100644
> index 000..62154ff
> --- /dev/null
> +++ b/user/start/gsoc.rst
> @@ -0,0 +1,132 @@
> +.. SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. Copyright (C) 2020 Niteesh Babu 
> +
> +.. _QuickStartGSoC:
> +
> +GSoC Getting Started
> +
> +
> +The goal of this page is to help new users, especially students get RTEMS
> +compiled and running so they can start with the real work.
> +
> +Please join the :r:list:`users` and :r:list:`devel` and ask
> +questions. Help correct any deficiencies in the code or documentation you 
> spot,
> +including those on the wiki. The ultimate goal of GSoC is to help you become
> +part of the open source community.
> +
> +This section will help you to quickly setup a development environment without
> +delving into the details. For more information you can go through the other
> +subsections under :ref:`Quick Start ` chapter or ask on the
> +:r:list:`devel`.
> +
> +You will be best served by using a GNU/Linux environment, which could be in a
> +virtual machine, for example that uses `Virtualbox 
> `_
> +and should run on most modern desktop systems. You should also be able to 
> work
> +with a MacOS or Windows system, but might encounter more difficulty than a 
> *nix
> +environment.
> +
> +Setting up a development environment consists of the following steps.
> +
> +1) Installing dependencies for your host operating system.
> +2) Choosing an installation prefix.
> +3) Downloading the source code.
> +4) Installing the tool suite.
> +5) Building the Board Support Package (BSP).
> +6) Testing the Board Support Package (BSP).
> +
> +Installing Dependencies
> +---
> +
> +You need tools for your host’s operating system to build the RTEMS tool suite
> +from source. Please have a look at the :ref:`host-computer` chapter for the
> +instructions to install the tools for your OS.
> +
> +Choosing an installation prefix
> +---
> +
> +The term ``prefix`` refers to the path on your computer where the software 
> is to
> +be installed.
> +You can refer to the :ref:`Prefix ` section for details 
> on
> +choosing an installation prefix.
> +
> +Downloading the Sources
> +---
> +
> +We will be using Git to clone the sources for RTEMS and RSB. This is the
> +preferred way if you are planning to make contributions to the RTEMS project.
> +
> +Please refer to the :ref:`QuickStartSources_Git` section for instructions on
> +obtaining sources using Git.
> +
> +Installing the Tool Suite
> +-
> +
> +The Tools suite is the collection of tools required to build the BSP. This
> +includes the compiler, debugger, assembler and other tools. These tools are
> +architecture-specific. We will be installing the SPARC tool suite since we 
> are
> +building a SPARC based BSP.
> +
> +Please refer to the :ref:`QuickStartTools` section for instructions on
> +building and installing the tool suite.
> +
> +Building the Board Support Package
> +--
> +
> +There are two ways of building a BSP. We could either ask RSB to build the 
> BSP
> +or manually build it. In this section will we be building it manually.
> +Please refer the :ref:`QuickStartBSPBuild_Manual` section for the
> +instructions.
> +
> +Testing the Board Support Package
> +-
> +
> +Testing is an essential part of RTEMS development process. The main reason 
> for
> +choosing the SPARC erc32 BSP is that, it has very good simulator support. 
> This
> +will allow you to test your changes without the need for SPARC hardware.
> +
> +Please refer to :ref:`QuickStartBSPTest` for instructions on testing the BSP.
> +
> +Prove You Can Work On RTEMS
> +---
> +
> +This section is only for students interested in Google Summer of Code.
> +
> +You have to finish the following task to prove that you can work on RTEMS.
> +
> +Modify the hello world example to include a new different print statement.
> +Something like "Hello from The Dark

Re: [PATCH libbsd 10/11] ehci_imx: Set/clear ENHOSTDISCONNECT in USB PHY.

2020-04-02 Thread Christian Mauderer

On 02/04/2020 17:20, Gedare Bloom wrote:
> On Thu, Apr 2, 2020 at 9:18 AM Christian Mauderer
>  wrote:
>>
>> On 02/04/2020 17:13, Gedare Bloom wrote:
>>> Maybe file a ticket against this for the future.
>>
>> Problematic point is: I'm not sure when or if FreeBSD ever will have the
>> necessary functions. So that ticket would be a candidate for being open
>> forever.
>>
> OK that's fine.

Thanks.

> 
> It seems all the imx stuff is ok, except for the changes noted in the
> shared files to address. The new imports seem straightforward and if
> you need this stuff for 5.1 then once you sort out the patch order and
> the unaligned access, if Sebastian is happy go for it.

I'll clean it up.

> 
> New BSPs/features that can wait for 6.0 at this point should.

OK.

> 
>>>
>>> On Thu, Apr 2, 2020 at 8:43 AM Christian Mauderer
>>>  wrote:

 This is not a nice solution but it should work on all chips. As soon as
 FreeBSD has a nice solution via the USB PHY driver, this should be
 replaced.

 Update #3869.
 ---
  freebsd/sys/dev/usb/controller/ehci_imx.c | 59 
 +++
  1 file changed, 59 insertions(+)

 diff --git a/freebsd/sys/dev/usb/controller/ehci_imx.c 
 b/freebsd/sys/dev/usb/controller/ehci_imx.c
 index d158df1d..544a63b5 100644
 --- a/freebsd/sys/dev/usb/controller/ehci_imx.c
 +++ b/freebsd/sys/dev/usb/controller/ehci_imx.c
 @@ -50,6 +50,9 @@ __FBSDID("$FreeBSD$");

  #include 
  #include 
 +#ifdef __rtems__
 +#include 
 +#endif /* __rtems__ */

  #include 
  #include 
 @@ -270,6 +273,9 @@ struct imx_ehci_softc {
 device_tdev;
 struct resource *ehci_mem_res;  /* EHCI core regs. */
 struct resource *ehci_irq_res;  /* EHCI core IRQ. */
 +#ifdef __rtems__
 +   void*phy_regs;
 +#endif /* __rtems__ */
  };

  static struct ofw_compat_data compat_data[] = {
 @@ -380,6 +386,32 @@ imx_ehci_disable_oc(struct imx_ehci_softc *sc)
 index = usbmprops[1];
 imx_usbmisc_set_ctrl(usbmdev, index, USBNC_OVER_CUR_DIS);
  }
 +#ifdef __rtems__
 +#define BUS_SPACE_PHYSADDR(res, offs) \
 +   ((u_int)(rman_get_start(res)+(offs)))
 +
 +static uint16_t
 +imx_ehci_get_port_speed_portsc(struct ehci_softc *sc, uint16_t index)
 +{
 +   uint32_t v;
 +   struct imx_ehci_softc *isc = (struct imx_ehci_softc *)sc;
 +
 +   v = ehci_get_port_speed_portsc(sc, index);
 +
 +   /* Set/clear ENHOSTDISCONDETECT in USBPHY CTRL register */
 +   /* FIXME: This is a very hacky method. It should be done by the phy
 +* driver instead. */
 +   volatile uint32_t *ctrl_set = isc->phy_regs + 0x34;
 +   volatile uint32_t *ctrl_clr = isc->phy_regs + 0x38;
 +   if (v == UPS_HIGH_SPEED) {
 +   *ctrl_set = 0x2;
 +   } else {
 +   *ctrl_clr = 0x2;
 +   }
 +
 +   return (v);
 +}
 +#endif /* __rtems__ */

  static int
  imx_ehci_attach(device_t dev)
 @@ -474,6 +506,33 @@ imx_ehci_attach(device_t dev)
 esc->sc_flags |= EHCI_SCFLG_NORESTERM | EHCI_SCFLG_TT;
 esc->sc_vendor_post_reset = imx_ehci_post_reset;
 esc->sc_vendor_get_port_speed = ehci_get_port_speed_portsc;
 +#ifdef __rtems__
 +   /*
 +* FIXME: This is a big hack to get the PHY regs and set one bit 
 during
 +* changes of the port speed.
 +*/
 +   sc->phy_regs = 0;
 +   if (OF_hasprop(ofw_bus_get_node(sc->dev), "fsl,usbphy")) {
 +   phandle_t *cells;
 +   int len;
 +   phandle_t phynode;
 +
 +   cells = NULL;
 +   len = OF_getencprop_alloc_multi(ofw_bus_get_node(sc->dev),
 +   "fsl,usbphy", sizeof(*cells), (void **));
 +   if (len > 0
 +   && (phynode = OF_node_from_xref(cells[0])) != -1 &&
 +   ofw_bus_node_is_compatible(phynode, 
 "fsl,imx6ul-usbphy")) {
 +   u_long base, size;
 +   if (fdt_regsize(phynode, , ) == 0) {
 +   sc->phy_regs = (void*)base;
 +   esc->sc_vendor_get_port_speed =
 +   imx_ehci_get_port_speed_portsc;
 +   }
 +   }
 +   OF_prop_free(cells);
 +   }
 +#endif /* __rtems__ */

 err = ehci_init(esc);
 if (err != 0) {
 --
 2.16.4

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

Re: [PATCH libbsd 10/11] ehci_imx: Set/clear ENHOSTDISCONNECT in USB PHY.

2020-04-02 Thread Gedare Bloom

On Thu, Apr 2, 2020 at 9:18 AM Christian Mauderer
 wrote:
>
> On 02/04/2020 17:13, Gedare Bloom wrote:
> > Maybe file a ticket against this for the future.
>
> Problematic point is: I'm not sure when or if FreeBSD ever will have the
> necessary functions. So that ticket would be a candidate for being open
> forever.
>
OK that's fine.

It seems all the imx stuff is ok, except for the changes noted in the
shared files to address. The new imports seem straightforward and if
you need this stuff for 5.1 then once you sort out the patch order and
the unaligned access, if Sebastian is happy go for it.

New BSPs/features that can wait for 6.0 at this point should.

> >
> > On Thu, Apr 2, 2020 at 8:43 AM Christian Mauderer
> >  wrote:
> >>
> >> This is not a nice solution but it should work on all chips. As soon as
> >> FreeBSD has a nice solution via the USB PHY driver, this should be
> >> replaced.
> >>
> >> Update #3869.
> >> ---
> >>  freebsd/sys/dev/usb/controller/ehci_imx.c | 59 
> >> +++
> >>  1 file changed, 59 insertions(+)
> >>
> >> diff --git a/freebsd/sys/dev/usb/controller/ehci_imx.c 
> >> b/freebsd/sys/dev/usb/controller/ehci_imx.c
> >> index d158df1d..544a63b5 100644
> >> --- a/freebsd/sys/dev/usb/controller/ehci_imx.c
> >> +++ b/freebsd/sys/dev/usb/controller/ehci_imx.c
> >> @@ -50,6 +50,9 @@ __FBSDID("$FreeBSD$");
> >>
> >>  #include 
> >>  #include 
> >> +#ifdef __rtems__
> >> +#include 
> >> +#endif /* __rtems__ */
> >>
> >>  #include 
> >>  #include 
> >> @@ -270,6 +273,9 @@ struct imx_ehci_softc {
> >> device_tdev;
> >> struct resource *ehci_mem_res;  /* EHCI core regs. */
> >> struct resource *ehci_irq_res;  /* EHCI core IRQ. */
> >> +#ifdef __rtems__
> >> +   void*phy_regs;
> >> +#endif /* __rtems__ */
> >>  };
> >>
> >>  static struct ofw_compat_data compat_data[] = {
> >> @@ -380,6 +386,32 @@ imx_ehci_disable_oc(struct imx_ehci_softc *sc)
> >> index = usbmprops[1];
> >> imx_usbmisc_set_ctrl(usbmdev, index, USBNC_OVER_CUR_DIS);
> >>  }
> >> +#ifdef __rtems__
> >> +#define BUS_SPACE_PHYSADDR(res, offs) \
> >> +   ((u_int)(rman_get_start(res)+(offs)))
> >> +
> >> +static uint16_t
> >> +imx_ehci_get_port_speed_portsc(struct ehci_softc *sc, uint16_t index)
> >> +{
> >> +   uint32_t v;
> >> +   struct imx_ehci_softc *isc = (struct imx_ehci_softc *)sc;
> >> +
> >> +   v = ehci_get_port_speed_portsc(sc, index);
> >> +
> >> +   /* Set/clear ENHOSTDISCONDETECT in USBPHY CTRL register */
> >> +   /* FIXME: This is a very hacky method. It should be done by the phy
> >> +* driver instead. */
> >> +   volatile uint32_t *ctrl_set = isc->phy_regs + 0x34;
> >> +   volatile uint32_t *ctrl_clr = isc->phy_regs + 0x38;
> >> +   if (v == UPS_HIGH_SPEED) {
> >> +   *ctrl_set = 0x2;
> >> +   } else {
> >> +   *ctrl_clr = 0x2;
> >> +   }
> >> +
> >> +   return (v);
> >> +}
> >> +#endif /* __rtems__ */
> >>
> >>  static int
> >>  imx_ehci_attach(device_t dev)
> >> @@ -474,6 +506,33 @@ imx_ehci_attach(device_t dev)
> >> esc->sc_flags |= EHCI_SCFLG_NORESTERM | EHCI_SCFLG_TT;
> >> esc->sc_vendor_post_reset = imx_ehci_post_reset;
> >> esc->sc_vendor_get_port_speed = ehci_get_port_speed_portsc;
> >> +#ifdef __rtems__
> >> +   /*
> >> +* FIXME: This is a big hack to get the PHY regs and set one bit 
> >> during
> >> +* changes of the port speed.
> >> +*/
> >> +   sc->phy_regs = 0;
> >> +   if (OF_hasprop(ofw_bus_get_node(sc->dev), "fsl,usbphy")) {
> >> +   phandle_t *cells;
> >> +   int len;
> >> +   phandle_t phynode;
> >> +
> >> +   cells = NULL;
> >> +   len = OF_getencprop_alloc_multi(ofw_bus_get_node(sc->dev),
> >> +   "fsl,usbphy", sizeof(*cells), (void **));
> >> +   if (len > 0
> >> +   && (phynode = OF_node_from_xref(cells[0])) != -1 &&
> >> +   ofw_bus_node_is_compatible(phynode, 
> >> "fsl,imx6ul-usbphy")) {
> >> +   u_long base, size;
> >> +   if (fdt_regsize(phynode, , ) == 0) {
> >> +   sc->phy_regs = (void*)base;
> >> +   esc->sc_vendor_get_port_speed =
> >> +   imx_ehci_get_port_speed_portsc;
> >> +   }
> >> +   }
> >> +   OF_prop_free(cells);
> >> +   }
> >> +#endif /* __rtems__ */
> >>
> >> err = ehci_init(esc);
> >> if (err != 0) {
> >> --
> >> 2.16.4
> >>
> >> ___
> >> 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:

Re: [PATCH libbsd 09/11] ehci_imx.c: Port to RTEMS

2020-04-02 Thread Sebastian Huber


On 02/04/2020 17:15, Christian Mauderer wrote:


On 02/04/2020 17:00, Sebastian Huber wrote:

On 02/04/2020 16:42, Christian Mauderer wrote:


diff --git a/freebsd/sys/dev/usb/usb_busdma.c
b/freebsd/sys/dev/usb/usb_busdma.c
index 9a70c687..c8000170 100644
--- a/freebsd/sys/dev/usb/usb_busdma.c
+++ b/freebsd/sys/dev/usb/usb_busdma.c
@@ -78,6 +78,52 @@ static void    usb_pc_common_mem_cb(void *,
bus_dma_segment_t *, int, int,
   uint8_t);
   #endif
   +#ifdef __rtems__
+#include 
+#if defined(LIBBSP_ARM_IMX_BSP_H)
+#define NEED_MISSALIGNED_COPY
+#endif

Could you please move changes in general file imported from FreeBSD to
separate commits.

OK. I'll split them.


I don't like this change here at all. I had a similar issue with
misaligned memcpy() to device memory here on the STM32H7 platform. Could
you first try this patch here:

Works fine too. The patch seems generic. Do you plan to add it soon as
an extra patch?

I will try to send a patch tomorrow.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH libbsd 10/11] ehci_imx: Set/clear ENHOSTDISCONNECT in USB PHY.

2020-04-02 Thread Christian Mauderer

On 02/04/2020 17:13, Gedare Bloom wrote:
> Maybe file a ticket against this for the future.

Problematic point is: I'm not sure when or if FreeBSD ever will have the
necessary functions. So that ticket would be a candidate for being open
forever.

> 
> On Thu, Apr 2, 2020 at 8:43 AM Christian Mauderer
>  wrote:
>>
>> This is not a nice solution but it should work on all chips. As soon as
>> FreeBSD has a nice solution via the USB PHY driver, this should be
>> replaced.
>>
>> Update #3869.
>> ---
>>  freebsd/sys/dev/usb/controller/ehci_imx.c | 59 
>> +++
>>  1 file changed, 59 insertions(+)
>>
>> diff --git a/freebsd/sys/dev/usb/controller/ehci_imx.c 
>> b/freebsd/sys/dev/usb/controller/ehci_imx.c
>> index d158df1d..544a63b5 100644
>> --- a/freebsd/sys/dev/usb/controller/ehci_imx.c
>> +++ b/freebsd/sys/dev/usb/controller/ehci_imx.c
>> @@ -50,6 +50,9 @@ __FBSDID("$FreeBSD$");
>>
>>  #include 
>>  #include 
>> +#ifdef __rtems__
>> +#include 
>> +#endif /* __rtems__ */
>>
>>  #include 
>>  #include 
>> @@ -270,6 +273,9 @@ struct imx_ehci_softc {
>> device_tdev;
>> struct resource *ehci_mem_res;  /* EHCI core regs. */
>> struct resource *ehci_irq_res;  /* EHCI core IRQ. */
>> +#ifdef __rtems__
>> +   void*phy_regs;
>> +#endif /* __rtems__ */
>>  };
>>
>>  static struct ofw_compat_data compat_data[] = {
>> @@ -380,6 +386,32 @@ imx_ehci_disable_oc(struct imx_ehci_softc *sc)
>> index = usbmprops[1];
>> imx_usbmisc_set_ctrl(usbmdev, index, USBNC_OVER_CUR_DIS);
>>  }
>> +#ifdef __rtems__
>> +#define BUS_SPACE_PHYSADDR(res, offs) \
>> +   ((u_int)(rman_get_start(res)+(offs)))
>> +
>> +static uint16_t
>> +imx_ehci_get_port_speed_portsc(struct ehci_softc *sc, uint16_t index)
>> +{
>> +   uint32_t v;
>> +   struct imx_ehci_softc *isc = (struct imx_ehci_softc *)sc;
>> +
>> +   v = ehci_get_port_speed_portsc(sc, index);
>> +
>> +   /* Set/clear ENHOSTDISCONDETECT in USBPHY CTRL register */
>> +   /* FIXME: This is a very hacky method. It should be done by the phy
>> +* driver instead. */
>> +   volatile uint32_t *ctrl_set = isc->phy_regs + 0x34;
>> +   volatile uint32_t *ctrl_clr = isc->phy_regs + 0x38;
>> +   if (v == UPS_HIGH_SPEED) {
>> +   *ctrl_set = 0x2;
>> +   } else {
>> +   *ctrl_clr = 0x2;
>> +   }
>> +
>> +   return (v);
>> +}
>> +#endif /* __rtems__ */
>>
>>  static int
>>  imx_ehci_attach(device_t dev)
>> @@ -474,6 +506,33 @@ imx_ehci_attach(device_t dev)
>> esc->sc_flags |= EHCI_SCFLG_NORESTERM | EHCI_SCFLG_TT;
>> esc->sc_vendor_post_reset = imx_ehci_post_reset;
>> esc->sc_vendor_get_port_speed = ehci_get_port_speed_portsc;
>> +#ifdef __rtems__
>> +   /*
>> +* FIXME: This is a big hack to get the PHY regs and set one bit 
>> during
>> +* changes of the port speed.
>> +*/
>> +   sc->phy_regs = 0;
>> +   if (OF_hasprop(ofw_bus_get_node(sc->dev), "fsl,usbphy")) {
>> +   phandle_t *cells;
>> +   int len;
>> +   phandle_t phynode;
>> +
>> +   cells = NULL;
>> +   len = OF_getencprop_alloc_multi(ofw_bus_get_node(sc->dev),
>> +   "fsl,usbphy", sizeof(*cells), (void **));
>> +   if (len > 0
>> +   && (phynode = OF_node_from_xref(cells[0])) != -1 &&
>> +   ofw_bus_node_is_compatible(phynode, 
>> "fsl,imx6ul-usbphy")) {
>> +   u_long base, size;
>> +   if (fdt_regsize(phynode, , ) == 0) {
>> +   sc->phy_regs = (void*)base;
>> +   esc->sc_vendor_get_port_speed =
>> +   imx_ehci_get_port_speed_portsc;
>> +   }
>> +   }
>> +   OF_prop_free(cells);
>> +   }
>> +#endif /* __rtems__ */
>>
>> err = ehci_init(esc);
>> if (err != 0) {
>> --
>> 2.16.4
>>
>> ___
>> 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

Re: [PATCH libbsd 09/11] ehci_imx.c: Port to RTEMS

2020-04-02 Thread Christian Mauderer

On 02/04/2020 17:00, Sebastian Huber wrote:
> On 02/04/2020 16:42, Christian Mauderer wrote:
> 
>> diff --git a/freebsd/sys/dev/usb/usb_busdma.c
>> b/freebsd/sys/dev/usb/usb_busdma.c
>> index 9a70c687..c8000170 100644
>> --- a/freebsd/sys/dev/usb/usb_busdma.c
>> +++ b/freebsd/sys/dev/usb/usb_busdma.c
>> @@ -78,6 +78,52 @@ static void    usb_pc_common_mem_cb(void *,
>> bus_dma_segment_t *, int, int,
>>   uint8_t);
>>   #endif
>>   +#ifdef __rtems__
>> +#include 
>> +#if defined(LIBBSP_ARM_IMX_BSP_H)
>> +#define NEED_MISSALIGNED_COPY
>> +#endif
> 
> Could you please move changes in general file imported from FreeBSD to
> separate commits.

OK. I'll split them.

> 
> I don't like this change here at all. I had a similar issue with
> misaligned memcpy() to device memory here on the STM32H7 platform. Could
> you first try this patch here:

Works fine too. The patch seems generic. Do you plan to add it soon as
an extra patch?

> 
> diff --git a/freebsd/sys/dev/usb/usb_busdma.c
> b/freebsd/sys/dev/usb/usb_busdma.c
> index 9a70c687..973a3409 100644
> --- a/freebsd/sys/dev/usb/usb_busdma.c
> +++ b/freebsd/sys/dev/usb/usb_busdma.c
> @@ -584,7 +584,7 @@ usb_pc_alloc_mem(struct usb_page_cache *pc, struct
> usb_page *pg,
>     }
>     /* allocate memory */
>     if (bus_dmamem_alloc(
> -   utag->tag, , (BUS_DMA_WAITOK | BUS_DMA_COHERENT), )) {
> +   utag->tag, , BUS_DMA_WAITOK, )) {
>     goto error;
>     }
>     /* setup page cache */
> 

-- 

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

Re: [PATCH libbsd 10/11] ehci_imx: Set/clear ENHOSTDISCONNECT in USB PHY.

2020-04-02 Thread Gedare Bloom

Maybe file a ticket against this for the future.

On Thu, Apr 2, 2020 at 8:43 AM Christian Mauderer
 wrote:
>
> This is not a nice solution but it should work on all chips. As soon as
> FreeBSD has a nice solution via the USB PHY driver, this should be
> replaced.
>
> Update #3869.
> ---
>  freebsd/sys/dev/usb/controller/ehci_imx.c | 59 
> +++
>  1 file changed, 59 insertions(+)
>
> diff --git a/freebsd/sys/dev/usb/controller/ehci_imx.c 
> b/freebsd/sys/dev/usb/controller/ehci_imx.c
> index d158df1d..544a63b5 100644
> --- a/freebsd/sys/dev/usb/controller/ehci_imx.c
> +++ b/freebsd/sys/dev/usb/controller/ehci_imx.c
> @@ -50,6 +50,9 @@ __FBSDID("$FreeBSD$");
>
>  #include 
>  #include 
> +#ifdef __rtems__
> +#include 
> +#endif /* __rtems__ */
>
>  #include 
>  #include 
> @@ -270,6 +273,9 @@ struct imx_ehci_softc {
> device_tdev;
> struct resource *ehci_mem_res;  /* EHCI core regs. */
> struct resource *ehci_irq_res;  /* EHCI core IRQ. */
> +#ifdef __rtems__
> +   void*phy_regs;
> +#endif /* __rtems__ */
>  };
>
>  static struct ofw_compat_data compat_data[] = {
> @@ -380,6 +386,32 @@ imx_ehci_disable_oc(struct imx_ehci_softc *sc)
> index = usbmprops[1];
> imx_usbmisc_set_ctrl(usbmdev, index, USBNC_OVER_CUR_DIS);
>  }
> +#ifdef __rtems__
> +#define BUS_SPACE_PHYSADDR(res, offs) \
> +   ((u_int)(rman_get_start(res)+(offs)))
> +
> +static uint16_t
> +imx_ehci_get_port_speed_portsc(struct ehci_softc *sc, uint16_t index)
> +{
> +   uint32_t v;
> +   struct imx_ehci_softc *isc = (struct imx_ehci_softc *)sc;
> +
> +   v = ehci_get_port_speed_portsc(sc, index);
> +
> +   /* Set/clear ENHOSTDISCONDETECT in USBPHY CTRL register */
> +   /* FIXME: This is a very hacky method. It should be done by the phy
> +* driver instead. */
> +   volatile uint32_t *ctrl_set = isc->phy_regs + 0x34;
> +   volatile uint32_t *ctrl_clr = isc->phy_regs + 0x38;
> +   if (v == UPS_HIGH_SPEED) {
> +   *ctrl_set = 0x2;
> +   } else {
> +   *ctrl_clr = 0x2;
> +   }
> +
> +   return (v);
> +}
> +#endif /* __rtems__ */
>
>  static int
>  imx_ehci_attach(device_t dev)
> @@ -474,6 +506,33 @@ imx_ehci_attach(device_t dev)
> esc->sc_flags |= EHCI_SCFLG_NORESTERM | EHCI_SCFLG_TT;
> esc->sc_vendor_post_reset = imx_ehci_post_reset;
> esc->sc_vendor_get_port_speed = ehci_get_port_speed_portsc;
> +#ifdef __rtems__
> +   /*
> +* FIXME: This is a big hack to get the PHY regs and set one bit 
> during
> +* changes of the port speed.
> +*/
> +   sc->phy_regs = 0;
> +   if (OF_hasprop(ofw_bus_get_node(sc->dev), "fsl,usbphy")) {
> +   phandle_t *cells;
> +   int len;
> +   phandle_t phynode;
> +
> +   cells = NULL;
> +   len = OF_getencprop_alloc_multi(ofw_bus_get_node(sc->dev),
> +   "fsl,usbphy", sizeof(*cells), (void **));
> +   if (len > 0
> +   && (phynode = OF_node_from_xref(cells[0])) != -1 &&
> +   ofw_bus_node_is_compatible(phynode, "fsl,imx6ul-usbphy")) 
> {
> +   u_long base, size;
> +   if (fdt_regsize(phynode, , ) == 0) {
> +   sc->phy_regs = (void*)base;
> +   esc->sc_vendor_get_port_speed =
> +   imx_ehci_get_port_speed_portsc;
> +   }
> +   }
> +   OF_prop_free(cells);
> +   }
> +#endif /* __rtems__ */
>
> err = ehci_init(esc);
> if (err != 0) {
> --
> 2.16.4
>
> ___
> 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 libbsd 09/11] ehci_imx.c: Port to RTEMS

2020-04-02 Thread Sebastian Huber


On 02/04/2020 16:42, Christian Mauderer wrote:


diff --git a/freebsd/sys/dev/usb/usb_busdma.c b/freebsd/sys/dev/usb/usb_busdma.c
index 9a70c687..c8000170 100644
--- a/freebsd/sys/dev/usb/usb_busdma.c
+++ b/freebsd/sys/dev/usb/usb_busdma.c
@@ -78,6 +78,52 @@ static void  usb_pc_common_mem_cb(void *, bus_dma_segment_t 
*, int, int,
uint8_t);
  #endif
  
+#ifdef __rtems__

+#include 
+#if defined(LIBBSP_ARM_IMX_BSP_H)
+#define NEED_MISSALIGNED_COPY
+#endif


Could you please move changes in general file imported from FreeBSD to 
separate commits.


I don't like this change here at all. I had a similar issue with 
misaligned memcpy() to device memory here on the STM32H7 platform. Could 
you first try this patch here:


diff --git a/freebsd/sys/dev/usb/usb_busdma.c 
b/freebsd/sys/dev/usb/usb_busdma.c

index 9a70c687..973a3409 100644
--- a/freebsd/sys/dev/usb/usb_busdma.c
+++ b/freebsd/sys/dev/usb/usb_busdma.c
@@ -584,7 +584,7 @@ usb_pc_alloc_mem(struct usb_page_cache *pc, struct 
usb_page *pg,

    }
    /* allocate memory */
    if (bus_dmamem_alloc(
-   utag->tag, , (BUS_DMA_WAITOK | BUS_DMA_COHERENT), )) {
+   utag->tag, , BUS_DMA_WAITOK, )) {
    goto error;
    }
    /* setup page cache */

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

[PATCH rtems-docs v2] user/imx: Add i.MX6UL/ULL.

2020-04-02 Thread Christian Mauderer

Update #3869
---
 user/bsps/arm/imx.rst | 47 ---
 1 file changed, 44 insertions(+), 3 deletions(-)

diff --git a/user/bsps/arm/imx.rst b/user/bsps/arm/imx.rst
index bc93ae3..ee98f0b 100644
--- a/user/bsps/arm/imx.rst
+++ b/user/bsps/arm/imx.rst
@@ -7,9 +7,10 @@ imx (NXP i.MX)
 ==
 
 This BSP offers only one variant, the `imx7`.  This variant supports the i.MX
-7Dual processor.  The basic hardware initialization is not performed by the
-BSP.  A boot loader with device tree support must be used to start the BSP,
-e.g. U-Boot.
+7Dual processor and the i.MX 6UL/ULL processor family (with slightly different
+clock settings).  The basic hardware initialization is not performed by the 
BSP.
+A boot loader with device tree support must be used to start the BSP, e.g.
+U-Boot or barebox.
 
 Build Configuration Options
 ---
@@ -40,9 +41,30 @@ The following options are available at the configure command 
line.
 ``IMX_CCM_UART_HZ``
The UART clock frequency in Hz (default is 2400).
 
+``IMX_CCM_ECSPI_HZ``
+   The ECSPI clock frequency in Hz (default is 6750).
+
 ``IMX_CCM_AHB_HZ``
The AHB clock frequency in Hz (default is 13500).
 
+``IMX_CCM_SDHCI_HZ``
+   The SDHCI clock frequency in Hz (default is 196363000).
+
+Clock settings for different boards
+---
+
+The default clock settings are targeted for an i.MX 7Dual evaluation board 
using
+U-Boot. Some other boards with different boot loaders need different settings:
+
+ * Phytec phyCORE-i.MX 6ULL (system on module) with MCIMX6Y2CVM08AB and a
+   barebox bootloader (version ``2019.01.0-bsp-yocto-i.mx6ul-pd19.1.0``):
+
+   * IMX_CCM_IPG_HZ=6600
+   * IMX_CCM_UART_HZ=8000
+   * IMX_CCM_AHB_HZ=6600
+   * IMX_CCM_SDHCI_HZ=19800
+   * IMX_CCM_ECSPI_HZ=6000
+
 Boot via U-Boot
 ---
 
@@ -65,6 +87,14 @@ The ``loadfdt`` command may be not defined in your U-Boot 
environment.  Just
 replace it with the appropriate commands to load the device tree at
 ``${fdt_addr}``.
 
+Boot via barebox
+
+
+The same command like for U-Boot can be used to generate an application image.
+In a default configuration barebox expects an fdt image called `oftree` and a
+kernel image called `zImage` in the root folder of the bootable medium (e.g. an
+SD card).
+
 Clock Driver
 
 
@@ -133,6 +163,17 @@ system controls:
 A value of zero for the time or count disables the interrupt coalescing in the
 corresponding direction.
 
+On the Phytec phyCORE-i.MX 6ULL modules the PHY needs an initialization for the
+clock. A special PHY driver handles that (``ksz8091rnb``). Add it to your 
libbsd
+config like that:
+
+.. code-block:: c
+
+#define RTEMS_BSD_CONFIG_BSP_CONFIG
+#define RTEMS_BSD_CONFIG_INIT
+SYSINIT_DRIVER_REFERENCE(ksz8091rnb, miibus);
+#include 
+
 MMC/SDCard Driver
 -
 
-- 
2.16.4

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

Re: [PATCH libbsd 09/11] ehci_imx.c: Port to RTEMS

2020-04-02 Thread Sebastian Huber


On 02/04/2020 16:47, Christian Mauderer wrote:


Hello,

just noted: This patch now contains more from my code than from
Sebastian. I'll discuss with him whether we change the author before
commiting it.

Just change the author if it makes sense.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs] user/imx: Add i.MX6UL/ULL.

2020-04-02 Thread Christian Mauderer

On 02/04/2020 16:53, Gedare Bloom wrote:
> PS: how do you get the repo inlined to the [PATCH xxx] subject line? It's 
> handy.

git format patch supports to set the prefix with:

 git format-patch HEAD^ --subject-prefix="PATCH rtems-docs"

I haven't found a good method yet to set it automatically to the repo
name. But With the growing number of repositories in RTEMS I try to add
the prefixes when not comiting to the core.

> 
> On Thu, Apr 2, 2020 at 8:51 AM Gedare Bloom  wrote:
>>
>> On Thu, Apr 2, 2020 at 8:43 AM Christian Mauderer
>>  wrote:
>>>
>>> Update #3869
>>> ---
>>>  user/bsps/arm/imx.rst | 49 
>>> ++---
>>>  1 file changed, 46 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/user/bsps/arm/imx.rst b/user/bsps/arm/imx.rst
>>> index bc93ae3..51c3b7e 100644
>>> --- a/user/bsps/arm/imx.rst
>>> +++ b/user/bsps/arm/imx.rst
>>> @@ -7,9 +7,10 @@ imx (NXP i.MX)
>>>  ==
>>>
>>>  This BSP offers only one variant, the `imx7`.  This variant supports the 
>>> i.MX
>>> -7Dual processor.  The basic hardware initialization is not performed by the
>>> -BSP.  A boot loader with device tree support must be used to start the BSP,
>>> -e.g. U-Boot.
>>> +7Dual processor and the i.MX 6UL/ULL processor family (with slightly 
>>> different
>>> +clock settings).  The basic hardware initialization is not performed by 
>>> the BSP.
>>> +A boot loader with device tree support must be used to start the BSP, e.g.
>>> +U-Boot or barebox.
>>>
>>>  Build Configuration Options
>>>  ---
>>> @@ -40,9 +41,30 @@ The following options are available at the configure 
>>> command line.
>>>  ``IMX_CCM_UART_HZ``
>>> The UART clock frequency in Hz (default is 2400).
>>>
>>> +``IMX_CCM_ECSPI_HZ``
>>> +   The ECSPI clock frequency in Hz (default is 6750).
>>> +
>>>  ``IMX_CCM_AHB_HZ``
>>> The AHB clock frequency in Hz (default is 13500).
>>>
>>> +``IMX_CCM_SDHCI_HZ``
>>> +   The SDHCI clock frequency in Hz (default is 196363000).
>>> +
>>> +Clock settings for different boards
>>> +---
>>> +
>>> +The default clock settings are targeted for an i.MX 7Dual evaluation board 
>>> using
>>> +U-Boot. Some other boards with different boot loaders need different 
>>> settings:
>>> +
>>> + * Phytec phyCORE-i.MX 6ULL (system on module) with MCIMX6Y2CVM08AB and a
>>> +   barebox bootloader (version ``2019.01.0-bsp-yocto-i.mx6ul-pd19.1.0``):
>>> +
>>> +   * IMX_CCM_IPG_HZ=6600
>>> +   * IMX_CCM_UART_HZ=8000
>>> +   * IMX_CCM_AHB_HZ=6600
>>> +   * IMX_CCM_SDHCI_HZ=19800
>>> +   * IMX_CCM_ECSPI_HZ=6000
>>> +
>>>  Boot via U-Boot
>>>  ---
>>>
>>> @@ -65,6 +87,14 @@ The ``loadfdt`` command may be not defined in your 
>>> U-Boot environment.  Just
>>>  replace it with the appropriate commands to load the device tree at
>>>  ``${fdt_addr}``.
>>>
>>> +Boot via barebox
>>> +
>>> +
>>> +The same command like for U-Boot can be used to generate an application 
>>> image.
>>> +In a default configuration barebox expects an fdt image called `oftree` 
>>> and a
>>> +kernel image called `zImage` in the root folder of the bootable medium 
>>> (e.g. an
>>> +SD card).
>>> +
>>>  Clock Driver
>>>  
>>>
>>> @@ -133,6 +163,18 @@ system controls:
>>>  A value of zero for the time or count disables the interrupt coalescing in 
>>> the
>>>  corresponding direction.
>>>
>>> +On the Phytec phyCORE-i.MX 6ULL modules the PHY needs an initialization 
>>> for the
>>> +clock. A special PHY driver handles that (``ksz8091rnb``). Add it to your 
>>> libbsd
>>> +config like that:
>>> +
>>> +.. code-block:: c
>>> +
>>> +#define RTEMS_BSD_CONFIG_BSP_CONFIG
>>> +#define RTEMS_BSD_CONFIG_INIT
>>> +SYSINIT_DRIVER_REFERENCE(ksz8091rnb, miibus);
>>> +#include 
>>> +
>>> +
>> Is the extra space needed here?
>>
>>>  MMC/SDCard Driver
>>>  -
>>>
>>> @@ -147,3 +189,4 @@ Caveats
>>>  The clock and pin configuration support is quite rudimentary and mostly 
>>> relies
>>>  on the boot loader.  For a pin group configuration see
>>>  ``imx_iomux_configure_pins()``.  There is no power management support.
>>> +
>>
>> Many docs end without the blank line. It does cause git to complain.
>> I'm not sure if we have any rule about it for writing docs.
>>
>>> --
>>> 2.16.4
>>>
>>> ___
>>> 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

Re: [PATCH rtems-docs] user/imx: Add i.MX6UL/ULL.

2020-04-02 Thread Gedare Bloom

PS: how do you get the repo inlined to the [PATCH xxx] subject line? It's handy.

On Thu, Apr 2, 2020 at 8:51 AM Gedare Bloom  wrote:
>
> On Thu, Apr 2, 2020 at 8:43 AM Christian Mauderer
>  wrote:
> >
> > Update #3869
> > ---
> >  user/bsps/arm/imx.rst | 49 
> > ++---
> >  1 file changed, 46 insertions(+), 3 deletions(-)
> >
> > diff --git a/user/bsps/arm/imx.rst b/user/bsps/arm/imx.rst
> > index bc93ae3..51c3b7e 100644
> > --- a/user/bsps/arm/imx.rst
> > +++ b/user/bsps/arm/imx.rst
> > @@ -7,9 +7,10 @@ imx (NXP i.MX)
> >  ==
> >
> >  This BSP offers only one variant, the `imx7`.  This variant supports the 
> > i.MX
> > -7Dual processor.  The basic hardware initialization is not performed by the
> > -BSP.  A boot loader with device tree support must be used to start the BSP,
> > -e.g. U-Boot.
> > +7Dual processor and the i.MX 6UL/ULL processor family (with slightly 
> > different
> > +clock settings).  The basic hardware initialization is not performed by 
> > the BSP.
> > +A boot loader with device tree support must be used to start the BSP, e.g.
> > +U-Boot or barebox.
> >
> >  Build Configuration Options
> >  ---
> > @@ -40,9 +41,30 @@ The following options are available at the configure 
> > command line.
> >  ``IMX_CCM_UART_HZ``
> > The UART clock frequency in Hz (default is 2400).
> >
> > +``IMX_CCM_ECSPI_HZ``
> > +   The ECSPI clock frequency in Hz (default is 6750).
> > +
> >  ``IMX_CCM_AHB_HZ``
> > The AHB clock frequency in Hz (default is 13500).
> >
> > +``IMX_CCM_SDHCI_HZ``
> > +   The SDHCI clock frequency in Hz (default is 196363000).
> > +
> > +Clock settings for different boards
> > +---
> > +
> > +The default clock settings are targeted for an i.MX 7Dual evaluation board 
> > using
> > +U-Boot. Some other boards with different boot loaders need different 
> > settings:
> > +
> > + * Phytec phyCORE-i.MX 6ULL (system on module) with MCIMX6Y2CVM08AB and a
> > +   barebox bootloader (version ``2019.01.0-bsp-yocto-i.mx6ul-pd19.1.0``):
> > +
> > +   * IMX_CCM_IPG_HZ=6600
> > +   * IMX_CCM_UART_HZ=8000
> > +   * IMX_CCM_AHB_HZ=6600
> > +   * IMX_CCM_SDHCI_HZ=19800
> > +   * IMX_CCM_ECSPI_HZ=6000
> > +
> >  Boot via U-Boot
> >  ---
> >
> > @@ -65,6 +87,14 @@ The ``loadfdt`` command may be not defined in your 
> > U-Boot environment.  Just
> >  replace it with the appropriate commands to load the device tree at
> >  ``${fdt_addr}``.
> >
> > +Boot via barebox
> > +
> > +
> > +The same command like for U-Boot can be used to generate an application 
> > image.
> > +In a default configuration barebox expects an fdt image called `oftree` 
> > and a
> > +kernel image called `zImage` in the root folder of the bootable medium 
> > (e.g. an
> > +SD card).
> > +
> >  Clock Driver
> >  
> >
> > @@ -133,6 +163,18 @@ system controls:
> >  A value of zero for the time or count disables the interrupt coalescing in 
> > the
> >  corresponding direction.
> >
> > +On the Phytec phyCORE-i.MX 6ULL modules the PHY needs an initialization 
> > for the
> > +clock. A special PHY driver handles that (``ksz8091rnb``). Add it to your 
> > libbsd
> > +config like that:
> > +
> > +.. code-block:: c
> > +
> > +#define RTEMS_BSD_CONFIG_BSP_CONFIG
> > +#define RTEMS_BSD_CONFIG_INIT
> > +SYSINIT_DRIVER_REFERENCE(ksz8091rnb, miibus);
> > +#include 
> > +
> > +
> Is the extra space needed here?
>
> >  MMC/SDCard Driver
> >  -
> >
> > @@ -147,3 +189,4 @@ Caveats
> >  The clock and pin configuration support is quite rudimentary and mostly 
> > relies
> >  on the boot loader.  For a pin group configuration see
> >  ``imx_iomux_configure_pins()``.  There is no power management support.
> > +
>
> Many docs end without the blank line. It does cause git to complain.
> I'm not sure if we have any rule about it for writing docs.
>
> > --
> > 2.16.4
> >
> > ___
> > 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 rtems-docs] user/imx: Add i.MX6UL/ULL.

2020-04-02 Thread Christian Mauderer

On 02/04/2020 16:51, Gedare Bloom wrote:
> On Thu, Apr 2, 2020 at 8:43 AM Christian Mauderer
>  wrote:
>>
>> Update #3869
>> ---
>>  user/bsps/arm/imx.rst | 49 ++---
>>  1 file changed, 46 insertions(+), 3 deletions(-)
>>
>> diff --git a/user/bsps/arm/imx.rst b/user/bsps/arm/imx.rst
>> index bc93ae3..51c3b7e 100644
>> --- a/user/bsps/arm/imx.rst
>> +++ b/user/bsps/arm/imx.rst
>> @@ -7,9 +7,10 @@ imx (NXP i.MX)
>>  ==
>>
>>  This BSP offers only one variant, the `imx7`.  This variant supports the 
>> i.MX
>> -7Dual processor.  The basic hardware initialization is not performed by the
>> -BSP.  A boot loader with device tree support must be used to start the BSP,
>> -e.g. U-Boot.
>> +7Dual processor and the i.MX 6UL/ULL processor family (with slightly 
>> different
>> +clock settings).  The basic hardware initialization is not performed by the 
>> BSP.
>> +A boot loader with device tree support must be used to start the BSP, e.g.
>> +U-Boot or barebox.
>>
>>  Build Configuration Options
>>  ---
>> @@ -40,9 +41,30 @@ The following options are available at the configure 
>> command line.
>>  ``IMX_CCM_UART_HZ``
>> The UART clock frequency in Hz (default is 2400).
>>
>> +``IMX_CCM_ECSPI_HZ``
>> +   The ECSPI clock frequency in Hz (default is 6750).
>> +
>>  ``IMX_CCM_AHB_HZ``
>> The AHB clock frequency in Hz (default is 13500).
>>
>> +``IMX_CCM_SDHCI_HZ``
>> +   The SDHCI clock frequency in Hz (default is 196363000).
>> +
>> +Clock settings for different boards
>> +---
>> +
>> +The default clock settings are targeted for an i.MX 7Dual evaluation board 
>> using
>> +U-Boot. Some other boards with different boot loaders need different 
>> settings:
>> +
>> + * Phytec phyCORE-i.MX 6ULL (system on module) with MCIMX6Y2CVM08AB and a
>> +   barebox bootloader (version ``2019.01.0-bsp-yocto-i.mx6ul-pd19.1.0``):
>> +
>> +   * IMX_CCM_IPG_HZ=6600
>> +   * IMX_CCM_UART_HZ=8000
>> +   * IMX_CCM_AHB_HZ=6600
>> +   * IMX_CCM_SDHCI_HZ=19800
>> +   * IMX_CCM_ECSPI_HZ=6000
>> +
>>  Boot via U-Boot
>>  ---
>>
>> @@ -65,6 +87,14 @@ The ``loadfdt`` command may be not defined in your U-Boot 
>> environment.  Just
>>  replace it with the appropriate commands to load the device tree at
>>  ``${fdt_addr}``.
>>
>> +Boot via barebox
>> +
>> +
>> +The same command like for U-Boot can be used to generate an application 
>> image.
>> +In a default configuration barebox expects an fdt image called `oftree` and 
>> a
>> +kernel image called `zImage` in the root folder of the bootable medium 
>> (e.g. an
>> +SD card).
>> +
>>  Clock Driver
>>  
>>
>> @@ -133,6 +163,18 @@ system controls:
>>  A value of zero for the time or count disables the interrupt coalescing in 
>> the
>>  corresponding direction.
>>
>> +On the Phytec phyCORE-i.MX 6ULL modules the PHY needs an initialization for 
>> the
>> +clock. A special PHY driver handles that (``ksz8091rnb``). Add it to your 
>> libbsd
>> +config like that:
>> +
>> +.. code-block:: c
>> +
>> +#define RTEMS_BSD_CONFIG_BSP_CONFIG
>> +#define RTEMS_BSD_CONFIG_INIT
>> +SYSINIT_DRIVER_REFERENCE(ksz8091rnb, miibus);
>> +#include 
>> +
>> +
> Is the extra space needed here?
> 

No, sorry. That was an accident.

>>  MMC/SDCard Driver
>>  -
>>
>> @@ -147,3 +189,4 @@ Caveats
>>  The clock and pin configuration support is quite rudimentary and mostly 
>> relies
>>  on the boot loader.  For a pin group configuration see
>>  ``imx_iomux_configure_pins()``.  There is no power management support.
>> +
> 
> Many docs end without the blank line. It does cause git to complain.
> I'm not sure if we have any rule about it for writing docs.
> 

Hm. That line shouldn't even be there. I don't wanted to add a blank
line at the end. I'll remove it again.

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

Re: [PATCH rtems-docs] user/imx: Add i.MX6UL/ULL.

2020-04-02 Thread Gedare Bloom

On Thu, Apr 2, 2020 at 8:43 AM Christian Mauderer
 wrote:
>
> Update #3869
> ---
>  user/bsps/arm/imx.rst | 49 ++---
>  1 file changed, 46 insertions(+), 3 deletions(-)
>
> diff --git a/user/bsps/arm/imx.rst b/user/bsps/arm/imx.rst
> index bc93ae3..51c3b7e 100644
> --- a/user/bsps/arm/imx.rst
> +++ b/user/bsps/arm/imx.rst
> @@ -7,9 +7,10 @@ imx (NXP i.MX)
>  ==
>
>  This BSP offers only one variant, the `imx7`.  This variant supports the i.MX
> -7Dual processor.  The basic hardware initialization is not performed by the
> -BSP.  A boot loader with device tree support must be used to start the BSP,
> -e.g. U-Boot.
> +7Dual processor and the i.MX 6UL/ULL processor family (with slightly 
> different
> +clock settings).  The basic hardware initialization is not performed by the 
> BSP.
> +A boot loader with device tree support must be used to start the BSP, e.g.
> +U-Boot or barebox.
>
>  Build Configuration Options
>  ---
> @@ -40,9 +41,30 @@ The following options are available at the configure 
> command line.
>  ``IMX_CCM_UART_HZ``
> The UART clock frequency in Hz (default is 2400).
>
> +``IMX_CCM_ECSPI_HZ``
> +   The ECSPI clock frequency in Hz (default is 6750).
> +
>  ``IMX_CCM_AHB_HZ``
> The AHB clock frequency in Hz (default is 13500).
>
> +``IMX_CCM_SDHCI_HZ``
> +   The SDHCI clock frequency in Hz (default is 196363000).
> +
> +Clock settings for different boards
> +---
> +
> +The default clock settings are targeted for an i.MX 7Dual evaluation board 
> using
> +U-Boot. Some other boards with different boot loaders need different 
> settings:
> +
> + * Phytec phyCORE-i.MX 6ULL (system on module) with MCIMX6Y2CVM08AB and a
> +   barebox bootloader (version ``2019.01.0-bsp-yocto-i.mx6ul-pd19.1.0``):
> +
> +   * IMX_CCM_IPG_HZ=6600
> +   * IMX_CCM_UART_HZ=8000
> +   * IMX_CCM_AHB_HZ=6600
> +   * IMX_CCM_SDHCI_HZ=19800
> +   * IMX_CCM_ECSPI_HZ=6000
> +
>  Boot via U-Boot
>  ---
>
> @@ -65,6 +87,14 @@ The ``loadfdt`` command may be not defined in your U-Boot 
> environment.  Just
>  replace it with the appropriate commands to load the device tree at
>  ``${fdt_addr}``.
>
> +Boot via barebox
> +
> +
> +The same command like for U-Boot can be used to generate an application 
> image.
> +In a default configuration barebox expects an fdt image called `oftree` and a
> +kernel image called `zImage` in the root folder of the bootable medium (e.g. 
> an
> +SD card).
> +
>  Clock Driver
>  
>
> @@ -133,6 +163,18 @@ system controls:
>  A value of zero for the time or count disables the interrupt coalescing in 
> the
>  corresponding direction.
>
> +On the Phytec phyCORE-i.MX 6ULL modules the PHY needs an initialization for 
> the
> +clock. A special PHY driver handles that (``ksz8091rnb``). Add it to your 
> libbsd
> +config like that:
> +
> +.. code-block:: c
> +
> +#define RTEMS_BSD_CONFIG_BSP_CONFIG
> +#define RTEMS_BSD_CONFIG_INIT
> +SYSINIT_DRIVER_REFERENCE(ksz8091rnb, miibus);
> +#include 
> +
> +
Is the extra space needed here?

>  MMC/SDCard Driver
>  -
>
> @@ -147,3 +189,4 @@ Caveats
>  The clock and pin configuration support is quite rudimentary and mostly 
> relies
>  on the boot loader.  For a pin group configuration see
>  ``imx_iomux_configure_pins()``.  There is no power management support.
> +

Many docs end without the blank line. It does cause git to complain.
I'm not sure if we have any rule about it for writing docs.

> --
> 2.16.4
>
> ___
> 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: [PATCHES] Add more i.MX6UL/ULL support

2020-04-02 Thread Christian Mauderer

Hello,

just noted another bug that happened during rebase: Not all steps in
libbsd are compileable. Please see the libbsd stuff as a draft version.
The content won't change but the order of the patches has to.

Best regards

Christian

On 02/04/2020 16:41, Christian Mauderer wrote:
> Hello,
> 
> this set of patches for RTEMS, libbsd and docs extend the i.MX6UL/ULL
> support.
> 
> 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

Re: [PATCH] bsp/imx: Add an extra ecspi clock.

2020-04-02 Thread Gedare Bloom

Looks good to me

On Thu, Apr 2, 2020 at 8:42 AM Christian Mauderer
 wrote:
>
> Some imx chips or boards don't use the same frequency for ECSPI and IPG.
>
> Update #3869
> ---
>  bsps/arm/imx/include/arm/freescale/imx/imx_ccmvar.h | 3 +++
>  bsps/arm/imx/spi/imx-ecspi.c| 2 +-
>  bsps/arm/imx/start/ccm.c| 5 +
>  c/src/lib/libbsp/arm/imx/configure.ac   | 3 +++
>  4 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/bsps/arm/imx/include/arm/freescale/imx/imx_ccmvar.h 
> b/bsps/arm/imx/include/arm/freescale/imx/imx_ccmvar.h
> index 5633de6f50..0f19d80813 100644
> --- a/bsps/arm/imx/include/arm/freescale/imx/imx_ccmvar.h
> +++ b/bsps/arm/imx/include/arm/freescale/imx/imx_ccmvar.h
> @@ -48,6 +48,9 @@ uint32_t imx_ccm_perclk_hz(void);
>  uint32_t imx_ccm_sdhci_hz(void);
>  uint32_t imx_ccm_uart_hz(void);
>  uint32_t imx_ccm_ahb_hz(void);
> +#ifdef __rtems__
> +uint32_t imx_ccm_ecspi_hz(void);
> +#endif /* __rtems__ */
>
>  #ifndef __rtems__
>  void imx_ccm_usb_enable(device_t _usbdev);
> diff --git a/bsps/arm/imx/spi/imx-ecspi.c b/bsps/arm/imx/spi/imx-ecspi.c
> index 4c4978cdac..a18047f2e0 100644
> --- a/bsps/arm/imx/spi/imx-ecspi.c
> +++ b/bsps/arm/imx/spi/imx-ecspi.c
> @@ -435,7 +435,7 @@ int spi_bus_register_imx(const char *bus_path, const char 
> *alias_or_path)
>  return -1;
>}
>
> -  bus->base.max_speed_hz = imx_ccm_ipg_hz();
> +  bus->base.max_speed_hz = imx_ccm_ecspi_hz();
>bus->base.delay_usecs = 1;
>bus->regs = imx_get_reg_of_node(fdt, node);
>bus->irq = imx_get_irq_of_node(fdt, node, 0);
> diff --git a/bsps/arm/imx/start/ccm.c b/bsps/arm/imx/start/ccm.c
> index cc93dcbd5d..3487470357 100644
> --- a/bsps/arm/imx/start/ccm.c
> +++ b/bsps/arm/imx/start/ccm.c
> @@ -27,6 +27,11 @@ uint32_t imx_ccm_uart_hz(void)
>return IMX_CCM_UART_HZ;
>  }
>
> +uint32_t imx_ccm_ecspi_hz(void)
> +{
> +  return IMX_CCM_ECSPI_HZ;
> +}
> +
>  uint32_t imx_ccm_ahb_hz(void)
>  {
>return IMX_CCM_AHB_HZ;
> diff --git a/c/src/lib/libbsp/arm/imx/configure.ac 
> b/c/src/lib/libbsp/arm/imx/configure.ac
> index aa119b9236..fbb9d9278a 100644
> --- a/c/src/lib/libbsp/arm/imx/configure.ac
> +++ b/c/src/lib/libbsp/arm/imx/configure.ac
> @@ -43,6 +43,9 @@ RTEMS_BSPOPTS_HELP([IMX_CCM_IPG_HZ],[IPG clock frequency in 
> Hz])
>  RTEMS_BSPOPTS_SET([IMX_CCM_UART_HZ],[*],[2400])
>  RTEMS_BSPOPTS_HELP([IMX_CCM_UART_HZ],[UART clock frequency in Hz])
>
> +RTEMS_BSPOPTS_SET([IMX_CCM_ECSPI_HZ],[*],[6750])
> +RTEMS_BSPOPTS_HELP([IMX_CCM_ECSPI_HZ],[ECSPI clock frequency in Hz])
> +
>  RTEMS_BSPOPTS_SET([IMX_CCM_AHB_HZ],[*],[13500])
>  RTEMS_BSPOPTS_HELP([IMX_CCM_AHB_HZ],[AHB clock frequency in Hz])
>
> --
> 2.16.4
>
> ___
> 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] bsps/console: Support device file system

2020-04-02 Thread Sebastian Huber


On 02/04/2020 16:45, Gedare Bloom wrote:


Can we hold this until 6?
Joel complained that the CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM is 
broken. For me it is not important.

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

Re: [PATCH libbsd 09/11] ehci_imx.c: Port to RTEMS

2020-04-02 Thread Christian Mauderer

Hello,

just noted: This patch now contains more from my code than from
Sebastian. I'll discuss with him whether we change the author before
commiting it.

Best regards

Christian

On 02/04/2020 16:42, Christian Mauderer wrote:
> From: Sebastian Huber 
> 
> Update #3869.
> ---
>  freebsd/sys/arm/freescale/imx/imx6_usbphy.c | 11 ++
>  freebsd/sys/dev/usb/controller/ehci_imx.c   | 12 +++
>  freebsd/sys/dev/usb/usb_busdma.c| 54 
> +
>  libbsd.py   |  4 +++
>  rtemsbsd/include/bsp/nexus-devices.h|  5 +++
>  5 files changed, 86 insertions(+)
> 
> diff --git a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c 
> b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
> index 8f47507b..ad545601 100644
> --- a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
> +++ b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
> @@ -91,6 +91,17 @@ usbphy_detach(device_t dev)
>   return (0);
>  }
>  
> +#ifdef __rtems__
> +#define BUS_SPACE_PHYSADDR(res, offs) \
> + ((u_int)(rman_get_start(res)+(offs)))
> +
> +void
> +imx6_anatop_write_4(bus_size_t offset, uint32_t value)
> +{
> +
> + bus_space_write_4(0, 0x20c8000, offset, value);
> +}
> +#endif /* __rtems__ */
>  static int
>  usbphy_attach(device_t dev)
>  {
> diff --git a/freebsd/sys/dev/usb/controller/ehci_imx.c 
> b/freebsd/sys/dev/usb/controller/ehci_imx.c
> index a872fb62..d158df1d 100644
> --- a/freebsd/sys/dev/usb/controller/ehci_imx.c
> +++ b/freebsd/sys/dev/usb/controller/ehci_imx.c
> @@ -303,6 +303,16 @@ imx_ehci_probe(device_t dev)
>   return (ENXIO);
>  
>   if (ofw_bus_search_compatible(dev, compat_data)->ocd_data != 0) {
> +#ifdef __rtems__
> + char dr_mode[24];
> +
> + if (OF_getprop(ofw_bus_get_node(dev), "dr_mode",
> + _mode, sizeof(dr_mode)) > 0 &&
> + strcasecmp(dr_mode, "host") != 0) {
> + return (ENXIO);
> + }
> +#endif /* __rtems__ */
> +
>   device_set_desc(dev, "Freescale i.MX integrated USB 
> controller");
>   return (BUS_PROBE_DEFAULT);
>   }
> @@ -437,8 +447,10 @@ imx_ehci_attach(device_t dev)
>   goto out;
>   }
>  
> +#ifndef __rtems__
>   /* Turn on clocks. */
>   imx_ccm_usb_enable(dev);
> +#endif /* __rtems__ */
>  
>   /* Disable overcurrent detection, if configured to do so. */
>   if (OF_hasprop(ofw_bus_get_node(sc->dev), "disable-over-current"))
> diff --git a/freebsd/sys/dev/usb/usb_busdma.c 
> b/freebsd/sys/dev/usb/usb_busdma.c
> index 9a70c687..c8000170 100644
> --- a/freebsd/sys/dev/usb/usb_busdma.c
> +++ b/freebsd/sys/dev/usb/usb_busdma.c
> @@ -78,6 +78,52 @@ static voidusb_pc_common_mem_cb(void *, 
> bus_dma_segment_t *, int, int,
>   uint8_t);
>  #endif
>  
> +#ifdef __rtems__
> +#include 
> +#if defined(LIBBSP_ARM_IMX_BSP_H)
> +#define NEED_MISSALIGNED_COPY
> +#endif
> +
> +#ifdef NEED_MISSALIGNED_COPY
> +/*
> + * Note: This functions are used instead of memcpy for regions where a
> + * misaligned access is not allowed (e.g. peripheral memory).
> + */
> +static void misaligned_do_copy(
> +  uint8_t *dst,
> +  const uint8_t *src,
> +  size_t n,
> +  bool aligned
> +)
> +{
> +  if (aligned) {
> +while (n > 3) {
> +  *(uint32_t *)dst = *(uint32_t *)src;
> +  dst += 4;
> +  src += 4;
> +  n -= 4;
> +}
> +  }
> +
> +  while (n > 0) {
> +*dst = *src;
> +++dst;
> +++src;
> +--n;
> +  }
> +}
> +
> +void misaligned_copy_to_io(void *dst, const void *src, size_t n)
> +{
> +  misaligned_do_copy(dst, src, n, ((uintptr_t)dst) % 4 == 0);
> +}
> +
> +void misaligned_copy_from_io(void *dst, const void *src, size_t n)
> +{
> +  misaligned_do_copy(dst, src, n, ((uintptr_t)src) % 4 == 0);
> +}
> +#endif
> +#endif /* __rtems__ */
>  /**
>   *  usbd_get_page - lookup DMA-able memory for the given offset
>   *
> @@ -182,7 +228,11 @@ usbd_copy_in(struct usb_page_cache *cache, 
> usb_frlength_t offset,
>   if (buf_res.length > len) {
>   buf_res.length = len;
>   }
> +#if defined(__rtems__) && defined(NEED_MISSALIGNED_COPY)
> + misaligned_copy_to_io(buf_res.buffer, ptr, buf_res.length);
> +#else /* __rtems__ */
>   memcpy(buf_res.buffer, ptr, buf_res.length);
> +#endif /* __rtems__ */
>  
>   offset += buf_res.length;
>   len -= buf_res.length;
> @@ -302,7 +352,11 @@ usbd_copy_out(struct usb_page_cache *cache, 
> usb_frlength_t offset,
>   if (res.length > len) {
>   res.length = len;
>   }
> +#if defined(__rtems__) && defined(NEED_MISSALIGNED_COPY)
> + misaligned_copy_from_io(ptr, res.buffer, res.length);
> +#else /* __rtems__ */
>   memcpy(ptr, res.buffer, res.length);
> +#endif /* __rtems__ */
>  
>   offset +=

Re: [PATCH] bsps/console: Support device file system

2020-04-02 Thread Gedare Bloom

On Thu, Apr 2, 2020 at 8:45 AM Gedare Bloom  wrote:
>
> Can we hold this until 6?
>
Trying to avoid anything that might break random BSPs in subtle ways.

> On Thu, Apr 2, 2020 at 4:02 AM Sebastian Huber
>  wrote:
> >
> > Update #3926.
> > ---
> >  bsps/include/bsp/fatal.h  |  2 --
> >  bsps/shared/dev/serial/console-termios-init.c | 28 
> > +++
> >  2 files changed, 16 insertions(+), 14 deletions(-)
> >
> > diff --git a/bsps/include/bsp/fatal.h b/bsps/include/bsp/fatal.h
> > index 3f8e1eb591..cd3c42aec0 100644
> > --- a/bsps/include/bsp/fatal.h
> > +++ b/bsps/include/bsp/fatal.h
> > @@ -38,8 +38,6 @@ typedef enum {
> >BSP_FATAL_CONSOLE_REGISTER_DEV_0,
> >BSP_FATAL_CONSOLE_REGISTER_DEV_1,
> >BSP_FATAL_CONSOLE_NO_DEV,
> > -  BSP_FATAL_CONSOLE_INSTALL_0,
> > -  BSP_FATAL_CONSOLE_INSTALL_1,
> >BSP_FATAL_CONSOLE_REGISTER_DEV_2,
> >
> >/* ARM fatal codes */
> > diff --git a/bsps/shared/dev/serial/console-termios-init.c 
> > b/bsps/shared/dev/serial/console-termios-init.c
> > index a01a75abf2..87806cc39d 100644
> > --- a/bsps/shared/dev/serial/console-termios-init.c
> > +++ b/bsps/shared/dev/serial/console-termios-init.c
> > @@ -32,31 +32,35 @@ rtems_device_driver console_initialize(
> >void  *arg
> >  )
> >  {
> > -  bool console_device_done = false;
> > +  bool console_device_done;
> >
> >rtems_termios_initialize();
> > +  console_device_done = false;
> >
> >for ( minor = 0; minor < console_device_count; ++minor ) {
> > -const console_device *ctx = _device_table[ minor ];
> > -rtems_status_code sc;
> > +const console_device *ctx;
> > +
> > +ctx = _device_table[ minor ];
> >
> >  if ( ( *ctx->probe )( ctx->context ) ) {
> > -  sc = rtems_termios_device_install(
> > -ctx->device_file,
> > +  const char *device_file;
> > +
> > +  if ( console_device_done ) {
> > +device_file = ctx->device_file;
> > +  } else {
> > +device_file = CONSOLE_DEVICE_NAME;
> > +  }
> > +
> > +  (void) rtems_termios_device_install(
> > +device_file,
> >  ctx->handler,
> >  ctx->flow,
> >  ctx->context
> >);
> > -  if ( sc != RTEMS_SUCCESSFUL ) {
> > -bsp_fatal( BSP_FATAL_CONSOLE_INSTALL_0 );
> > -  }
> >
> >if ( !console_device_done ) {
> >  console_device_done = true;
> > -
> > -if ( link( ctx->device_file, CONSOLE_DEVICE_NAME ) != 0 ) {
> > -  bsp_fatal( BSP_FATAL_CONSOLE_INSTALL_1 );
> > -}
> > +(void) link( CONSOLE_DEVICE_NAME, ctx->device_file );
> >}
> >  }
> >}
> > --
> > 2.16.4
> >
> > ___
> > 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] bsps/arm: Add support for MPU region alignment

2020-04-02 Thread Sebastian Huber


On 02/04/2020 16:44, Gedare Bloom wrote:


On Thu, Apr 2, 2020 at 12:15 AM Sebastian Huber
  wrote:

---
  bsps/arm/shared/start/linkcmds.base | 21 +
  1 file changed, 21 insertions(+)

diff --git a/bsps/arm/shared/start/linkcmds.base 
b/bsps/arm/shared/start/linkcmds.base
index 1f5f1ef959..d0663cf97e 100644
--- a/bsps/arm/shared/start/linkcmds.base
+++ b/bsps/arm/shared/start/linkcmds.base
@@ -81,6 +81,17 @@ SECTIONS {
 } > REGION_TEXT AT > REGION_TEXT_LOAD
 .fini : ALIGN_WITH_INPUT {
 KEEP (*(.fini))
+
+   /*
+* If requested, align the size of the combined start and text
+* section to the next power of two to meet MPU region
+* alignment requirements.
+*/
+   . = DEFINED (bsp_section_do_mpu_align) ?
+   bsp_section_start_begin
+   + ALIGN (. - bsp_section_start_begin,
+   1 << LOG2CEIL (. - bsp_section_start_begin)) : .;

This looks alright. I don't find the symbol bsp_section_do_mpu_align
anywhere though, is it currently unused?

Do you need this in 5.1.0 for something?
This can wait, it is for the new STM32H7 BSP. It could be useful for the 
other ARMv7-M BSPs as well.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/console: Support device file system

2020-04-02 Thread Gedare Bloom

Can we hold this until 6?

On Thu, Apr 2, 2020 at 4:02 AM Sebastian Huber
 wrote:
>
> Update #3926.
> ---
>  bsps/include/bsp/fatal.h  |  2 --
>  bsps/shared/dev/serial/console-termios-init.c | 28 
> +++
>  2 files changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/bsps/include/bsp/fatal.h b/bsps/include/bsp/fatal.h
> index 3f8e1eb591..cd3c42aec0 100644
> --- a/bsps/include/bsp/fatal.h
> +++ b/bsps/include/bsp/fatal.h
> @@ -38,8 +38,6 @@ typedef enum {
>BSP_FATAL_CONSOLE_REGISTER_DEV_0,
>BSP_FATAL_CONSOLE_REGISTER_DEV_1,
>BSP_FATAL_CONSOLE_NO_DEV,
> -  BSP_FATAL_CONSOLE_INSTALL_0,
> -  BSP_FATAL_CONSOLE_INSTALL_1,
>BSP_FATAL_CONSOLE_REGISTER_DEV_2,
>
>/* ARM fatal codes */
> diff --git a/bsps/shared/dev/serial/console-termios-init.c 
> b/bsps/shared/dev/serial/console-termios-init.c
> index a01a75abf2..87806cc39d 100644
> --- a/bsps/shared/dev/serial/console-termios-init.c
> +++ b/bsps/shared/dev/serial/console-termios-init.c
> @@ -32,31 +32,35 @@ rtems_device_driver console_initialize(
>void  *arg
>  )
>  {
> -  bool console_device_done = false;
> +  bool console_device_done;
>
>rtems_termios_initialize();
> +  console_device_done = false;
>
>for ( minor = 0; minor < console_device_count; ++minor ) {
> -const console_device *ctx = _device_table[ minor ];
> -rtems_status_code sc;
> +const console_device *ctx;
> +
> +ctx = _device_table[ minor ];
>
>  if ( ( *ctx->probe )( ctx->context ) ) {
> -  sc = rtems_termios_device_install(
> -ctx->device_file,
> +  const char *device_file;
> +
> +  if ( console_device_done ) {
> +device_file = ctx->device_file;
> +  } else {
> +device_file = CONSOLE_DEVICE_NAME;
> +  }
> +
> +  (void) rtems_termios_device_install(
> +device_file,
>  ctx->handler,
>  ctx->flow,
>  ctx->context
>);
> -  if ( sc != RTEMS_SUCCESSFUL ) {
> -bsp_fatal( BSP_FATAL_CONSOLE_INSTALL_0 );
> -  }
>
>if ( !console_device_done ) {
>  console_device_done = true;
> -
> -if ( link( ctx->device_file, CONSOLE_DEVICE_NAME ) != 0 ) {
> -  bsp_fatal( BSP_FATAL_CONSOLE_INSTALL_1 );
> -}
> +(void) link( CONSOLE_DEVICE_NAME, ctx->device_file );
>}
>  }
>}
> --
> 2.16.4
>
> ___
> 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] bsps/arm: Add support for MPU region alignment

2020-04-02 Thread Gedare Bloom

On Thu, Apr 2, 2020 at 12:15 AM Sebastian Huber
 wrote:
>
> ---
>  bsps/arm/shared/start/linkcmds.base | 21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/bsps/arm/shared/start/linkcmds.base 
> b/bsps/arm/shared/start/linkcmds.base
> index 1f5f1ef959..d0663cf97e 100644
> --- a/bsps/arm/shared/start/linkcmds.base
> +++ b/bsps/arm/shared/start/linkcmds.base
> @@ -81,6 +81,17 @@ SECTIONS {
> } > REGION_TEXT AT > REGION_TEXT_LOAD
> .fini : ALIGN_WITH_INPUT {
> KEEP (*(.fini))
> +
> +   /*
> +* If requested, align the size of the combined start and text
> +* section to the next power of two to meet MPU region
> +* alignment requirements.
> +*/
> +   . = DEFINED (bsp_section_do_mpu_align) ?
> +   bsp_section_start_begin
> +   + ALIGN (. - bsp_section_start_begin,
> +   1 << LOG2CEIL (. - bsp_section_start_begin)) : .;
This looks alright. I don't find the symbol bsp_section_do_mpu_align
anywhere though, is it currently unused?

Do you need this in 5.1.0 for something?


> +
> bsp_section_text_end = .;
> } > REGION_TEXT AT > REGION_TEXT_LOAD
> bsp_section_text_size = bsp_section_text_end - bsp_section_text_begin;
> @@ -248,6 +259,16 @@ SECTIONS {
> *(set_pseudo_*);
>
> KEEP (*(SORT(.rtemsroset.*)))
> +
> +   /*
> +* If requested, align the size of the rodata section to the
> +* next power of two to meet MPU region alignment 
> requirements.
> +*/
> +   . = DEFINED (bsp_section_do_mpu_align) ?
> +   bsp_section_rodata_begin
> +   + ALIGN (. - bsp_section_rodata_begin,
> +   1 << LOG2CEIL (. - bsp_section_rodata_begin)) : .;
> +
> bsp_section_rodata_end = .;
> } > REGION_RODATA AT > REGION_RODATA_LOAD
> bsp_section_rodata_size = bsp_section_rodata_end - 
> bsp_section_rodata_begin;
> --
> 2.16.4
>
> ___
> 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 rtems-docs] user/imx: Add i.MX6UL/ULL.

2020-04-02 Thread Christian Mauderer

Update #3869
---
 user/bsps/arm/imx.rst | 49 ++---
 1 file changed, 46 insertions(+), 3 deletions(-)

diff --git a/user/bsps/arm/imx.rst b/user/bsps/arm/imx.rst
index bc93ae3..51c3b7e 100644
--- a/user/bsps/arm/imx.rst
+++ b/user/bsps/arm/imx.rst
@@ -7,9 +7,10 @@ imx (NXP i.MX)
 ==
 
 This BSP offers only one variant, the `imx7`.  This variant supports the i.MX
-7Dual processor.  The basic hardware initialization is not performed by the
-BSP.  A boot loader with device tree support must be used to start the BSP,
-e.g. U-Boot.
+7Dual processor and the i.MX 6UL/ULL processor family (with slightly different
+clock settings).  The basic hardware initialization is not performed by the 
BSP.
+A boot loader with device tree support must be used to start the BSP, e.g.
+U-Boot or barebox.
 
 Build Configuration Options
 ---
@@ -40,9 +41,30 @@ The following options are available at the configure command 
line.
 ``IMX_CCM_UART_HZ``
The UART clock frequency in Hz (default is 2400).
 
+``IMX_CCM_ECSPI_HZ``
+   The ECSPI clock frequency in Hz (default is 6750).
+
 ``IMX_CCM_AHB_HZ``
The AHB clock frequency in Hz (default is 13500).
 
+``IMX_CCM_SDHCI_HZ``
+   The SDHCI clock frequency in Hz (default is 196363000).
+
+Clock settings for different boards
+---
+
+The default clock settings are targeted for an i.MX 7Dual evaluation board 
using
+U-Boot. Some other boards with different boot loaders need different settings:
+
+ * Phytec phyCORE-i.MX 6ULL (system on module) with MCIMX6Y2CVM08AB and a
+   barebox bootloader (version ``2019.01.0-bsp-yocto-i.mx6ul-pd19.1.0``):
+
+   * IMX_CCM_IPG_HZ=6600
+   * IMX_CCM_UART_HZ=8000
+   * IMX_CCM_AHB_HZ=6600
+   * IMX_CCM_SDHCI_HZ=19800
+   * IMX_CCM_ECSPI_HZ=6000
+
 Boot via U-Boot
 ---
 
@@ -65,6 +87,14 @@ The ``loadfdt`` command may be not defined in your U-Boot 
environment.  Just
 replace it with the appropriate commands to load the device tree at
 ``${fdt_addr}``.
 
+Boot via barebox
+
+
+The same command like for U-Boot can be used to generate an application image.
+In a default configuration barebox expects an fdt image called `oftree` and a
+kernel image called `zImage` in the root folder of the bootable medium (e.g. an
+SD card).
+
 Clock Driver
 
 
@@ -133,6 +163,18 @@ system controls:
 A value of zero for the time or count disables the interrupt coalescing in the
 corresponding direction.
 
+On the Phytec phyCORE-i.MX 6ULL modules the PHY needs an initialization for the
+clock. A special PHY driver handles that (``ksz8091rnb``). Add it to your 
libbsd
+config like that:
+
+.. code-block:: c
+
+#define RTEMS_BSD_CONFIG_BSP_CONFIG
+#define RTEMS_BSD_CONFIG_INIT
+SYSINIT_DRIVER_REFERENCE(ksz8091rnb, miibus);
+#include 
+
+
 MMC/SDCard Driver
 -
 
@@ -147,3 +189,4 @@ Caveats
 The clock and pin configuration support is quite rudimentary and mostly relies
 on the boot loader.  For a pin group configuration see
 ``imx_iomux_configure_pins()``.  There is no power management support.
+
-- 
2.16.4

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

[PATCH libbsd 09/11] ehci_imx.c: Port to RTEMS

2020-04-02 Thread Christian Mauderer

From: Sebastian Huber 

Update #3869.
---
 freebsd/sys/arm/freescale/imx/imx6_usbphy.c | 11 ++
 freebsd/sys/dev/usb/controller/ehci_imx.c   | 12 +++
 freebsd/sys/dev/usb/usb_busdma.c| 54 +
 libbsd.py   |  4 +++
 rtemsbsd/include/bsp/nexus-devices.h|  5 +++
 5 files changed, 86 insertions(+)

diff --git a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c 
b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
index 8f47507b..ad545601 100644
--- a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
+++ b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
@@ -91,6 +91,17 @@ usbphy_detach(device_t dev)
return (0);
 }
 
+#ifdef __rtems__
+#define BUS_SPACE_PHYSADDR(res, offs) \
+   ((u_int)(rman_get_start(res)+(offs)))
+
+void
+imx6_anatop_write_4(bus_size_t offset, uint32_t value)
+{
+
+   bus_space_write_4(0, 0x20c8000, offset, value);
+}
+#endif /* __rtems__ */
 static int
 usbphy_attach(device_t dev)
 {
diff --git a/freebsd/sys/dev/usb/controller/ehci_imx.c 
b/freebsd/sys/dev/usb/controller/ehci_imx.c
index a872fb62..d158df1d 100644
--- a/freebsd/sys/dev/usb/controller/ehci_imx.c
+++ b/freebsd/sys/dev/usb/controller/ehci_imx.c
@@ -303,6 +303,16 @@ imx_ehci_probe(device_t dev)
return (ENXIO);
 
if (ofw_bus_search_compatible(dev, compat_data)->ocd_data != 0) {
+#ifdef __rtems__
+   char dr_mode[24];
+
+   if (OF_getprop(ofw_bus_get_node(dev), "dr_mode",
+   _mode, sizeof(dr_mode)) > 0 &&
+   strcasecmp(dr_mode, "host") != 0) {
+   return (ENXIO);
+   }
+#endif /* __rtems__ */
+
device_set_desc(dev, "Freescale i.MX integrated USB 
controller");
return (BUS_PROBE_DEFAULT);
}
@@ -437,8 +447,10 @@ imx_ehci_attach(device_t dev)
goto out;
}
 
+#ifndef __rtems__
/* Turn on clocks. */
imx_ccm_usb_enable(dev);
+#endif /* __rtems__ */
 
/* Disable overcurrent detection, if configured to do so. */
if (OF_hasprop(ofw_bus_get_node(sc->dev), "disable-over-current"))
diff --git a/freebsd/sys/dev/usb/usb_busdma.c b/freebsd/sys/dev/usb/usb_busdma.c
index 9a70c687..c8000170 100644
--- a/freebsd/sys/dev/usb/usb_busdma.c
+++ b/freebsd/sys/dev/usb/usb_busdma.c
@@ -78,6 +78,52 @@ static void  usb_pc_common_mem_cb(void *, bus_dma_segment_t 
*, int, int,
uint8_t);
 #endif
 
+#ifdef __rtems__
+#include 
+#if defined(LIBBSP_ARM_IMX_BSP_H)
+#define NEED_MISSALIGNED_COPY
+#endif
+
+#ifdef NEED_MISSALIGNED_COPY
+/*
+ * Note: This functions are used instead of memcpy for regions where a
+ * misaligned access is not allowed (e.g. peripheral memory).
+ */
+static void misaligned_do_copy(
+  uint8_t *dst,
+  const uint8_t *src,
+  size_t n,
+  bool aligned
+)
+{
+  if (aligned) {
+while (n > 3) {
+  *(uint32_t *)dst = *(uint32_t *)src;
+  dst += 4;
+  src += 4;
+  n -= 4;
+}
+  }
+
+  while (n > 0) {
+*dst = *src;
+++dst;
+++src;
+--n;
+  }
+}
+
+void misaligned_copy_to_io(void *dst, const void *src, size_t n)
+{
+  misaligned_do_copy(dst, src, n, ((uintptr_t)dst) % 4 == 0);
+}
+
+void misaligned_copy_from_io(void *dst, const void *src, size_t n)
+{
+  misaligned_do_copy(dst, src, n, ((uintptr_t)src) % 4 == 0);
+}
+#endif
+#endif /* __rtems__ */
 /**
  *  usbd_get_page - lookup DMA-able memory for the given offset
  *
@@ -182,7 +228,11 @@ usbd_copy_in(struct usb_page_cache *cache, usb_frlength_t 
offset,
if (buf_res.length > len) {
buf_res.length = len;
}
+#if defined(__rtems__) && defined(NEED_MISSALIGNED_COPY)
+   misaligned_copy_to_io(buf_res.buffer, ptr, buf_res.length);
+#else /* __rtems__ */
memcpy(buf_res.buffer, ptr, buf_res.length);
+#endif /* __rtems__ */
 
offset += buf_res.length;
len -= buf_res.length;
@@ -302,7 +352,11 @@ usbd_copy_out(struct usb_page_cache *cache, usb_frlength_t 
offset,
if (res.length > len) {
res.length = len;
}
+#if defined(__rtems__) && defined(NEED_MISSALIGNED_COPY)
+   misaligned_copy_from_io(ptr, res.buffer, res.length);
+#else /* __rtems__ */
memcpy(ptr, res.buffer, res.length);
+#endif /* __rtems__ */
 
offset += res.length;
len -= res.length;
diff --git a/libbsd.py b/libbsd.py
index 6eaca5ad..ed6493b2 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -5018,6 +5018,8 @@ class imx(builder.Module):
 mm = self.manager
 self.addKernelSpaceHeaderFiles(
 [
+'sys/arm/freescale/imx/imx6_anatopreg.h',
+'sys/arm/freescale/imx/imx6_anatopvar.h',
 'sys/arm/freescale/imx/imx6_ccmreg.h',

[PATCH libbsd 10/11] ehci_imx: Set/clear ENHOSTDISCONNECT in USB PHY.

2020-04-02 Thread Christian Mauderer

This is not a nice solution but it should work on all chips. As soon as
FreeBSD has a nice solution via the USB PHY driver, this should be
replaced.

Update #3869.
---
 freebsd/sys/dev/usb/controller/ehci_imx.c | 59 +++
 1 file changed, 59 insertions(+)

diff --git a/freebsd/sys/dev/usb/controller/ehci_imx.c 
b/freebsd/sys/dev/usb/controller/ehci_imx.c
index d158df1d..544a63b5 100644
--- a/freebsd/sys/dev/usb/controller/ehci_imx.c
+++ b/freebsd/sys/dev/usb/controller/ehci_imx.c
@@ -50,6 +50,9 @@ __FBSDID("$FreeBSD$");
 
 #include 
 #include 
+#ifdef __rtems__
+#include 
+#endif /* __rtems__ */
 
 #include 
 #include 
@@ -270,6 +273,9 @@ struct imx_ehci_softc {
device_tdev;
struct resource *ehci_mem_res;  /* EHCI core regs. */
struct resource *ehci_irq_res;  /* EHCI core IRQ. */ 
+#ifdef __rtems__
+   void*phy_regs;
+#endif /* __rtems__ */
 };
 
 static struct ofw_compat_data compat_data[] = {
@@ -380,6 +386,32 @@ imx_ehci_disable_oc(struct imx_ehci_softc *sc)
index = usbmprops[1];
imx_usbmisc_set_ctrl(usbmdev, index, USBNC_OVER_CUR_DIS);
 }
+#ifdef __rtems__
+#define BUS_SPACE_PHYSADDR(res, offs) \
+   ((u_int)(rman_get_start(res)+(offs)))
+
+static uint16_t
+imx_ehci_get_port_speed_portsc(struct ehci_softc *sc, uint16_t index)
+{
+   uint32_t v;
+   struct imx_ehci_softc *isc = (struct imx_ehci_softc *)sc;
+
+   v = ehci_get_port_speed_portsc(sc, index);
+
+   /* Set/clear ENHOSTDISCONDETECT in USBPHY CTRL register */
+   /* FIXME: This is a very hacky method. It should be done by the phy
+* driver instead. */
+   volatile uint32_t *ctrl_set = isc->phy_regs + 0x34;
+   volatile uint32_t *ctrl_clr = isc->phy_regs + 0x38;
+   if (v == UPS_HIGH_SPEED) {
+   *ctrl_set = 0x2;
+   } else {
+   *ctrl_clr = 0x2;
+   }
+
+   return (v);
+}
+#endif /* __rtems__ */
 
 static int
 imx_ehci_attach(device_t dev)
@@ -474,6 +506,33 @@ imx_ehci_attach(device_t dev)
esc->sc_flags |= EHCI_SCFLG_NORESTERM | EHCI_SCFLG_TT;
esc->sc_vendor_post_reset = imx_ehci_post_reset;
esc->sc_vendor_get_port_speed = ehci_get_port_speed_portsc;
+#ifdef __rtems__
+   /*
+* FIXME: This is a big hack to get the PHY regs and set one bit during
+* changes of the port speed.
+*/
+   sc->phy_regs = 0;
+   if (OF_hasprop(ofw_bus_get_node(sc->dev), "fsl,usbphy")) {
+   phandle_t *cells;
+   int len;
+   phandle_t phynode;
+
+   cells = NULL;
+   len = OF_getencprop_alloc_multi(ofw_bus_get_node(sc->dev),
+   "fsl,usbphy", sizeof(*cells), (void **));
+   if (len > 0
+   && (phynode = OF_node_from_xref(cells[0])) != -1 &&
+   ofw_bus_node_is_compatible(phynode, "fsl,imx6ul-usbphy")) {
+   u_long base, size;
+   if (fdt_regsize(phynode, , ) == 0) {
+   sc->phy_regs = (void*)base;
+   esc->sc_vendor_get_port_speed =
+   imx_ehci_get_port_speed_portsc;
+   }
+   }
+   OF_prop_free(cells);
+   }
+#endif /* __rtems__ */
 
err = ehci_init(esc);
if (err != 0) {
-- 
2.16.4

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

[PATCH libbsd 05/11] regulator: Port to RTEMS.

2020-04-02 Thread Christian Mauderer

Update #3869.
---
 Makefile.todo |  26 +++
 buildset/default.ini  |   1 +
 libbsd.py |  30 
 rtemsbsd/include/bsp/nexus-devices.h  |   3 +
 rtemsbsd/include/rtems/bsd/local/regdev_if.h  |  36 +
 rtemsbsd/include/rtems/bsd/local/regnode_if.h | 107 ++
 rtemsbsd/local/regdev_if.c|  27 +++
 rtemsbsd/local/regnode_if.c   |  52 +
 8 files changed, 282 insertions(+)
 create mode 100644 rtemsbsd/include/rtems/bsd/local/regdev_if.h
 create mode 100644 rtemsbsd/include/rtems/bsd/local/regnode_if.h
 create mode 100644 rtemsbsd/local/regdev_if.c
 create mode 100644 rtemsbsd/local/regnode_if.c

diff --git a/Makefile.todo b/Makefile.todo
index 59e630e1..a05716ef 100644
--- a/Makefile.todo
+++ b/Makefile.todo
@@ -45,6 +45,10 @@ GENERATED += $(LOCAL_INC)/sdhci_if.h
 GENERATED += $(LOCAL_SRC)/sdhci_if.c
 GENERATED += $(LOCAL_INC)/gpiobus_if.h
 GENERATED += $(LOCAL_SRC)/gpiobus_if.c
+GENERATED += $(LOCAL_INC)/regdev_if.h
+GENERATED += $(LOCAL_SRC)/regdev_if.c
+GENERATED += $(LOCAL_INC)/regnode_if.h
+GENERATED += $(LOCAL_SRC)/regnode_if.c
 GENERATED += rtemsbsd/include/machine/rtems-bsd-regdomain.h
 GENERATED += rtemsbsd/rtems/rtems-bsd-regdomain.c
 GENERATED += freebsd/contrib/libpcap/pcap_version.h
@@ -231,6 +235,28 @@ $(LOCAL_SRC)/gpio_if.c: 
$(FREEBSD_SRC)/sys/dev/gpio/gpio_if.m
awk -f $(TOOLS)/makeobjops.awk $< -c
mv gpio_if.c $@
 
+$(LOCAL_INC)/regnode_if.h: $(FREEBSD_SRC)/sys/dev/extres/regulator/regnode_if.m
+   awk -f $(TOOLS)/makeobjops.awk $< -h
+   mv regnode_if.h $@
+
+$(LOCAL_SRC)/regnode_if.c: $(FREEBSD_SRC)/sys/dev/extres/regulator/regnode_if.m
+   awk -f $(TOOLS)/makeobjops.awk $< -c
+   sed -i regnode_if.c \
+   -e '1 i\#include \n' \
+   -e 's|#include "regnode_if.h"|#include 
|'
+   mv regnode_if.c $@
+
+$(LOCAL_INC)/regdev_if.h: $(FREEBSD_SRC)/sys/dev/extres/regulator/regdev_if.m
+   awk -f $(TOOLS)/makeobjops.awk $< -h
+   mv regdev_if.h $@
+
+$(LOCAL_SRC)/regdev_if.c: $(FREEBSD_SRC)/sys/dev/extres/regulator/regdev_if.m
+   awk -f $(TOOLS)/makeobjops.awk $< -c
+   sed -i regdev_if.c \
+   -e '1 i\#include \n' \
+   -e 's|#include "regdev_if.h"|#include 
|'
+   mv regdev_if.c $@
+
 $(LOCAL_SRC)/rtwn-rtl8192cfwT.c: 
$(FREEBSD_SRC)/sys/contrib/dev/rtwn/rtwn-rtl8192cfwT.fw.uu
uudecode -o /dev/stdout $< | python firmware-gen.py \
-l "$(FREEBSD_SRC)/sys/contrib/dev/rtwn/LICENSE" \
diff --git a/buildset/default.ini b/buildset/default.ini
index ac8c9c48..b17f2b59 100644
--- a/buildset/default.ini
+++ b/buildset/default.ini
@@ -54,6 +54,7 @@ nvme = on
 opencrypto = on
 pci = on
 pf = on
+regulator = on
 rtems = on
 tests = on
 tty = on
diff --git a/libbsd.py b/libbsd.py
index eeb1ec4f..6eaca5ad 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -5030,6 +5030,35 @@ class imx(builder.Module):
 mm.generator['source']()
 )
 
+class regulator(builder.Module):
+def __init__(self, manager):
+super(regulator, self).__init__(manager, type(self).__name__)
+
+def generate(self):
+mm = self.manager
+self.addRTEMSSourceFiles(
+[
+'local/regdev_if.c',
+'local/regnode_if.c',
+],
+mm.generator['source']()
+)
+self.addKernelSpaceHeaderFiles(
+[
+'sys/dev/extres/regulator/regulator.h',
+'sys/dev/extres/regulator/regulator_fixed.h',
+]
+)
+self.addKernelSpaceSourceFiles(
+[
+'sys/dev/extres/regulator/regulator.c',
+'sys/dev/extres/regulator/regulator_bus.c',
+'sys/dev/extres/regulator/regulator_fixed.c',
+'sys/dev/gpio/gpioregulator.c',
+],
+mm.generator['source']()
+)
+
 #
 # Tests
 #
@@ -5187,6 +5216,7 @@ def load(mm):
 
 mm.addModule(nvme(mm))
 mm.addModule(imx(mm))
+mm.addModule(regulator(mm))
 
 # Add in_chksum
 mm.addModule(in_cksum(mm))
diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index 92665409..0a210bd9 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -136,6 +136,9 @@ SYSINIT_DRIVER_REFERENCE(imx51_gpio, simplebus);
 SYSINIT_DRIVER_REFERENCE(sdhci_fsl, simplebus);
 RTEMS_BSD_DRIVER_MMC;
 
+SYSINIT_DRIVER_REFERENCE(ofw_regulator_bus, simplebus);
+SYSINIT_DRIVER_REFERENCE(gpioregulator, simplebus);
+
 #elif defined(LIBBSP_ARM_LPC24XX_BSP_H)
 
 RTEMS_BSD_DEFINE_NEXUS_DEVICE(ohci, 0, 0, NULL);
diff --git a/rtemsbsd/include/rtems/bsd/local/regdev_if.h 
b/rtemsbsd/include/rtems/bsd/local/regdev_if.h
new file mode 100644
index ..4a75810f
--- /dev/null
+++ b/rtemsbsd/include/rtems/bsd/local/regdev_if.h
@@ -0,0

[PATCH libbsd 03/11] imx gpio port

2020-04-02 Thread Christian Mauderer

From: Sebastian Huber 

Update #3869.
---
 freebsd/sys/arm/freescale/imx/imx_gpio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/freebsd/sys/arm/freescale/imx/imx_gpio.c 
b/freebsd/sys/arm/freescale/imx/imx_gpio.c
index f5b476d7..7dd49e3f 100644
--- a/freebsd/sys/arm/freescale/imx/imx_gpio.c
+++ b/freebsd/sys/arm/freescale/imx/imx_gpio.c
@@ -125,6 +125,7 @@ struct imx51_gpio_softc {
 
 static struct ofw_compat_data compat_data[] = {
 #ifdef __rtems__
+   {"fsl,imx35-gpio",  1},
{"fsl,imx7d-gpio",  1},
 #endif /* __rtems__ */
{"fsl,imx6q-gpio",  1},
-- 
2.16.4

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

[PATCH libbsd 01/11] imx6_ccm: Import from FreeBSD

2020-04-02 Thread Christian Mauderer

From: Sebastian Huber 

Update #3869.
---
 freebsd/sys/arm/freescale/imx/imx6_ccm.c | 468 +++
 freebsd/sys/arm/freescale/imx/imx6_ccmreg.h  | 149 +
 freebsd/sys/arm/freescale/imx/imx6_machdep.h |  38 +++
 freebsd/sys/arm/freescale/imx/imx_machdep.h  |  72 +
 4 files changed, 727 insertions(+)
 create mode 100644 freebsd/sys/arm/freescale/imx/imx6_ccm.c
 create mode 100644 freebsd/sys/arm/freescale/imx/imx6_ccmreg.h
 create mode 100644 freebsd/sys/arm/freescale/imx/imx6_machdep.h
 create mode 100644 freebsd/sys/arm/freescale/imx/imx_machdep.h

diff --git a/freebsd/sys/arm/freescale/imx/imx6_ccm.c 
b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
new file mode 100644
index ..2993f1d6
--- /dev/null
+++ b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
@@ -0,0 +1,468 @@
+#include 
+
+/*-
+ * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
+ *
+ * Copyright (c) 2013 Ian Lepore 
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include 
+__FBSDID("$FreeBSD$");
+
+/*
+ * Clocks and power control driver for Freescale i.MX6 family of SoCs.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifndef CCGR_CLK_MODE_ALWAYS
+#defineCCGR_CLK_MODE_OFF   0
+#defineCCGR_CLK_MODE_RUNMODE   1
+#defineCCGR_CLK_MODE_ALWAYS3
+#endif
+
+struct ccm_softc {
+   device_tdev;
+   struct resource *mem_res;
+};
+
+static struct ccm_softc *ccm_sc;
+
+static inline uint32_t
+RD4(struct ccm_softc *sc, bus_size_t off)
+{
+
+   return (bus_read_4(sc->mem_res, off));
+}
+
+static inline void
+WR4(struct ccm_softc *sc, bus_size_t off, uint32_t val)
+{
+
+   bus_write_4(sc->mem_res, off, val);
+}
+
+/*
+ * Until we have a fully functional ccm driver which implements the fdt_clock
+ * interface, use the age-old workaround of unconditionally enabling the clocks
+ * for devices we might need to use.  The SoC defaults to most clocks enabled,
+ * but the rom boot code and u-boot disable a few of them.  We turn on only
+ * what's needed to run the chip plus devices we have drivers for, and turn off
+ * devices we don't yet have drivers for.  (Note that USB is not turned on here
+ * because that is one we do when the driver asks for it.)
+ */
+static void
+ccm_init_gates(struct ccm_softc *sc)
+{
+   uint32_t reg;
+
+   /* ahpbdma, aipstz 1 & 2 buses */
+   reg = CCGR0_AIPS_TZ1 | CCGR0_AIPS_TZ2 | CCGR0_ABPHDMA;
+   WR4(sc, CCM_CCGR0, reg);
+
+   /* enet, epit, gpt, spi */
+   reg = CCGR1_ENET | CCGR1_EPIT1 | CCGR1_GPT | CCGR1_ECSPI1 |
+   CCGR1_ECSPI2 | CCGR1_ECSPI3 | CCGR1_ECSPI4 | CCGR1_ECSPI5;
+   WR4(sc, CCM_CCGR1, reg);
+
+   /* ipmux & ipsync (bridges), iomux, i2c */
+   reg = CCGR2_I2C1 | CCGR2_I2C2 | CCGR2_I2C3 | CCGR2_IIM |
+   CCGR2_IOMUX_IPT | CCGR2_IPMUX1 | CCGR2_IPMUX2 | CCGR2_IPMUX3 |
+   CCGR2_IPSYNC_IP2APB_TZASC1 | CCGR2_IPSYNC_IP2APB_TZASC2 |
+   CCGR2_IPSYNC_VDOA;
+   WR4(sc, CCM_CCGR2, reg);
+
+   /* DDR memory controller */
+   reg = CCGR3_OCRAM | CCGR3_MMDC_CORE_IPG |
+   CCGR3_MMDC_CORE_ACLK_FAST | CCGR3_CG11 | CCGR3_CG13;
+   WR4(sc, CCM_CCGR3, reg);
+
+   /* pl301 bus crossbar */
+   reg = CCGR4_PL301_MX6QFAST1_S133 |
+   CCGR4_PL301_MX6QPER1_BCH | CCGR4_PL301_MX6QPER2_MAIN;
+   WR4(sc, CCM_CCGR4, reg);
+
+   /* uarts, ssi, sdma */
+   reg = CCGR5_SDMA | CCGR5_SSI1 | CCGR5_SSI2 | CCGR5_SSI3 |
+   CCGR5_UART | CCGR5_UART_SERIAL;
+   WR4(sc, CCM_CCGR5, reg);
+
+   /* usdhc 1-4, usboh3 */
+   reg =

[PATCH libbsd 08/11] ehci_imx: Import from FreeBSD

2020-04-02 Thread Christian Mauderer

From: Sebastian Huber 

Update #3869.
---
 freebsd/sys/arm/freescale/imx/imx6_anatopreg.h | 193 +
 freebsd/sys/arm/freescale/imx/imx6_anatopvar.h |  49 +++
 freebsd/sys/arm/freescale/imx/imx6_usbphy.c| 212 ++
 freebsd/sys/dev/usb/controller/ehci_imx.c  | 516 +
 4 files changed, 970 insertions(+)
 create mode 100644 freebsd/sys/arm/freescale/imx/imx6_anatopreg.h
 create mode 100644 freebsd/sys/arm/freescale/imx/imx6_anatopvar.h
 create mode 100644 freebsd/sys/arm/freescale/imx/imx6_usbphy.c
 create mode 100644 freebsd/sys/dev/usb/controller/ehci_imx.c

diff --git a/freebsd/sys/arm/freescale/imx/imx6_anatopreg.h 
b/freebsd/sys/arm/freescale/imx/imx6_anatopreg.h
new file mode 100644
index ..e8269526
--- /dev/null
+++ b/freebsd/sys/arm/freescale/imx/imx6_anatopreg.h
@@ -0,0 +1,193 @@
+/*-
+ * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
+ *
+ * Copyright (c) 2013 Ian Lepore 
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * $FreeBSD$
+ */
+
+#ifndefIMX6_ANATOPREG_H
+#defineIMX6_ANATOPREG_H
+
+#defineIMX6_ANALOG_CCM_PLL_ARM 0x000
+#defineIMX6_ANALOG_CCM_PLL_ARM_SET 0x004
+#defineIMX6_ANALOG_CCM_PLL_ARM_CLR 0x008
+#defineIMX6_ANALOG_CCM_PLL_ARM_TOG 0x00C
+#define  IMX6_ANALOG_CCM_PLL_ARM_DIV_MASK0x7F
+#define  IMX6_ANALOG_CCM_PLL_ARM_LOCK(1U << 31)
+#define  IMX6_ANALOG_CCM_PLL_ARM_BYPASS  (1 << 16)
+#define  IMX6_ANALOG_CCM_PLL_ARM_CLK_SRC_MASK(0x03 << 16)
+#defineIMX6_ANALOG_CCM_PLL_USB10x010
+#defineIMX6_ANALOG_CCM_PLL_USB1_SET0x014
+#defineIMX6_ANALOG_CCM_PLL_USB1_CLR0x018
+#defineIMX6_ANALOG_CCM_PLL_USB1_TOG0x01C
+#define   IMX6_ANALOG_CCM_PLL_USB_LOCK   (1U << 31)
+#define   IMX6_ANALOG_CCM_PLL_USB_BYPASS (1 << 16)
+#define   IMX6_ANALOG_CCM_PLL_USB_ENABLE (1 << 13)
+#define   IMX6_ANALOG_CCM_PLL_USB_POWER  (1 << 12)
+#define   IMX6_ANALOG_CCM_PLL_USB_EN_USB_CLKS(1 <<  6)
+#defineIMX6_ANALOG_CCM_PLL_USB20x020
+#defineIMX6_ANALOG_CCM_PLL_USB2_SET0x024
+#defineIMX6_ANALOG_CCM_PLL_USB2_CLR0x028
+#defineIMX6_ANALOG_CCM_PLL_USB2_TOG0x02C
+#defineIMX6_ANALOG_CCM_PLL_SYS 0x030
+#defineIMX6_ANALOG_CCM_PLL_SYS_SET 0x034
+#defineIMX6_ANALOG_CCM_PLL_SYS_CLR 0x038
+#defineIMX6_ANALOG_CCM_PLL_SYS_TOG 0x03C
+#defineIMX6_ANALOG_CCM_PLL_SYS_SS  0x040
+#defineIMX6_ANALOG_CCM_PLL_SYS_NUM 0x050
+#defineIMX6_ANALOG_CCM_PLL_SYS_DENOM   0x060
+#defineIMX6_ANALOG_CCM_PLL_AUDIO   0x070
+#define   IMX6_ANALOG_CCM_PLL_AUDIO_ENABLE   (1 << 13)
+#define   IMX6_ANALOG_CCM_PLL_AUDIO_DIV_SELECT_SHIFT 0
+#define   IMX6_ANALOG_CCM_PLL_AUDIO_DIV_SELECT_MASK  0x7f
+#defineIMX6_ANALOG_CCM_PLL_AUDIO_SET   0x074
+#defineIMX6_ANALOG_CCM_PLL_AUDIO_CLR   0x078
+#defineIMX6_ANALOG_CCM_PLL_AUDIO_TOG   0x07C
+#defineIMX6_ANALOG_CCM_PLL_AUDIO_NUM   0x080
+#defineIMX6_ANALOG_CCM_PLL_AUDIO_DENOM

[PATCH libbsd 11/11] freebsd/imx6_usbphy: Add regulator (vbus-supply).

2020-04-02 Thread Christian Mauderer

Update #3869.
---
 freebsd/sys/arm/freescale/imx/imx6_usbphy.c | 31 +
 1 file changed, 31 insertions(+)

diff --git a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c 
b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
index ad545601..7df2e124 100644
--- a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
+++ b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
@@ -52,6 +52,9 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#ifdef __rtems__
+#include 
+#endif /* __rtems__ */
 
 /*
  * Hardware register defines.
@@ -70,6 +73,9 @@ struct usbphy_softc {
device_tdev;
struct resource *mem_res;
u_int   phy_num;
+#ifdef __rtems__
+   regulator_t supply_vbus;
+#endif /* __rtems__ */
 };
 
 static struct ofw_compat_data compat_data[] = {
@@ -107,6 +113,10 @@ usbphy_attach(device_t dev)
 {
struct usbphy_softc *sc;
int err, regoff, rid;
+#ifdef __rtems__
+   int rv;
+   phandle_t node;
+#endif /* __rtems__ */
 
sc = device_get_softc(dev);
err = 0;
@@ -121,6 +131,27 @@ usbphy_attach(device_t dev)
goto out;
}
 
+#ifdef __rtems__
+   node = ofw_bus_get_node(dev);
+   if (OF_hasprop(node, "vbus-supply")) {
+   rv = regulator_get_by_ofw_property(sc->dev, 0, "vbus-supply",
+   >supply_vbus);
+   if (rv != 0) {
+   device_printf(sc->dev,
+  "Cannot get \"vbus\" regulator\n");
+   err = ENXIO;
+   goto out;
+   }
+   rv = regulator_enable(sc->supply_vbus);
+   if (rv != 0) {
+   device_printf(sc->dev,
+   "Cannot enable  \"vbus\" regulator\n");
+   err = ENXIO;
+   goto out;
+   }
+   }
+
+#endif /* __rtems__ */
/*
 * XXX Totally lame way to get the unit number (but not quite as lame as
 * adding an ad-hoc property to the fdt data).  This works as long as
-- 
2.16.4

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

[PATCH libbsd 04/11] regulator: Import from FreeBSD.

2020-04-02 Thread Christian Mauderer

Update #3869.
---
 freebsd/sys/dev/extres/regulator/regulator.c   | 1196 
 freebsd/sys/dev/extres/regulator/regulator.h   |  150 +++
 freebsd/sys/dev/extres/regulator/regulator_bus.c   |   89 ++
 freebsd/sys/dev/extres/regulator/regulator_fixed.c |  501 
 freebsd/sys/dev/extres/regulator/regulator_fixed.h |   44 +
 freebsd/sys/dev/gpio/gpioregulator.c   |  350 ++
 6 files changed, 2330 insertions(+)
 create mode 100644 freebsd/sys/dev/extres/regulator/regulator.c
 create mode 100644 freebsd/sys/dev/extres/regulator/regulator.h
 create mode 100644 freebsd/sys/dev/extres/regulator/regulator_bus.c
 create mode 100644 freebsd/sys/dev/extres/regulator/regulator_fixed.c
 create mode 100644 freebsd/sys/dev/extres/regulator/regulator_fixed.h
 create mode 100644 freebsd/sys/dev/gpio/gpioregulator.c

diff --git a/freebsd/sys/dev/extres/regulator/regulator.c 
b/freebsd/sys/dev/extres/regulator/regulator.c
new file mode 100644
index ..588d87d5
--- /dev/null
+++ b/freebsd/sys/dev/extres/regulator/regulator.c
@@ -0,0 +1,1196 @@
+#include 
+
+/*-
+ * Copyright 2016 Michal Meloun 
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include 
+__FBSDID("$FreeBSD$");
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef FDT
+#include 
+#include 
+#include 
+#endif
+#include 
+
+#include 
+
+SYSCTL_NODE(_hw, OID_AUTO, regulator, CTLFLAG_RD, NULL, "Regulators");
+
+MALLOC_DEFINE(M_REGULATOR, "regulator", "Regulator framework");
+
+#defineDIV_ROUND_UP(n,d) howmany(n, d)
+
+/* Forward declarations. */
+struct regulator;
+struct regnode;
+
+typedef TAILQ_HEAD(regnode_list, regnode) regnode_list_t;
+typedef TAILQ_HEAD(regulator_list, regulator) regulator_list_t;
+
+/* Default regulator methods. */
+static int regnode_method_enable(struct regnode *regnode, bool enable,
+int *udelay);
+static int regnode_method_status(struct regnode *regnode, int *status);
+static int regnode_method_set_voltage(struct regnode *regnode, int min_uvolt,
+int max_uvolt, int *udelay);
+static int regnode_method_get_voltage(struct regnode *regnode, int *uvolt);
+static void regulator_shutdown(void *dummy);
+
+/*
+ * Regulator controller methods.
+ */
+static regnode_method_t regnode_methods[] = {
+   REGNODEMETHOD(regnode_enable,   regnode_method_enable),
+   REGNODEMETHOD(regnode_status,   regnode_method_status),
+   REGNODEMETHOD(regnode_set_voltage,  regnode_method_set_voltage),
+   REGNODEMETHOD(regnode_get_voltage,  regnode_method_get_voltage),
+
+   REGNODEMETHOD_END
+};
+DEFINE_CLASS_0(regnode, regnode_class, regnode_methods, 0);
+
+/*
+ * Regulator node - basic element for modelling SOC and bard power supply
+ * chains. Its contains producer data.
+ */
+struct regnode {
+   KOBJ_FIELDS;
+
+   TAILQ_ENTRY(regnode)reglist_link;   /* Global list entry */
+   regulator_list_tconsumers_list; /* Consumers list */
+
+   /* Cache for already resolved names */
+   struct regnode  *parent;/* Resolved parent */
+
+   /* Details of this device. */
+   const char  *name;  /* Globally unique name */
+   const char  *parent_name;   /* Parent name */
+
+   device_tpdev;   /* Producer device_t */
+   void*softc; /* Producer softc */
+   intptr_tid; /* Per producer unique id */
+#ifdef FDT
+phandle_t  ofw_node;   /* OFW node of regulator */
+#endif
+   int

[PATCH libbsd 02/11] imx6_ccm: Port to RTEMS

2020-04-02 Thread Christian Mauderer

From: Sebastian Huber 

Update #3869.
---
 buildset/default.ini |  1 +
 freebsd/sys/arm/freescale/imx/imx6_ccm.c |  7 +++
 libbsd.py| 21 +
 rtemsbsd/include/bsp/nexus-devices.h |  2 ++
 4 files changed, 31 insertions(+)

diff --git a/buildset/default.ini b/buildset/default.ini
index 43ea82a3..ac8c9c48 100644
--- a/buildset/default.ini
+++ b/buildset/default.ini
@@ -40,6 +40,7 @@ dhcpcd = on
 dpaa = on
 evdev = on
 fdt = on
+imx = on
 in_cksum = on
 mdnsresponder = on
 mmc = on
diff --git a/freebsd/sys/arm/freescale/imx/imx6_ccm.c 
b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
index 2993f1d6..cef79933 100644
--- a/freebsd/sys/arm/freescale/imx/imx6_ccm.c
+++ b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
@@ -92,6 +92,7 @@ WR4(struct ccm_softc *sc, bus_size_t off, uint32_t val)
 static void
 ccm_init_gates(struct ccm_softc *sc)
 {
+#ifndef __rtems__
uint32_t reg;
 
/* ahpbdma, aipstz 1 & 2 buses */
@@ -129,6 +130,7 @@ ccm_init_gates(struct ccm_softc *sc)
reg = CCGR6_USBOH3 | CCGR6_USDHC1 | CCGR6_USDHC2 |
CCGR6_USDHC3 | CCGR6_USDHC4;
WR4(sc, CCM_CCGR6, reg);
+#endif /* __rtems__ */
 }
 
 static int
@@ -204,7 +206,12 @@ ccm_probe(device_t dev)
if (!ofw_bus_status_okay(dev))
return (ENXIO);
 
+#ifndef __rtems__
 if (ofw_bus_is_compatible(dev, "fsl,imx6q-ccm") == 0)
+#else /* __rtems__ */
+if (ofw_bus_is_compatible(dev, "fsl,imx6q-ccm") == 0 &&
+   ofw_bus_is_compatible(dev, "fsl,imx6ul-ccm") == 0)
+#endif /* __rtems__ */
return (ENXIO);
 
device_set_desc(dev, "Freescale i.MX6 Clock Control Module");
diff --git a/libbsd.py b/libbsd.py
index d791efe4..eeb1ec4f 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -5010,6 +5010,26 @@ class dpaa(builder.Module):
 mm.generator['source']()
 )
 
+class imx(builder.Module):
+def __init__(self, manager):
+super(imx, self).__init__(manager, type(self).__name__)
+
+def generate(self):
+mm = self.manager
+self.addKernelSpaceHeaderFiles(
+[
+'sys/arm/freescale/imx/imx6_ccmreg.h',
+'sys/arm/freescale/imx/imx6_machdep.h',
+'sys/arm/freescale/imx/imx_machdep.h',
+]
+)
+self.addKernelSpaceSourceFiles(
+[
+'sys/arm/freescale/imx/imx6_ccm.c',
+],
+mm.generator['source']()
+)
+
 #
 # Tests
 #
@@ -5166,6 +5186,7 @@ def load(mm):
 mm.addModule(dev_nic_broadcomm(mm))
 
 mm.addModule(nvme(mm))
+mm.addModule(imx(mm))
 
 # Add in_chksum
 mm.addModule(in_cksum(mm))
diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index a916c664..92665409 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -127,6 +127,8 @@ RTEMS_BSD_DRIVER_MMC;
 RTEMS_BSD_DEFINE_NEXUS_DEVICE(ofwbus, 0, 0, NULL);
 SYSINIT_DRIVER_REFERENCE(simplebus, ofwbus);
 
+SYSINIT_DRIVER_REFERENCE(ccm, simplebus);
+
 SYSINIT_DRIVER_REFERENCE(ffec, simplebus);
 SYSINIT_DRIVER_REFERENCE(ukphy, miibus);
 
-- 
2.16.4

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

[PATCH libbsd 06/11] Add support for i.mx cache.

2020-04-02 Thread Christian Mauderer

Update #3869.
---
 rtemsbsd/include/machine/rtems-bsd-cache.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rtemsbsd/include/machine/rtems-bsd-cache.h 
b/rtemsbsd/include/machine/rtems-bsd-cache.h
index bd496f9d..73b55e25 100755
--- a/rtemsbsd/include/machine/rtems-bsd-cache.h
+++ b/rtemsbsd/include/machine/rtems-bsd-cache.h
@@ -45,7 +45,7 @@
 #if defined(LIBBSP_ARM_LPC24XX_BSP_H) || (defined(LIBBSP_ARM_LPC32XX_BSP_H) && 
defined(LPC32XX_DISABLE_MMU))
   /* No cache */
 #elif defined(LIBBSP_ARM_ALTERA_CYCLONE_V_BSP_H) || \
-  defined(LIBBSP_ARM_XILINX_ZYNQ_BSP_H) || (defined(LIBBSP_ARM_LPC32XX_BSP_H) 
&& !defined(LPC32XX_DISABLE_MMU))
+  defined(LIBBSP_ARM_XILINX_ZYNQ_BSP_H) || (defined(LIBBSP_ARM_LPC32XX_BSP_H) 
&& !defined(LPC32XX_DISABLE_MMU)) || defined(LIBBSP_ARM_IMX_BSP_H)
   /* With cache, no coherency support in hardware */
   #define CPU_DATA_CACHE_ALIGNMENT 32
 #elif defined(__GEN83xx_BSP_h)
-- 
2.16.4

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

[PATCH libbsd 07/11] bus-dma, imx: Don't sync nocache area.

2020-04-02 Thread Christian Mauderer

This area doesn't support all cache operations.

Update #3869.
---
 rtemsbsd/rtems/rtems-kernel-bus-dma.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/rtemsbsd/rtems/rtems-kernel-bus-dma.c 
b/rtemsbsd/rtems/rtems-kernel-bus-dma.c
index 8c15e92b..8674bef1 100644
--- a/rtemsbsd/rtems/rtems-kernel-bus-dma.c
+++ b/rtemsbsd/rtems/rtems-kernel-bus-dma.c
@@ -48,6 +48,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -396,6 +398,11 @@ bus_dmamap_sync(bus_dma_tag_t dmat, bus_dmamap_t map, 
bus_dmasync_op_t op)
uintptr_t size = map->buffer_size;
uintptr_t begin = (uintptr_t) map->buffer_begin;
uintptr_t end = begin + size;
+#if defined(LIBBSP_ARM_IMX_BSP_H)
+   if (begin >= bsp_section_nocache_begin && end <= 
bsp_section_nocachenoload_end) {
+   return;
+   }
+#endif
 
if ((op & BUS_DMASYNC_PREWRITE) != 0 && (op & BUS_DMASYNC_PREREAD) == 
0) {
rtems_cache_flush_multiple_data_lines((void *) begin, size);
-- 
2.16.4

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

[PATCH] bsp/imx: Add an extra ecspi clock.

2020-04-02 Thread Christian Mauderer

Some imx chips or boards don't use the same frequency for ECSPI and IPG.

Update #3869
---
 bsps/arm/imx/include/arm/freescale/imx/imx_ccmvar.h | 3 +++
 bsps/arm/imx/spi/imx-ecspi.c| 2 +-
 bsps/arm/imx/start/ccm.c| 5 +
 c/src/lib/libbsp/arm/imx/configure.ac   | 3 +++
 4 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/bsps/arm/imx/include/arm/freescale/imx/imx_ccmvar.h 
b/bsps/arm/imx/include/arm/freescale/imx/imx_ccmvar.h
index 5633de6f50..0f19d80813 100644
--- a/bsps/arm/imx/include/arm/freescale/imx/imx_ccmvar.h
+++ b/bsps/arm/imx/include/arm/freescale/imx/imx_ccmvar.h
@@ -48,6 +48,9 @@ uint32_t imx_ccm_perclk_hz(void);
 uint32_t imx_ccm_sdhci_hz(void);
 uint32_t imx_ccm_uart_hz(void);
 uint32_t imx_ccm_ahb_hz(void);
+#ifdef __rtems__
+uint32_t imx_ccm_ecspi_hz(void);
+#endif /* __rtems__ */
 
 #ifndef __rtems__
 void imx_ccm_usb_enable(device_t _usbdev);
diff --git a/bsps/arm/imx/spi/imx-ecspi.c b/bsps/arm/imx/spi/imx-ecspi.c
index 4c4978cdac..a18047f2e0 100644
--- a/bsps/arm/imx/spi/imx-ecspi.c
+++ b/bsps/arm/imx/spi/imx-ecspi.c
@@ -435,7 +435,7 @@ int spi_bus_register_imx(const char *bus_path, const char 
*alias_or_path)
 return -1;
   }
 
-  bus->base.max_speed_hz = imx_ccm_ipg_hz();
+  bus->base.max_speed_hz = imx_ccm_ecspi_hz();
   bus->base.delay_usecs = 1;
   bus->regs = imx_get_reg_of_node(fdt, node);
   bus->irq = imx_get_irq_of_node(fdt, node, 0);
diff --git a/bsps/arm/imx/start/ccm.c b/bsps/arm/imx/start/ccm.c
index cc93dcbd5d..3487470357 100644
--- a/bsps/arm/imx/start/ccm.c
+++ b/bsps/arm/imx/start/ccm.c
@@ -27,6 +27,11 @@ uint32_t imx_ccm_uart_hz(void)
   return IMX_CCM_UART_HZ;
 }
 
+uint32_t imx_ccm_ecspi_hz(void)
+{
+  return IMX_CCM_ECSPI_HZ;
+}
+
 uint32_t imx_ccm_ahb_hz(void)
 {
   return IMX_CCM_AHB_HZ;
diff --git a/c/src/lib/libbsp/arm/imx/configure.ac 
b/c/src/lib/libbsp/arm/imx/configure.ac
index aa119b9236..fbb9d9278a 100644
--- a/c/src/lib/libbsp/arm/imx/configure.ac
+++ b/c/src/lib/libbsp/arm/imx/configure.ac
@@ -43,6 +43,9 @@ RTEMS_BSPOPTS_HELP([IMX_CCM_IPG_HZ],[IPG clock frequency in 
Hz])
 RTEMS_BSPOPTS_SET([IMX_CCM_UART_HZ],[*],[2400])
 RTEMS_BSPOPTS_HELP([IMX_CCM_UART_HZ],[UART clock frequency in Hz])
 
+RTEMS_BSPOPTS_SET([IMX_CCM_ECSPI_HZ],[*],[6750])
+RTEMS_BSPOPTS_HELP([IMX_CCM_ECSPI_HZ],[ECSPI clock frequency in Hz])
+
 RTEMS_BSPOPTS_SET([IMX_CCM_AHB_HZ],[*],[13500])
 RTEMS_BSPOPTS_HELP([IMX_CCM_AHB_HZ],[AHB clock frequency in Hz])
 
-- 
2.16.4

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

[PATCHES] Add more i.MX6UL/ULL support

2020-04-02 Thread Christian Mauderer

Hello,

this set of patches for RTEMS, libbsd and docs extend the i.MX6UL/ULL
support.

Best regards

Christian

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

Re: [PATCH] arm: ARMv7-M statically initialized vector table

2020-04-02 Thread Gedare Bloom

Ok

On Thu, Apr 2, 2020 at 12:14 AM Sebastian Huber
 wrote:
>
> Statically initialize the ARMv7-M vector table to allow a placement in
> ROM with read-only MPU settings.
>
> Change licence to BSD-2-Clause in some files.
> ---
>  bsps/arm/shared/clock/clock-armv7m.c  | 39 --
>  bsps/arm/shared/irq/irq-armv7m.c  | 50 
> +++
>  bsps/arm/shared/start/start.S | 10 ++---
>  cpukit/score/cpu/arm/armv7m-initialize.c  | 44 
>  cpukit/score/cpu/arm/include/rtems/score/armv7m.h |  2 +
>  5 files changed, 93 insertions(+), 52 deletions(-)
>
> diff --git a/bsps/arm/shared/clock/clock-armv7m.c 
> b/bsps/arm/shared/clock/clock-armv7m.c
> index 7a51690562..255de1ca42 100644
> --- a/bsps/arm/shared/clock/clock-armv7m.c
> +++ b/bsps/arm/shared/clock/clock-armv7m.c
> @@ -1,15 +1,29 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
>  /*
> - * Copyright (c) 2011, 2018 Sebastian Huber.  All rights reserved.
> + * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> + * Copyright (C) 2011, 2018 Sebastian Huber
>   *
> - *  embedded brains GmbH
> - *  Dornierstr. 4
> - *  82178 Puchheim
> - *  Germany
> - *  
> + * 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.
>   *
> - * The license and distribution terms for this file may be
> - * found in the file LICENSE in this distribution or at
> - * http://www.rtems.org/license/LICENSE.
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY 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.
>   */
>
>  #include 
> @@ -29,7 +43,7 @@ static uint32_t _ARMV7M_TC_get_timecount(struct timecounter 
> *base)
>return _ARMV7M_Clock_counter((ARMV7M_Timecounter *) base);
>  }
>
> -static void _ARMV7M_Clock_handler(void)
> +void _ARMV7M_Clock_handler(void)
>  {
>_ARMV7M_Interrupt_service_enter();
>Clock_isr(NULL);
> @@ -38,10 +52,9 @@ static void _ARMV7M_Clock_handler(void)
>
>  static void _ARMV7M_Clock_handler_install(void)
>  {
> -  _ARMV7M_Set_exception_priority_and_handler(
> +  _ARMV7M_Set_exception_priority(
>  ARMV7M_VECTOR_SYSTICK,
> -BSP_ARMV7M_SYSTICK_PRIORITY,
> -_ARMV7M_Clock_handler
> +BSP_ARMV7M_SYSTICK_PRIORITY
>);
>  }
>
> diff --git a/bsps/arm/shared/irq/irq-armv7m.c 
> b/bsps/arm/shared/irq/irq-armv7m.c
> index 99c0e373bf..84ebeeb159 100644
> --- a/bsps/arm/shared/irq/irq-armv7m.c
> +++ b/bsps/arm/shared/irq/irq-armv7m.c
> @@ -1,27 +1,41 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
>  /*
> - * Copyright (c) 2011-2012 Sebastian Huber.  All rights reserved.
> + * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> + * Copyright (C) 2011, 2012 Sebastian Huber
>   *
> - *  embedded brains GmbH
> - *  Obere Lagerstr. 30
> - *  82178 Puchheim
> - *  Germany
> - *  
> + * 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.
>   *
> - * The license and distribution terms for this file may be
> - * found in the file LICENSE in this distribution or at
> - * http://www.rtems.org/license/LICENSE.
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE

Re: RTEMS Release Snapshot: 5.0.0-m2004 (02 Apr 2020)

2020-04-02 Thread Gedare Bloom

On Thu, Apr 2, 2020 at 4:17 AM Sebastian Huber
 wrote:
>
> Hello,
>
> in the readme file:
>
>   cd
>   mkdir -p development/rtems
>   wget 
> https://ftp.rtems.org/pub/rtems/releases/sources/rtems-source-builder-5.0.0-m2004.tar.xz
>   tar jxf rtems-source-builder-5.0.0-m2004.tar.xz
And this j should be capital J?

>   cd rtems-source-builder-5.0.0-m2004/rtems
>
> there is probably a
>
>   cd development/rtems
>
> missing after the mkdir.
>
> ___
> 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] sb/setbuilder: do not include remotes in mailed reports

2020-04-02 Thread Gedare Bloom

On Wed, Apr 1, 2020 at 10:52 PM Chris Johns  wrote:
>
> Hi Gedare,
>
> Thanks for taking a look at this ticket. Comments below..
>
> On 2020-04-02 15:33, Gedare Bloom wrote:
> > Closes #3887.
> > ---
> >   source-builder/sb/reports.py| 47 -
> >   source-builder/sb/setbuilder.py |  2 +-
> >   2 files changed, 29 insertions(+), 20 deletions(-)
> >
> > diff --git a/source-builder/sb/reports.py b/source-builder/sb/reports.py
> > index ab20671..2f72088 100644
> > --- a/source-builder/sb/reports.py
> > +++ b/source-builder/sb/reports.py
> > @@ -241,13 +241,16 @@ class markdown_formatter(formatter):
> >   self.line(self._strong('Remotes:'))
> >   self.line('')
> >   rc = 1
> > -for r in remotes:
> > -if 'url' in remotes[r]:
> > -text = remotes[r]['url']
> > -else:
> > -text = 'no URL found'
> > -self.line('%d. %s: %s' % (rc, r, text))
> > -rc += 1
> > +if not remotes:
> > +self.line('[ removed for email, reply to sender for 
> > details ]')
> > +else:
> > +for r in remotes:
> > +if 'url' in remotes[r]:
> > +text = remotes[r]['url']
> > +else:
> > +text = 'no URL found'
> > +self.line('%d. %s: %s' % (rc, r, text))
> > +rc += 1
> >   self.line('')
> >   self.line(self._strong('Status:'))
> >   self.line('')
> > @@ -427,14 +430,17 @@ class text_formatter(formatter):
> >   if valid:
> >   self.line('%s Remotes:' % (self.cini))
> >   rc = 0
> > -for r in remotes:
> > -rc += 1
> > -if 'url' in remotes[r]:
> > -text = remotes[r]['url']
> > -else:
> > -text = 'no URL found'
> > -text = '%s: %s' % (r, text)
> > -self.line('%s  %2d: %s' % (self.cini, rc, text))
> > +if not remotes:
> > +self.line('[ removed for email, reply to sender for 
> > details ]')
>
> Maybe something more generic ...
>
>[ remotes removed, contact to sender for details ]
>
> ?
>
Sure.

> > +else:
> > +for r in remotes:
> > +rc += 1
> > +if 'url' in remotes[r]:
> > +text = remotes[r]['url']
> > +else:
> > +text = 'no URL found'
> > +text = '%s: %s' % (r, text)
> > +self.line('%s  %2d: %s' % (self.cini, rc, text))
> >   self.line('%s Status:' % (self.cini))
> >   if dirty:
> >   self.line('%s  Repository is dirty' % (self.cini))
> > @@ -647,17 +653,20 @@ class report:
> >   def release_status(self):
> >   self.formatter.release_status(version.string())
> >
> > -def git_status(self):
> > +def git_status(self, sanitize = False):
> >   r = git.repo('.', self.opts, self.macros)
> > -self.formatter.git_status(r.valid(), r.dirty(), r.head(), 
> > r.remotes())
> > +if sanitize:
> > +self.formatter.git_status(r.valid(), r.dirty(), r.head(), None)
> > +else:
> > +self.formatter.git_status(r.valid(), r.dirty(), r.head(), 
> > r.remotes())
> >
> > -def introduction(self, name, intro_text = None):
> > +def introduction(self, name, intro_text = None, sanitize = False):
> >   now = datetime.datetime.now().ctime()
> >   self.formatter.introduction(name, now, intro_text)
> >   if version.released():
> >   self.release_status()
> >   else:
> > -self.git_status()
> > +self.git_status(sanitize)
> >
> >   def epilogue(self, name):
> >   self.formatter.epilogue(name)
> > diff --git a/source-builder/sb/setbuilder.py 
> > b/source-builder/sb/setbuilder.py
> > index 7b80817..9367d55 100644
> > --- a/source-builder/sb/setbuilder.py
> > +++ b/source-builder/sb/setbuilder.py
> > @@ -201,7 +201,7 @@ class buildset:
> >   if mail:
> >   r = reports.report('text', self.configs,
> >  copy.copy(opts), copy.copy(macros))
> > -r.introduction(_build.config.file_name())
> > +r.introduction(_build.config.file_name(), sanitize = True)
>
> Should the `sanitize` value be True if self.mail is not None?
>
I'm not sure where that comes in? This seemed to be the best point to
squash the remote info just for mailing.

> Chris
>
> >   r.generate(_build.config.file_name())
> >   r.epilogue(_build.config.file_name())
> >   self.write_mail_report(r.get_output())
> >

[PATCH docs] start/gsoc: GSoC Getting started instructions.

2020-04-02 Thread G S Niteesh Babu

Added instructions to setup development environment for students
interested in GSoC.
---
 user/index.rst   |   1 +
 user/start/gsoc.rst  | 132 +++
 user/start/index.rst |   1 +
 3 files changed, 134 insertions(+)
 create mode 100644 user/start/gsoc.rst

diff --git a/user/index.rst b/user/index.rst
index 7b584c5..4e91994 100644
--- a/user/index.rst
+++ b/user/index.rst
@@ -10,6 +10,7 @@ RTEMS User Manual (|version|).
 
 .. topic:: Copyrights and License
 
+| |copy| 2020 Niteesh Babu
 | |copy| 2019 Vijay Kumar Banerjee
 | |copy| 2018 Amaan Cheval
 | |copy| 2018 Marçal Comajoan Cara
diff --git a/user/start/gsoc.rst b/user/start/gsoc.rst
new file mode 100644
index 000..62154ff
--- /dev/null
+++ b/user/start/gsoc.rst
@@ -0,0 +1,132 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2020 Niteesh Babu 
+
+.. _QuickStartGSoC:
+
+GSoC Getting Started
+
+
+The goal of this page is to help new users, especially students get RTEMS
+compiled and running so they can start with the real work.
+
+Please join the :r:list:`users` and :r:list:`devel` and ask
+questions. Help correct any deficiencies in the code or documentation you spot,
+including those on the wiki. The ultimate goal of GSoC is to help you become
+part of the open source community.
+
+This section will help you to quickly setup a development environment without
+delving into the details. For more information you can go through the other
+subsections under :ref:`Quick Start ` chapter or ask on the
+:r:list:`devel`.
+
+You will be best served by using a GNU/Linux environment, which could be in a
+virtual machine, for example that uses `Virtualbox 
`_
+and should run on most modern desktop systems. You should also be able to work
+with a MacOS or Windows system, but might encounter more difficulty than a *nix
+environment.
+
+Setting up a development environment consists of the following steps.
+
+1) Installing dependencies for your host operating system.
+2) Choosing an installation prefix.
+3) Downloading the source code.
+4) Installing the tool suite.
+5) Building the Board Support Package (BSP).
+6) Testing the Board Support Package (BSP).
+
+Installing Dependencies
+---
+
+You need tools for your host’s operating system to build the RTEMS tool suite
+from source. Please have a look at the :ref:`host-computer` chapter for the
+instructions to install the tools for your OS.
+
+Choosing an installation prefix
+---
+
+The term ``prefix`` refers to the path on your computer where the software is 
to
+be installed.
+You can refer to the :ref:`Prefix ` section for details on
+choosing an installation prefix.
+
+Downloading the Sources
+---
+
+We will be using Git to clone the sources for RTEMS and RSB. This is the
+preferred way if you are planning to make contributions to the RTEMS project.
+
+Please refer to the :ref:`QuickStartSources_Git` section for instructions on
+obtaining sources using Git.
+
+Installing the Tool Suite
+-
+
+The Tools suite is the collection of tools required to build the BSP. This
+includes the compiler, debugger, assembler and other tools. These tools are
+architecture-specific. We will be installing the SPARC tool suite since we are
+building a SPARC based BSP.
+
+Please refer to the :ref:`QuickStartTools` section for instructions on
+building and installing the tool suite.
+
+Building the Board Support Package
+--
+
+There are two ways of building a BSP. We could either ask RSB to build the BSP
+or manually build it. In this section will we be building it manually.
+Please refer the :ref:`QuickStartBSPBuild_Manual` section for the
+instructions.
+
+Testing the Board Support Package
+-
+
+Testing is an essential part of RTEMS development process. The main reason for
+choosing the SPARC erc32 BSP is that, it has very good simulator support. This
+will allow you to test your changes without the need for SPARC hardware.
+
+Please refer to :ref:`QuickStartBSPTest` for instructions on testing the BSP.
+
+Prove You Can Work On RTEMS
+---
+
+This section is only for students interested in Google Summer of Code.
+
+You have to finish the following task to prove that you can work on RTEMS.
+
+Modify the hello world example to include a new different print statement.
+Something like "Hello from The Dark Side!". Then send us enough to prove to us
+that you did this. We want to know you can work with RTEMS.
+
+Create a patch of your changes and send it to :r:list:`devel` along with the
+screenshot of the output.
+
+If you followed this guide, this hello world modification will likely need to 
be
+made in ``$HOME/quick-start/src/rtems/testsuites/samples/hello/init.c``.
+To test your changes, you have to build the BSP again. This could be done

libbsd failures- atsamv bsp bset

2020-04-02 Thread Joel Sherrill

Hi

The atsamv BSP bset fails with this:

[1846/1914] Linking build/arm-rtems5-atsamv-default/epoch01.exe
/home/joel/rtems-cron-5/rtems-source-builder/rtems/build/tmp/sb-1001-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:linkcmds.base:326
cannot move location counter backwards (from 2047ab60 to
2045f000)
collect2: error: ld returned 1 exit status

/home/joel/rtems-cron-5/rtems-source-builder/rtems/build/tmp/sb-1001-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:linkcmds.base:326
cannot move location counter backwards (from 2053f960 to
2045f000)
collect2: error: ld returned 1 exit status

/home/joel/rtems-cron-5/rtems-source-builder/rtems/build/tmp/sb-1001-staging/bin/../lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:linkcmds.base:326
cannot move location counter backwards (from 2053f960 to
2045f000)
collect2: error: ld returned 1 exit status

Waf: Leaving directory
`/home/joel/rtems-cron-5/rtems-source-builder/rtems/build/rtems-libbsd-v236295c67ed0e2ae5d98cf3bbbe253b4a311e8af-x86_64-linux-gnu-1/rtems-libbsd-236295c67ed0e2ae5d98cf3bbbe253b4a311e8af/build/arm-rtems5-atsamv-default'
Build failed
 -> task in 'commands01.exe' failed with exit status 1 (run with -v to
display more information)
 -> task in 'dhcpcd02.exe' failed with exit status 1 (run with -v to
display more information)
 -> task in 'dhcpcd01.exe' failed with exit status 1 (run with -v to
display more information)
shell cmd failed: /bin/sh -ex
 /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/

Is there a mechanism to account for tests that don't fit?

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

[PATCH docs] user/bsp-build: Fix broken cross references.

2020-04-02 Thread G S Niteesh Babu

The QuickStartBSPBuild_Manual and QuickStartBSPBuild_RSB are
missing the underscore in front. This breaks any reference to
them from other sections.
---
 user/start/bsp-build.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/user/start/bsp-build.rst b/user/start/bsp-build.rst
index 33ecb29..59da2fd 100644
--- a/user/start/bsp-build.rst
+++ b/user/start/bsp-build.rst
@@ -29,7 +29,7 @@ use one of the listed methods to build the BSP.
 In the output in this section the base directory :file:`$HOME/quick-start` was
 replaced by ``$BASE``.
 
-.. QuickStartBSPBuild_RSB:
+.. _QuickStartBSPBuild_RSB:
 
 RSB BSP Build
 -
@@ -92,7 +92,7 @@ The RSB BSP build can be customised with following RSB 
command line options:
 If you have built a BSP with the RSB, you can move on to
 :ref:`QuickStartBSPTest`.
 
-.. QuickStartBSPBuild_Manual:
+.. _QuickStartBSPBuild_Manual:
 
 Manual BSP Build
 
-- 
2.17.1

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

[PATCH v2] Tests for inttype.h methods

2020-04-02 Thread Eshan dhawan

---
 testsuites/psxtests/psxinttypes01/init.c | 25 +---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/testsuites/psxtests/psxinttypes01/init.c 
b/testsuites/psxtests/psxinttypes01/init.c
index 030aa2aa57..d86313b251 100644
--- a/testsuites/psxtests/psxinttypes01/init.c
+++ b/testsuites/psxtests/psxinttypes01/init.c
@@ -6,6 +6,7 @@
 /*
  * SPDX-License-Identifier: BSD-2-Clause
  *
+ * Copyright (C) 2020, Eshan Dhawan 
  * Copyright (C) 2019, Aditya Upadhyay and Vaibhav Gupta
  *
  * Redistribution and use in source and binary forms, with or without
@@ -64,11 +65,29 @@ rtems_task Init(rtems_task_argument ignored)
   wchar_t  *nptr2_n_errange = L"-99";
   wchar_t  *endptr2 = NULL;
 
-  intmax_t  result_strtoimax;
+  intmax_t  result_strtoimax, result_imaxabs, input_1, input_2 ;
+  imaxdiv_t result_exp, result_imaxdiv ;
   uintmax_t result_strtoumax;
 
   TEST_BEGIN();
-
+  /* Test for imaxabs */ 
+  input_1 = -10 ;
+  result_imaxabs = 10 ;
+  rtems_test_assert( imaxabs(input_1) == result_imaxabs );
+   
+  input_1 = 10 ;
+  result_imaxabs = 10 ;
+  rtems_test_assert( imaxabs(input_1) == result_imaxabs );
+
+  /* Test for imaxdiv */
+  input_1 = 10 ;
+  input_2 = 3 ;
+  result_exp.quot = input_1 / input_2 ;
+  result_exp.rem =  input_1 % input_2 ;
+  result_imaxdiv = imaxdiv(input_1, input_2) ; 
+  rtems_test_assert( result_imaxdiv.quot == result_exp.quot && 
+  result_imaxdiv.rem == result_exp.rem ); 
+   
   /* Test for strtoimax  */
   puts( "\nstrtoimax Testcases" );
   puts( "Valid Inputs - Positive Number" );
@@ -83,7 +102,7 @@ rtems_task Init(rtems_task_argument ignored)
   rtems_test_assert( result_strtoimax == -123 );
 
   puts( "Final string pointed by endptr" );
-  rtems_test_assert( endptr1 == ( nptr1_n + 4 ) );
+  rtems_test_assert( endptr1 == ( nptr1_n + 4 ) ); 
 
   puts( "Valid Input - Positive Number - Number out of Range" );
   result_strtoimax = strtoimax( nptr1_p_errange, , base );
-- 
2.17.1

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

Re: RTEMS Release Snapshot: 5.0.0-m2004 (02 Apr 2020)

2020-04-02 Thread Sebastian Huber


Hello,

in the readme file:

  cd
  mkdir -p development/rtems
  wget 
https://ftp.rtems.org/pub/rtems/releases/sources/rtems-source-builder-5.0.0-m2004.tar.xz
  tar jxf rtems-source-builder-5.0.0-m2004.tar.xz
  cd rtems-source-builder-5.0.0-m2004/rtems

there is probably a

  cd development/rtems

missing after the mkdir.

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

RTEMS Release Snapshot: 5.0.0-m2004 (02 Apr 2020)

2020-04-02 Thread chrisj

RTEMS Release Build - 5.0.0-m2004

RTEMS 5 Release snapshot m2004 is avaliable for testing.
It can be found at:

 https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m2004

Please test and report any issues to the u...@rtems.org or devel@rtems.org
mailing lists or please raise a ticket.

If you are part of the RTEMS testing program please build on your preferred
host posting build and BSP test results to bu...@rtems.org.

This is a development release and may have errors and be unstable.

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

[PATCH] bsps/console: Support device file system

2020-04-02 Thread Sebastian Huber

Update #3926.
---
 bsps/include/bsp/fatal.h  |  2 --
 bsps/shared/dev/serial/console-termios-init.c | 28 +++
 2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/bsps/include/bsp/fatal.h b/bsps/include/bsp/fatal.h
index 3f8e1eb591..cd3c42aec0 100644
--- a/bsps/include/bsp/fatal.h
+++ b/bsps/include/bsp/fatal.h
@@ -38,8 +38,6 @@ typedef enum {
   BSP_FATAL_CONSOLE_REGISTER_DEV_0,
   BSP_FATAL_CONSOLE_REGISTER_DEV_1,
   BSP_FATAL_CONSOLE_NO_DEV,
-  BSP_FATAL_CONSOLE_INSTALL_0,
-  BSP_FATAL_CONSOLE_INSTALL_1,
   BSP_FATAL_CONSOLE_REGISTER_DEV_2,
 
   /* ARM fatal codes */
diff --git a/bsps/shared/dev/serial/console-termios-init.c 
b/bsps/shared/dev/serial/console-termios-init.c
index a01a75abf2..87806cc39d 100644
--- a/bsps/shared/dev/serial/console-termios-init.c
+++ b/bsps/shared/dev/serial/console-termios-init.c
@@ -32,31 +32,35 @@ rtems_device_driver console_initialize(
   void  *arg
 )
 {
-  bool console_device_done = false;
+  bool console_device_done;
 
   rtems_termios_initialize();
+  console_device_done = false;
 
   for ( minor = 0; minor < console_device_count; ++minor ) {
-const console_device *ctx = _device_table[ minor ];
-rtems_status_code sc;
+const console_device *ctx;
+
+ctx = _device_table[ minor ];
 
 if ( ( *ctx->probe )( ctx->context ) ) {
-  sc = rtems_termios_device_install(
-ctx->device_file,
+  const char *device_file;
+
+  if ( console_device_done ) {
+device_file = ctx->device_file;
+  } else {
+device_file = CONSOLE_DEVICE_NAME;
+  }
+
+  (void) rtems_termios_device_install(
+device_file,
 ctx->handler,
 ctx->flow,
 ctx->context
   );
-  if ( sc != RTEMS_SUCCESSFUL ) {
-bsp_fatal( BSP_FATAL_CONSOLE_INSTALL_0 );
-  }
 
   if ( !console_device_done ) {
 console_device_done = true;
-
-if ( link( ctx->device_file, CONSOLE_DEVICE_NAME ) != 0 ) {
-  bsp_fatal( BSP_FATAL_CONSOLE_INSTALL_1 );
-}
+(void) link( CONSOLE_DEVICE_NAME, ctx->device_file );
   }
 }
   }
-- 
2.16.4

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

Re: [PATCH rtems-docs] user/rsb: Fix typos (#3922)

2020-04-02 Thread Chris Johns


Pushed. Thanks.

Chris

On 2020-04-02 19:18, Mritunjay wrote:

Closes #3922
---
  user/rsb/configuration.rst| 14 +++---
  user/rsb/cross-canadian-cross.rst |  2 +-
  user/rsb/project-sets.rst |  2 +-
  user/rsb/third-party-packages.rst |  2 +-
  4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/user/rsb/configuration.rst b/user/rsb/configuration.rst
index fc387a1..8c8c87f 100644
--- a/user/rsb/configuration.rst
+++ b/user/rsb/configuration.rst
@@ -181,7 +181,7 @@ errors that can arise.
  
  The protocol option lets you set a specific protocol. The ``git://`` prefix

  used by the RSB to select a git repository can be removed using *none* or
-replaced with one of the standard git protcols.
+replaced with one of the standard git protocols.
  
  CVS

  ~~~
@@ -315,7 +315,7 @@ Maps are declared anywhere in the map using the map 
directive:
  
1. The map is set to ``my-special-map``.
  
-Any macro defintions following a map declaration are placed in that map and the

+Any macro definitions following a map declaration are placed in that map and 
the
  default map is ``global`` when loading a file. Maps are selected in
  configuration files by using the ``%select`` directive:
  
@@ -328,7 +328,7 @@ if present return that value else the ``global`` map is used. Any new macros or

  changes update only the ``global`` map. This may change in future releases so
  please make sure you use the ``override`` attribute.
  
-The macro files specificed on the command line are looked for in the

+The macro files specified on the command line are looked for in the
  ``_configdir`` paths. See <> variable for details. Included
  files need to add the ``%{_configdir}`` macro to the start of the file.
  
@@ -636,8 +636,8 @@ source packages based on the outer configuration options:

  The remainder of the script is broken in to the various phases of a build. 
They
  are:
  
-. Preperation

-. Bulding
+. Preparation
+. Building
  . Installing, and
  . Cleaning
  
@@ -799,8 +799,8 @@ To build this you can use something similar to:
  
  The build is for a FreeBSD host and the prefix is for user installed

  packages. In this example I cannot let the source builder perform the install
-because I never run the RSB with root priviledges so a build set or bset tar
-file is created. This can then be installed using root priviledges.
+because I never run the RSB with root privileges so a build set or bset tar
+file is created. This can then be installed using root privileges.
  
  The command also supplies the ``--trace`` option. The output in the log file

  will contain all the macros.
diff --git a/user/rsb/cross-canadian-cross.rst 
b/user/rsb/cross-canadian-cross.rst
index 8eceed3..7ccd6c3 100644
--- a/user/rsb/cross-canadian-cross.rst
+++ b/user/rsb/cross-canadian-cross.rst
@@ -37,7 +37,7 @@ To build the Curl package for RTEMS you enter the RSB command:
  
2. The ``--host`` command is the RTEMS architecture and version.
  
-  3. The BSP is built and installed in the prefix. The arhcitecture must match

+  3. The BSP is built and installed in the prefix. The architecture must match
   the ``--host`` architecture.
  
  .. note: Installing Into Different Directories

diff --git a/user/rsb/project-sets.rst b/user/rsb/project-sets.rst
index 6eb8729..54a3f8e 100644
--- a/user/rsb/project-sets.rst
+++ b/user/rsb/project-sets.rst
@@ -154,7 +154,7 @@ Patches are added to a component's name and in the 
``%prep:`` section the
  patches can be set up, meaning they are applied to source. The patches are
  applied in the order they are added. If there is a dependency make sure you
  order the patches correctly when you add them. You can add any number of
-patches and the RSB will handle them efficently.
+patches and the RSB will handle them efficiently.
  
  Patches can have options. These are added before the patch URL. If no options

  are provided the patch's setup default options are used.
diff --git a/user/rsb/third-party-packages.rst 
b/user/rsb/third-party-packages.rst
index 0d9fa81..8610650 100644
--- a/user/rsb/third-party-packages.rst
+++ b/user/rsb/third-party-packages.rst
@@ -133,7 +133,7 @@ A custom RTEMS patch to an executate's source code can turn 
it into a function
  that can be called by the RTEMS shell. Users can call the function in their
  executables simulating the running of the package's command. If the package
  does not export the code in a suitable manner please contact the project's
-commuinity and see if you can work with them to provide a way for the code to
+community and see if you can work with them to provide a way for the code to
  be exported. This may be difficult because exporting internal headers and
  functions opens the project up to API compatibility issues they did not have
  before. In the simplest case attempting to get the code into a static library


___
devel mailing list
devel@rtems.org

Re: [PATCH] config: Remove filesystem entry config options

2020-04-02 Thread Sebastian Huber


On 02/04/2020 11:11, Chris Johns wrote:


On 2020-04-02 18:39, Sebastian Huber wrote:

On 31/03/2020 12:48, Sebastian Huber wrote:


Remove the following undocumented configuration options:

* CONFIGURE_FILESYSTEM_ENTRY_DEVFS

* CONFIGURE_FILESYSTEM_ENTRY_DOSFS

* CONFIGURE_FILESYSTEM_ENTRY_FTPFS

* CONFIGURE_FILESYSTEM_ENTRY_IMFS

* CONFIGURE_FILESYSTEM_ENTRY_JFFS2

* CONFIGURE_FILESYSTEM_ENTRY_NFS

* CONFIGURE_FILESYSTEM_ENTRY_RFS

* CONFIGURE_FILESYSTEM_ENTRY_TFTPFS
What about this change? I would like to get the configuration cleaned 
up and fully documented before the 5.1 release.


OK and understandable as it is an on going task.

How much more is there for this task? 


This and this:

https://lists.rtems.org/pipermail/devel/2020-April/058842.html

Plus everything a potential review finds.

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

Re: RTEMS 5 release status

2020-04-02 Thread Christian Mauderer

On 02/04/2020 11:10, Chris Johns wrote:
> On 2020-04-02 20:02, Christian Mauderer wrote:
>> Hello Chris,
>>
>> I don't think that littlevgl is such an essential or stable package yet.
> 
> Sure.
> 
>> Currently I know of exactly one project using this repository and that's
>> only because I added it.
> 
> I have used it successfully however not on RTEMS. It is great to use.
> 
> Chris

Yes, you pointed me toward it last year. It's a nice library. I meant
that I know exactly one project using the rtems-littlevgl repository. In
this project I'll most likely not use a release version but track the
master instead. So I don't think that it's necessary to put effort into
including rtems-littlevgl into this release.

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

Re: Documentation of Application Configuration Options

2020-04-02 Thread Chris Johns


On 2020-04-02 18:57, Sebastian Huber wrote:

Hello,

I reworked the documentation of the application configuration options in 
the last weeks. All 149 options are now documented. Several options are 
obsolete in RTEMS 5.1.


The documentation is generated via a script from these specification items:

https://git.rtems.org/sebh/rtems-qual.git/tree/spec/acfg/opt/

Please review the documentation, there were changes throughout all options.

https://docs.rtems.org/branches/master/c-user/config/index.html


Thanks for these changes.

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

Re: [PATCH] eng: Add documentation guidelines

2020-04-02 Thread Chris Johns


On 2020-04-02 19:25, Sebastian Huber wrote:

Start with templates for the application configuration options.

Remove "Format to be followed for making changes in this file" from
c-user.

Update #3910.


OK.

Chris


---
  c-user/config/intro.rst | 44 ---
  eng/doc-guide.rst   | 79 +
  eng/management.rst  |  1 +
  3 files changed, 80 insertions(+), 44 deletions(-)
  create mode 100644 eng/doc-guide.rst

diff --git a/c-user/config/intro.rst b/c-user/config/intro.rst
index 46267d7..4c2f715 100644
--- a/c-user/config/intro.rst
+++ b/c-user/config/intro.rst
@@ -151,50 +151,6 @@ In general,  is very accurate when 
given enough
  information.  However, it is quite easy to use a library and forget to account
  for its resources.
  
-Format to be followed for making changes in this file

-=
-
-MACRO NAME:
-  Should be alphanumeric. Can have '_' (underscore).
-
-DATA TYPE:
-  Please refer to all existing formats.
-
-RANGE:
-  The range depends on the Data Type of the macro.
-
-  - If the data type is of type task priority, then its value should be an
-integer in the range of 1 to 255.
-
-  - If the data type is an integer, then it can have numbers, characters (in
-case the value is defined using another macro) and arithmetic operations
-(+, -, \*, /).
-
-  - If the data type is a function pointer the first character should be an
-alphabet or an underscore. The rest of the string can be alphanumeric.
-
-  - If the data type is RTEMS Attributes or RTEMS Mode then the string should
-be alphanumeric.
-
-  - If the data type is RTEMS NAME then the value should be an integer>=0 or
-``RTEMS_BUILD_NAME( 'U', 'I', '1', ' ' )``
-
-DEFAULT VALUE:
-  The default value should be in the following formats- Please note that the
-  '.' (full stop) is necessary.
-
-  - In case the value is not defined then: This is not defined by default.
-
-  - If we know the default value then: The default value is XXX.
-
-  - If the default value is BSP Specific then: This option is BSP specific.
-
-DESCRIPTION:
-  The description of the macro. (No specific format)
-
-NOTES:
-  Any further notes. (No specific format)
-
  Configuration Example
  =
  
diff --git a/eng/doc-guide.rst b/eng/doc-guide.rst

new file mode 100644
index 000..cdcd04f
--- /dev/null
+++ b/eng/doc-guide.rst
@@ -0,0 +1,79 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+
+.. _DocGuide:
+
+Documentation Guidelines
+
+
+Application Configuration Options
+=
+
+Add at least an index entry and a label for the configuration option.  Use a
+pattern of ``CONFIGURE_[A-Z0-9_]+`` for the option name.  Use the following
+template for application configuration feature options:
+
+.. code-block:: rst
+
+.. index:: CONFIGURE_FEATURE
+
+.. _CONFIGURE_FEATURE:
+
+CONFIGURE_FEATURE
+-
+
+CONSTANT:
+``CONFIGURE_FEATURE``
+
+OPTION TYPE:
+This configuration option is a boolean feature define.
+
+DEFAULT CONFIGURATION:
+If this configuration option is undefined, then the described feature 
is not
+enabled.
+
+DESCRIPTION:
+In case this configuration option is defined, then feature happens.
+
+NOTES:
+Keep the description short.  Add all special cases, usage notes, error
+conditions, configuration dependencies, references, etc. here to the 
notes.
+
+Use the following template for application configuration integer and
+initializer options:
+
+.. code-block:: rst
+
+.. index:: CONFIGURE_VALUE
+
+.. _CONFIGURE_VALUE:
+
+CONFIGURE_VALUE
+-
+
+CONSTANT:
+``CONFIGURE_VALUE``
+
+OPTION TYPE:
+This configuration option is an integer (or initializer) define.
+
+DEFAULT VALUE:
+The default value is X.
+
+VALUE CONSTRAINTS:
+The value of this configuration option shall satisfy all of the 
following
+constraints:
+
+* It shall be greater than or equal to A.
+
+* It shall be less than or equal to B.
+
+* It shall meet C.
+
+DESCRIPTION:
+The value of this configuration option defines the Y of Z in W.
+
+NOTES:
+Keep the description short.  Add all special cases, usage notes, error
+conditions, configuration dependencies, references, etc. here to the 
notes.
diff --git a/eng/management.rst b/eng/management.rst
index 6eb4217..6a8e057 100644
--- a/eng/management.rst
+++ b/eng/management.rst
@@ -16,6 +16,7 @@ Software Development Management
  vc-users
  vc-authors
  coding
+doc-guide
  python-devel
  change-management
  issue-tracking


___
devel mailing list
devel@rtems.org

Re: [PATCH] config: Remove filesystem entry config options

2020-04-02 Thread Chris Johns


On 2020-04-02 18:39, Sebastian Huber wrote:

On 31/03/2020 12:48, Sebastian Huber wrote:


Remove the following undocumented configuration options:

* CONFIGURE_FILESYSTEM_ENTRY_DEVFS

* CONFIGURE_FILESYSTEM_ENTRY_DOSFS

* CONFIGURE_FILESYSTEM_ENTRY_FTPFS

* CONFIGURE_FILESYSTEM_ENTRY_IMFS

* CONFIGURE_FILESYSTEM_ENTRY_JFFS2

* CONFIGURE_FILESYSTEM_ENTRY_NFS

* CONFIGURE_FILESYSTEM_ENTRY_RFS

* CONFIGURE_FILESYSTEM_ENTRY_TFTPFS
What about this change? I would like to get the configuration cleaned up 
and fully documented before the 5.1 release.


OK and understandable as it is an on going task.

How much more is there for this task?

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

Re: RTEMS 5 release status

2020-04-02 Thread Chris Johns


On 2020-04-02 20:02, Christian Mauderer wrote:

Hello Chris,

I don't think that littlevgl is such an essential or stable package yet.


Sure.


Currently I know of exactly one project using this repository and that's
only because I added it.


I have used it successfully however not on RTEMS. It is great to use.

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

Re: RTEMS 5 release status

2020-04-02 Thread Christian Mauderer

Hello Chris,

I don't think that littlevgl is such an essential or stable package yet.
Currently I know of exactly one project using this repository and that's
only because I added it.

Best regards

Christian

On 02/04/2020 11:00, Chris Johns wrote:
> Hi,
> 
> All OK and thanks for letting us know.
> 
> I am not sure littlevgl is in the release. Maybe it should be?
> 
> I am picking up packages via the RSB.
> 
> Chris
> 
> On 2020-04-02 19:03, Christian Mauderer wrote:
>> Hello Chris,
>>
>> sorry, I missed that mail this morning. I pushed a small patch to
>> rtems-littlevgl that fixes a build problem with python3.
>>
>> I hope I didn't make problems with that.
>>
>> Best regards
>>
>> Christian
>>
>> On 02/04/2020 01:31, Chris Johns wrote:
>>> Hello,
>>>
>>> Please read if you have commit access.
>>>
>>> I am cleaning up a few issues like the release README.txt to match
>>> moving all the released source in to `sources`, then updating the
>>> documentation to reference this and then I will create a 5.0.0-m2004
>>> snapshot.
>>>
>>> After this I will be looking to make a branch so please wait for an ack
>>> from Joel, Gedare or myself for any pushes to any repo. We are in a
>>> slushy state to fix tickets.
>>>
>>> The sooner we clear the tickets from 5.1 the sooner I can create the
>>> branch in the repos and the repos can be open again.
>>>
>>> You help is needed and welcomed.
>>>
>>> Thanks
>>> Chris
>>>
>>> ___
>>> 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

Re: RTEMS 5 release status

2020-04-02 Thread Chris Johns


Hi,

All OK and thanks for letting us know.

I am not sure littlevgl is in the release. Maybe it should be?

I am picking up packages via the RSB.

Chris

On 2020-04-02 19:03, Christian Mauderer wrote:

Hello Chris,

sorry, I missed that mail this morning. I pushed a small patch to
rtems-littlevgl that fixes a build problem with python3.

I hope I didn't make problems with that.

Best regards

Christian

On 02/04/2020 01:31, Chris Johns wrote:

Hello,

Please read if you have commit access.

I am cleaning up a few issues like the release README.txt to match
moving all the released source in to `sources`, then updating the
documentation to reference this and then I will create a 5.0.0-m2004
snapshot.

After this I will be looking to make a branch so please wait for an ack
from Joel, Gedare or myself for any pushes to any repo. We are in a
slushy state to fix tickets.

The sooner we clear the tickets from 5.1 the sooner I can create the
branch in the repos and the repos can be open again.

You help is needed and welcomed.

Thanks
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 v5] doc: Moving M68K BSP Content to User Manual (#3905)

2020-04-02 Thread Mritunjay

Fixed trailing spaces.
---
 user/bsps/bsps-m68k.rst | 190 +++-
 1 file changed, 188 insertions(+), 2 deletions(-)

diff --git a/user/bsps/bsps-m68k.rst b/user/bsps/bsps-m68k.rst
index 60882fb..bdb516b 100644
--- a/user/bsps/bsps-m68k.rst
+++ b/user/bsps/bsps-m68k.rst
@@ -53,7 +53,19 @@ TODO.
 mcf5329
 ===
 
-TODO.
+Overview
+
+
+This BSP is heavily based on the MCF5235 BSP. The MCF5329EVB is a Motorola
+evaluation board (Zoom) with a LogicPD MCF5329-10 SODIMM-144 card. The
+development kit features the MCF5329 based Fire Engine, as well as a plug-in
+system-on-module containing 32 MB of DDR-SDRAM. The board also includes 2 MB of
+boot flash, 16 MB of NAND flash, a core frequency of 240MHz, an onboard 800x600
+LCD controller, FEC, USB, uarts, CAN bus, QSPI, I2C, and 10/100 Ethernet.
+
+You can find the link to MCF5329 Reference Manual below:
+
+* `MCF5329 Reference Manual 
`_
 
 mrm332
 ==
@@ -73,7 +85,181 @@ TODO.
 mvme162
 ===
 
-TODO.
+Overview
+
+
+The MVME162 family provides OEMs and solution developers an ideal platform for
+embedded monitoring and control apllications it allows an OEM to minimize
+engineering expenses while integrating value-added hardware and software
+applications onto an off-the-shelf product. In order to provide the wide range
+of solutions, the MVME162 allows a variety of MPU, memory, and interface
+options such as floating-point, Ethernet, SCSI, and VME. The result is a
+variation of the MVME162 which most closely fits the application requirement.
+
+There are a large number of model variations on this board. This was the first
+user submitted BSP and continues to be a fairly popular simply because at one
+point it was the highest selling VMEBus board of all time.
+
+Board Setup
+---
+
+We will setup the RTEMS Lab Board initally to proceed further for the setup
+of TFTP transfer.
+
+The env settings are:
+
+.. code-block:: none
+
+MPU Clock Speed =25Mhz
+162-Bug>env
+Bug or System environment [B/S] = B?
+Field Service Menu Enable [Y/N] = N?
+   Remote Start Method Switch [G/M/B/N] = B?
+   Probe System for Supported I/O Controllers [Y/N] = Y?
+   Negate VMEbus SYSFAIL* Always [Y/N] = N?
+   Local SCSI Bus Reset on Debugger Startup [Y/N] = N?
+   Local SCSI Bus Negotiations Type [A/S/N]   = A?
+   Industry Pack Reset on Debugger Startup [Y/N]  = Y?
+   Ignore CFGA Block on a Hard Disk Boot [Y/N]= Y?
+   Auto Boot Enable [Y/N]   = N?
+   Auto Boot at power-up only [Y/N] = Y?
+   Auto Boot Controller LUN = 00?
+   Auto Boot Device LUN = 00?
+   Auto Boot Abort Delay= 15?
+   Auto Boot Default String [NULL for a empty string] = ?
+   ROM Boot Enable [Y/N]= N?
+   ROM Boot at power-up only [Y/N]  = Y?
+   ROM Boot Enable search of VMEbus [Y/N] = N?
+   ROM Boot Abort Delay = 0?
+   ROM Boot Direct Starting Address = FF80?
+   ROM Boot Direct Ending Address   = FFDC?
+   Network Auto Boot Enable [Y/N]   = N?
+   Network Auto Boot at power-up only [Y/N] = Y?
+   Network Auto Boot Controller LUN = 00?
+   Network Auto Boot Device LUN = 00?
+   Network Auto Boot Abort Delay= 5?
+   Network Auto Boot Configuration Parameters Pointer (NVRAM) = FFE0FF00?
+   Memory Search Starting Address   = ?
+   Memory Search Ending Address = 0100?
+   Memory Search Increment Size = 0001?
+   Memory Search Delay Enable [Y/N] = N?
+   Memory Search Delay Address  = D20F?
+   Memory Size Enable [Y/N] = Y?
+   Memory Size Starting Address = ?
+   Memory Size Ending Address   = 0100?
+   Base Address of Dynamic Memory   = ?
+   Size of Parity Memory= ?
+   Size of ECC Memory Board #0  = 0100?
+   Size of ECC Memory Board #1  = ?
+   Base Address of Static Memory= FFE0?
+   Size of Static Memory= 0002?
+   Slave Enable #1 [Y/N] = Y?
+   Slave Starting Address #1 = ?
+   Slave Ending Address #1   = 00FF?
+   Slave Address Translation Address #1 = ?
+   Slave Address Translation Select #1  = ?
+   Slave Control #1 = 03FF?
+   Slave Enable #2 [Y/N] = N?
+   Slave Starting Address #2 = ?
+   Slave Ending Address #2   = ?
+   Slave Address Translation Address #2 = ?
+   Slave Address Translation Select #2  = ?
+   Slave Control #2 = ?
+   Master Enable #1 [Y/N] = Y?
+   Master Starting Address #1 = 0100?
+   Master Ending Address #1   = EFFF?
+   Master Control #1 = 0D?
+   Master Enable #2 [Y/N] = N?
+   Master Starting Address #2 = ?
+   Master Ending Address #2   =

[PATCH] eng: Add documentation guidelines

2020-04-02 Thread Sebastian Huber

Start with templates for the application configuration options.

Remove "Format to be followed for making changes in this file" from
c-user.

Update #3910.
---
 c-user/config/intro.rst | 44 ---
 eng/doc-guide.rst   | 79 +
 eng/management.rst  |  1 +
 3 files changed, 80 insertions(+), 44 deletions(-)
 create mode 100644 eng/doc-guide.rst

diff --git a/c-user/config/intro.rst b/c-user/config/intro.rst
index 46267d7..4c2f715 100644
--- a/c-user/config/intro.rst
+++ b/c-user/config/intro.rst
@@ -151,50 +151,6 @@ In general,  is very accurate when 
given enough
 information.  However, it is quite easy to use a library and forget to account
 for its resources.
 
-Format to be followed for making changes in this file
-=
-
-MACRO NAME:
-  Should be alphanumeric. Can have '_' (underscore).
-
-DATA TYPE:
-  Please refer to all existing formats.
-
-RANGE:
-  The range depends on the Data Type of the macro.
-
-  - If the data type is of type task priority, then its value should be an
-integer in the range of 1 to 255.
-
-  - If the data type is an integer, then it can have numbers, characters (in
-case the value is defined using another macro) and arithmetic operations
-(+, -, \*, /).
-
-  - If the data type is a function pointer the first character should be an
-alphabet or an underscore. The rest of the string can be alphanumeric.
-
-  - If the data type is RTEMS Attributes or RTEMS Mode then the string should
-be alphanumeric.
-
-  - If the data type is RTEMS NAME then the value should be an integer>=0 or
-``RTEMS_BUILD_NAME( 'U', 'I', '1', ' ' )``
-
-DEFAULT VALUE:
-  The default value should be in the following formats- Please note that the
-  '.' (full stop) is necessary.
-
-  - In case the value is not defined then: This is not defined by default.
-
-  - If we know the default value then: The default value is XXX.
-
-  - If the default value is BSP Specific then: This option is BSP specific.
-
-DESCRIPTION:
-  The description of the macro. (No specific format)
-
-NOTES:
-  Any further notes. (No specific format)
-
 Configuration Example
 =
 
diff --git a/eng/doc-guide.rst b/eng/doc-guide.rst
new file mode 100644
index 000..cdcd04f
--- /dev/null
+++ b/eng/doc-guide.rst
@@ -0,0 +1,79 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+
+.. _DocGuide:
+
+Documentation Guidelines
+
+
+Application Configuration Options
+=
+
+Add at least an index entry and a label for the configuration option.  Use a
+pattern of ``CONFIGURE_[A-Z0-9_]+`` for the option name.  Use the following
+template for application configuration feature options:
+
+.. code-block:: rst
+
+.. index:: CONFIGURE_FEATURE
+
+.. _CONFIGURE_FEATURE:
+
+CONFIGURE_FEATURE
+-
+
+CONSTANT:
+``CONFIGURE_FEATURE``
+
+OPTION TYPE:
+This configuration option is a boolean feature define.
+
+DEFAULT CONFIGURATION:
+If this configuration option is undefined, then the described feature 
is not
+enabled.
+
+DESCRIPTION:
+In case this configuration option is defined, then feature happens.
+
+NOTES:
+Keep the description short.  Add all special cases, usage notes, error
+conditions, configuration dependencies, references, etc. here to the 
notes.
+
+Use the following template for application configuration integer and
+initializer options:
+
+.. code-block:: rst
+
+.. index:: CONFIGURE_VALUE
+
+.. _CONFIGURE_VALUE:
+
+CONFIGURE_VALUE
+-
+
+CONSTANT:
+``CONFIGURE_VALUE``
+
+OPTION TYPE:
+This configuration option is an integer (or initializer) define.
+
+DEFAULT VALUE:
+The default value is X.
+
+VALUE CONSTRAINTS:
+The value of this configuration option shall satisfy all of the 
following
+constraints:
+
+* It shall be greater than or equal to A.
+
+* It shall be less than or equal to B.
+
+* It shall meet C.
+
+DESCRIPTION:
+The value of this configuration option defines the Y of Z in W.
+
+NOTES:
+Keep the description short.  Add all special cases, usage notes, error
+conditions, configuration dependencies, references, etc. here to the 
notes.
diff --git a/eng/management.rst b/eng/management.rst
index 6eb4217..6a8e057 100644
--- a/eng/management.rst
+++ b/eng/management.rst
@@ -16,6 +16,7 @@ Software Development Management
 vc-users
 vc-authors
 coding
+doc-guide
 python-devel
 change-management
 issue-tracking
-- 
2.16.4

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

[PATCH rtems-docs] user/rsb: Fix typos (#3922)

2020-04-02 Thread Mritunjay

Closes #3922
---
 user/rsb/configuration.rst| 14 +++---
 user/rsb/cross-canadian-cross.rst |  2 +-
 user/rsb/project-sets.rst |  2 +-
 user/rsb/third-party-packages.rst |  2 +-
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/user/rsb/configuration.rst b/user/rsb/configuration.rst
index fc387a1..8c8c87f 100644
--- a/user/rsb/configuration.rst
+++ b/user/rsb/configuration.rst
@@ -181,7 +181,7 @@ errors that can arise.
 
 The protocol option lets you set a specific protocol. The ``git://`` prefix
 used by the RSB to select a git repository can be removed using *none* or
-replaced with one of the standard git protcols.
+replaced with one of the standard git protocols.
 
 CVS
 ~~~
@@ -315,7 +315,7 @@ Maps are declared anywhere in the map using the map 
directive:
 
   1. The map is set to ``my-special-map``.
 
-Any macro defintions following a map declaration are placed in that map and the
+Any macro definitions following a map declaration are placed in that map and 
the
 default map is ``global`` when loading a file. Maps are selected in
 configuration files by using the ``%select`` directive:
 
@@ -328,7 +328,7 @@ if present return that value else the ``global`` map is 
used. Any new macros or
 changes update only the ``global`` map. This may change in future releases so
 please make sure you use the ``override`` attribute.
 
-The macro files specificed on the command line are looked for in the
+The macro files specified on the command line are looked for in the
 ``_configdir`` paths. See <> variable for details. Included
 files need to add the ``%{_configdir}`` macro to the start of the file.
 
@@ -636,8 +636,8 @@ source packages based on the outer configuration options:
 The remainder of the script is broken in to the various phases of a build. They
 are:
 
-. Preperation
-. Bulding
+. Preparation
+. Building
 . Installing, and
 . Cleaning
 
@@ -799,8 +799,8 @@ To build this you can use something similar to:
 
 The build is for a FreeBSD host and the prefix is for user installed
 packages. In this example I cannot let the source builder perform the install
-because I never run the RSB with root priviledges so a build set or bset tar
-file is created. This can then be installed using root priviledges.
+because I never run the RSB with root privileges so a build set or bset tar
+file is created. This can then be installed using root privileges.
 
 The command also supplies the ``--trace`` option. The output in the log file
 will contain all the macros.
diff --git a/user/rsb/cross-canadian-cross.rst 
b/user/rsb/cross-canadian-cross.rst
index 8eceed3..7ccd6c3 100644
--- a/user/rsb/cross-canadian-cross.rst
+++ b/user/rsb/cross-canadian-cross.rst
@@ -37,7 +37,7 @@ To build the Curl package for RTEMS you enter the RSB command:
 
   2. The ``--host`` command is the RTEMS architecture and version.
 
-  3. The BSP is built and installed in the prefix. The arhcitecture must match
+  3. The BSP is built and installed in the prefix. The architecture must match
  the ``--host`` architecture.
 
 .. note: Installing Into Different Directories
diff --git a/user/rsb/project-sets.rst b/user/rsb/project-sets.rst
index 6eb8729..54a3f8e 100644
--- a/user/rsb/project-sets.rst
+++ b/user/rsb/project-sets.rst
@@ -154,7 +154,7 @@ Patches are added to a component's name and in the 
``%prep:`` section the
 patches can be set up, meaning they are applied to source. The patches are
 applied in the order they are added. If there is a dependency make sure you
 order the patches correctly when you add them. You can add any number of
-patches and the RSB will handle them efficently.
+patches and the RSB will handle them efficiently.
 
 Patches can have options. These are added before the patch URL. If no options
 are provided the patch's setup default options are used.
diff --git a/user/rsb/third-party-packages.rst 
b/user/rsb/third-party-packages.rst
index 0d9fa81..8610650 100644
--- a/user/rsb/third-party-packages.rst
+++ b/user/rsb/third-party-packages.rst
@@ -133,7 +133,7 @@ A custom RTEMS patch to an executate's source code can turn 
it into a function
 that can be called by the RTEMS shell. Users can call the function in their
 executables simulating the running of the package's command. If the package
 does not export the code in a suitable manner please contact the project's
-commuinity and see if you can work with them to provide a way for the code to
+community and see if you can work with them to provide a way for the code to
 be exported. This may be difficult because exporting internal headers and
 functions opens the project up to API compatibility issues they did not have
 before. In the simplest case attempting to get the code into a static library
-- 
2.17.1

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

Re: RTEMS 5 release status

2020-04-02 Thread Christian Mauderer

Hello Chris,

sorry, I missed that mail this morning. I pushed a small patch to
rtems-littlevgl that fixes a build problem with python3.

I hope I didn't make problems with that.

Best regards

Christian

On 02/04/2020 01:31, Chris Johns wrote:
> Hello,
> 
> Please read if you have commit access.
> 
> I am cleaning up a few issues like the release README.txt to match
> moving all the released source in to `sources`, then updating the
> documentation to reference this and then I will create a 5.0.0-m2004
> snapshot.
> 
> After this I will be looking to make a branch so please wait for an ack
> from Joel, Gedare or myself for any pushes to any repo. We are in a
> slushy state to fix tickets.
> 
> The sooner we clear the tickets from 5.1 the sooner I can create the
> branch in the repos and the repos can be open again.
> 
> You help is needed and welcomed.
> 
> Thanks
> Chris
> 
> ___
> 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

Documentation of Application Configuration Options

2020-04-02 Thread Sebastian Huber


Hello,

I reworked the documentation of the application configuration options in 
the last weeks. All 149 options are now documented. Several options are 
obsolete in RTEMS 5.1.


The documentation is generated via a script from these specification items:

https://git.rtems.org/sebh/rtems-qual.git/tree/spec/acfg/opt/

Please review the documentation, there were changes throughout all options.

https://docs.rtems.org/branches/master/c-user/config/index.html

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

Re: [PATCH] config: Remove filesystem entry config options

2020-04-02 Thread Sebastian Huber


On 31/03/2020 12:48, Sebastian Huber wrote:


Remove the following undocumented configuration options:

* CONFIGURE_FILESYSTEM_ENTRY_DEVFS

* CONFIGURE_FILESYSTEM_ENTRY_DOSFS

* CONFIGURE_FILESYSTEM_ENTRY_FTPFS

* CONFIGURE_FILESYSTEM_ENTRY_IMFS

* CONFIGURE_FILESYSTEM_ENTRY_JFFS2

* CONFIGURE_FILESYSTEM_ENTRY_NFS

* CONFIGURE_FILESYSTEM_ENTRY_RFS

* CONFIGURE_FILESYSTEM_ENTRY_TFTPFS
What about this change? I would like to get the configuration cleaned up 
and fully documented before the 5.1 release.

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

Re: [PATCH] libdebugger: Fix ARMv7-M with -O0

2020-04-02 Thread Sebastian Huber


On 02/04/2020 08:46, Chris Johns wrote:


On 2020-04-02 16:53, Sebastian Huber wrote:

Hallo Chris,
On 21/03/2020 07:45, Sebastian Huber wrote:

On 20/03/2020 22:23, Chris Johns wrote:
On 20 Mar 2020, at 4:49 pm, Sebastian Huber 
 wrote:


On 20/03/2020 05:15, Chris Johns wrote:


On 19/3/20 7:52 pm, Sebastian Huber wrote:

The ARMv7-M architecture has no CP-15.  The inline assembly for the
CP-15 access leads to assembler errors if compiled with -O0.
I would like to understand this one in detail to see why there is 
cp15 in the build.

In ARMv7-M the system registers are memory mapped.

If I compile a Cortex-M based BSP with -O0, then I get:


BSP?

For example the atsamv BSP.
could you please have a look at this. Being able to build with -O0 is 
quite helpful during BSP development.


Is this important for 5.1.0? 


It is not absolutely necessary, but I regularly had to fix this locally. 
We have several ARMv7-M based BSPs. This was my first attempt to address 
this issue:


https://lists.rtems.org/pipermail/devel/2019-February/024914.html

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

Re: [PATCH] libdebugger: Fix ARMv7-M with -O0

2020-04-02 Thread Chris Johns


On 2020-04-02 16:53, Sebastian Huber wrote:

Hallo Chris,
On 21/03/2020 07:45, Sebastian Huber wrote:

On 20/03/2020 22:23, Chris Johns wrote:
On 20 Mar 2020, at 4:49 pm, Sebastian Huber 
 wrote:


On 20/03/2020 05:15, Chris Johns wrote:


On 19/3/20 7:52 pm, Sebastian Huber wrote:

The ARMv7-M architecture has no CP-15.  The inline assembly for the
CP-15 access leads to assembler errors if compiled with -O0.

I would like to understand this one in detail to see why there is cp15 in the 
build.

In ARMv7-M the system registers are memory mapped.

If I compile a Cortex-M based BSP with -O0, then I get:


BSP?

For example the atsamv BSP.
could you please have a look at this. Being able to build with -O0 is 
quite helpful during BSP development.


Is this important for 5.1.0?

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

[PATCH] bsps/arm: Add support for MPU region alignment

2020-04-02 Thread Sebastian Huber

---
 bsps/arm/shared/start/linkcmds.base | 21 +
 1 file changed, 21 insertions(+)

diff --git a/bsps/arm/shared/start/linkcmds.base 
b/bsps/arm/shared/start/linkcmds.base
index 1f5f1ef959..d0663cf97e 100644
--- a/bsps/arm/shared/start/linkcmds.base
+++ b/bsps/arm/shared/start/linkcmds.base
@@ -81,6 +81,17 @@ SECTIONS {
} > REGION_TEXT AT > REGION_TEXT_LOAD
.fini : ALIGN_WITH_INPUT {
KEEP (*(.fini))
+
+   /*
+* If requested, align the size of the combined start and text
+* section to the next power of two to meet MPU region
+* alignment requirements.
+*/
+   . = DEFINED (bsp_section_do_mpu_align) ?
+   bsp_section_start_begin
+   + ALIGN (. - bsp_section_start_begin,
+   1 << LOG2CEIL (. - bsp_section_start_begin)) : .;
+
bsp_section_text_end = .;
} > REGION_TEXT AT > REGION_TEXT_LOAD
bsp_section_text_size = bsp_section_text_end - bsp_section_text_begin;
@@ -248,6 +259,16 @@ SECTIONS {
*(set_pseudo_*);
 
KEEP (*(SORT(.rtemsroset.*)))
+
+   /*
+* If requested, align the size of the rodata section to the
+* next power of two to meet MPU region alignment requirements.
+*/
+   . = DEFINED (bsp_section_do_mpu_align) ?
+   bsp_section_rodata_begin
+   + ALIGN (. - bsp_section_rodata_begin,
+   1 << LOG2CEIL (. - bsp_section_rodata_begin)) : .;
+
bsp_section_rodata_end = .;
} > REGION_RODATA AT > REGION_RODATA_LOAD
bsp_section_rodata_size = bsp_section_rodata_end - 
bsp_section_rodata_begin;
-- 
2.16.4

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

[PATCH] arm: ARMv7-M statically initialized vector table

2020-04-02 Thread Sebastian Huber

Statically initialize the ARMv7-M vector table to allow a placement in
ROM with read-only MPU settings.

Change licence to BSD-2-Clause in some files.
---
 bsps/arm/shared/clock/clock-armv7m.c  | 39 --
 bsps/arm/shared/irq/irq-armv7m.c  | 50 +++
 bsps/arm/shared/start/start.S | 10 ++---
 cpukit/score/cpu/arm/armv7m-initialize.c  | 44 
 cpukit/score/cpu/arm/include/rtems/score/armv7m.h |  2 +
 5 files changed, 93 insertions(+), 52 deletions(-)

diff --git a/bsps/arm/shared/clock/clock-armv7m.c 
b/bsps/arm/shared/clock/clock-armv7m.c
index 7a51690562..255de1ca42 100644
--- a/bsps/arm/shared/clock/clock-armv7m.c
+++ b/bsps/arm/shared/clock/clock-armv7m.c
@@ -1,15 +1,29 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /*
- * Copyright (c) 2011, 2018 Sebastian Huber.  All rights reserved.
+ * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+ * Copyright (C) 2011, 2018 Sebastian Huber
  *
- *  embedded brains GmbH
- *  Dornierstr. 4
- *  82178 Puchheim
- *  Germany
- *  
+ * 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.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY 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.
  */
 
 #include 
@@ -29,7 +43,7 @@ static uint32_t _ARMV7M_TC_get_timecount(struct timecounter 
*base)
   return _ARMV7M_Clock_counter((ARMV7M_Timecounter *) base);
 }
 
-static void _ARMV7M_Clock_handler(void)
+void _ARMV7M_Clock_handler(void)
 {
   _ARMV7M_Interrupt_service_enter();
   Clock_isr(NULL);
@@ -38,10 +52,9 @@ static void _ARMV7M_Clock_handler(void)
 
 static void _ARMV7M_Clock_handler_install(void)
 {
-  _ARMV7M_Set_exception_priority_and_handler(
+  _ARMV7M_Set_exception_priority(
 ARMV7M_VECTOR_SYSTICK,
-BSP_ARMV7M_SYSTICK_PRIORITY,
-_ARMV7M_Clock_handler
+BSP_ARMV7M_SYSTICK_PRIORITY
   );
 }
 
diff --git a/bsps/arm/shared/irq/irq-armv7m.c b/bsps/arm/shared/irq/irq-armv7m.c
index 99c0e373bf..84ebeeb159 100644
--- a/bsps/arm/shared/irq/irq-armv7m.c
+++ b/bsps/arm/shared/irq/irq-armv7m.c
@@ -1,27 +1,41 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /*
- * Copyright (c) 2011-2012 Sebastian Huber.  All rights reserved.
+ * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+ * Copyright (C) 2011, 2012 Sebastian Huber
  *
- *  embedded brains GmbH
- *  Obere Lagerstr. 30
- *  82178 Puchheim
- *  Germany
- *  
+ * 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.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY 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
+ *

93 matches

Mail list logo