Re: [PATCH rtems-libbsd v2 12/14] ehci_imx: Add to build.

[Christian Mauderer]

On 16/04/2020 09:21, Vijay Kumar Banerjee wrote:
> 
> 
> On Thu, Apr 16, 2020 at 12:41 PM Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
> 
> Hello Vijay,
> 
> On 16/04/2020 09:04, Vijay Kumar Banerjee wrote:
> > Hi Christian,
> >
> > I'm not able to build libbsd with this patch. I'm getting the
> following
> > error:
> > ```
> > ../../freebsd/sys/dev/usb/controller/ehci_imx.c:70:10: fatal error:
> > arm/freescale/imx/imx_ccmvar.h: No such file or directory
> >  #include 
> > ```
> > From git blame I got to know that this file was introduced by the
> commit
> > from this patch.
> > Am I missing something or is it really a bug?
> 
> Thanks for the report. On what BSP and which exact commit did you try to
> build? I had no trouble building the patch set from a clean checkout
> yesterday before committing it.
> 
> I did a pull from the upstream master and tried the build on
> arm/beagleboneblack
> I see that the header file is not present in the freebsd/ directory
> ```
> rtems-libbsd $>find -iname imx_ccmvar.h
> ./freebsd-org/sys/arm/freescale/imx/imx_ccmvar.h
> ``` 

Hello Vijay,

that's quite clearly a bug that I introduced. I'll create a patch.

The imx_ccmvar.h is a file that is provided by the BSP I used for testing.

Best regards

Christian

> 
> >
> > Sorry for commenting on the patch that has already been committed,
> > please let me know of
> > the preferred way to comment on a commit if this is not the right way.
> 
> No problem. That's exactly the right way to do it. If there is a bug it
> has to be solved and everyone should know that someone is having a look
> at it.
> 
> Best regards
> 
> Christian
> 
> >
> >
> > Best regards,
> > Vijay
> > On Tue, Apr 14, 2020 at 8:21 PM Christian Mauderer
> >  <mailto:christian.maude...@embedded-brains.de>
> > <mailto:christian.maude...@embedded-brains.de
> <mailto:christian.maude...@embedded-brains.de>>> wrote:
> >
> >     ---
> >      libbsd.py                            | 2 ++
> >      rtemsbsd/include/bsp/nexus-devices.h | 5 +
> >      2 files changed, 7 insertions(+)
> >
> >     diff --git a/libbsd.py b/libbsd.py
> >     index 4f8fb4d2..ed6493b2 100644
> >     --- a/libbsd.py
> >     +++ b/libbsd.py
> >     @@ -5028,6 +5028,8 @@ class imx(builder.Module):
> >              self.addKernelSpaceSourceFiles(
> >                  [
> >                      'sys/arm/freescale/imx/imx6_ccm.c',
> >     +                'sys/arm/freescale/imx/imx6_usbphy.c',
> >     +                'sys/dev/usb/controller/ehci_imx.c',
> >                  ],
> >                  mm.generator['source']()
> >              )
> >     diff --git a/rtemsbsd/include/bsp/nexus-devices.h
> >     b/rtemsbsd/include/bsp/nexus-devices.h
> >     index 0a210bd9..d2ceab8e 100644
> >     --- a/rtemsbsd/include/bsp/nexus-devices.h
> >     +++ b/rtemsbsd/include/bsp/nexus-devices.h
> >     @@ -128,6 +128,11 @@ RTEMS_BSD_DEFINE_NEXUS_DEVICE(ofwbus, 0,
> 0, NULL);
> >      SYSINIT_DRIVER_REFERENCE(simplebus, ofwbus);
> >
> >      SYSINIT_DRIVER_REFERENCE(ccm, simplebus);
> >     +SYSINIT_DRIVER_REFERENCE(ehci, simplebus);
> >     +SYSINIT_DRIVER_REFERENCE(usbphy, simplebus);
> >     +SYSINIT_DRIVER_REFERENCE(usbus, ehci);
> >     +RTEMS_BSD_DRIVER_USB;
> >     +RTEMS_BSD_DRIVER_USB_MASS;
> >
> >      SYSINIT_DRIVER_REFERENCE(ffec, simplebus);
> >      SYSINIT_DRIVER_REFERENCE(ukphy, miibus);
> >     --
> >     2.16.4
> >
> >     ___
> >     devel mailing list
> >     devel@rtems.org <mailto:devel@rtems.org>
> <mailto:devel@rtems.org <mailto: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
> <mailto: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.
> 

-- 

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-libbsd v2 12/14] ehci_imx: Add to build.

[Christian Mauderer]

Hello Vijay,

On 16/04/2020 09:04, Vijay Kumar Banerjee wrote:
> Hi Christian,
> 
> I'm not able to build libbsd with this patch. I'm getting the following
> error:
> ```
> ../../freebsd/sys/dev/usb/controller/ehci_imx.c:70:10: fatal error:
> arm/freescale/imx/imx_ccmvar.h: No such file or directory
>  #include 
> ```
> From git blame I got to know that this file was introduced by the commit
> from this patch.
> Am I missing something or is it really a bug?

Thanks for the report. On what BSP and which exact commit did you try to
build? I had no trouble building the patch set from a clean checkout
yesterday before committing it.

> 
> Sorry for commenting on the patch that has already been committed,
> please let me know of
> the preferred way to comment on a commit if this is not the right way.

No problem. That's exactly the right way to do it. If there is a bug it
has to be solved and everyone should know that someone is having a look
at it.

Best regards

Christian

> 
> 
> Best regards,
> Vijay
> On Tue, Apr 14, 2020 at 8:21 PM Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
> 
> ---
>  libbsd.py                            | 2 ++
>  rtemsbsd/include/bsp/nexus-devices.h | 5 +
>  2 files changed, 7 insertions(+)
> 
> diff --git a/libbsd.py b/libbsd.py
> index 4f8fb4d2..ed6493b2 100644
> --- a/libbsd.py
> +++ b/libbsd.py
> @@ -5028,6 +5028,8 @@ class imx(builder.Module):
>          self.addKernelSpaceSourceFiles(
>              [
>                  'sys/arm/freescale/imx/imx6_ccm.c',
> +                'sys/arm/freescale/imx/imx6_usbphy.c',
> +                'sys/dev/usb/controller/ehci_imx.c',
>              ],
>              mm.generator['source']()
>          )
> diff --git a/rtemsbsd/include/bsp/nexus-devices.h
> b/rtemsbsd/include/bsp/nexus-devices.h
> index 0a210bd9..d2ceab8e 100644
> --- a/rtemsbsd/include/bsp/nexus-devices.h
> +++ b/rtemsbsd/include/bsp/nexus-devices.h
> @@ -128,6 +128,11 @@ RTEMS_BSD_DEFINE_NEXUS_DEVICE(ofwbus, 0, 0, NULL);
>  SYSINIT_DRIVER_REFERENCE(simplebus, ofwbus);
> 
>  SYSINIT_DRIVER_REFERENCE(ccm, simplebus);
> +SYSINIT_DRIVER_REFERENCE(ehci, simplebus);
> +SYSINIT_DRIVER_REFERENCE(usbphy, simplebus);
> +SYSINIT_DRIVER_REFERENCE(usbus, ehci);
> +RTEMS_BSD_DRIVER_USB;
> +RTEMS_BSD_DRIVER_USB_MASS;
> 
>  SYSINIT_DRIVER_REFERENCE(ffec, simplebus);
>  SYSINIT_DRIVER_REFERENCE(ukphy, miibus);
> -- 
> 2.16.4
> 
> ___
> devel mailing list
> devel@rtems.org <mailto: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: [PATCHES v2] Add more i.MX6UL/ULL support

[Christian Mauderer]

Hello Gedare,

On 15/04/2020 18:23, Gedare Bloom wrote:
> On Wed, Apr 15, 2020 at 9:31 AM Christian Mauderer
>  wrote:
>>
>> On 15/04/2020 15:56, Gedare Bloom wrote:
>>> Yes, go ahead and push them in.
>>
>> Thanks. I pushed them. But now I have a small problem: I wanted to
>> update RSB to use the new versions (Chris said in another mail that it
>> should be up to date that near to a release). But I noted that I have no
>> idea what format is used for the hash. Currently
>> rtems/config/tools/rtems-kernel-5.cfg contains the following:
>>
>>
>> %define rtems_kernel_version01219541289e8081054d4a57924ee169339f1eaf
>> %hash sha512 rtems-kernel-%{rtems_kernel_version}.tar.bz2 \
>>
>> qJIBYkdFGRROoJlkmxRk5Ugr2IcrcWIlXH5FfuE88mecUkDDy4JBtFDXcH0YzjwyrpmlFSaaaK850nb4o89ZCA==
>>
>>
>> That's definitively not an unprocessed output of sha512sum. Can someone
>> help me?
>>
> Use rtems-source-builder/source-builder/sha512-base64

Thanks for that.

I've updated the RSB to use the latest patches.

> 
>> Best regards
>>
>> Christian
>>
>>>
>>> On Wed, Apr 15, 2020 at 12:07 AM Christian Mauderer
>>>  wrote:
>>>>
>>>> On 15/04/2020 07:06, Sebastian Huber wrote:
>>>>> Hello Christian,
>>>>>
>>>>> the patch set looks good (except maybe "[PATCH rtems-libbsd v2 09/14]
>>>>> bus-dma, imx: Don't sync nocache area.").
>>>>>
>>>>
>>>> Thanks.
>>>>
>>>> Chris, Gedare, Joel: Would it be OK for you if I push the patches before
>>>> the 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.
>>
>> --
>> 
>> 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
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCHES v2] Add more i.MX6UL/ULL support

[Christian Mauderer]

On 15/04/2020 15:56, Gedare Bloom wrote:
> Yes, go ahead and push them in.

Thanks. I pushed them. But now I have a small problem: I wanted to
update RSB to use the new versions (Chris said in another mail that it
should be up to date that near to a release). But I noted that I have no
idea what format is used for the hash. Currently
rtems/config/tools/rtems-kernel-5.cfg contains the following:


%define rtems_kernel_version01219541289e8081054d4a57924ee169339f1eaf
%hash sha512 rtems-kernel-%{rtems_kernel_version}.tar.bz2 \

qJIBYkdFGRROoJlkmxRk5Ugr2IcrcWIlXH5FfuE88mecUkDDy4JBtFDXcH0YzjwyrpmlFSaaaK850nb4o89ZCA==


That's definitively not an unprocessed output of sha512sum. Can someone
help me?

Best regards

Christian

> 
> On Wed, Apr 15, 2020 at 12:07 AM Christian Mauderer
>  wrote:
>>
>> On 15/04/2020 07:06, Sebastian Huber wrote:
>>> Hello Christian,
>>>
>>> the patch set looks good (except maybe "[PATCH rtems-libbsd v2 09/14]
>>> bus-dma, imx: Don't sync nocache area.").
>>>
>>
>> Thanks.
>>
>> Chris, Gedare, Joel: Would it be OK for you if I push the patches before
>> the 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.

-- 

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 Timeline Update and 25th Anniversary of First Public Commit

[Christian Mauderer]

On 14/04/2020 15:40, Joel Sherrill wrote:
> 
> 
> On Tue, Apr 14, 2020 at 1:47 AM Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
> 
> Hello Joel,
> 
> On 07/04/2020 22:44, Joel Sherrill wrote:
> > Hi
> >
> > The RTEMS Project is rapidly approaching a major milestone -- the 25th
> > anniversary of the oldest commit in the git repository! That
> occurs on 4
> > May 2020!
> >
> > Before that time, the source code was managed on an internal research
> > project repository and snapshots/releases made available via ftp.
> I know
> > I started with the project in July 1989 and was coding nearly from the
> > first day.
> >
> > With this in mind,
> the https://devel.rtems.org/wiki/History/Timeline is
> > sorely out of date and lacking missing entries. Multiple mission
> > launches, addition of SMP, GSoC, GCI, and SOCIC participation, move to
> > OSU OSL, incorporation of RTEMS Foundation, scientific
> discoveries like
> > the particle discovered by an Atlas detector at CERN or the famous
> gamma
> > ray burst from Fermi. All are missing. 
> >
> > Please pitch in and help. If you want to help but don't have any
> ideas,
> > just post back and I will try to follow up with ideas that someone
> else
> > can put a date on. 
> >
> > Thanks.
> >
> > --joel
> 
> I added some small stuff (start of SMP work, main work, release numbers)
> based on the git history (see
> 
> https://devel.rtems.org/wiki/History/Timeline?action=diff=27_version=25).
> 
> 
> Thanks! That's a good set of information. 
> 
> 
> Although I'm terribly bad with dates: You said you would try to follow
> up with ideas. If you have any where I might could help, please let
> me know.
> 
> 
> How about these (random and before coffee/tea)
> 
> + Any cool non-space programs folks can admit to?
> + First submission from some core developers.
>     - Chris was second submitter and is in the 91-92 timeframe. We don't
> remember.
>     - Thomas first shows up in git in March 1998. 
>     - Sebastian gets a nod in July 2008. :)
> + When were some ports added?
> + When were some interesting/popular BSPs added: Zyng, Leon3, gba, etc
>     - FWIW the original PC BSP was based on DJ Delorie's go32 and pre-dates 
>       the git history. I did that on a single PC (486 with 32 MB RAM). I
> couldn't run
>       X11 and compile at the same time. I had to reboot to test. Yes it
> was uphill
>       both ways back in those days. :)
> + When were some of the original ports/BSPs removed?
>    - mvme135/136 was first BSP
>    - i386 was second port
>    - i960 was last of original 3 ports
> + Interesting features? Like libnetworking, libbsd, shell, dynamic loading?
> + The Cygnus floppy mailing:
>     https://ftp.rtems.org/pub/rtems/people/joel/CygnusFloppyAugust1995/
> 
> This may be good as a small tasks ticket where people cross things off 
> as they get added.

I added a ticket here: https://devel.rtems.org/ticket/3952

> 
> It is amazing how much this has prodded my memory.  :)
> 
> --joel
>      
> 
> 
> Best regards
> 
> Christian
> -- 
> 
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
>     email: christian.maude...@embedded-brains.de
> <mailto: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.
> 

-- 

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

[Christian Mauderer]

On 15/04/2020 07:06, Sebastian Huber wrote:
> Hello Christian,
> 
> the patch set looks good (except maybe "[PATCH rtems-libbsd v2 09/14]
> bus-dma, imx: Don't sync nocache area.").
> 

Thanks.

Chris, Gedare, Joel: Would it be OK for you if I push the patches before
the 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: [PATCH rtems-libbsd v2 09/14] bus-dma, imx: Don't sync nocache area.

[Christian Mauderer]

On 15/04/2020 07:02, Sebastian Huber wrote:
> Is this patch still necessary?
> 

Thanks for the hint. I missed to remove it. It's not necessary any more
and I'll just skip it when pushing.

-- 

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

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

[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

[PATCH rtems-libbsd v2 01/14] usb_busdma: Add USB_NEED_BUSDMA_COHERENT_ALLOC

[Christian Mauderer]

From: Sebastian Huber 

Some BSPs have a cache-coherent memory area, however, it should not be
used for the USB controller.
---
 freebsd/sys/dev/usb/usb_busdma.c   | 4 
 rtemsbsd/include/rtems/bsd/local/opt_usb.h | 5 +
 2 files changed, 9 insertions(+)

diff --git a/freebsd/sys/dev/usb/usb_busdma.c b/freebsd/sys/dev/usb/usb_busdma.c
index 9a70c687..dc52fe15 100644
--- a/freebsd/sys/dev/usb/usb_busdma.c
+++ b/freebsd/sys/dev/usb/usb_busdma.c
@@ -584,7 +584,11 @@ usb_pc_alloc_mem(struct usb_page_cache *pc, struct 
usb_page *pg,
}
/* allocate memory */
if (bus_dmamem_alloc(
+#if !defined(__rtems__) || USB_NEED_BUSDMA_COHERENT_ALLOC
utag->tag, , (BUS_DMA_WAITOK | BUS_DMA_COHERENT), )) {
+#else /* __rtems__ */
+   utag->tag, , BUS_DMA_WAITOK, )) {
+#endif /* __rtems__ */
goto error;
}
/* setup page cache */
diff --git a/rtemsbsd/include/rtems/bsd/local/opt_usb.h 
b/rtemsbsd/include/rtems/bsd/local/opt_usb.h
index 809a969f..9f654863 100644
--- a/rtemsbsd/include/rtems/bsd/local/opt_usb.h
+++ b/rtemsbsd/include/rtems/bsd/local/opt_usb.h
@@ -1,4 +1,5 @@
 #include 
+#include 
 
 #define USB_HAVE_CONDVAR 1
 
@@ -6,6 +7,10 @@
 
 #define USB_HAVE_BUSDMA 1
 
+#if !defined(LIBBSP_ARM_IMX_BSP_H) && !defined(LIBBSP_ARM_STM32H7_BSP_H)
+#define USB_NEED_BUSDMA_COHERENT_ALLOC 1
+#endif
+
 #define USB_HAVE_COMPAT_LINUX 0
 
 #define USB_HAVE_USER_IO 0
-- 
2.16.4

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

[PATCH rtems-libbsd v2 05/14] imx gpio port

[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 rtems-libbsd v2 11/14] ehci_imx: Port to RTEMS

[Christian Mauderer]

Update #3869.
---
 freebsd/sys/arm/freescale/imx/imx6_usbphy.c | 11 +++
 freebsd/sys/dev/usb/controller/ehci_imx.c   | 12 
 2 files changed, 23 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"))
-- 
2.16.4

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

[PATCH rtems-libbsd v2 04/14] imx6_ccm: Add and build module.

[Christian Mauderer]

Update #3869.
---
 buildset/default.ini |  1 +
 libbsd.py| 23 +++
 rtemsbsd/include/bsp/nexus-devices.h |  2 ++
 3 files changed, 26 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/libbsd.py b/libbsd.py
index d791efe4..e0690601 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -5010,6 +5010,28 @@ 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_anatopreg.h',
+'sys/arm/freescale/imx/imx6_anatopvar.h',
+'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 +5188,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 rtems-libbsd v2 09/14] bus-dma, imx: Don't sync nocache area.

[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 rtems-libbsd v2 08/14] Add support for i.mx cache.

[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 rtems-libbsd v2 03/14] imx6_ccm: Port to RTEMS

[Christian Mauderer]

From: Sebastian Huber 

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

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");
-- 
2.16.4

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

[PATCH rtems-libbsd v2 06/14] regulator: Import from FreeBSD.

[Christian Mauderer]

Update #3869.
---
 freebsd/sys/dev/extres/regulator/regulator.c   | 1321 
 freebsd/sys/dev/extres/regulator/regulator.h   |  156 +++
 freebsd/sys/dev/extres/regulator/regulator_bus.c   |   89 ++
 freebsd/sys/dev/extres/regulator/regulator_fixed.c |  502 
 freebsd/sys/dev/extres/regulator/regulator_fixed.h |   44 +
 freebsd/sys/dev/gpio/gpioregulator.c   |  350 ++
 6 files changed, 2462 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 ..4ad6e94a
--- /dev/null
+++ b/freebsd/sys/dev/extres/regulator/regulator.c
@@ -0,0 +1,1321 @@
+#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_init(struct regnode *regnode);
+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_constraint(void *dummy);
+static void regulator_shutdown(void *dummy);
+
+/*
+ * Regulator controller methods.
+ */
+static regnode_method_t regnode_methods[] = {
+   REGNODEMETHOD(regnode_init, regnode_method_init),
+   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(regnode_check_voltage,regnode_method_check_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 */
+  

[PATCH rtems-libbsd v2 10/14] ehci_imx: Import from FreeBSD

[Christian Mauderer]

From: Sebastian Huber 

Update #3869.
---
 freebsd/sys/arm/freescale/imx/imx6_usbphy.c | 212 
 freebsd/sys/dev/usb/controller/ehci_imx.c   | 516 
 2 files changed, 728 insertions(+)
 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_usbphy.c 
b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
new file mode 100644
index ..8f47507b
--- /dev/null
+++ b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
@@ -0,0 +1,212 @@
+#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$");
+
+/*
+ * USBPHY driver for Freescale i.MX6 family of SoCs.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+/*
+ * Hardware register defines.
+ */
+#definePWD_REG 0x
+#defineCTRL_STATUS_REG 0x0030
+#defineCTRL_SET_REG0x0034
+#defineCTRL_CLR_REG0x0038
+#defineCTRL_TOGGLE_REG 0x003c
+#define  CTRL_SFTRST (1U << 31)
+#define  CTRL_CLKGATE(1 << 30)
+#define  CTRL_ENUTMILEVEL3   (1 << 15)
+#define  CTRL_ENUTMILEVEL2   (1 << 14)
+
+struct usbphy_softc {
+   device_tdev;
+   struct resource *mem_res;
+   u_int   phy_num;
+};
+
+static struct ofw_compat_data compat_data[] = {
+   {"fsl,imx6q-usbphy",true},
+   {"fsl,imx6ul-usbphy",   true},
+   {NULL,  false}
+};
+
+static int
+usbphy_detach(device_t dev)
+{
+   struct usbphy_softc *sc;
+
+   sc = device_get_softc(dev);
+
+   if (sc->mem_res != NULL)
+   bus_release_resource(dev, SYS_RES_MEMORY, 0, sc->mem_res);
+
+   return (0);
+}
+
+static int
+usbphy_attach(device_t dev)
+{
+   struct usbphy_softc *sc;
+   int err, regoff, rid;
+
+   sc = device_get_softc(dev);
+   err = 0;
+
+   /* Allocate bus_space resources. */
+   rid = 0;
+   sc->mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, ,
+   RF_ACTIVE);
+   if (sc->mem_res == NULL) {
+   device_printf(dev, "Cannot allocate memory resources\n");
+   err = ENXIO;
+   goto out;
+   }
+
+   /*
+* 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
+* this driver is used for imx6 only.
+*/
+   const uint32_t PWD_PHY1_REG_PHYSADDR = 0x020c9000;
+   if (BUS_SPACE_PHYSADDR(sc->mem_res, 0) == PWD_PHY1_REG_PHYSADDR) {
+   sc->phy_num = 0;
+   regoff = 0;
+   } else {
+   sc->phy_num = 1;
+   regoff = 0x60;
+   }
+
+   /*
+* Based on a note in the u-boot source code, disable charger detection
+* to avoid degrading the differential signaling on the DP line.  Note
+* that this disables (by design) both charger detection and contact
+* detection, because of the screwball mix of active-high and active-low
+* bits in this register.
+*/
+   imx6_anatop_write_4(IMX6_ANALOG_USB1_CHRG_DETECT + regoff, 
+   IMX6_ANALOG_USB_CHRG_DETECT_N_ENABLE | 
+   IMX6_ANALOG_USB_CHRG_DETECT_N_CHK_CHRG);
+
+   

[PATCH rtems-libbsd v2 07/14] regulator: Add to build.

[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 | 121 ++
 rtemsbsd/local/regdev_if.c|  27 ++
 rtemsbsd/local/regnode_if.c   |  56 
 8 files changed, 300 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 e0690601..4f8fb4d2 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -5032,6 +5032,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
 #
@@ -5189,6 +5218,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 +1,36 

[PATCH rtems-libbsd v2 13/14] ehci_imx: Set/clear ENHOSTDISCONNECT in USB PHY.

[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 rtems-libbsd v2 02/14] imx6_ccm: Import from FreeBSD

[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_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 
 6 files changed, 969 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_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_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
+#define

[PATCH rtems-libbsd v2 12/14] ehci_imx: Add to build.

[Christian Mauderer]

---
 libbsd.py| 2 ++
 rtemsbsd/include/bsp/nexus-devices.h | 5 +
 2 files changed, 7 insertions(+)

diff --git a/libbsd.py b/libbsd.py
index 4f8fb4d2..ed6493b2 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -5028,6 +5028,8 @@ class imx(builder.Module):
 self.addKernelSpaceSourceFiles(
 [
 'sys/arm/freescale/imx/imx6_ccm.c',
+'sys/arm/freescale/imx/imx6_usbphy.c',
+'sys/dev/usb/controller/ehci_imx.c',
 ],
 mm.generator['source']()
 )
diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index 0a210bd9..d2ceab8e 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -128,6 +128,11 @@ RTEMS_BSD_DEFINE_NEXUS_DEVICE(ofwbus, 0, 0, NULL);
 SYSINIT_DRIVER_REFERENCE(simplebus, ofwbus);
 
 SYSINIT_DRIVER_REFERENCE(ccm, simplebus);
+SYSINIT_DRIVER_REFERENCE(ehci, simplebus);
+SYSINIT_DRIVER_REFERENCE(usbphy, simplebus);
+SYSINIT_DRIVER_REFERENCE(usbus, ehci);
+RTEMS_BSD_DRIVER_USB;
+RTEMS_BSD_DRIVER_USB_MASS;
 
 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

[PATCHES v2] Add more i.MX6UL/ULL support

[Christian Mauderer]

Hello,

this patches are an update for

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

The RTEMS and docs patch is rebased to the current master.

The libbsd patches are adapted to have the right order and include the
changes like discussed. This version is for the 5-freebsd-12 branch.
I'll adapt them for libbsd master and push them together as soon as I
have a go.

Best regards

Christian

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

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

[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

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

[Christian Mauderer]

On 02/04/2020 16:56, Christian Mauderer wrote:
> 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.

I found a nicer solution with some help from Stackoverflow:

git config --global alias.format-patch-repo '!git format-patch
--subject-prefix="PATCH $(basename $(git rev-parse --show-toplevel))"'

This adds an alias that automatically adds the folder name of the
repository. It can be used with

git format-patch-repo HEAD^

If you only work in one directory, an alternative is to set the
format.subjectPrefix option in the repository.

Best regards

Christian

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

Re: RTEMS Timeline Update and 25th Anniversary of First Public Commit

[Christian Mauderer]

Hello Joel,

On 07/04/2020 22:44, Joel Sherrill wrote:
> Hi
> 
> The RTEMS Project is rapidly approaching a major milestone -- the 25th
> anniversary of the oldest commit in the git repository! That occurs on 4
> May 2020!
> 
> Before that time, the source code was managed on an internal research
> project repository and snapshots/releases made available via ftp. I know
> I started with the project in July 1989 and was coding nearly from the
> first day.
> 
> With this in mind, the https://devel.rtems.org/wiki/History/Timeline is
> sorely out of date and lacking missing entries. Multiple mission
> launches, addition of SMP, GSoC, GCI, and SOCIC participation, move to
> OSU OSL, incorporation of RTEMS Foundation, scientific discoveries like
> the particle discovered by an Atlas detector at CERN or the famous gamma
> ray burst from Fermi. All are missing. 
> 
> Please pitch in and help. If you want to help but don't have any ideas,
> just post back and I will try to follow up with ideas that someone else
> can put a date on. 
> 
> Thanks.
> 
> --joel

I added some small stuff (start of SMP work, main work, release numbers)
based on the git history (see
https://devel.rtems.org/wiki/History/Timeline?action=diff=27_version=25).

Although I'm terribly bad with dates: You said you would try to follow
up with ideas. If you have any where I might could help, please let me know.

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 v3] bsp/beagle: Update console to new Termios API.

[Christian Mauderer]

On 10/04/2020 20:53, Niteesh G. S. wrote:
> On Fri, Apr 10, 2020 at 9:18 PM Christian Mauderer  <mailto:o...@c-mauderer.de>> wrote:
> 
> Hello Niteesh,
> 
> sorry for the late review. It somehow slipped my attention.
> 
> Although I'm generally OK with it, my suggestion would be to move it
> after the release. It's a not strictly necessary change and therefore I
> don't want to potentially break stuff with it now.
> 
> Okay then, I will make the changes and will send the patches after the
> release. 

You can send it anytime before the release too so that we can merge it
right after it.

> 
> I added some comments below:
> 
> On 23/03/2020 11:28, G S Niteesh Babu wrote:
> > This patch updates the console driver to new Termios API.
> >
> > Update #3034
> > ---
> >  bsps/arm/beagle/console/console-config.c | 117
> +--
> >  c/src/lib/libbsp/arm/beagle/Makefile.am  |   4 +-
> >  2 files changed, 69 insertions(+), 52 deletions(-)
> >
> > diff --git a/bsps/arm/beagle/console/console-config.c
> b/bsps/arm/beagle/console/console-config.c
> > index 78af5f6a93..b2246571f8 100644
> > --- a/bsps/arm/beagle/console/console-config.c
> > +++ b/bsps/arm/beagle/console/console-config.c
> > @@ -21,12 +21,15 @@
> >   *
> >   * Modified by Ben Gras  <mailto:b...@shrike-systems.com>> to make
> >   * interrupt-driven uart i/o work for beagleboards; beaglebone
> support added.
> > + *
> > + * Modified by Niteesh Babu G S  <mailto:niteesh...@gmail.com>>
> > + * Update console to new termios API.
> >   */
> > 
> > -#include 
> >  #include 
> > 
> >  #include 
> > +#include 
> > 
> >  #include 
> >  #include 
> > @@ -41,6 +44,8 @@
> >  #define TX_FIFO_E (1<<5)
> >  #define RX_FIFO_E (1<<0)
> > 
> > +#define BEAGLE_UART0 "/dev/ttyS0"
> > +
> >  static uint8_t beagle_uart_get_register(uintptr_t addr, uint8_t i)
> >  {
> >    uint8_t v;
> > @@ -65,77 +70,91 @@ static void beagle_uart_set_register(uintptr_t
> addr, uint8_t i, uint8_t val)
> >    reg [i] = val;
> >  }
> > 
> > -console_tbl Console_Configuration_Ports [] = {
> > -    {
> > -      .sDeviceName = "/dev/ttyS0",
> > -      .deviceType = SERIAL_NS16550,
> > -#if CONSOLE_POLLED   /* option to facilitate running the tests */
> > -      .pDeviceFns = _fns_polled,
> > -#else
> > -      .pDeviceFns = _fns,
> > -#endif
> > -      .ulMargin = 16,
> > -      .ulHysteresis = 8,
> > -      .pDeviceParams = (void *) CONSOLE_BAUD,
> > -      .ulCtrlPort1 = BSP_CONSOLE_UART_BASE,
> > -      .ulDataPort = BSP_CONSOLE_UART_BASE,
> > -      .ulIntVector = BSP_CONSOLE_UART_IRQ,
> > -      .getRegister = beagle_uart_get_register,
> > -      .setRegister = beagle_uart_set_register,
> > -      .ulClock = UART_CLOCK,  /* 48MHz base clock */
> > -    },
> > -};
> > -
> > -unsigned long Console_Configuration_Count = 1;
> > -
> > -static int init_needed = 1; // don't rely on bss being 0
> > +static ns16550_context uart_context;
> > +static void uart_write_polled( char c );
> > 
> >  static void beagle_console_init(void)
> >  {
> > -  if(init_needed) {
> > -    const uint32_t div = UART_CLOCK / 16 / CONSOLE_BAUD;
> > -    CONSOLE_SYSC = 2;
> > -    while ((CONSOLE_SYSS & 1) == 0)
> > -      ;
> > -    if ((CONSOLE_LSR & (CONSOLE_LSR_THRE | CONSOLE_LSR_TEMT)) ==
> CONSOLE_LSR_THRE) {
> > -      CONSOLE_LCR = 0x83;
> > -      CONSOLE_DLL = div;
> > -      CONSOLE_DLM = (div >> 8) & 0xff;
> > -      CONSOLE_LCR = 0x03;
> > -      CONSOLE_ACR = 0x00;
> > -    }
> > +  ns16550_context *ctx;
> > +  static bool initialized = false;
> > 
> > -    while ((CONSOLE_LSR & CONSOLE_LSR_TEMT) == 0)
> > -      ;
> > +  if ( initialized ) {
> 
> You never set initialized to true. So this will never happen.
> 
> > +    return ;
> > +  }
> > 
> > -    CONSOLE_LCR = 0x80 | 0x03;
> > -    CONSOLE_DLL = 0x00;
> > -    CONSOLE_DLM = 0x00;
> > -    CON

Re: [PATCH v3] bsp/beagle: Update console to new Termios API.

[Christian Mauderer]

Hello Niteesh,

sorry for the late review. It somehow slipped my attention.

Although I'm generally OK with it, my suggestion would be to move it
after the release. It's a not strictly necessary change and therefore I
don't want to potentially break stuff with it now.

I added some comments below:

On 23/03/2020 11:28, G S Niteesh Babu wrote:
> This patch updates the console driver to new Termios API.
> 
> Update #3034
> ---
>  bsps/arm/beagle/console/console-config.c | 117 +--
>  c/src/lib/libbsp/arm/beagle/Makefile.am  |   4 +-
>  2 files changed, 69 insertions(+), 52 deletions(-)
> 
> diff --git a/bsps/arm/beagle/console/console-config.c 
> b/bsps/arm/beagle/console/console-config.c
> index 78af5f6a93..b2246571f8 100644
> --- a/bsps/arm/beagle/console/console-config.c
> +++ b/bsps/arm/beagle/console/console-config.c
> @@ -21,12 +21,15 @@
>   *
>   * Modified by Ben Gras  to make
>   * interrupt-driven uart i/o work for beagleboards; beaglebone support added.
> + *
> + * Modified by Niteesh Babu G S 
> + * Update console to new termios API.
>   */
>  
> -#include 
>  #include 
>  
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -41,6 +44,8 @@
>  #define TX_FIFO_E (1<<5)
>  #define RX_FIFO_E (1<<0)
>  
> +#define BEAGLE_UART0 "/dev/ttyS0"
> +
>  static uint8_t beagle_uart_get_register(uintptr_t addr, uint8_t i)
>  {
>uint8_t v;
> @@ -65,77 +70,91 @@ static void beagle_uart_set_register(uintptr_t addr, 
> uint8_t i, uint8_t val)
>reg [i] = val;
>  }
>  
> -console_tbl Console_Configuration_Ports [] = {
> -{
> -  .sDeviceName = "/dev/ttyS0",
> -  .deviceType = SERIAL_NS16550,
> -#if CONSOLE_POLLED   /* option to facilitate running the tests */
> -  .pDeviceFns = _fns_polled,
> -#else
> -  .pDeviceFns = _fns,
> -#endif
> -  .ulMargin = 16,
> -  .ulHysteresis = 8,
> -  .pDeviceParams = (void *) CONSOLE_BAUD,
> -  .ulCtrlPort1 = BSP_CONSOLE_UART_BASE,
> -  .ulDataPort = BSP_CONSOLE_UART_BASE,
> -  .ulIntVector = BSP_CONSOLE_UART_IRQ,
> -  .getRegister = beagle_uart_get_register,
> -  .setRegister = beagle_uart_set_register,
> -  .ulClock = UART_CLOCK,  /* 48MHz base clock */
> -},
> -};
> -
> -unsigned long Console_Configuration_Count = 1;
> -
> -static int init_needed = 1; // don't rely on bss being 0
> +static ns16550_context uart_context;
> +static void uart_write_polled( char c );
>  
>  static void beagle_console_init(void)
>  {
> -  if(init_needed) {
> -const uint32_t div = UART_CLOCK / 16 / CONSOLE_BAUD;
> -CONSOLE_SYSC = 2;
> -while ((CONSOLE_SYSS & 1) == 0)
> -  ;
> -if ((CONSOLE_LSR & (CONSOLE_LSR_THRE | CONSOLE_LSR_TEMT)) == 
> CONSOLE_LSR_THRE) {
> -  CONSOLE_LCR = 0x83;
> -  CONSOLE_DLL = div;
> -  CONSOLE_DLM = (div >> 8) & 0xff;
> -  CONSOLE_LCR = 0x03;
> -  CONSOLE_ACR = 0x00;
> -}
> +  ns16550_context *ctx;
> +  static bool initialized = false;
>  
> -while ((CONSOLE_LSR & CONSOLE_LSR_TEMT) == 0)
> -  ;
> +  if ( initialized ) {

You never set initialized to true. So this will never happen.

> +return ;
> +  }
>  
> -CONSOLE_LCR = 0x80 | 0x03;
> -CONSOLE_DLL = 0x00;
> -CONSOLE_DLM = 0x00;
> -CONSOLE_LCR = 0x03;
> -CONSOLE_MCR = 0x03;
> -CONSOLE_FCR = 0x07;
> +  /*
> +   * Don't rely on BSS being zeroed
> +   */
> +  memset(_context, 0, sizeof(uart_context));
> +  ctx = _context;
> +
> +  ctx->port = BSP_CONSOLE_UART_BASE;
> +  ctx->irq = BSP_CONSOLE_UART_IRQ;
> +  ctx->set_reg = beagle_uart_set_register;
> +  ctx->get_reg = beagle_uart_get_register;
> +  ctx->initial_baud = CONSOLE_BAUD;
> +  ctx->clock = UART_CLOCK;
> +
> +  const uint32_t div = UART_CLOCK / 16 / CONSOLE_BAUD;

I would prefer declarations at the top of the function.

> +  CONSOLE_SYSC = 2;
> +  while ((CONSOLE_SYSS & 1) == 0)
> +;
> +  if ((CONSOLE_LSR & (CONSOLE_LSR_THRE | CONSOLE_LSR_TEMT)) == 
> CONSOLE_LSR_THRE) {
>  CONSOLE_LCR = 0x83;
>  CONSOLE_DLL = div;
>  CONSOLE_DLM = (div >> 8) & 0xff;
>  CONSOLE_LCR = 0x03;
>  CONSOLE_ACR = 0x00;
> -init_needed = 0;
>}
> +  while ((CONSOLE_LSR & CONSOLE_LSR_TEMT) == 0)
> +;
> +  CONSOLE_LCR = 0x80 | 0x03;
> +  CONSOLE_DLL = 0x00;
> +  CONSOLE_DLM = 0x00;
> +  CONSOLE_LCR = 0x03;
> +  CONSOLE_MCR = 0x03;
> +  CONSOLE_FCR = 0x07;
> +  CONSOLE_LCR = 0x83;
> +  CONSOLE_DLL = div;
> +  CONSOLE_DLM = (div >> 8) & 0xff;
> +  CONSOLE_LCR = 0x03;
> +  CONSOLE_ACR = 0x00;
> +
> +  BSP_output_char = uart_write_polled;
>  }
>  
>  #define CONSOLE_THR8 (*(volatile uint8_t *) (BSP_CONSOLE_UART_BASE + 0x00))
>  
>  static void uart_write_polled( char c )
>  {
> -  if(init_needed) beagle_console_init();
> -
>while( ( CONSOLE_LSR & TX_FIFO_E ) == 0 )
>  ;
>CONSOLE_THR8 = c;
>  }
>  
> +rtems_status_code console_initialize(
> +  rtems_device_major_number major,
> +  rtems_device_minor_number minor,
> +  void *arg
> +)
> +{
> +  rtems_termios_initialize();
> +
> +  

Re: [PATCH] rsb: Fix Spike build

[Christian Mauderer]

Hello Hesham and Joel,

On 07/04/2020 16:01, Joel Sherrill wrote:
> Please apply your Christian's and your patch. 

I haven't created a patch for 1.4 yet. But it's quite straightforward.
So maybe just create one instead of applying mine.

Best regards

Christian

> 
> Also bump the dtc base package version number.
> 
> I thought we settled on 1.4.
> 
> --joel
> 
> On Tue, Apr 7, 2020 at 3:56 AM Hesham Almatary
> mailto:hesham.almat...@cl.cam.ac.uk>> wrote:
> 
> * There is no all$ target in Spike
> * There is no longer --with-fesvr flag since fesvr is source-inlined
> by default
> ---
>  source-builder/config/spike-1-1.cfg | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/source-builder/config/spike-1-1.cfg
> b/source-builder/config/spike-1-1.cfg
> index 760e1cc..e731348 100644
> --- a/source-builder/config/spike-1-1.cfg
> +++ b/source-builder/config/spike-1-1.cfg
> @@ -37,10 +37,9 @@ URL:           
> https://github.com/riscv/riscv-isa-sim/
>    cd ${source_dir_spike}
> 
>    ./configure \
> -    --prefix=%{_prefix} \
> -    --with-fesvr=%{_prefix}
> +    --prefix=%{_prefix}
> 
> -  %{__make} %{?_smp_mflags} all$
> +  %{__make} %{?_smp_mflags}
> 
>    cd ${build_top}
> 
> -- 
> 2.17.1
> 
> ___
> devel mailing list
> devel@rtems.org 
> http://lists.rtems.org/mailman/listinfo/devel
> 
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-source-builder] dtc: Update to 1.6.0.

[Christian Mauderer]

Hello Joel,

On 06/04/2020 19:09, Joel Sherrill wrote:
> I tested it and it failed.
> 
>          CC treesource.o
> gmake: *** No rule to make target 'yaml.h', needed by 'yamltree.o'.  Stop.
> + cd
> /usr/home/joel/rtems-work/rtems-source-builder/bare/build/dtc-1.6.0-x86_64-freebsd12.1-1
> + echo '==> %install:'
> ==> %install:
> + pwd
> +
> build_top=/usr/home/joel/rtems-work/rtems-source-builder/bare/build/dtc-1.6.0-x86_64-freebsd12.1-1
> 
> I am guessing it has picked up a dependency on yaml that is not
> accounted for.

Hm. Not really good. I checked an the yaml dependency is already there
in 1.5.1. So most likely the best solution for the release is to just
switch the default dtc to the 1.4.1 that is already used for spike.
Otherwise we will have to add libyaml which might isn't a good idea in
the pre-release phase. What do you think?

Best regards

Christian

> 
> This is the place where spike references dtc.
> 
> ===
> $ git diff
> diff --git a/bare/config/devel/spike.bset b/bare/config/devel/spike.bset
> index 76392f7..bf52b9f 100644
> --- a/bare/config/devel/spike.bset
> +++ b/bare/config/devel/spike.bset
> @@ -4,5 +4,5 @@
>  
>  %define release 1
>  
> -devel/dtc-1.4.1-1
> +devel/dtc-1.6.0-1
>  devel/spike-1.1.0
> 
> 
> On Mon, Apr 6, 2020 at 11:29 AM Joel Sherrill  <mailto:j...@rtems.org>> wrote:
> 
> Before I test it, what about the spike.bset? It still references dtc
> 1.4?
> 
> On Mon, Apr 6, 2020 at 10:54 AM Christian Mauderer
> mailto:o...@c-mauderer.de>> wrote:
> 
> ---
>  bare/config/devel/dtc-1.6.0-1.cfg | 18 ++
>  bare/config/devel/dtc.bset        |  2 +-
>  2 files changed, 19 insertions(+), 1 deletion(-)
>  create mode 100644 bare/config/devel/dtc-1.6.0-1.cfg
> 
> diff --git a/bare/config/devel/dtc-1.6.0-1.cfg
> b/bare/config/devel/dtc-1.6.0-1.cfg
> new file mode 100644
> index 000..f293f12
> --- /dev/null
> +++ b/bare/config/devel/dtc-1.6.0-1.cfg
> @@ -0,0 +1,18 @@
> +#
> +# DTC (Device Tree Compiler) 1.6.0
> +#
> +
> +%if %{release} == %{nil}
> +%define release 1
> +%endif
> +
> +%include %{_configdir}/base.cfg
> +
> +%define dtc_version 1.6.0
> +
> +%hash sha256 dtc-%{dtc_version}.tar.gz
> 9fbe07223a98f2d7088a340b5505d4dfe682d77580e788d08cfcc1b61d8be237
> +
> +#
> +# The DTC build instructions. We use 1.x.x Release 1.
> +#
> +%include %{_configdir}/dtc-1-1.cfg
> diff --git a/bare/config/devel/dtc.bset b/bare/config/devel/dtc.bset
> index d701f93..6700823 100644
> --- a/bare/config/devel/dtc.bset
> +++ b/bare/config/devel/dtc.bset
> @@ -4,4 +4,4 @@
> 
>  %define release 1
> 
> -devel/dtc-1.2.0
> +devel/dtc-1.6.0-1
> -- 
> 2.25.1
> 
> ___
> devel mailing list
> devel@rtems.org <mailto: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-source-builder 0/1] dtc: Update to 1.6.0

[Christian Mauderer]

Hello,

Joel mentioned in the following thread that the DTC build with RSB is a
bit old:

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

This patch updates it to the latest V1.6.0.

I tested it only with Linux. So we should definitively not merge it
without further feedback. Joel: I think you offered tests on FreeBSD?

Best regards

Christian


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

[PATCH rtems-source-builder] dtc: Update to 1.6.0.

[Christian Mauderer]

---
 bare/config/devel/dtc-1.6.0-1.cfg | 18 ++
 bare/config/devel/dtc.bset|  2 +-
 2 files changed, 19 insertions(+), 1 deletion(-)
 create mode 100644 bare/config/devel/dtc-1.6.0-1.cfg

diff --git a/bare/config/devel/dtc-1.6.0-1.cfg 
b/bare/config/devel/dtc-1.6.0-1.cfg
new file mode 100644
index 000..f293f12
--- /dev/null
+++ b/bare/config/devel/dtc-1.6.0-1.cfg
@@ -0,0 +1,18 @@
+#
+# DTC (Device Tree Compiler) 1.6.0
+#
+
+%if %{release} == %{nil}
+%define release 1
+%endif
+
+%include %{_configdir}/base.cfg
+
+%define dtc_version 1.6.0
+
+%hash sha256 dtc-%{dtc_version}.tar.gz 
9fbe07223a98f2d7088a340b5505d4dfe682d77580e788d08cfcc1b61d8be237
+
+#
+# The DTC build instructions. We use 1.x.x Release 1.
+#
+%include %{_configdir}/dtc-1-1.cfg
diff --git a/bare/config/devel/dtc.bset b/bare/config/devel/dtc.bset
index d701f93..6700823 100644
--- a/bare/config/devel/dtc.bset
+++ b/bare/config/devel/dtc.bset
@@ -4,4 +4,4 @@
 
 %define release 1
 
-devel/dtc-1.2.0
+devel/dtc-1.6.0-1
-- 
2.25.1

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

Re: Failures on Overnight build sweep

[Christian Mauderer]

On 06/04/2020 13:59, Christian Mauderer wrote:
> On 06/04/2020 01:40, Chris Johns wrote:
>> On 2020-04-06 09:11, Joel Sherrill wrote:
>>> On Sun, Apr 5, 2020, 5:55 PM Chris Johns >> <mailto:chr...@rtems.org>> wrote:
>>>
>>>     On 2020-04-06 05:04, Christian Mauderer wrote:
>>>  > libbsd on raspberry should work again since yesterday (if you
>>>     refer to
>>>  > that ticket: https://devel.rtems.org/ticket/3903).
>>>
>>>     Did the libbsd config in the RSB get updated?
>>>
>>> I have no idea. Someone who is fixing issues in libbsd should check
>>> that and ensure the RSB reflects the best state of the world.
>>> Otherwise, my testing is a huge HUGE waste of time.
>>>
>>> Ditto for rtems-tools fixes and other repos. If you fix something,
>>> bump hashes
>>
>> It might be the rtems-kernel that needs to be update 
>>
>> https://git.rtems.org/rtems-source-builder/tree/rtems/config/tools/rtems-kernel-5.cfg
> 
> Hello Joel and Chris,
> 
> sorry I missed to update that. I'll check it and send a patch for review.
> 
> Best regards
> 
> Christian

I checked it: Chris pulled that one in together with the reverted commit
from Sebastian today at about 7:00 UTC. So both patches are included in
current RSB master.

Sorry for missing that step. It's something normally not really
necessary during normal development (except if we really want to have a
commit for every RTEMS commit) and I'm still not aware of a lot of stuff
that is touched by the release.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Failures on Overnight build sweep

[Christian Mauderer]

On 06/04/2020 01:40, Chris Johns wrote:
> On 2020-04-06 09:11, Joel Sherrill wrote:
>> On Sun, Apr 5, 2020, 5:55 PM Chris Johns > <mailto:chr...@rtems.org>> wrote:
>>
>>     On 2020-04-06 05:04, Christian Mauderer wrote:
>>  > libbsd on raspberry should work again since yesterday (if you
>>     refer to
>>  > that ticket: https://devel.rtems.org/ticket/3903).
>>
>>     Did the libbsd config in the RSB get updated?
>>
>> I have no idea. Someone who is fixing issues in libbsd should check
>> that and ensure the RSB reflects the best state of the world.
>> Otherwise, my testing is a huge HUGE waste of time.
>>
>> Ditto for rtems-tools fixes and other repos. If you fix something,
>> bump hashes
> 
> It might be the rtems-kernel that needs to be update 
> 
> https://git.rtems.org/rtems-source-builder/tree/rtems/config/tools/rtems-kernel-5.cfg

Hello Joel and Chris,

sorry I missed to update that. I'll check it and send a patch for review.

Best regards

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

Re: Failures on Overnight build sweep

[Christian Mauderer]

Hello Joel,

libbsd on raspberry should work again since yesterday (if you refer to
that ticket: https://devel.rtems.org/ticket/3903).

Did your build already include the revert here:
https://git.rtems.org/rtems/commit/?id=d582d0e130a463842e27070a2e85ebc1acc7b71f

Sebastian reverted it after Chris said that it broke some builds:
https://lists.rtems.org/pipermail/devel/2020-April/059014.html

Best regards

Christian

On 05/04/2020 18:28, Joel Sherrill wrote:
> Hi
> 
> It will take me some time to go through all the failures reported on my
> overnight sweep (which isn't finished everywhere) for Centos 7, Ubuntu,
> and FreeBSD. 
> 
> Please try to look at the failure messages at 
> 
> https://lists.rtems.org/pipermail/build/2020-April/date.html 
> 
> And see if you can help identify the various root causes and fix them. 
> 
> It appears that a number of the BSP bsets do not build to completion 
> on Centos, many things fail on FreeBSD 12, etc.  For example, this
> for the PC BSP bset on CentOS:
> 
> https://lists.rtems.org/pipermail/build/2020-April/012862.html 
> 
> The rasperrypi2 bset build failure is well-known and has a ticket. 
> 
> Help is really appreciated triaging and fixing these. 
> 
> --joel
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] bsp/raspberry: Add a bsp_fdt_map_intr().

[Christian Mauderer]

On 04/04/2020 19:10, Gedare Bloom wrote:
> Looks good, go ahead; thanks.

Thanks for the review. Pushed it.

> 
> On Sat, Apr 4, 2020 at 10:39 AM Christian Mauderer  wrote:
>>
>> From: Christian Mauderer 
>>
>> Fixes #3903
>> ---
>>  bsps/arm/raspberrypi/include/bsp/irq.h |  3 +++
>>  bsps/arm/raspberrypi/start/bspstart.c  | 24 
>>  2 files changed, 27 insertions(+)
>>
>> diff --git a/bsps/arm/raspberrypi/include/bsp/irq.h 
>> b/bsps/arm/raspberrypi/include/bsp/irq.h
>> index 6a9d05cba6..17e4472b34 100644
>> --- a/bsps/arm/raspberrypi/include/bsp/irq.h
>> +++ b/bsps/arm/raspberrypi/include/bsp/irq.h
>> @@ -35,6 +35,8 @@
>>
>>  #define BCM2835_INTC_TOTAL_IRQ   64 + 8
>>
>> +#define BCM2835_IRQ_SET1_MIN 0
>> +#define BCM2835_IRQ_SET2_MIN 32
>>
>>  #define BCM2835_IRQ_ID_GPU_TIMER_M0  0
>>  #define BCM2835_IRQ_ID_GPU_TIMER_M1  1
>> @@ -69,6 +71,7 @@
>>
>>  #define BSP_INTERRUPT_VECTOR_MIN(0)
>>  #define BSP_INTERRUPT_VECTOR_MAX(BCM2835_INTC_TOTAL_IRQ - 1)
>> +#define BSP_INTERRUPT_VECTOR_INVALID (UINT32_MAX)
>>
>>  #define BSP_IRQ_COUNT   (BCM2835_INTC_TOTAL_IRQ)
>>
>> diff --git a/bsps/arm/raspberrypi/start/bspstart.c 
>> b/bsps/arm/raspberrypi/start/bspstart.c
>> index 49896e4d47..8d7f6aa503 100644
>> --- a/bsps/arm/raspberrypi/start/bspstart.c
>> +++ b/bsps/arm/raspberrypi/start/bspstart.c
>> @@ -23,6 +23,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>
>> @@ -101,6 +102,29 @@ void *raspberrypi_get_reg_of_node(const void *fdt, int 
>> node)
>>return (BUS_TO_PHY((void *) fdt32_to_cpu(val[0])));
>>  }
>>
>> +#ifdef BSP_FDT_IS_SUPPORTED
>> +uint32_t bsp_fdt_map_intr(const uint32_t *intr, size_t icells)
>> +{
>> +  uint32_t controller = intr[0];
>> +  uint32_t source = intr[1];
>> +
>> +  switch ( controller ) {
>> +case 0:
>> +return source + BCM2835_IRQ_ID_BASIC_BASE_ID;
>> +break;
>> +case 1:
>> +return source + BCM2835_IRQ_SET1_MIN;
>> +break;
>> +case 2:
>> +return source + BCM2835_IRQ_SET2_MIN;
>> +break;
>> +default:
>> +return BSP_INTERRUPT_VECTOR_INVALID;
>> +break;
>> +  }
>> +}
>> +#endif /* BSP_FDT_IS_SUPPORTED */
>> +
>>  void bsp_start(void)
>>  {
>>  bcm2835_get_board_spec_entries spec = { 0 };
>> --
>> 2.25.1
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2] bsp/raspberry: Add a bsp_fdt_map_intr().

[Christian Mauderer]

From: Christian Mauderer 

Fixes #3903
---
 bsps/arm/raspberrypi/include/bsp/irq.h |  3 +++
 bsps/arm/raspberrypi/start/bspstart.c  | 24 
 2 files changed, 27 insertions(+)

diff --git a/bsps/arm/raspberrypi/include/bsp/irq.h 
b/bsps/arm/raspberrypi/include/bsp/irq.h
index 6a9d05cba6..17e4472b34 100644
--- a/bsps/arm/raspberrypi/include/bsp/irq.h
+++ b/bsps/arm/raspberrypi/include/bsp/irq.h
@@ -35,6 +35,8 @@
 
 #define BCM2835_INTC_TOTAL_IRQ   64 + 8
 
+#define BCM2835_IRQ_SET1_MIN 0
+#define BCM2835_IRQ_SET2_MIN 32
 
 #define BCM2835_IRQ_ID_GPU_TIMER_M0  0
 #define BCM2835_IRQ_ID_GPU_TIMER_M1  1
@@ -69,6 +71,7 @@
 
 #define BSP_INTERRUPT_VECTOR_MIN(0)
 #define BSP_INTERRUPT_VECTOR_MAX(BCM2835_INTC_TOTAL_IRQ - 1)
+#define BSP_INTERRUPT_VECTOR_INVALID (UINT32_MAX)
 
 #define BSP_IRQ_COUNT   (BCM2835_INTC_TOTAL_IRQ)
 
diff --git a/bsps/arm/raspberrypi/start/bspstart.c 
b/bsps/arm/raspberrypi/start/bspstart.c
index 49896e4d47..8d7f6aa503 100644
--- a/bsps/arm/raspberrypi/start/bspstart.c
+++ b/bsps/arm/raspberrypi/start/bspstart.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -101,6 +102,29 @@ void *raspberrypi_get_reg_of_node(const void *fdt, int 
node)
   return (BUS_TO_PHY((void *) fdt32_to_cpu(val[0])));
 }
 
+#ifdef BSP_FDT_IS_SUPPORTED
+uint32_t bsp_fdt_map_intr(const uint32_t *intr, size_t icells)
+{
+  uint32_t controller = intr[0];
+  uint32_t source = intr[1];
+
+  switch ( controller ) {
+case 0:
+return source + BCM2835_IRQ_ID_BASIC_BASE_ID;
+break;
+case 1:
+return source + BCM2835_IRQ_SET1_MIN;
+break;
+case 2:
+return source + BCM2835_IRQ_SET2_MIN;
+break;
+default:
+return BSP_INTERRUPT_VECTOR_INVALID;
+break;
+  }
+}
+#endif /* BSP_FDT_IS_SUPPORTED */
+
 void bsp_start(void)
 {
 bcm2835_get_board_spec_entries spec = { 0 };
-- 
2.25.1

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

Re: [PATCH] bsp/raspberry: Add a bsp_fdt_map_intr().

[Christian Mauderer]

On 04/04/2020 17:04, Gedare Bloom wrote:
> On Sat, Apr 4, 2020 at 4:57 AM Christian Mauderer  wrote:
>>
>> From: Christian Mauderer 
>>
>> Fixes #3903
>> ---
>>  bsps/arm/raspberrypi/include/bsp/irq.h |  2 ++
>>  bsps/arm/raspberrypi/start/bspstart.c  | 23 +++
>>  2 files changed, 25 insertions(+)
>>
>> diff --git a/bsps/arm/raspberrypi/include/bsp/irq.h 
>> b/bsps/arm/raspberrypi/include/bsp/irq.h
>> index 6a9d05cba6..6758094519 100644
>> --- a/bsps/arm/raspberrypi/include/bsp/irq.h
>> +++ b/bsps/arm/raspberrypi/include/bsp/irq.h
>> @@ -35,6 +35,8 @@
>>
>>  #define BCM2835_INTC_TOTAL_IRQ   64 + 8
>>
>> +#define BCM2835_IRQ_SET1_MIN 0
>> +#define BCM2835_IRQ_SET2_MIN 32
>>
>>  #define BCM2835_IRQ_ID_GPU_TIMER_M0  0
>>  #define BCM2835_IRQ_ID_GPU_TIMER_M1  1
>> diff --git a/bsps/arm/raspberrypi/start/bspstart.c 
>> b/bsps/arm/raspberrypi/start/bspstart.c
>> index 49896e4d47..89fe8707f1 100644
>> --- a/bsps/arm/raspberrypi/start/bspstart.c
>> +++ b/bsps/arm/raspberrypi/start/bspstart.c
>> @@ -101,6 +101,29 @@ void *raspberrypi_get_reg_of_node(const void *fdt, int 
>> node)
>>return (BUS_TO_PHY((void *) fdt32_to_cpu(val[0])));
>>  }
>>
>> +#ifdef BSP_FDT_IS_SUPPORTED
>> +uint32_t bsp_fdt_map_intr(const uint32_t *intr, size_t icells)
>> +{
>> +  uint32_t controller = intr[0];
>> +  uint32_t source = intr[1];
>> +
>> +  switch(controller) {
> should have spaces here:
>   switch ( controller ) {

I'll fix that before pushing.

> 
>> +case 0:
>> +return source + BCM2835_IRQ_ID_BASIC_BASE_ID;
>> +break;
>> +case 1:
>> +return source + BCM2835_IRQ_SET1_MIN;
>> +break;
>> +case 2:
>> +return source + BCM2835_IRQ_SET2_MIN;
>> +break;
>> +default:
>> +return (uint32_t)(-1);
> Not my favorite thing to see. Is 0 an ok error condition?
> 
> It can be pushed either way

0 is a valid interrupt. I wanted one that isn't valid as an error value
so that some function throws an error (for example there are some checks
during bsp_interrupt_vector_enable / _disable for this BSP).

If you prefer, I could use one of the following:

* (BSP_INTERRUPT_VECTOR_MAX + 1)
* BSP_IRQ_COUNT
* UINT32_MAX
* BSP_INTERRUPT_VECTOR_INVALID and set that define to for example UINT32_MAX

Best regards

Christian

> 
>> +break;
>> +  }
>> +}
>> +#endif /* BSP_FDT_IS_SUPPORTED */
>> +
>>  void bsp_start(void)
>>  {
>>  bcm2835_get_board_spec_entries spec = { 0 };
>> --
>> 2.25.1
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] bsp/raspberry: Add a bsp_fdt_map_intr().

[Christian Mauderer]

From: Christian Mauderer 

Fixes #3903
---
 bsps/arm/raspberrypi/include/bsp/irq.h |  2 ++
 bsps/arm/raspberrypi/start/bspstart.c  | 23 +++
 2 files changed, 25 insertions(+)

diff --git a/bsps/arm/raspberrypi/include/bsp/irq.h 
b/bsps/arm/raspberrypi/include/bsp/irq.h
index 6a9d05cba6..6758094519 100644
--- a/bsps/arm/raspberrypi/include/bsp/irq.h
+++ b/bsps/arm/raspberrypi/include/bsp/irq.h
@@ -35,6 +35,8 @@
 
 #define BCM2835_INTC_TOTAL_IRQ   64 + 8
 
+#define BCM2835_IRQ_SET1_MIN 0
+#define BCM2835_IRQ_SET2_MIN 32
 
 #define BCM2835_IRQ_ID_GPU_TIMER_M0  0
 #define BCM2835_IRQ_ID_GPU_TIMER_M1  1
diff --git a/bsps/arm/raspberrypi/start/bspstart.c 
b/bsps/arm/raspberrypi/start/bspstart.c
index 49896e4d47..89fe8707f1 100644
--- a/bsps/arm/raspberrypi/start/bspstart.c
+++ b/bsps/arm/raspberrypi/start/bspstart.c
@@ -101,6 +101,29 @@ void *raspberrypi_get_reg_of_node(const void *fdt, int 
node)
   return (BUS_TO_PHY((void *) fdt32_to_cpu(val[0])));
 }
 
+#ifdef BSP_FDT_IS_SUPPORTED
+uint32_t bsp_fdt_map_intr(const uint32_t *intr, size_t icells)
+{
+  uint32_t controller = intr[0];
+  uint32_t source = intr[1];
+
+  switch(controller) {
+case 0:
+return source + BCM2835_IRQ_ID_BASIC_BASE_ID;
+break;
+case 1:
+return source + BCM2835_IRQ_SET1_MIN;
+break;
+case 2:
+return source + BCM2835_IRQ_SET2_MIN;
+break;
+default:
+return (uint32_t)(-1);
+break;
+  }
+}
+#endif /* BSP_FDT_IS_SUPPORTED */
+
 void bsp_start(void)
 {
 bcm2835_get_board_spec_entries spec = { 0 };
-- 
2.25.1

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

[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;
>>>> + 

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

[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

[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

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

[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 rtems-docs] user/imx: Add i.MX6UL/ULL.

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

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

[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 libbsd 09/11] ehci_imx.c: Port to RTEMS

[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

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

[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

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

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

[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

[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

[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

[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).

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

[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

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

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

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

[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

[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: RTEMS 5 release status

[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: RTEMS 5 release status

[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

[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

Re: [PATCH libbsd v2] mmcsd: Don't handle multiple hardware partitions.

[Christian Mauderer]

On 01/04/2020 14:10, Sebastian Huber wrote:
> On 01/04/2020 14:09, Christian Mauderer wrote:
> 
>> On 01/04/2020 11:55, Sebastian Huber wrote:
>>> On 01/04/2020 11:45, Christian Mauderer wrote:
>>>> The rtems_bsd_mmcsd_attach_worker acquired the bus without releasing it.
>>>> If a MMC device has multiple hardware partitions (like eMMC which
>>>> typically has at least one boot partition) the
>>>> rtems_bsd_mmcsd_attach_worker would try to acquire the bus multiple
>>>> times. This doesn't work.
>>>>
>>>> Doing it right would mean to acquire and release the bus for each
>>>> access which would have an performance impact. Beneath that it would
>>>> mean that partition switching has to be supported by the RTEMS code too.
>>>>
>>>> There is currently no known use case where the access would be
>>>> necessary. Therefore this patch prefers the performance and just avoids
>>>> all further hardware partitions.
>>> Looks good.
>>>
>> Should we apply it only to master or to 5-freebsd-12 too? The problem
>> affects both so I would suggest to apply it to both branches.
> Both branches please.

Thanks. I pushed it.
-- 

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 v2] mmcsd: Don't handle multiple hardware partitions.

[Christian Mauderer]

On 01/04/2020 11:55, Sebastian Huber wrote:
> On 01/04/2020 11:45, Christian Mauderer wrote:
>> The rtems_bsd_mmcsd_attach_worker acquired the bus without releasing it.
>> If a MMC device has multiple hardware partitions (like eMMC which
>> typically has at least one boot partition) the
>> rtems_bsd_mmcsd_attach_worker would try to acquire the bus multiple
>> times. This doesn't work.
>>
>> Doing it right would mean to acquire and release the bus for each
>> access which would have an performance impact. Beneath that it would
>> mean that partition switching has to be supported by the RTEMS code too.
>>
>> There is currently no known use case where the access would be
>> necessary. Therefore this patch prefers the performance and just avoids
>> all further hardware partitions.
> 
> Looks good.
> 

Should we apply it only to master or to 5-freebsd-12 too? The problem
affects both so I would suggest to apply it to both branches.

-- 

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

[PATCH libbsd v2] mmcsd: Don't handle multiple hardware partitions.

[Christian Mauderer]

The rtems_bsd_mmcsd_attach_worker acquired the bus without releasing it.
If a MMC device has multiple hardware partitions (like eMMC which
typically has at least one boot partition) the
rtems_bsd_mmcsd_attach_worker would try to acquire the bus multiple
times. This doesn't work.

Doing it right would mean to acquire and release the bus for each
access which would have an performance impact. Beneath that it would
mean that partition switching has to be supported by the RTEMS code too.

There is currently no known use case where the access would be
necessary. Therefore this patch prefers the performance and just avoids
all further hardware partitions.
---
 freebsd/sys/dev/mmc/mmcsd.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/freebsd/sys/dev/mmc/mmcsd.c b/freebsd/sys/dev/mmc/mmcsd.c
index 077f8d74..21f54046 100644
--- a/freebsd/sys/dev/mmc/mmcsd.c
+++ b/freebsd/sys/dev/mmc/mmcsd.c
@@ -436,6 +436,15 @@ rtems_bsd_mmcsd_attach_worker(rtems_media_state state, 
const char *src, char **d
goto error;
}
 
+   /*
+* FIXME: There is no release for this acquire. Implementing
+* this would be necessary for:
+* - multiple hardware partitions of eMMC chips
+* - multiple devices on one bus
+*
+* On the other hand it would mean that the bus has to be
+* acquired on every read which would decrease the performance.
+*/
MMCBUS_ACQUIRE_BUS(device_get_parent(dev), dev);
 
status_code = rtems_bsd_mmcsd_set_block_size(dev, block_size);
@@ -764,6 +773,10 @@ mmcsd_add_part(struct mmcsd_softc *sc, u_int type, const 
char *name, u_int cnt,
free(part, M_DEVBUF);
return;
}
+#ifdef __rtems__
+   } else if (type != EXT_CSD_PART_CONFIG_ACC_DEFAULT) {
+   printf("%s: Additional partition. This is currently not 
supported in RTEMS.", part->name);
+#endif /* __rtems__ */
} else {
MMCSD_DISK_LOCK_INIT(part);
 
-- 
2.16.4

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

Re: [PATCH libbsd] mmcsd: Fix missing MMCBUS_RELEASE_BUS.

[Christian Mauderer]

Hello Sebastian,

thanks for the review.

On 01/04/2020 10:41, Sebastian Huber wrote:
> On 01/04/2020 10:03, Christian Mauderer wrote:
> 
>> The rtems_bsd_mmcsd_attach_worker acquired the bus without releasing it.
>> Fix that by only acquire the bus if necessary (during initialization and
>> during read / writes).
>> ---
>>   freebsd/sys/dev/mmc/mmcsd.c | 8 ++--
>>   1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/freebsd/sys/dev/mmc/mmcsd.c b/freebsd/sys/dev/mmc/mmcsd.c
>> index 077f8d74..674be6a7 100644
>> --- a/freebsd/sys/dev/mmc/mmcsd.c
>> +++ b/freebsd/sys/dev/mmc/mmcsd.c
>> @@ -268,6 +268,8 @@ rtems_bsd_mmcsd_set_block_size(device_t dev,
>> uint32_t block_size)
>>   memset(, 0, sizeof(req));
>>   memset(, 0, sizeof(cmd));
>>   +    MMCBUS_ACQUIRE_BUS(device_get_parent(dev), dev);
>> +
>>   req.cmd = 
>>   cmd.opcode = MMC_SET_BLOCKLEN;
>>   cmd.flags = MMC_RSP_R1 | MMC_CMD_AC;
>> @@ -278,6 +280,8 @@ rtems_bsd_mmcsd_set_block_size(device_t dev,
>> uint32_t block_size)
>>   status_code = RTEMS_IO_ERROR;
>>   }
>>   +    MMCBUS_RELEASE_BUS(device_get_parent(dev), dev);
>> +
>>   return status_code;
>>   }
>>   @@ -316,6 +320,7 @@ rtems_bsd_mmcsd_disk_read_write(struct
>> mmcsd_part *part, rtems_blkdev_request *b
>>   data_flags = MMC_DATA_READ;
>>   }
>>   +    MMCBUS_ACQUIRE_BUS(device_get_parent(dev), dev);
>>   MMCSD_DISK_LOCK(part);
> 
> I don't really know when you have to acquire the bus, but it is an
> expensive operation. Did you measure the performance impact of this change?
> 

No I didn't measure the performance impact.

The original FreeBSD code does the acquire and release around bus
accesses in the mmcsd_task. It covers switching partitions as well as
reading and writing.:

MMCBUS_ACQUIRE_BUS(mmcbus, dev);
sz = part->disk->d_sectorsize;
block = bp->bio_pblkno;
end = bp->bio_pblkno + (bp->bio_bcount / sz);
err = mmcsd_switch_part(mmcbus, dev, sc->rca, part->type);
if (err != MMC_ERR_NONE) {
if (ppsratecheck(>log_time, >log_count,
LOG_PPS))
device_printf(dev, "Partition switch error\n");
goto release;
}
if (bp->bio_cmd == BIO_READ || bp->bio_cmd == BIO_WRITE) {
/* Access to the remaining erase block obsoletes it. */
if (block < part->eend && end > part->eblock)
part->eblock = part->eend = 0;
block = mmcsd_rw(part, bp);
} else if (bp->bio_cmd == BIO_DELETE) {
block = mmcsd_delete(part, bp);
}
release:
MMCBUS_RELEASE_BUS(mmcbus, dev);

> I guess the use of the disk lock here was an optimization. If we really
> want to use the bus lock, then the disk lock should be removed.
> 
>>     for (i = 0; i < buffer_count; ++i) {
>> @@ -394,6 +399,7 @@ rtems_bsd_mmcsd_disk_read_write(struct mmcsd_part
>> *part, rtems_blkdev_request *b
>>   error:
>>     MMCSD_DISK_UNLOCK(part);
>> +    MMCBUS_RELEASE_BUS(device_get_parent(dev), dev);
>>     rtems_blkdev_request_done(blkreq, status_code);
>>   @@ -436,8 +442,6 @@ rtems_bsd_mmcsd_attach_worker(rtems_media_state
>> state, const char *src, char **d
>>   goto error;
>>   }
>>   -    MMCBUS_ACQUIRE_BUS(device_get_parent(dev), dev);
> 
> I think the bus acquire here is necessary to prevent an
> rtems_blkdev_create() while the bus is detached in parallel, e.g. a fast
> plug/unplug of an USB stick.
> 
> After reviewing the code I think this bus acquire without a release
> (which is in the code since the import from libusb in 2015) was a hack
> to improve the read/write performance. We didn't support hot plugging of
> MMC busses and devices. Do we need this feature now?

Sorry I didn't explain it: The problem is not hot plugging the busses or
the card. For that quite a bit more changes would be necessary. The
problem is that eMMC cards have multiple (hardware) partitions and
therefore call this code multiple times. For the second partition the
bus is already locked and therefore the MMCBUS_ACQUIRE_BUS just hangs.
The function is called from the media_server which then hangs too and
can't handle any new disks.

But I noted that there is a partition switching missing for the eMMC
cards too. Otherwise the wrong partition is used during detection of the
second one.

So another maybe better approach for now is to ignore any additional
hardware partions except the first one. That would need a hack to
mmcsd

[PATCH libbsd] mmcsd: Fix missing MMCBUS_RELEASE_BUS.

[Christian Mauderer]

The rtems_bsd_mmcsd_attach_worker acquired the bus without releasing it.
Fix that by only acquire the bus if necessary (during initialization and
during read / writes).
---
 freebsd/sys/dev/mmc/mmcsd.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/freebsd/sys/dev/mmc/mmcsd.c b/freebsd/sys/dev/mmc/mmcsd.c
index 077f8d74..674be6a7 100644
--- a/freebsd/sys/dev/mmc/mmcsd.c
+++ b/freebsd/sys/dev/mmc/mmcsd.c
@@ -268,6 +268,8 @@ rtems_bsd_mmcsd_set_block_size(device_t dev, uint32_t 
block_size)
memset(, 0, sizeof(req));
memset(, 0, sizeof(cmd));
 
+   MMCBUS_ACQUIRE_BUS(device_get_parent(dev), dev);
+
req.cmd = 
cmd.opcode = MMC_SET_BLOCKLEN;
cmd.flags = MMC_RSP_R1 | MMC_CMD_AC;
@@ -278,6 +280,8 @@ rtems_bsd_mmcsd_set_block_size(device_t dev, uint32_t 
block_size)
status_code = RTEMS_IO_ERROR;
}
 
+   MMCBUS_RELEASE_BUS(device_get_parent(dev), dev);
+
return status_code;
 }
 
@@ -316,6 +320,7 @@ rtems_bsd_mmcsd_disk_read_write(struct mmcsd_part *part, 
rtems_blkdev_request *b
data_flags = MMC_DATA_READ;
}
 
+   MMCBUS_ACQUIRE_BUS(device_get_parent(dev), dev);
MMCSD_DISK_LOCK(part);
 
for (i = 0; i < buffer_count; ++i) {
@@ -394,6 +399,7 @@ rtems_bsd_mmcsd_disk_read_write(struct mmcsd_part *part, 
rtems_blkdev_request *b
 error:
 
MMCSD_DISK_UNLOCK(part);
+   MMCBUS_RELEASE_BUS(device_get_parent(dev), dev);
 
rtems_blkdev_request_done(blkreq, status_code);
 
@@ -436,8 +442,6 @@ rtems_bsd_mmcsd_attach_worker(rtems_media_state state, 
const char *src, char **d
goto error;
}
 
-   MMCBUS_ACQUIRE_BUS(device_get_parent(dev), dev);
-
status_code = rtems_bsd_mmcsd_set_block_size(dev, block_size);
if (status_code != RTEMS_SUCCESSFUL) {
printf("OOPS: set block size failed\n");
-- 
2.16.4

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

Re: Problem about porting TCP/IP Stack

[Christian Mauderer]

On 27/03/2020 15:58, jameszxj wrote:
> Hi all,
> ?0?2 ?0?2 ?0?2 ?0?2 Since rtems-libbsd is too heavy for our project, so I 
> tried to
> port?0?2Lightweight TCP/IP stacks.?0?2 First I tried lwip, it worked but
> crashed now and then.
> The PC pointed at function?0?2_Heap_Block_split()??I could not figure it
> out. So I tried cycloneTCP . It is more simple than lwip.?0?2 But I
> encountered the same problem.
> System still crashed at?0?2_Heap_Block_split()?0?2sometimes 
> (random),?0?2?0?2It made
> me crazy :(
> ?0?2 ?0?2 ?0?2 ?0?2I tried on diffrent CPUs (zynq7020, sunxi-t3), the problem 
> was
> still there.?0?2?0?2_Heap_Block_split() is a core function, It seems to have
> nothing to do with the stack.
> Attachments are error messages and?0?2disassembly code.?0?2Any advices?
> ?0?2 ?0?2 ?0?2 ?0?2Thanks.
> 
> 
> 

Hello,

I'm quite sure that I've seen some mails regarding lwIP. So there should
be already users for that.

Without having a detailed look at the crash message: If there are
problems with the heap you might want to use

--enable-rtems-debug

during RTEMS configure and maybe add

#define CONFIGURE_STACK_CHECKER_ENABLED

to your configuration. Problems with the heap can be from some part of
the application writing over the end of a buffer or similar. If that
destroys heap structures, you might get problems as soon as RTEMS want's
to do something with the heap. The rtems_debug enables quite a lot of
run time checks like a heap protection. That can help finding the bug.

Note that you have to re-build all libraries after you enable or disable
rtems-debug because some data structures change with that.

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?0?1ftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] MAINTAINERS: Add myself to Write After Approval

[Christian Mauderer]

On 25/03/2020 15:59, Vijay Kumar Banerjee wrote:
> 
> 
> On Wed, Mar 25, 2020 at 8:16 PM Gedare Bloom  <mailto:ged...@rtems.org>> wrote:
> 
> Looks good, please push.
> 
> Pushed! :) 

Congratulations. Your maintainer status is now officially documented.

Best regards

Christian

> 
> On Tue, Mar 24, 2020 at 1:49 PM Vijay Kumar Banerjee
> mailto:vi...@rtems.org>> wrote:
> >
> > ---
> >  MAINTAINERS | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 437b55418b..29e22357a5 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -52,6 +52,7 @@ Pavel Pisa                 pp...@pikron.com
> <mailto:pp...@pikron.com>
> >  Christian Mauderer         christian.maude...@embedded-brains.de
> <mailto:christian.maude...@embedded-brains.de>
> >  Hesham Almatary            heshamelmat...@gmail.com
> <mailto:heshamelmat...@gmail.com>
> >  Amaan Cheval               am...@rtems.org <mailto:am...@rtems.org>
> > +Vijay Kumar Banerjee       vi...@rtems.org <mailto:vi...@rtems.org>
> >
> >  Localized Write Permission
> >  ==
> > @@ -60,4 +61,5 @@ beagle                     Ben Gras
> (b...@rtems.org <mailto:b...@rtems.org>)
> >  tms570                     Pavel Pisa (p...@cmp.felk.cvut.cz
> <mailto:p...@cmp.felk.cvut.cz>)
> >  raspberrypi                Pavel Pisa (p...@cmp.felk.cvut.cz
> <mailto:p...@cmp.felk.cvut.cz>)
> >  x86_64                     Amaan Cheval (am...@rtems.org
> <mailto:am...@rtems.org>)
> > +beagle                     Vijay Kumar Banerjee (vi...@rtems.org
> <mailto:vi...@rtems.org>)
> >
> > --
> > 2.21.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org <mailto:devel@rtems.org>
> > http://lists.rtems.org/mailman/listinfo/devel
> 
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 

-- 

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

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

Re: [PATCH v2] bsp/beagle: Update console to new Termios device API.

[Christian Mauderer]

Hello Niteesh,


On 15/03/2020 20:44, G S Niteesh Babu wrote:
> This patch updates the console to use new Termios device API.
> Update #3034
> ---
>  bsps/arm/beagle/console/console-config.c | 66 +++-
>  1 file changed, 41 insertions(+), 25 deletions(-)
> 
> diff --git a/bsps/arm/beagle/console/console-config.c 
> b/bsps/arm/beagle/console/console-config.c
> index 78af5f6a93..860a44cb00 100644
> --- a/bsps/arm/beagle/console/console-config.c
> +++ b/bsps/arm/beagle/console/console-config.c
> @@ -41,6 +41,8 @@
>  #define TX_FIFO_E (1<<5)
>  #define RX_FIFO_E (1<<0)
>  
> +#define UART0 "/dev/ttyS0"
> +

I'm not a big fan of such a generic name for a define. It's quite
possible that it conflicts with another define in the future.

I would suggest BEAGLE_UART0 or similar.

>  static uint8_t beagle_uart_get_register(uintptr_t addr, uint8_t i)
>  {
>uint8_t v;
> @@ -65,34 +67,27 @@ static void beagle_uart_set_register(uintptr_t addr, 
> uint8_t i, uint8_t val)
>reg [i] = val;
>  }
>  
> -console_tbl Console_Configuration_Ports [] = {
> -{
> -  .sDeviceName = "/dev/ttyS0",
> -  .deviceType = SERIAL_NS16550,
> -#if CONSOLE_POLLED   /* option to facilitate running the tests */
> -  .pDeviceFns = _fns_polled,
> -#else
> -  .pDeviceFns = _fns,
> -#endif
> -  .ulMargin = 16,
> -  .ulHysteresis = 8,
> -  .pDeviceParams = (void *) CONSOLE_BAUD,
> -  .ulCtrlPort1 = BSP_CONSOLE_UART_BASE,
> -  .ulDataPort = BSP_CONSOLE_UART_BASE,
> -  .ulIntVector = BSP_CONSOLE_UART_IRQ,
> -  .getRegister = beagle_uart_get_register,
> -  .setRegister = beagle_uart_set_register,
> -  .ulClock = UART_CLOCK,  /* 48MHz base clock */
> -},
> -};
> -
> -unsigned long Console_Configuration_Count = 1;
> +ns16550_context uart_context;
>  
>  static int init_needed = 1; // don't rely on bss being 0
>  
>  static void beagle_console_init(void)
>  {
>if(init_needed) {
> +ns16550_context *ctx;
> +
> +/*
> +   *  Don't rely on BSS being 0
> +*/
> +memset(_context, 0, sizeof(uart_context));
> +ctx = _context;
> +
> +ctx->port = BSP_CONSOLE_UART_BASE;
> +ctx->get_reg = beagle_uart_get_register;
> +ctx->set_reg = beagle_uart_set_register;
> +ctx->clock = UART_CLOCK;
> +ctx->initial_baud = CONSOLE_BAUD;
> +
>  const uint32_t div = UART_CLOCK / 16 / CONSOLE_BAUD;
>  CONSOLE_SYSC = 2;
>  while ((CONSOLE_SYSS & 1) == 0)
> @@ -120,6 +115,8 @@ static void beagle_console_init(void)
>  CONSOLE_LCR = 0x03;
>  CONSOLE_ACR = 0x00;
>  init_needed = 0;
> +
> +BSP_output_char = uart_write_polled;
>}
>  }
>  
> @@ -127,15 +124,17 @@ static void beagle_console_init(void)
>  
>  static void uart_write_polled( char c )
>  {
> -  if(init_needed) beagle_console_init();
> -
>while( ( CONSOLE_LSR & TX_FIFO_E ) == 0 )
>  ;
>CONSOLE_THR8 = c;
>  }
>  
>  static void _BSP_put_char( char c ) {
> -   uart_write_polled( c );
> +
> +  if ( init_needed ) {
> +beagle_console_init();
> +  }
> +  uart_write_polled( c );

Why did you have to move the "if (init_needed)" from uart_write_polled
to _BSP_put_char? It seems that it does the same as long as
_BSP_put_char is called first. But if uart_write_polled is called first,
it will lead to an unitialised hardware, wouldn't it?

By the way: Did you have a look whether there are two functions? They
are both static and it seems that only _BSP_put_char is used. So it
seems a bit odd...

>  }
>  
>  static int _BSP_get_char(void)
> @@ -147,6 +146,23 @@ static int _BSP_get_char(void)
>}
>  }
>  
> +rtems_status_code console_initialize(
> +  rtems_device_major_number major,
> +  rtems_device_minor_number minor,
> +  void *arg
> +)
> +{
> +  rtems_termios_initialize();
> +  rtems_termios_device_install(
> +UART0,
> +_handler_polled,
> +NULL,
> +_context.base
> +  );
> +
> +  return RTEMS_SUCCESSFUL;
> +}
> +
>  BSP_output_char_function_type BSP_output_char = _BSP_put_char;
>  
>  BSP_polling_getchar_function_type BSP_poll_char = _BSP_get_char;
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-boot-image tool: Raspberry Pi

[Christian Mauderer]

Hello Niteesh,

thanks for the (private) remainder. This thread really stopped quite
some time ago. A lot of us are quite busy right now but that shouldn't
happen. If you don't get a response for some question: Please give it
about a week of time and then just ping the thread.

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

Chris is most likely too busy with the release right now.

> 
> In my opinion, there are two ways to do it.
> The first would be to modify the U-Boot bootloader object to have a
> files field
> to make sure the user provides all the necessary files(fixup.dat,
> startx.elf, config.txt).
> So after this change the rtems-boot.ini for RPI should look something
> like this
> [u-boot-raspberrypi]
> uses = u-boot-arm-raspberrypi
> ..
> ..
> first_stage = %{ubootdir}/bootcode.bin
> boot_device = mmc 0
> second_stage = uboot or startx
> files = [config.txt, fixup.dat etc]
> But also please keep in mind that if we want to support RPi4 then the
> first_stage
> will start4x.elf since bootcode.bin is now replaced by code in the
> EEPROM in RPi4 SOC.

As far as I understand that approach it more or less tells: To start a
raspberry you need U-Boot. U-Boot needs the fixup.dat, startx.elf and
config.txt to boot. But that sounds a bit wrong. On Raspberry U-Boot is
purely optional, isn't it? So from a high-level view it would be more a

- Raspberry needs fixup.dat, startx.elf and config.txt
- That can start either:
  - an application or
  - an U-Boot which can then start an application (or do other things)

> 
> Another approach will be to create the default Raspberry Pi bootloader
> object. But having
> support for U-Boot is important since it will allow for automatic testing.

That approach sounds more correct. But I don't really know the
rtems-boot-image tool. That makes it a lot harder for me to tell whether
that approach works well. From that ignorant position I would say that
it would be nice to have a boot-image command that can be called with or
without a option (like --with-u-boot). Alternatively maybe two targets
would be possible. One raspiboot-u-boot-pi1 and one raspiboot-raw-pi1.

But your best bet might is to wait for Chris to get free again and
answer that question. He knows the boot image tool and can tell you a
lot better which concept works best.

Best regards

Christian

> 
> Which one do you think is a better approach?
> 
> Thank you.
> 
> 
> >
> > So, what should be the values for the first and second stages in
> rtems-boot.ini
> > for Rpi?
> 
> Would this be bootcode.bin?
> 
> > And also wouldn't it be nice if we could add a files field, which
> will copy the
> > specified files to the image? This would save a lot of typing in
> case of RPi
> 
> Do you have an example?
> 
> Chris
> 
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 rtems_littlevgl 1/3] waf: Remove unnecessary code.

[Christian Mauderer]

No one objected to these patches so I pushed them.

Best regards

Christian

On 17/03/2020 08:18, Christian Mauderer wrote:
> ---
>  lvgl.py | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/lvgl.py b/lvgl.py
> index 5452ed0..f275287 100644
> --- a/lvgl.py
> +++ b/lvgl.py
> @@ -68,26 +68,17 @@ def build(bld):
>  
>  sources, includes = source_list(bld)
>  includes.append('.')
> -objects = []
>  include_paths = []
>  
>  for source in sources:
> -objects.append(source[:-1] + 'o')
>  source_dir = os.path.dirname(source)
>  if source_dir not in include_paths:
>  include_paths.append(source_dir)
>  
> -bld.objects(target = objects,
> -features = 'c',
> -cflags = '-O2',
> -includes = includes,
> -source = source)
> -
>  bld.stlib(target = 'lvgl',
>features = 'c',
>includes = includes,
> -  source = sources,
> -  use = objects)
> +  source = sources)
>  
>  arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
>  bld.env.RTEMS_ARCH_BSP)
> 

-- 

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: Maintainers of rtems-littlevgl package

[Christian Mauderer]

On 18/03/2020 22:17, Gedare Bloom wrote:
> Hi everyone,
> 
> I'm pleased to announce that the rtems-littlevgl package will be
> maintained (officially) by Christian Mauderer and Vijay Kumar
> Bannerjee. Christian/Vijay, please add a README file to the
> rtems-littlevgl package and include some details about the role of
> that repo in RTEMS, and with your information as the package
> maintainers. Eventually there should also be some instructions on how
> to use it in the README :)
> 
> Thanks,
> Gedare

Hello Gedare,

thanks for the trust.

I'll discuss with Vijay whether he will create the patch or whether I
should do that.

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 rtems-docs] user/raspberrypi: Fix typo

[Christian Mauderer]

Hello Niteesh,

thanks for finding and fixing that. It's a very small patch and no one
objected in the last days. So I pushed it.

Best regards

Christian

On 16/03/2020 15:42, G S Niteesh Babu wrote:
> enable-uart should be enable_uart in config.txt
> ---
>  user/bsps/arm/raspberrypi.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/user/bsps/arm/raspberrypi.rst b/user/bsps/arm/raspberrypi.rst
> index 72889a5..c26f4b5 100644
> --- a/user/bsps/arm/raspberrypi.rst
> +++ b/user/bsps/arm/raspberrypi.rst
> @@ -46,7 +46,7 @@ Make sure you have these lines below, in your 
> ``config.txt``.
>  
>  .. code-block:: none
>  
> - enable-uart=1
> + enable_uart=1
>   kernel_address=0x20
>   kernel=kernel.img
>  
> 

-- 
--------
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: RFC: Exceptions to PEP-8 Adoption for RTEMS Tools

[Christian Mauderer]

Hello Chris and Amar,

On 19/03/2020 04:01, Chris Johns wrote:
> On 19/3/20 7:06 am, Christian Mauderer wrote:
>> Hello Amar,
>>
>> On 18/03/2020 19:24, Amar Takhar wrote:
>>> The only one I would like to propose is the 80 character limit.  This 
>>> should be 
>>> moved to something more reasonable such as 120.
>>>
>>> Code comments should remain below 80 however.
>>>
>>
>> I'm not a big fan of long lines (reason further below) but I won't block
>> it either. But what I think is really a bad idea is to have different
>> rules for different parts of the code.
> 
> And different parts of the project.

Different parts of the project are far less difficult. In that case it's
mostly personal preference / set up of the personal development
environment. Like you noted: Mine isn't 120 characters too. But I could
live with it.

Again: The biggest problem that I see is the tools that will be
difficult to set up if we mix inside of the affected part.

> 
>> I think we will have a really hard time to set up tools like formatters
>> or pylint to check and use these rules. I think setting a line length to
>> 120 should be easy to possible for nearly any tool. But I expect that
>> setting it to 120 for code and 80 for comments can be _very_ difficult
>> depending on the tool.
>>
>>
>> PS: Reason for me being not a fan of long lines: While programming I
>> often use a split window. In that configuration my editor can show 112
>> columns in each window on my current screen. That fits well for nearly
>> all code that follows the 80 character convention. But for example your
>> proposed length of 120 the code will lead to either a smaller font, a
>> lot of random line breaks done by the editor or to loosing one window.
>> Again: It's not a strong opinion and I'll accept 120 too. But expect
>> that some others have stronger opinions about 80 characters.
> 
> I run everything in text mode under tmux and in Emacs I split vertically and
> variable length is painful and prefer we settle on 80.

Maybe let's wait whether there are more opinions. Currently we have

- one clear vote for 120 lines (Amar)
- one clear vote for 80 lines (Chris)
- one a bit undecided with tendency to shorter lines (myself)

Best regards

Christian

> 
> 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: RFC: Exceptions to PEP-8 Adoption for RTEMS Tools

[Christian Mauderer]

Hello Amar,

On 18/03/2020 19:24, Amar Takhar wrote:
> The only one I would like to propose is the 80 character limit.  This should 
> be 
> moved to something more reasonable such as 120.
> 
> Code comments should remain below 80 however.
> 

I'm not a big fan of long lines (reason further below) but I won't block
it either. But what I think is really a bad idea is to have different
rules for different parts of the code.

I think we will have a really hard time to set up tools like formatters
or pylint to check and use these rules. I think setting a line length to
120 should be easy to possible for nearly any tool. But I expect that
setting it to 120 for code and 80 for comments can be _very_ difficult
depending on the tool.


PS: Reason for me being not a fan of long lines: While programming I
often use a split window. In that configuration my editor can show 112
columns in each window on my current screen. That fits well for nearly
all code that follows the 80 character convention. But for example your
proposed length of 120 the code will lead to either a smaller font, a
lot of random line breaks done by the editor or to loosing one window.
Again: It's not a strong opinion and I'll accept 120 too. But expect
that some others have stronger opinions about 80 characters. At least it
have been 80 chars since at least punch hole cards:

https://softwareengineering.stackexchange.com/questions/148677/why-is-80-characters-the-standard-limit-for-code-width#148678


PPS: Also note one of the first rules in PEP-008: "A Foolish Consistency
is the Hobgoblin of Little Minds":
https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds

It explicitly tells you to not follow the standard if your code gets
less readable by doing it. So if we only have few cases with long lines,
we can use exceptions and it is conform to PEP-008. Of course it might
could be tricky to tell our tools that this line is an exception.


Best regards

Christian

> Python itself has not followed this rule for a long time you can see many 
> lines 
> over 80 in the Python source itself.
> 
> Also, due to the nature of the language most lines end up below 80 characters 
> anyway.  Python is not an easy language to read when you have to break long 
> lines into 2 especially when you start breaking up strings.
> 
> I'm with most of the developers here -- 80 characters as been the norm for a 
> very long time however this is no longer true for new developers.  There are 
> already examples in our own rtems-tool codebase that make no sense being 
> split:
> 
>   
> https://git.rtems.org/rtems-tools/tree/rtemstoolkit/execute.py?id=274981f77d648ceb87f84cdeaec33a58dfd37385#n579
> 
> I've ran into this more than once where a Python developer ends up in 
> confusion 
> when reading source that has line breaks to keep under line lengths.
> 
> I'd like to go the direction the wind is blowing on this and relax this rule 
> to 
> 120 for source, 80 for documentation where possible.
> 
> This is of course applied to cases where leaving the line long makes sense.  
> A 
> function with 20 parameters shouldn't be in a long line that is a disaster in 
> any language.
> 
> 
> Amar.
> ___
> 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_littlevgl 1/2] waf: Remove unnecessary code.

[Christian Mauderer]

Hello Vijay,

thanks for the hint and the review. I removed the objects too. Beneath
that I added another patch to use a release version of lvgl.

Best regards

Christian

On 16/03/2020 21:50, Vijay Kumar Banerjee wrote:
> Hi!
> 
> On Wed, Mar 11, 2020 at 7:59 PM Christian Mauderer
>  <mailto:christian.maude...@embedded-brains.de>> wrote:
> 
> ---
>  lvgl.py | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/lvgl.py b/lvgl.py
> index 5452ed0..d6584f7 100644
> --- a/lvgl.py
> +++ b/lvgl.py
> @@ -77,12 +77,6 @@ def build(bld):
>          if source_dir not in include_paths:
>              include_paths.append(source_dir)
> 
> -    bld.objects(target = objects,
> -                features = 'c',
> -                cflags = '-O2',
> -                includes = includes,
> -                source = source)
> -
>      bld.stlib(target = 'lvgl',
>                features = 'c',
>                includes = includes,
> 
> 
> I think `use=objects` isn't required either in the next line. This
> builds fine.
> 
> Best regards,
> Vijay
> 
> -- 
> 2.16.4
> 
> ___
> devel mailing list
> devel@rtems.org <mailto: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

[PATCH v2 rtems_littlevgl 2/3] waf: Enable optimization and debug symbols.

[Christian Mauderer]

---
 lvgl.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lvgl.py b/lvgl.py
index f275287..b91a265 100644
--- a/lvgl.py
+++ b/lvgl.py
@@ -77,6 +77,7 @@ def build(bld):
 
 bld.stlib(target = 'lvgl',
   features = 'c',
+  cflags = ['-O2', '-g'],
   includes = includes,
   source = sources)
 
-- 
2.16.4

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

[PATCH v2 rtems_littlevgl 1/3] waf: Remove unnecessary code.

[Christian Mauderer]

---
 lvgl.py | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/lvgl.py b/lvgl.py
index 5452ed0..f275287 100644
--- a/lvgl.py
+++ b/lvgl.py
@@ -68,26 +68,17 @@ def build(bld):
 
 sources, includes = source_list(bld)
 includes.append('.')
-objects = []
 include_paths = []
 
 for source in sources:
-objects.append(source[:-1] + 'o')
 source_dir = os.path.dirname(source)
 if source_dir not in include_paths:
 include_paths.append(source_dir)
 
-bld.objects(target = objects,
-features = 'c',
-cflags = '-O2',
-includes = includes,
-source = source)
-
 bld.stlib(target = 'lvgl',
   features = 'c',
   includes = includes,
-  source = sources,
-  use = objects)
+  source = sources)
 
 arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
 bld.env.RTEMS_ARCH_BSP)
-- 
2.16.4

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

[PATCH v2 rtems_littlevgl 3/3] Update to lvgl v6.1.2

[Christian Mauderer]

---
 lv_drivers | 2 +-
 lvgl   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lv_drivers b/lv_drivers
index 117812e..24cedaa 16
--- a/lv_drivers
+++ b/lv_drivers
@@ -1 +1 @@
-Subproject commit 117812eec9a5b82fe879f53ee0d1bf39cb9027c8
+Subproject commit 24cedaa756b83c50c36f4aa0c625fcdfba89431b
diff --git a/lvgl b/lvgl
index 94c95bc..2ead495 16
--- a/lvgl
+++ b/lvgl
@@ -1 +1 @@
-Subproject commit 94c95bc9e461847a734a5bde9818fa837d343425
+Subproject commit 2ead4959038fcfd01eaee0f124b98a8ae3efec21
-- 
2.16.4

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

[PATCH rtems_littlevgl 1/2] waf: Remove unnecessary code.

[Christian Mauderer]

---
 lvgl.py | 6 --
 1 file changed, 6 deletions(-)

diff --git a/lvgl.py b/lvgl.py
index 5452ed0..d6584f7 100644
--- a/lvgl.py
+++ b/lvgl.py
@@ -77,12 +77,6 @@ def build(bld):
 if source_dir not in include_paths:
 include_paths.append(source_dir)
 
-bld.objects(target = objects,
-features = 'c',
-cflags = '-O2',
-includes = includes,
-source = source)
-
 bld.stlib(target = 'lvgl',
   features = 'c',
   includes = includes,
-- 
2.16.4

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

[PATCH rtems_littlevgl 2/2] waf: Enable optimization and debug symbols.

[Christian Mauderer]

---
 lvgl.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lvgl.py b/lvgl.py
index d6584f7..90644bf 100644
--- a/lvgl.py
+++ b/lvgl.py
@@ -79,6 +79,7 @@ def build(bld):
 
 bld.stlib(target = 'lvgl',
   features = 'c',
+  cflags = ['-O2', '-g'],
   includes = includes,
   source = sources,
   use = objects)
-- 
2.16.4

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

Re: Any short projects available?

[Christian Mauderer]

Hello Niteesh,

currently the release process for 5.1 is very active. Maybe you want to
take a look whether you can support some small tasks there:

https://devel.rtems.org/query?status=assigned=accepted=reopened=status=5.1

https://devel.rtems.org/query?status=new=status=5.1

For example:

Testing the patch I added here: https://devel.rtems.org/ticket/3903

Or adding a test: https://devel.rtems.org/ticket/3889 or
https://devel.rtems.org/ticket/3890

Best regards

Christian

On 10/03/2020 18:32, G. S. Niteesh wrote:
> Hii,
> 
> I interested in taking up small tasks/projects as a primer for GSoC.
> I am mostly interested in drivers, build system, core (Schedulers, MPU, etc)
> part of RTEMS.
> I am also okay with large projects if small ones aren't available. I'll
> start learning
> about them and will start working after GSoC.
> 
> Thank you,
> Niteesh.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Beaglebone Black USB-OTG/FDT Support GSOC

[Christian Mauderer]

Hello John,

On 08/03/2020 18:32, John kongtcheu wrote:
> Thank you for the information. I have already done the hello world
> project, (I just forwarded it to you to take a look) and I took a break
> for a little bit, because of school work.

sorry, I missed that mail. Did Gedare or Joel respond to it? Can you
please add your name to the list here:

  https://devel.rtems.org/wiki/GSoC/2020

> Regarding, working on
> peripherals I was wondering if there any spots on working on GPIO work
> and ADC conversion as those are also two jobs I would be greatly
> interested in.

There are really few peripherals left on BBB. Someone already added a
GPIO driver some time back. I don't think anything has been done
regarding ADC. But on the other hand we don't really have an abstraction
layer for that in RTEMS. Depending on what you plan to add it can be
anything from not useful at all to a nice part of a project. But you
have to create some convincing suggestion ;-)

> Also thank you again for your advice on the USB-OTG work
> and I will also do my research regarding that topic.

No problem. Don't hesitate to ask if you are stuck somewhere.

Best regards

Christian

> 
> On Sun, Mar 8, 2020 at 12:53 PM Christian Mauderer  <mailto:l...@c-mauderer.de>> wrote:
> 
> On 08/03/2020 15:58, John kongtcheu wrote:
> > Dear Dev Mailing list,
> > I'm interested in work regarding peripherals and it seems like working
> > on the beaglebone black projects would be something I would be be good
> > at. I have experience working in embedded systems before, and I
> have my
> > own BBB. I was curious if there was anyone willing to mentor for this
> > project or if this project is a good idea at all.
> > Thank you,
> 
> Hello John,
> 
> welcome to RTEMS. Please note that we require students to send in some
> proof that they can build and run RTEMS on the hardware for the project.
> See the GSoC Getting Started guide in the wiki.
> 
> Regarding your suggested project: I would love to see the USB-OTG
> support working. But note that we already have a proposal to extend the
> FDT support in BBB. And I'm not sure whether USB-OTG is really enough
> for a whole GSoC.
> 
> Adding the USB-OTG support will be mostly a libbsd project and won't be
> too peripheral oriented. It is more a question about how to analyze how
> to set up an OTG device in FreeBSD and find out how that can be
> implemented in RTEMS using libbsd.
> 
> Maybe you want to start by taking a short look at FreeBSD and how to set
> up a USB-OTG device there. Depending on that there might could be topics
> that are similar that would be a good match for the project. For example
> if it is done via rc.conf: I think there are quite some other stuff that
> could be added to rc.conf too (e.g. WLAN support; see Trac ticket
> #3222).
> 
> Best regards
> 
> Christian
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Beaglebone Black USB-OTG/FDT Support GSOC

[Christian Mauderer]

On 08/03/2020 15:58, John kongtcheu wrote:
> Dear Dev Mailing list,
> I'm interested in work regarding peripherals and it seems like working
> on the beaglebone black projects would be something I would be be good
> at. I have experience working in embedded systems before, and I have my
> own BBB. I was curious if there was anyone willing to mentor for this
> project or if this project is a good idea at all.
> Thank you,

Hello John,

welcome to RTEMS. Please note that we require students to send in some
proof that they can build and run RTEMS on the hardware for the project.
See the GSoC Getting Started guide in the wiki.

Regarding your suggested project: I would love to see the USB-OTG
support working. But note that we already have a proposal to extend the
FDT support in BBB. And I'm not sure whether USB-OTG is really enough
for a whole GSoC.

Adding the USB-OTG support will be mostly a libbsd project and won't be
too peripheral oriented. It is more a question about how to analyze how
to set up an OTG device in FreeBSD and find out how that can be
implemented in RTEMS using libbsd.

Maybe you want to start by taking a short look at FreeBSD and how to set
up a USB-OTG device there. Depending on that there might could be topics
that are similar that would be a good match for the project. For example
if it is done via rc.conf: I think there are quite some other stuff that
could be added to rc.conf too (e.g. WLAN support; see Trac ticket #3222).

Best regards

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

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 04/03/2020 07:07, Sebastian Huber wrote:
> On 04/03/2020 05:55, Chris Johns wrote:
>>> I think for Boards that normally run a Linux it is a sane approach to
>>> just replace the Linux Kernel with a RTEMS binary and otherwise keep the
>>> boot process with for example U-Boot. Everything else is a lot of extra
>>> effort to implement and not necessary in a lot of situations.
>> Is there documentation about that shows this process for an existing
>> board?
>>
>> I get what you are saying and it make prefect sense and it would be no
>> issue for
>> me to do this however there are a number of steps involved and there is a
>> certain amount of assumed knowledge here. How do we establish a
>> framework or
>> template that lets are capture this so it is useful and usable to our
>> users?
> 
> My approach would be to use the devices trees shipped by the hardware
> vendor and fix our drivers if necessary. For example, I had to adjust
> the Altera Cyclone V BSP for these modules:
> 
> https://www.enclustra.com/en/products/system-on-chip-modules/mars-ma3/
> 
> The device tree has a different clock structure compared to the Altera
> Development Kit, so the update_clocks() function supports both:
> 
> https://git.rtems.org/rtems/tree/bsps/arm/altera-cyclone-v/start/bspstart.c#n79
> 
> 

Hello Sebastian,

note that the version delivered with a board is very undefined and it is
not necessarily the same for two boards with a different production
date. So it's quite hard to reproduce a special FDT that works together
with a special version of a BSP. So some method to archive them and say
"that BSP works with this FDT" isn't a bad idea.

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: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

Hello Chris,

On 04/03/2020 05:55, Chris Johns wrote:
> Sorry about delay in getting back to this. I have been focused on getting the
> release into something close to what we want for RC1.

No problem. The release is relevant for all of us.

> 
> On 28/2/20 9:48 pm, Christian Mauderer wrote:
>> Hello Gedare and Chris,
>>
>> On 27/02/2020 23:14, Gedare Bloom wrote:
>>> On Thu, Feb 27, 2020 at 3:01 PM Chris Johns  wrote:
>>>>
>>>> On 28/2/20 7:23 am, Alan Cudmore wrote:
>>>>> I noticed that the Zephyr RTOS (https://www.zephyrproject.org) uses a
>>>>> device tree based initialization for all of its BSPs.
>>>>> For example, here is the top level device tree source for the Adafruit
>>>>> Trinket M0, which is a very small Atmel Cortex M0 based board:
>>>>> https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/adafruit_trinket_m0/adafruit_trinket_m0.dts
>>>>>
>>>>> The rest of the device tree source for common processors and devices are 
>>>>> here:
>>>>> https://github.com/zephyrproject-rtos/zephyr/tree/master/dts
>>>>>
>>>>> To me, it looks like they have to develop (or port) and maintain
>>>>> device trees for each board and device that is supported.
>>>>>
>>>>> Does that look like a model that RTEMS could use? I'm not sure I
>>>>> understand everything that deploying such a model implies, or if it
>>>>> just makes more sense to use the existing FreeBSD or linux device
>>>>> trees.
>>>>
>>>> This is where I was heading in my thinking but I am not sure. I am 
>>>> settling on
>>>> having a dts tree in rtems.git and we may just have to manually manage the
>>>> files. I am not sure there are enough files to warrant a system like 
>>>> libbsd and
>>>> FreeBSD at this point in time. That may change with the new build system 
>>>> and
>>>> python being available however until then manual is fine. Let me explain 
>>>> ...
>>>>
>>>> I have been looking beyond the internal development aspects and to how we 
>>>> use
>>>> FDT blobs and I am wondering if the approach we have with the shared FDT 
>>>> BSP
>>>> support is the right fit for RTEMS and a statically linked executable.
>>>>
>>>> I believe currently we need a suitable bootloader, ie u-boot, to load a 
>>>> blob.
>>>> This is the Linux way of doing things and this may be the right approach 
>>>> for
>>>> Linux but I am not so sure it is for us. It means you need u-boot and a 
>>>> suitable
>>>> file system plus you have a lot more items to configuration manage in 
>>>> production
>>>> systems and a lot more complexity for self upgrading.
>>
>> I think for Boards that normally run a Linux it is a sane approach to
>> just replace the Linux Kernel with a RTEMS binary and otherwise keep the
>> boot process with for example U-Boot. Everything else is a lot of extra
>> effort to implement and not necessary in a lot of situations.
> 
> Is there documentation about that shows this process for an existing board?

To be honest: I don't know. Basically the description for the raspberry,
for BBB, for imx results in this. I haven't looked at the other BSPs
yet. But it isn't documented with this words.

> 
> I get what you are saying and it make prefect sense and it would be no issue 
> for
> me to do this however there are a number of steps involved and there is a
> certain amount of assumed knowledge here. How do we establish a framework or
> template that lets are capture this so it is useful and usable to our users?
> 

Basically the boot process should always be documented in the BSP
section of the manual. We maybe add some default cases:

1. Boards that normally run Linux: Suggestion: Use the same boot process
as Linux. For device trees: Use one delivered with the board (which only
maybe works) or use the one provided by the repository we are discussing
now (which should always work).

2. Boards that are not running Linux but want to use a FDT: I think we
currently don't have any. But if we would have ones, they most likely
have a small hand written FDT or one generated for example together with
a FPGA. Here it might would be a sane approach to link the FDT into the
application. Again: We don't have a BSP yet that is in that category so
not relevant for the release.

3. Boards that are not using an FDT. Most BSPs. The boot is very target
dependent. Not relevant for our current di

Re: [Project #3860]

[Christian Mauderer]

Hello Anmol,

On 28/02/2020 10:31, Anmol Mishra wrote:
> Hello,
> I was going through the list of potential projects for GSoC 2020, I love
> working with automation tools and "Code Formatting and Style Check for
> RTEMS score" looks exciting to me. I saw you edited the wiki and the
> owner was not mentioned so pinging you for the same.

I'm not sure whether we already assigned someone. But that is a topic
that could be handled by multiple mentors. So your best bet is to ask on
the list.

> I have read the requirements and hurdles, I have a question that
> 1. "Is there any tool/procedure currently being considered as an option?"

Not as far as I'm concerned. You might want to have a look at the wiki.
I think there have been some notes for code formatters a few years back.

> 2. "What is the timeframe I should look in the mail archive like the
> past 3 months?"

That topic was created during a recent discussion regarding style
checking for Python. It can only be a few weeks now. But there haven't
been much details about it.

Best regards

Christian

> 
> It goes without saying how much this means to me. I will be submitting 2
> project proposals and don't want to waste time and start with draft
> proposal asap. Looking forward to hearing from you.
> 
> Regards
> Anmol
> 
> ___
> 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: Suggestion

[Christian Mauderer]

Hello Anmol,

On 28/02/2020 10:49, Anmol Mishra wrote:
> I can see python2 code being used. And as of 2020 python2 has been
> depreciated but I assume everyone is aware of that. Is there any active
> plan to shift the codebase. I am open to discussion for this. 

We have the problem that some long living distributions (like CentOS 7)
still only have python2 in the default repositories. So till they run
out of support (year 2024 for CentOS 7) we will have to write our code
in a way that it works with python2 and 3 for everything that is daily
use for a RTEMS user.

We currently have the discussion for some special maintenance tools
whether they can be python3 only.

So as a summary: If you find any tool that works with python2 but not
with python3 it should definitively be updated to work with both
versions. Patches are welcome.

Best regards

Christian

> 
> Regards
> Anmol
> 
> ___
> 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: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

t; dtc -> FDT in static images seems beneficial to
> users. I don't know if we could get any input from users to justify
> that, but I can see advantages for pre-qual and license compliance
> that go beyond the technical advantages that you discuss above.
> 
> Initial steps in this direction would make a good GSoC for the right
> (strong) student.

If Chris sees it as a blocker for the release, GSoC might is not the
right frame. It would need too much time and the result is not
guaranteed to be OK.

Maybe we should add an intermediate solution and create a GSoC project
for improvement?

Best regards

Christian

> 
> Gedare
> 
>>>
>>> Just a thought.. I'm still catching up!
>>> Thanks,
>>> Alan
>>>
>>> On Thu, Feb 27, 2020 at 2:44 PM Amar Takhar  wrote:
>>>>
>>>> On 2020-02-27 20:06 +0100, Christian Mauderer wrote:
>>>>
>>>>>> The only good way to handle this is to have it all in 1 giant repository 
>>>>>> we work
>>>>>> with.  Every other solution is a pain no matter how well thought out it 
>>>>>> is.  I
>>>>>> personally lean more on the service side of things that it should be 
>>>>>> *our*
>>>>>> problem to maintain this and for users it should just work.>
>>>>>> The easiest way to handle this is to have the minimum version required 
>>>>>> in the
>>>>>> commit message.  Eg, when pushing to libbsd have:
>>>>>>
>>>>>>   Minimum RTEMS: 
>>>>>>
>>>>>> After that it's up to the user to ensure to keep up-to-date.  The first 
>>>>>> thing
>>>>>> most developers do is check the log.
>>>>>
>>>>> Sounds like a nice suggestion. But it needs quite a lot of discipline
>>>>> for the developers. So most likely a lot of errors will happen. Beneath
>>>>> that it's not far from what we do now: Suggest to use commits from the
>>>>> same date.
>>>>
>>>> There are two ways to look at it -- requiring discipline or simply doing
>>>> something we should already be doing.  Because right now there is no way 
>>>> to tell
>>>> other than updating to the latest and if you are trying to bisect an issue 
>>>> this
>>>> because huge because you could feasibly jump into a comment that skips a
>>>> version.  How would a user know which version of the library *or* RTEMS to 
>>>> use?
>>>>
>>>>
>>>>> But maybe we should move that discussion. It's not FDT related anymore
>>>>> so no one will find it in this toppic. And I think for Chris the
>>>>> pressing matter is FDT just now because it blocks the release.
>>>>
>>>> Yes that's true.
>>>>
>>>>> The BSP groups that use bsps/shared/start/bsp-fdt.c are:
>>>>>
>>>>> - riscv/riscv
>>>>> - arm/imx
>>>>> - arm/beagle
>>>>> - arm/raspberrypi
>>>>> - arm/altera-cyclone-v
>>>>> - powerpc/qoriq
>>>>>
>>>>> For beagle and raspberry it should be definitely the FreeBSD FDT.
>>>>>
>>>>> For imx: I'm currently working on imx6 support in the imx BSP and that
>>>>> one will use a FreeBSD derived one too. Not sure about the original imx7
>>>>> support in that BSP.
>>>>>
>>>>> For the other BSPs I don't have any idea which FDT has been used during
>>>>> development.
>>>>
>>>>
>>>> Okay that list is already compelling enough to have the split model of 
>>>> having
>>>> source based files in-tree and binary outside.  I think it makes sense to 
>>>> have
>>>> it 'just work' for opensource boards like the beagle and rpi even if 
>>>> that's the
>>>> only two that require it.
>>>>
>>>>
>>>> Amar.
>>>> ___
>>>> devel mailing list
>>>> devel@rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> ___
> 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: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 27/02/2020 18:14, Amar Takhar wrote:
> On 2020-02-27 08:45 +0100, Christian Mauderer wrote:
>>
>> It's just another problem that I noted sometimes on the mailing list
>> with RTEMS and libbsd: Sometimes libbsd doesn't compile with some odd
>> error messages like unresolved symbols. Most of the time the problem is
>> that libbsd has been updated by the user but RTEMS hasn't. Having
>> defined versions in a master repository could help the average user to
>> see which version should be used together. On the other hand someone
>> would have to keep it up to date and I'm not sure whether all
>> maintainers would be happy about another necessary maintainance task.
>> Therefore it's not yet a well thought through idea.
> 
> The only good way to handle this is to have it all in 1 giant repository we 
> work 
> with.  Every other solution is a pain no matter how well thought out it is.  
> I 
> personally lean more on the service side of things that it should be *our* 
> problem to maintain this and for users it should just work.>
> The easiest way to handle this is to have the minimum version required in the 
> commit message.  Eg, when pushing to libbsd have:
> 
>   Minimum RTEMS: 
> 
> After that it's up to the user to ensure to keep up-to-date.  The first thing 
> most developers do is check the log.

Sounds like a nice suggestion. But it needs quite a lot of discipline
for the developers. So most likely a lot of errors will happen. Beneath
that it's not far from what we do now: Suggest to use commits from the
same date.

But maybe we should move that discussion. It's not FDT related anymore
so no one will find it in this toppic. And I think for Chris the
pressing matter is FDT just now because it blocks the release.



> 
> Regardless of what we choose none of it will work if the user is not updating 
> their repository or checking online for changes.  Having it in the commit 
> message also helps for build automation.  I've used git tags for this in the 
> past but hardly anyone uses or checks those which is too bad.
> >
>> If you are a new user and see "for this BSP use the FDT from X" but you
>> want to use some other BSP and someone tells you "for that BSP the FDT
>> isn't in X but at Y" it maybe isn't really that clear. Therefore - if we
>> introduce some handling - I would be in favor of only one location and
>> not a mix of two or three. Otherwise the situation is only slightly
>> better than now.
> 
> Having a section in the documentation to manage this is fine I think.  It's 
> either going to say:
> 
>   1. The FDT source is in rtems-fdt.git
>   2. The FDT source is already in RTEMS you don't need to do anything.
>   3. You need to purchase a board and place the files 
>   4. Covers all: If you want to roll your own place the files  -- same 
>  place as #3 maybe.
> 
> An easier way to make a decision would be to see what we're looking at right 
> now.  How many would be in-tree and how many external?
> 

The BSP groups that use bsps/shared/start/bsp-fdt.c are:

- riscv/riscv
- arm/imx
- arm/beagle
- arm/raspberrypi
- arm/altera-cyclone-v
- powerpc/qoriq

For beagle and raspberry it should be definitely the FreeBSD FDT.

For imx: I'm currently working on imx6 support in the imx BSP and that
one will use a FreeBSD derived one too. Not sure about the original imx7
support in that BSP.

For the other BSPs I don't have any idea which FDT has been used during
development.

Best regards

Christian

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

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 26/02/2020 22:12, Amar Takhar wrote:
> On 2020-02-26 18:46 +0100, Christian Mauderer wrote:
>> Hello Amar,
>>
>> somehow I missed your response this morning. My filter for the mailing
>> list normally keeps stuff with my name in the inbox but your answer
>> didn't contain it and therefore it was hidden in the mailing list folder.
> 
> No problem! :)
> 
> 
>> Full acknowledge. I'm not a fan of another repository like I already
>> said toward Chris. On the other hand: We already have that problem and
>> have to deal with it sometimes anyway. I added a note in the response
>> toward Chris that we maybe sometimes should think about a master
>> repository with sub-repos to make the version dependencies more clear.
>> In other words: One repository to rule them all ;-)
> 
> We can for sure create a sub repository to handle this.  That can be annoying 
> however if the sub repositories don't update often because git pull can take 
> a 
> while.

It's just another problem that I noted sometimes on the mailing list
with RTEMS and libbsd: Sometimes libbsd doesn't compile with some odd
error messages like unresolved symbols. Most of the time the problem is
that libbsd has been updated by the user but RTEMS hasn't. Having
defined versions in a master repository could help the average user to
see which version should be used together. On the other hand someone
would have to keep it up to date and I'm not sure whether all
maintainers would be happy about another necessary maintainance task.
Therefore it's not yet a well thought through idea.

> 
> The other option here is to just document for the user how to do a 'git 
> submodule add' and do it themselves within the RTEMS tree or a separate 
> repository it would depend on just how much demand there would be for this.  
> It's not a huge deal though to detect if the FDT repository is in-tree 
> otherwise 
> force a --with-fdt-repo.
> 
> 
> 
>>> We don't really have a choice here however I would 
>>> suggest we do a mix of the two.
>>>
>>
>> I'm not sure whether that is a very transparent approach.
> 
> Transparent or complicated?  :)  It will still all be documented and out in 
> the 
> open.
> 

If you are a new user and see "for this BSP use the FDT from X" but you
want to use some other BSP and someone tells you "for that BSP the FDT
isn't in X but at Y" it maybe isn't really that clear. Therefore - if we
introduce some handling - I would be in favor of only one location and
not a mix of two or three. Otherwise the situation is only slightly
better than now.

> 
>>>   1. Any source/permissive files be kept within the RTEMS repository.
>>>   2. Binary blobs get ejected to a separate repository lets say 'rtems-fdt'.
>>>   3. Source files with strict licensing gets the boot, too -- though we can 
>>>  discuss how much we care about this.
>>
>> I think we will get big problems finding "permissive" licenses. Most
>> device trees are Linux based and therefore GPL. Even the ones in FreeBSD.
> 
> Okay well if they're all GPL then instead of permissive just say source-based 
> because that is still far better than binary blobs.  It will still be left up 
> to 
> the user if they want to include it the license won't change whether it's in 
> tree 
> our outside.
> 
>>>
>>> How it would work is simple.  During configure if the required FDT files 
>>> exist 
>>> that's great we look for the two binaries we need and build them all as 
>>> part of 
>>> the normal building process.
>>
>> That would add dtc to our mandatory set of tools for RTEMS. Otherwise
>> nothing against it.
> 
> It would for BSPs that have it and if users want it.  Otherwise if there is 
> no 
> FDT then we wouldn't require those tools.
> 
> 
>> There is even a case 5: We have a FDT (for example for BBB) but the user
>> wants to use an adapted one because he has connected extra peripherals
>> or has a board that is only based on the evaluation board. Our build
>> system should be open enough to handle such a case.
>>
>> The FreeBSD FDT scripts work fine for that. You give them your file and
>> the path to the FreeBSD fdt sources and they do the rest.
> 
> Yes that adds yet another option letting users supply their own files.  I 
> should 
> have added that one thank you.
> 
> 
>> Agreed: Open BSPs are first class citizens.
> 
> Awesome I'm glad we agree on that! :)
> 
> 
> Amar.
> ___
> 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: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

Hello Amar,

somehow I missed your response this morning. My filter for the mailing
list normally keeps stuff with my name in the inbox but your answer
didn't contain it and therefore it was hidden in the mailing list folder.

On 26/02/2020 06:00, Amar Takhar wrote:
> 
> I've had to deal with this issue quite a lot in the past it can be really 
> annoying having to maintain separate repositories where we have to 'pin' a 
> version to the main repo. 

Full acknowledge. I'm not a fan of another repository like I already
said toward Chris. On the other hand: We already have that problem and
have to deal with it sometimes anyway. I added a note in the response
toward Chris that we maybe sometimes should think about a master
repository with sub-repos to make the version dependencies more clear.
In other words: One repository to rule them all ;-)

> We don't really have a choice here however I would 
> suggest we do a mix of the two.
> 

I'm not sure whether that is a very transparent approach.

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

I think we will get big problems finding "permissive" licenses. Most
device trees are Linux based and therefore GPL. Even the ones in FreeBSD.

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

That would add dtc to our mandatory set of tools for RTEMS. Otherwise
nothing against it.

> 
> If they are not found print a notice to the user to get the 'rtems-fdt' 
> repository and point to it with a --rtems-fdt-path=  This is where it gets 
> annoying because there are several steps to get the right file.  Generally we 
> have to:
> 
>   1. Read a file stored within RTEMS that says what version of the FDT 
>  repository to checkout.
>   2. As part of configure this file needs to be loaded and the 'rtems-fdt'
>  repository checked to see if it's at the right revision.
>   3. If it as not at the right revision then the user will have to fix this 
>  manually and re-run configure.
>   4. Some BSPs may not even have the FDT files until you purchase a board.  
> Do 
>  we have any of these cases?  Now we have a situation where we have no 
>  revision *or* files and no way to test this code or ensure it even works.

There is even a case 5: We have a FDT (for example for BBB) but the user
wants to use an adapted one because he has connected extra peripherals
or has a board that is only based on the evaluation board. Our build
system should be open enough to handle such a case.

The FreeBSD FDT scripts work fine for that. You give them your file and
the path to the FreeBSD fdt sources and they do the rest.

> 
> Regardless for case #4 it's going to be a user issue to get the FDT files and 
> our issue to suck these in.
> 
> It makes sense to do it this way for RTEMS as I don't see a reason to 
> "punish" 
> the BSPs where everything is free and open it would be great to have these 
> 'just 
> work' and it is less maintenance for us longterm.

Agreed: Open BSPs are first class citizens.

Best regards

Christian

> 
> 
> Amar.
> ___
> 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: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 26/02/2020 04:50, Chris Johns wrote:
> On 25/2/20 5:30 pm, Christian Mauderer wrote:
>> On 24/02/2020 23:26, Chris Johns wrote:
>>>> On 24 Feb 2020, at 7:39 pm, Christian Mauderer 
>>>>  wrote:
>>>>
>>>> On 24/02/2020 07:01, Chris Johns wrote:
>>>>>
>>>>>
>>>>>>> On 24 Feb 2020, at 5:32 am, Christian Mauderer  
>>>>>>> wrote:
>>>>>>
>>>>>> On 23/02/2020 17:07, Alan Cudmore wrote:
>>>>>>> I have been trying to bring up RTEMS with rtems-libbsd on the
>>>>>>> beaglebone black (latest master).
>>>>>>>
>>>>>>> I can run the regular RTEMS samples on the board, and a couple of the
>>>>>>> rtems-libbsd testsuite examples run as well.
>>>>>>>
>>>>>>> The samples such as ping01 and usb01 get a fatal exception in the
>>>>>>> function fdt_ro_probe_ , leading me to believe that maybe I am not
>>>>>>> using the correct device tree blob.
>>>>>>>
>>>>>>> I'm using the instructions here:
>>>>>>> https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
>>>>>>>
>>>>>>> And I have am loading am335x-boneblack.dtb that I copied from a linux
>>>>>>> u-boot build. The instructions talk about getting the one from the
>>>>>>> FreeBSD repository, but there are many other files included in that
>>>>>>> dts source.
>>>>>>>
>>>>>>> What dtb is normally used for the Beaglebone black RTEMS libbsd testing?
>>>>>>>
>>>>>>> Is the dtb needed for the non-libbsd BSP?
>>>>>>>
>>>>>>> Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
>>>>>>> libbsd to get ethernet?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alan
>>>>>>
>>>>>> Hello Alan,
>>>>>>
>>>>>> I recommend to use the FreeBSD device trees. libbsd is FreeBSD based and
>>>>>> therefore works best with them. Normally I would suggest to use the
>>>>>> version matching the FreeBSD commit used in libbsd. But unfortunately in
>>>>>> the last commit that doesn't seem to work. Vijay had some problems with
>>>>>> it and noted that the version from FreeBSD commit
>>>>>> 19a6ceb89dbacf74697d493e48c388767126d418 works fine.
>>>>>
>>>>> Is this with 5 branch in Libbsd?
>>>>>
>>>>> I am a little confused about the branch to package in a release and also 
>>>>> which FDT files we need for which branch. If different I feel a release 
>>>>> will makes things more complicated. This flies into the BSP  vertical 
>>>>> stack building in the RSB. 
>>>>>
>>>>> I am working on releasing and I hope this does not block things. 
>>>>>
>>>>> Chris
>>>>
>>>> Hello Chris,
>>>>
>>>> the non-working device tree is for the master branch from a few weeks
>>>> back. I didn't tested it with the 5-freebsd-12 branch.
>>>
>>> Which FDT files are needed for the 5-freebsd-12 branch? I could assume the
>>> 12-release branch in the FreeBSD repo however this is a guess, unfriendly 
>>> on our
>>> part and time consuming to sort out. I am not sure how we improve this and 
>>> how
>>> we should manage FDT source but we need to address the issue.
>>
>> Same problem here. The topic already popped up multiple times and I
>> can't really answer it.
> 
> I know but we have too.
> 
>> Like I said multiple time: My approach is to use the fdt that matches
>> the FreeBSD commit used in libbsd. So for the 5-freebsd-12 branch that
>> is the one from FreeBSD commit 0d1c391321b34b3025cf0e72f2231d836ff76da8.
>> But it's not a rule that works for all BSPs. Some BSPs are adapted to
>> use a board manufacturers DTB or some random Linux one.
> 
> This means users need a clone of the FreeBSD repo  and that means a bigger
> disk array and a larger net pipe ;)
> 

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

>>
>>>
>>> There are long time RTEMS users including myself strugg

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

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

Same problem here. The topic already popped up multiple times and I
can't really answer it.

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

> 
> There are long time RTEMS users including myself struggling with this so it 
> is a
> clear indication in my mind we have an issue we need to improve.
> 
>>> Again: In the normal case I would just suggest to use the FDT sources
>> that match the FreeBSD commit we use for libbsd. That worked best for me
>> in the past. But in the current referenced commit FreeBSD has updated
>> the device tree sources to the ones from a recent Linux version and the
>> drivers haven't been adapted yet (on master - I expect that it works
>> better on 5-freebsd-12).
>>
>> Regarding the release: I don't think you pack the FDT files (yet), do
>> you? 
> 
> No I do not but then should I be the one doing this in a release. I would have
> thought this is a core issue for the BSPs that depend on FDT blobs at runtime.
> 
> I am up to libbsd with the release packaging. I can build a beagleboneblack 
> as a
> vertical stack up to libbsd and then I hit the issue of using master and not 
> the
> 5-freebsd-12 branch and after that is the rtems_waf submodule naming. I would
>

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

tion in the same
>>>>> function.
>>>>>
>>>>> Do you know if a specific commit of rtems-libbsd is required to work
>>>>> with that dtb?
>>>>> I tried master, and then the "5-freebsd-12" branch.
>>>>>
>>>>> Thanks,
>>>>> Alan
>>>>>
>>>> Hi Alan,
>>>>
>>>> I checked with the usb01 and ping01 tests running on libbsd master
>>>> and the dtb from the commit mentioned by Christian. I can't reproduce
>>>> the error and it seems to run as expected. I'm not sure where the
>>>> error might be coming from. Below I'm pasting the contents of my uEnv.txt
>>>> If the error isn't in the uEnv, I can send you my sd card image(offlist) 
>>>> so that you
>>>> can try that on your board and that might give some hint on what was going
>>>> wrong.
>>>>
>>>> ```
>>>> setenv bootdelay 5
>>>> uenvcmd=run boot
>>>> boot=fatload mmc 0 0x8080 rtems-app.img ; fatload mmc 0 0x8800 
>>>> am335x-boneblack.dtb ; fdt addr 0x8800; bootm 0x8080 - 0x8800
>>>> ```
>>>>
>>>> Best regards,
>>>> Vijay
>>>>>
>>>>> On Sun, Feb 23, 2020 at 11:32 AM Christian Mauderer  
>>>>> wrote:
>>>>>>
>>>>>> On 23/02/2020 17:07, Alan Cudmore wrote:
>>>>>>> I have been trying to bring up RTEMS with rtems-libbsd on the
>>>>>>> beaglebone black (latest master).
>>>>>>>
>>>>>>> I can run the regular RTEMS samples on the board, and a couple of the
>>>>>>> rtems-libbsd testsuite examples run as well.
>>>>>>>
>>>>>>> The samples such as ping01 and usb01 get a fatal exception in the
>>>>>>> function fdt_ro_probe_ , leading me to believe that maybe I am not
>>>>>>> using the correct device tree blob.
>>>>>>>
>>>>>>> I'm using the instructions here:
>>>>>>> https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
>>>>>>>
>>>>>>> And I have am loading am335x-boneblack.dtb that I copied from a linux
>>>>>>> u-boot build. The instructions talk about getting the one from the
>>>>>>> FreeBSD repository, but there are many other files included in that
>>>>>>> dts source.
>>>>>>>
>>>>>>> What dtb is normally used for the Beaglebone black RTEMS libbsd testing?
>>>>>>>
>>>>>>> Is the dtb needed for the non-libbsd BSP?
>>>>>>>
>>>>>>> Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
>>>>>>> libbsd to get ethernet?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alan
>>>>>>
>>>>>> Hello Alan,
>>>>>>
>>>>>> I recommend to use the FreeBSD device trees. libbsd is FreeBSD based and
>>>>>> therefore works best with them. Normally I would suggest to use the
>>>>>> version matching the FreeBSD commit used in libbsd. But unfortunately in
>>>>>> the last commit that doesn't seem to work. Vijay had some problems with
>>>>>> it and noted that the version from FreeBSD commit
>>>>>> 19a6ceb89dbacf74697d493e48c388767126d418 works fine.
>>>>>>
>>>>>> Regarding Ethernet support: As far as I know there is no support for the
>>>>>> legacy stack. But the one in libbsd worked fine the last time I tested
>>>>>> it (which was when I ported it). If you really want to use the legacy
>>>>>> stack please note that it is still an IPv4 only one and therefore it is
>>>>>> quite limited nowadays.
>>>>>>
>>>>>> Best regards
>>>>>>
>>>>>> Christian
>>>>> ___
>>>>> devel mailing list
>>>>> devel@rtems.org
>>>>> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

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

Hello Chris,

the non-working device tree is for the master branch from a few weeks
back. I didn't tested it with the 5-freebsd-12 branch.

Again: In the normal case I would just suggest to use the FDT sources
that match the FreeBSD commit we use for libbsd. That worked best for me
in the past. But in the current referenced commit FreeBSD has updated
the device tree sources to the ones from a recent Linux version and the
drivers haven't been adapted yet (on master - I expect that it works
better on 5-freebsd-12).

Regarding the release: I don't think you pack the FDT files (yet), do
you? So I don't see why there should be a reason for this topic to block
the release.

Note that the exact FDT version used for different BSPs is still a
bigger problem. Some BSPs expect a version provided by a board
manufacturer. Some use a random Linux DTB. And some work well with the
ones from FreeBSD (which is just a snapshot of the Linux ones) - that's
the method I prefer because it works well with libbsd most of the time.
I think currently the right device tree for the board is only documented
in the User Manual (if it is documented).

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: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 24/02/2020 06:57, Vijay Kumar Banerjee wrote:
> 
> 
> On Sun, Feb 23, 2020 at 11:46 PM Alan Cudmore  <mailto:alan.cudm...@gmail.com>> wrote:
> 
> Hi Christian,
> Thanks for the quick response. I followed the instructions in the
> docs.rtems.org <http://docs.rtems.org> manual and generated the dtb
> from the FreeBSD commit
> that Vijay suggested. It still resulted in an exception in the same
> function.
> 
> Do you know if a specific commit of rtems-libbsd is required to work
> with that dtb?
> I tried master, and then the "5-freebsd-12" branch.
> 
> Thanks,
> Alan
> 
> Hi Alan,
> 
> I checked with the usb01 and ping01 tests running on libbsd master
> and the dtb from the commit mentioned by Christian. I can't reproduce
> the error and it seems to run as expected. I'm not sure where the
> error might be coming from. Below I'm pasting the contents of my uEnv.txt
> If the error isn't in the uEnv, I can send you my sd card image(offlist)
> so that you
> can try that on your board and that might give some hint on what was going
> wrong.
> 
> ```
> setenv bootdelay 5
> uenvcmd=run boot
> boot=fatload mmc 0 0x8080 rtems-app.img ; fatload mmc 0 0x8800
> am335x-boneblack.dtb ; fdt addr 0x8800; bootm 0x8080 - 0x8800
> ```
> 
> Best regards,
> Vijay

Hello Alan,

another point: You know that your exception is in fdt_ro_probe_. So I
assume you have a debugger connected? Can you post a full backtrace so
that we can see from which driver the exception comes from?

Best regards

Christian

> 
> On Sun, Feb 23, 2020 at 11:32 AM Christian Mauderer
> mailto:l...@c-mauderer.de>> wrote:
> >
> > On 23/02/2020 17:07, Alan Cudmore wrote:
> > > I have been trying to bring up RTEMS with rtems-libbsd on the
> > > beaglebone black (latest master).
> > >
> > > I can run the regular RTEMS samples on the board, and a couple
> of the
> > > rtems-libbsd testsuite examples run as well.
> > >
> > > The samples such as ping01 and usb01 get a fatal exception in the
> > > function fdt_ro_probe_ , leading me to believe that maybe I am not
> > > using the correct device tree blob.
> > >
> > > I'm using the instructions here:
> > > https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
> > >
> > > And I have am loading am335x-boneblack.dtb that I copied from a
> linux
> > > u-boot build. The instructions talk about getting the one from the
> > > FreeBSD repository, but there are many other files included in that
> > > dts source.
> > >
> > > What dtb is normally used for the Beaglebone black RTEMS libbsd
> testing?
> > >
> > > Is the dtb needed for the non-libbsd BSP?
> > >
> > > Also, is the ethernet supported on the RTEMS beagle BSP, or do I
> need
> > > libbsd to get ethernet?
> > >
> > > Thanks,
> > > Alan
> >
> > Hello Alan,
> >
> > I recommend to use the FreeBSD device trees. libbsd is FreeBSD
> based and
> > therefore works best with them. Normally I would suggest to use the
> > version matching the FreeBSD commit used in libbsd. But
> unfortunately in
> > the last commit that doesn't seem to work. Vijay had some problems
> with
> > it and noted that the version from FreeBSD commit
> > 19a6ceb89dbacf74697d493e48c388767126d418 works fine.
> >
> > Regarding Ethernet support: As far as I know there is no support
> for the
> > legacy stack. But the one in libbsd worked fine the last time I tested
> > it (which was when I ported it). If you really want to use the legacy
> > stack please note that it is still an IPv4 only one and therefore
> it is
> > quite limited nowadays.
> >
> > Best regards
> >
> > Christian
> ___
> devel mailing list
> devel@rtems.org <mailto:devel@rtems.org>
> http://lists.rtems.org/mailman/listinfo/devel
> 
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 

-- 

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

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

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 23/02/2020 17:07, Alan Cudmore wrote:
> I have been trying to bring up RTEMS with rtems-libbsd on the
> beaglebone black (latest master).
> 
> I can run the regular RTEMS samples on the board, and a couple of the
> rtems-libbsd testsuite examples run as well.
> 
> The samples such as ping01 and usb01 get a fatal exception in the
> function fdt_ro_probe_ , leading me to believe that maybe I am not
> using the correct device tree blob.
> 
> I'm using the instructions here:
> https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
> 
> And I have am loading am335x-boneblack.dtb that I copied from a linux
> u-boot build. The instructions talk about getting the one from the
> FreeBSD repository, but there are many other files included in that
> dts source.
> 
> What dtb is normally used for the Beaglebone black RTEMS libbsd testing?
> 
> Is the dtb needed for the non-libbsd BSP?
> 
> Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
> libbsd to get ethernet?
> 
> Thanks,
> Alan

Hello Alan,

I recommend to use the FreeBSD device trees. libbsd is FreeBSD based and
therefore works best with them. Normally I would suggest to use the
version matching the FreeBSD commit used in libbsd. But unfortunately in
the last commit that doesn't seem to work. Vijay had some problems with
it and noted that the version from FreeBSD commit
19a6ceb89dbacf74697d493e48c388767126d418 works fine.

Regarding Ethernet support: As far as I know there is no support for the
legacy stack. But the one in libbsd worked fine the last time I tested
it (which was when I ported it). If you really want to use the legacy
stack please note that it is still an IPv4 only one and therefore it is
quite limited nowadays.

Best regards

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