Re: Interested in contributing to Beaglebone BSP

[Chris Johns]

On 5/5/20 4:08 pm, Christian Mauderer wrote:

On 05/05/2020 06:38, Chris Johns wrote:

On 4/5/20 12:50 am, Vijay Kumar Banerjee wrote:

On Sun, May 3, 2020 at 8:12 PM Christian Mauderer mailto:o...@c-mauderer.de>> wrote:

     I don't think that would be a good idea before the release. After the
     release we should work on a 1.6 build set.


What about 5.2? :)


I don't have a problem adding it to the 5.2 release as a backport. 


Thanks.


But
currently I don't think that you would be happy about open patches for
5.1, correct?


Unfortunately, we are closing in on the remaining issues.

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

Re: Interested in contributing to Beaglebone BSP

[Christian Mauderer]

On 05/05/2020 06:38, Chris Johns wrote:
> On 4/5/20 12:50 am, Vijay Kumar Banerjee wrote:
>> On Sun, May 3, 2020 at 8:12 PM Christian Mauderer > > wrote:
>>
>>     I don't think that would be a good idea before the release. After the
>>     release we should work on a 1.6 build set.
> 
> What about 5.2? :)

I don't have a problem adding it to the 5.2 release as a backport. But
currently I don't think that you would be happy about open patches for
5.1, correct?

> 
>>     The 1.6 only needs libyaml
>>     (or libjson?) which is no default package on FreeBSD. So we need a
>>     solution for that on FreeBSD hosts.
>>
>> I didn't test it with FreeBSD. Yes, after the release we can make a best
>> for 1.6.0 and mention libjson/libyaml as a dependency. We'll just have
>> to figure out a way to check from RSB if the package is present, I hope
>> we'll find some example in the repo already.
> 
> GDB and Python is a example. It is complicated so I hope it provides a
> suitable example
> 
> https://git.rtems.org/rtems-source-builder/tree/source-builder/config/gdb-common-1.cfg#n70
> 
> 
> The `rtems-build-dep` script may help.
> 
> In the bare devel/qemu build set there are checks against pkgconfig and
> if a library is not found on the host it is built for you.
> 
> I hope this helps.
> 
> Chris
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users

-- 

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.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Interested in contributing to Beaglebone BSP

[Chris Johns]

On 4/5/20 12:50 am, Vijay Kumar Banerjee wrote:
On Sun, May 3, 2020 at 8:12 PM Christian Mauderer > wrote:


I don't think that would be a good idea before the release. After the
release we should work on a 1.6 build set.


What about 5.2? :)


The 1.6 only needs libyaml
(or libjson?) which is no default package on FreeBSD. So we need a
solution for that on FreeBSD hosts.

I didn't test it with FreeBSD. Yes, after the release we can make a best
for 1.6.0 and mention libjson/libyaml as a dependency. We'll just have
to figure out a way to check from RSB if the package is present, I hope
we'll find some example in the repo already.


GDB and Python is a example. It is complicated so I hope it provides a 
suitable example


https://git.rtems.org/rtems-source-builder/tree/source-builder/config/gdb-common-1.cfg#n70

The `rtems-build-dep` script may help.

In the bare devel/qemu build set there are checks against pkgconfig and 
if a library is not found on the host it is built for you.


I hope this helps.

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

Re: Interested in contributing to Beaglebone BSP

[Christian Mauderer]

Hello James,

On 04/05/2020 12:26, James Fitzsimons wrote:
> Hi Christian and Vijay,
> 
> Firstly thank you so much for your replies they were extremely helpful
> and much appreciated.
> 
> On Mon, 4 May 2020 at 02:50, Vijay Kumar Banerjee  > wrote:
> 
> 
> On Sun, May 3, 2020 at 8:12 PM Christian Mauderer  > wrote:
> 
> 
> Note that the repo works only most of the time. It's more of a
> test repo
> for me that just collects the necessary commands and
> repositories so I
> don't have to type everything manually.
> 
> The dtc that I build there currently doesn't work. I removed the
> step
> from the makefile so that the host dtc is used again
> 
> 
> Understood. it is extremely useful for people getting started with rtems
> on the BeagleBone though! On my Ubuntu 18.04 host the system dtc was
> version 1.4.5 which also didn't support the -@ option, so I took Vijays
> advice and downloaded and built 1.6.0 which solved the problem.

It's only relevant if you want to build overlays (which I do in my
repo). That is necessary for example when you want to use HDMI. If you
don't want HDMI you can just build the base FDT without the -@ option
and load only that. That should work fine too. If it doesn't work you
found a bug.

>  
> 
> That's correct. The -@ or --symbols is only there in newer dtc
> versions.
> Out of interest: Where did you find that the option is
> deprecated? It is
> still there in 1.6.0.
> 
> 
> That must be my mistake. I was sure I read that the other night but
> can't find the website or thread I was reading now so it was probably
> either bad information or my misinterpretation - apologies for that.

No problem. I would have just tried to move to an alternative if that
option would have been deprecated.

Best regards

Christian

> 
> >     If I then run the following steps in the makefile manually,
> >     bootstrap and bsp complete, but libbsd fails with the
> following error:
> >
> >     [1497/2193] Compiling freebsd/sys/netpfil/pf/pf_lb.c
> >     ../../freebsd/sys/arm/freescale/imx/imx6_ccm.c:54:10:
> fatal error:
> >     arm/freescale/imx/imx_ccmvar.h: No such file or directory
> >      #include 
> >               ^~~~
> >     compilation terminated.
> >
> > This bug was recently fixed in the rtems-libbsd ( for both
> master and
> > 5-freebsd-12 branches), if you update to recent HEAD of the
> libbsd, then
> > this error will hopefully not be there.
> 
> 
> Thanks for this. I thought my rtems-libbsd repo was up to date, but I
> did a git pull --recurse-submodules and now make libbsd succeeds.
> Loading the hello world test app onto the board produces the expected
> output in a terminal session, so I think I am now in a position to make
> a start on the eQEP driver. 
> 
> Many thanks for your help!
> 
> Regards
> James Fitzsimons
>  
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Interested in contributing to Beaglebone BSP

[James Fitzsimons]

Hi Christian and Vijay,

Firstly thank you so much for your replies they were extremely helpful and
much appreciated.

On Mon, 4 May 2020 at 02:50, Vijay Kumar Banerjee  wrote:

>
> On Sun, May 3, 2020 at 8:12 PM Christian Mauderer 
> wrote:
>
>>
>> Note that the repo works only most of the time. It's more of a test repo
>> for me that just collects the necessary commands and repositories so I
>> don't have to type everything manually.
>>
>> The dtc that I build there currently doesn't work. I removed the step
>> from the makefile so that the host dtc is used again
>>
>
Understood. it is extremely useful for people getting started with rtems on
the BeagleBone though! On my Ubuntu 18.04 host the system dtc was version
1.4.5 which also didn't support the -@ option, so I took Vijays advice and
downloaded and built 1.6.0 which solved the problem.


> That's correct. The -@ or --symbols is only there in newer dtc versions.
>> Out of interest: Where did you find that the option is deprecated? It is
>> still there in 1.6.0.
>>
>
That must be my mistake. I was sure I read that the other night but can't
find the website or thread I was reading now so it was probably either bad
information or my misinterpretation - apologies for that.

> If I then run the following steps in the makefile manually,
>> > bootstrap and bsp complete, but libbsd fails with the following
>> error:
>> >
>> > [1497/2193] Compiling freebsd/sys/netpfil/pf/pf_lb.c
>> > ../../freebsd/sys/arm/freescale/imx/imx6_ccm.c:54:10: fatal error:
>> > arm/freescale/imx/imx_ccmvar.h: No such file or directory
>> >  #include 
>> >   ^~~~
>> > compilation terminated.
>> >
>> > This bug was recently fixed in the rtems-libbsd ( for both master and
>> > 5-freebsd-12 branches), if you update to recent HEAD of the libbsd, then
>> > this error will hopefully not be there.
>>
>
Thanks for this. I thought my rtems-libbsd repo was up to date, but I did
a git pull --recurse-submodules and now make libbsd succeeds.
Loading the hello world test app onto the board produces the expected
output in a terminal session, so I think I am now in a position to make a
start on the eQEP driver.

Many thanks for your help!

Regards
James Fitzsimons
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Interested in contributing to Beaglebone BSP

[Vijay Kumar Banerjee]

On Sun, May 3, 2020 at 8:12 PM Christian Mauderer  wrote:

> Hello James and Vijay,
>
> On 03/05/2020 14:33, Vijay Kumar Banerjee wrote:
> > Hi James
> >
> > On Sun, May 3, 2020 at 4:30 PM James Fitzsimons
> > mailto:james.fitzsim...@gmail.com>> wrote:
> >
> > Hi Christian,
> >
> > I tried to make a start this evening but I hate to say I ran into
> > trouble getting my rtems environment setup, and after attempting to
> > debug this for a couple of hours I thought I might see if you (or
> > anyone else on the list) had some ideas.
> >
> > I started by forking
> > your https://gitlab.com/c-mauderer/rtems-bbb gitlab repo and running
> > make setup.
>
> Note that the repo works only most of the time. It's more of a test repo
> for me that just collects the necessary commands and repositories so I
> don't have to type everything manually.
>
> The dtc that I build there currently doesn't work. I removed the step
> from the makefile so that the host dtc is used again.
>
> >
> > Everything progresses fine up until the "dtb" step in the makefile.
> > At that point I get the following error:
> >
> > make -C /home/james/Documents/rtems/rtems-bbb//devicetree
> > MACHINE=arm install
> > make[1]: Entering directory
> > '/home/james/Documents/rtems/rtems-bbb/devicetree'
> > /home/james/Documents/rtems/rtems-bbb//install/rtems/5/bin/dtc -@ -o
> >
>  
> /home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo
> >
>  /home/james/Documents/rtems/rtems-bbb/devicetree//am335x-i2c-overlay.dtso
> > /home/james/Documents/rtems/rtems-bbb//install/rtems/5/bin/dtc:
> > invalid option -- '@'
> > Usage: dtc [options] 
> >
> > A bit of googling turned up some information that the -@ option is
> > deprecated, and sure enough running ./install/rtems/5/bin/dtc --help
> > shows that the version of dtc built (Version: DTC 1.4.1-gf2f0fdf1)
> > does not have the @ option. I tried modifying the makefile in the
> > devicetree directory so the last two lines look like this:
> >
> > The -@ option is required to generate the symbols without which there
> > will be errors in applying the overlay. The -@ option is not present in
> > version 1.4.1, you can build 1.4.6 from the source. I recently added the
> > rsb recipe for 1.4.6 but there's no bset present and the devel/dtc
> > builds the 1.4.1 .
>
> That's correct. The -@ or --symbols is only there in newer dtc versions.
> Out of interest: Where did you find that the option is deprecated? It is
> still there in 1.6.0.
>
> Firstly, sorry for the typo. I mistakenly wrote 1.4.6 instead of 1.6.
To make it clear: The option IS present in 1.6.0

> >
> > Christian: Can we make a bset for dtc-1.4.6 which can be separately
> > build like build/dtc-1.4.6.bset ?
>
> I don't think that would be a good idea before the release. After the
> release we should work on a 1.6 build set. The 1.6 only needs libyaml
> (or libjson?) which is no default package on FreeBSD. So we need a
> solution for that on FreeBSD hosts.
>
> I didn't test it with FreeBSD. Yes, after the release we can make a best
for 1.6.0 and mention libjson/libyaml as a dependency. We'll just have
to figure out a way to check from RSB if the package is present, I hope
we'll find some example in the repo already.

> >
> > $(TARGETDIR)/%.dtbo: $(MAKEFILE_DIR)/%.dtso
> >
> > $(PREFIX)/bin/dtc -o $@ $<
> >
> >
> > Now running $make dtb gives the following output:
> >
> > make[1]: Entering directory
> > '/home/james/Documents/rtems/rtems-bbb/devicetree'
> > /home/james/Documents/rtems/rtems-bbb//install/rtems/5/bin/dtc -o
> >
>  
> /home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo
> >
>  /home/james/Documents/rtems/rtems-bbb/devicetree//am335x-i2c-overlay.dtso
> > Error:
> >
>  
> /home/james/Documents/rtems/rtems-bbb/devicetree//am335x-i2c-overlay.dtso:2.2-8
> > syntax error
> > FATAL ERROR: Unable to parse input tree
> > Makefile:24: recipe for target
> >
>  
> '/home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo'
> > failed
> > make[1]: ***
> >
>  
> [/home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo]
> > Error 1
> > make[1]: Leaving directory
> > '/home/james/Documents/rtems/rtems-bbb/devicetree'
> > Makefile:96: recipe for target 'dtb' failed
> > make: *** [dtb] Error 2
> > james@opportunity:~/Documents/rtems/rtems-bbb$
> >
> > I'm not quite sure where to go from here though.
> >
> > If I then run the following steps in the makefile manually,
> > bootstrap and bsp complete, but libbsd fails with the following
> error:
> >
> > [1497/2193] Compiling freebsd/sys/netpfil/pf/pf_lb.c
> > ../../freebsd/sys/arm/freescale/imx/imx6_ccm.c:54:10: fatal error:
> > arm/freescale/imx/imx_ccmvar.h: No such file or directory
> >  #include 
> >

Re: Interested in contributing to Beaglebone BSP

[Christian Mauderer]

Hello James and Vijay,

On 03/05/2020 14:33, Vijay Kumar Banerjee wrote:
> Hi James
> 
> On Sun, May 3, 2020 at 4:30 PM James Fitzsimons
> mailto:james.fitzsim...@gmail.com>> wrote:
> 
> Hi Christian,
> 
> I tried to make a start this evening but I hate to say I ran into
> trouble getting my rtems environment setup, and after attempting to
> debug this for a couple of hours I thought I might see if you (or
> anyone else on the list) had some ideas.
> 
> I started by forking
> your https://gitlab.com/c-mauderer/rtems-bbb gitlab repo and running
> make setup.

Note that the repo works only most of the time. It's more of a test repo
for me that just collects the necessary commands and repositories so I
don't have to type everything manually.

The dtc that I build there currently doesn't work. I removed the step
from the makefile so that the host dtc is used again.

> 
> Everything progresses fine up until the "dtb" step in the makefile.
> At that point I get the following error:
> 
> make -C /home/james/Documents/rtems/rtems-bbb//devicetree
> MACHINE=arm install
> make[1]: Entering directory
> '/home/james/Documents/rtems/rtems-bbb/devicetree'
> /home/james/Documents/rtems/rtems-bbb//install/rtems/5/bin/dtc -@ -o
> 
> /home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo
> /home/james/Documents/rtems/rtems-bbb/devicetree//am335x-i2c-overlay.dtso
> /home/james/Documents/rtems/rtems-bbb//install/rtems/5/bin/dtc:
> invalid option -- '@'
> Usage: dtc [options] 
> 
> A bit of googling turned up some information that the -@ option is
> deprecated, and sure enough running ./install/rtems/5/bin/dtc --help
> shows that the version of dtc built (Version: DTC 1.4.1-gf2f0fdf1)
> does not have the @ option. I tried modifying the makefile in the
> devicetree directory so the last two lines look like this:
> 
> The -@ option is required to generate the symbols without which there
> will be errors in applying the overlay. The -@ option is not present in
> version 1.4.1, you can build 1.4.6 from the source. I recently added the
> rsb recipe for 1.4.6 but there's no bset present and the devel/dtc
> builds the 1.4.1 . 

That's correct. The -@ or --symbols is only there in newer dtc versions.
Out of interest: Where did you find that the option is deprecated? It is
still there in 1.6.0.

> 
> Christian: Can we make a bset for dtc-1.4.6 which can be separately
> build like build/dtc-1.4.6.bset ?

I don't think that would be a good idea before the release. After the
release we should work on a 1.6 build set. The 1.6 only needs libyaml
(or libjson?) which is no default package on FreeBSD. So we need a
solution for that on FreeBSD hosts.

> 
> $(TARGETDIR)/%.dtbo: $(MAKEFILE_DIR)/%.dtso
> 
> $(PREFIX)/bin/dtc -o $@ $<
> 
> 
> Now running $make dtb gives the following output:
> 
> make[1]: Entering directory
> '/home/james/Documents/rtems/rtems-bbb/devicetree'
> /home/james/Documents/rtems/rtems-bbb//install/rtems/5/bin/dtc -o
> 
> /home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo
> /home/james/Documents/rtems/rtems-bbb/devicetree//am335x-i2c-overlay.dtso
> Error:
> 
> /home/james/Documents/rtems/rtems-bbb/devicetree//am335x-i2c-overlay.dtso:2.2-8
> syntax error
> FATAL ERROR: Unable to parse input tree
> Makefile:24: recipe for target
> 
> '/home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo'
> failed
> make[1]: ***
> 
> [/home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo]
> Error 1
> make[1]: Leaving directory
> '/home/james/Documents/rtems/rtems-bbb/devicetree'
> Makefile:96: recipe for target 'dtb' failed
> make: *** [dtb] Error 2
> james@opportunity:~/Documents/rtems/rtems-bbb$
> 
> I'm not quite sure where to go from here though.
> 
> If I then run the following steps in the makefile manually,
> bootstrap and bsp complete, but libbsd fails with the following error:
> 
> [1497/2193] Compiling freebsd/sys/netpfil/pf/pf_lb.c
> ../../freebsd/sys/arm/freescale/imx/imx6_ccm.c:54:10: fatal error:
> arm/freescale/imx/imx_ccmvar.h: No such file or directory
>  #include 
>           ^~~~
> compilation terminated.
> 
> 
> This bug was recently fixed in the rtems-libbsd ( for both master and
> 5-freebsd-12 branches), if you update to recent HEAD of the libbsd, then
> this error will hopefully not be there.
> 
> Best regards,
> Vijay
> 
> 
> Thanks for any advice you can provide.
> 
> Regards,
> James Fitzsimons
> 
> 
> 
> 
> 
> 
> On Mon, 27 Apr 2020 at 00:25, Christian Mauderer  > wrote:
> 
> Hello James,
> 
> On 26/04/2020 12:05, James Fitzsimons wrote:
> > Hi Christian,
> >
>   

Re: Interested in contributing to Beaglebone BSP

[Vijay Kumar Banerjee]

Hi James

On Sun, May 3, 2020 at 4:30 PM James Fitzsimons 
wrote:

> Hi Christian,
>
> I tried to make a start this evening but I hate to say I ran into trouble
> getting my rtems environment setup, and after attempting to debug this for
> a couple of hours I thought I might see if you (or anyone else on the list)
> had some ideas.
>
> I started by forking your https://gitlab.com/c-mauderer/rtems-bbb gitlab
> repo and running make setup.
>
> Everything progresses fine up until the "dtb" step in the makefile. At
> that point I get the following error:
>
> make -C /home/james/Documents/rtems/rtems-bbb//devicetree MACHINE=arm
> install
> make[1]: Entering directory
> '/home/james/Documents/rtems/rtems-bbb/devicetree'
> /home/james/Documents/rtems/rtems-bbb//install/rtems/5/bin/dtc -@ -o
> /home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo
> /home/james/Documents/rtems/rtems-bbb/devicetree//am335x-i2c-overlay.dtso
> /home/james/Documents/rtems/rtems-bbb//install/rtems/5/bin/dtc: invalid
> option -- '@'
> Usage: dtc [options] 
>
> A bit of googling turned up some information that the -@ option is
> deprecated, and sure enough running ./install/rtems/5/bin/dtc --help shows
> that the version of dtc built (Version: DTC 1.4.1-gf2f0fdf1) does not have
> the @ option. I tried modifying the makefile in the devicetree directory so
> the last two lines look like this:
>
> The -@ option is required to generate the symbols without which there will
be errors in applying the overlay. The -@ option is not present in version
1.4.1, you can build 1.4.6 from the source. I recently added the rsb recipe
for 1.4.6 but there's no bset present and the devel/dtc builds the 1.4.1 .

Christian: Can we make a bset for dtc-1.4.6 which can be separately build
like build/dtc-1.4.6.bset ?

$(TARGETDIR)/%.dtbo: $(MAKEFILE_DIR)/%.dtso
>
> $(PREFIX)/bin/dtc -o $@ $<
>
>
> Now running $make dtb gives the following output:
>
> make[1]: Entering directory
> '/home/james/Documents/rtems/rtems-bbb/devicetree'
> /home/james/Documents/rtems/rtems-bbb//install/rtems/5/bin/dtc -o
> /home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo
> /home/james/Documents/rtems/rtems-bbb/devicetree//am335x-i2c-overlay.dtso
> Error:
> /home/james/Documents/rtems/rtems-bbb/devicetree//am335x-i2c-overlay.dtso:2.2-8
> syntax error
> FATAL ERROR: Unable to parse input tree
> Makefile:24: recipe for target
> '/home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo'
> failed
> make[1]: ***
> [/home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo]
> Error 1
> make[1]: Leaving directory
> '/home/james/Documents/rtems/rtems-bbb/devicetree'
> Makefile:96: recipe for target 'dtb' failed
> make: *** [dtb] Error 2
> james@opportunity:~/Documents/rtems/rtems-bbb$
>
> I'm not quite sure where to go from here though.
>
> If I then run the following steps in the makefile manually, bootstrap and
> bsp complete, but libbsd fails with the following error:
>
> [1497/2193] Compiling freebsd/sys/netpfil/pf/pf_lb.c
> ../../freebsd/sys/arm/freescale/imx/imx6_ccm.c:54:10: fatal error:
> arm/freescale/imx/imx_ccmvar.h: No such file or directory
>  #include 
>   ^~~~
> compilation terminated.
>

This bug was recently fixed in the rtems-libbsd ( for both master and
5-freebsd-12 branches), if you update to recent HEAD of the libbsd, then
this error will hopefully not be there.

Best regards,
Vijay

>
> Thanks for any advice you can provide.
>
> Regards,
> James Fitzsimons
>
>
>
>
>
>
> On Mon, 27 Apr 2020 at 00:25, Christian Mauderer 
> wrote:
>
>> Hello James,
>>
>> On 26/04/2020 12:05, James Fitzsimons wrote:
>> > Hi Christian,
>> >
>> > Thanks for your reply.
>> >
>> > On Wed, 22 Apr 2020 at 23:29, Christian Mauderer
>> > > > > wrote:
>> >
>> > Hello James,
>> >
>> > On 20/04/2020 13:13, James Fitzsimons wrote:
>> > > I am interested in adding support for the eQEP (Enhanced
>> Quadrature
>> > > Encoder Pulse Module) which I am using to decode the quadrature
>> > encoders
>> > > on my motors.
>> >
>> > That one isn't implemented yet and I don't know of any current work
>> on
>> > it. So feel free to go ahead.
>> >
>> >
>> > Thanks for the encouragement - I will start with the eQEP drivers.
>> >
>> >
>> > > I will eventually also need support for the ADC, PRU (I see some
>> work
>> > > has already been done on that by a GSoC project),
>> >
>> > There has been some work on PRU. I'm not entirely sure about ADC.
>> >
>> > > and ideally the TI
>> > > WiLink 8 WL1835MOD wireless chipset - although I realise that
>> might be
>> > > extremely difficult.
>> >
>> > That depends: What kind of interface is used for that? And is the
>> chip
>> > already supported in FreeBSD?
>> >
>> >
>> > I have done a bit of research and can't find any FreeBSD 

Re: Interested in contributing to Beaglebone BSP

[James Fitzsimons]

Hi Christian,

I tried to make a start this evening but I hate to say I ran into trouble
getting my rtems environment setup, and after attempting to debug this for
a couple of hours I thought I might see if you (or anyone else on the list)
had some ideas.

I started by forking your https://gitlab.com/c-mauderer/rtems-bbb gitlab
repo and running make setup.

Everything progresses fine up until the "dtb" step in the makefile. At that
point I get the following error:

make -C /home/james/Documents/rtems/rtems-bbb//devicetree MACHINE=arm
install
make[1]: Entering directory
'/home/james/Documents/rtems/rtems-bbb/devicetree'
/home/james/Documents/rtems/rtems-bbb//install/rtems/5/bin/dtc -@ -o
/home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo
/home/james/Documents/rtems/rtems-bbb/devicetree//am335x-i2c-overlay.dtso
/home/james/Documents/rtems/rtems-bbb//install/rtems/5/bin/dtc: invalid
option -- '@'
Usage: dtc [options] 

A bit of googling turned up some information that the -@ option is
deprecated, and sure enough running ./install/rtems/5/bin/dtc --help shows
that the version of dtc built (Version: DTC 1.4.1-gf2f0fdf1) does not have
the @ option. I tried modifying the makefile in the devicetree directory so
the last two lines look like this:

$(TARGETDIR)/%.dtbo: $(MAKEFILE_DIR)/%.dtso

$(PREFIX)/bin/dtc -o $@ $<


Now running $make dtb gives the following output:

make[1]: Entering directory
'/home/james/Documents/rtems/rtems-bbb/devicetree'
/home/james/Documents/rtems/rtems-bbb//install/rtems/5/bin/dtc -o
/home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo
/home/james/Documents/rtems/rtems-bbb/devicetree//am335x-i2c-overlay.dtso
Error:
/home/james/Documents/rtems/rtems-bbb/devicetree//am335x-i2c-overlay.dtso:2.2-8
syntax error
FATAL ERROR: Unable to parse input tree
Makefile:24: recipe for target
'/home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo'
failed
make[1]: ***
[/home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo]
Error 1
make[1]: Leaving directory
'/home/james/Documents/rtems/rtems-bbb/devicetree'
Makefile:96: recipe for target 'dtb' failed
make: *** [dtb] Error 2
james@opportunity:~/Documents/rtems/rtems-bbb$

I'm not quite sure where to go from here though.

If I then run the following steps in the makefile manually, bootstrap and
bsp complete, but libbsd fails with the following error:

[1497/2193] Compiling freebsd/sys/netpfil/pf/pf_lb.c
../../freebsd/sys/arm/freescale/imx/imx6_ccm.c:54:10: fatal error:
arm/freescale/imx/imx_ccmvar.h: No such file or directory
 #include 
  ^~~~
compilation terminated.

Thanks for any advice you can provide.

Regards,
James Fitzsimons






On Mon, 27 Apr 2020 at 00:25, Christian Mauderer  wrote:

> Hello James,
>
> On 26/04/2020 12:05, James Fitzsimons wrote:
> > Hi Christian,
> >
> > Thanks for your reply.
> >
> > On Wed, 22 Apr 2020 at 23:29, Christian Mauderer
> >  > > wrote:
> >
> > Hello James,
> >
> > On 20/04/2020 13:13, James Fitzsimons wrote:
> > > I am interested in adding support for the eQEP (Enhanced Quadrature
> > > Encoder Pulse Module) which I am using to decode the quadrature
> > encoders
> > > on my motors.
> >
> > That one isn't implemented yet and I don't know of any current work
> on
> > it. So feel free to go ahead.
> >
> >
> > Thanks for the encouragement - I will start with the eQEP drivers.
> >
> >
> > > I will eventually also need support for the ADC, PRU (I see some
> work
> > > has already been done on that by a GSoC project),
> >
> > There has been some work on PRU. I'm not entirely sure about ADC.
> >
> > > and ideally the TI
> > > WiLink 8 WL1835MOD wireless chipset - although I realise that
> might be
> > > extremely difficult.
> >
> > That depends: What kind of interface is used for that? And is the
> chip
> > already supported in FreeBSD?
> >
> >
> > I have done a bit of research and can't find any FreeBSD support for it.
> > There are obviously linux drivers but I realise these are not suitable
> > for porting to RTEMS
>
> I had a look at the Linux drivers. They are GPL only. So you are right:
> They wouldn't be accepted in RTEMS. In theory you could use a private
> repo for a port of the drivers but expect a lot of maintenance effort if
> you want to keep them up to date.
>
> You should think about asking on a FreeBSD mailing list whether someone
> is working on a driver. Maybe someone is working on it and there already
> exists a partial or complete driver in some private or separate repository.
>
> >
> >
> > If it is an USB interface and it is supported in FreeBSD adding it
> > shouldn't be much work. If it is an SDIO it will get a bit more
> > difficult but still possible in a decent time frame. If FreeBSD
> doesn't
> > know anything about 

Re: Interested in contributing to Beaglebone BSP

[Christian Mauderer]

Hello James,

On 26/04/2020 12:05, James Fitzsimons wrote:
> Hi Christian,
> 
> Thanks for your reply.
> 
> On Wed, 22 Apr 2020 at 23:29, Christian Mauderer
>  > wrote:
> 
> Hello James,
> 
> On 20/04/2020 13:13, James Fitzsimons wrote:
> > I am interested in adding support for the eQEP (Enhanced Quadrature
> > Encoder Pulse Module) which I am using to decode the quadrature
> encoders
> > on my motors.
> 
> That one isn't implemented yet and I don't know of any current work on
> it. So feel free to go ahead.
> 
> 
> Thanks for the encouragement - I will start with the eQEP drivers. 
> 
>
> > I will eventually also need support for the ADC, PRU (I see some work
> > has already been done on that by a GSoC project),
> 
> There has been some work on PRU. I'm not entirely sure about ADC.
> 
> > and ideally the TI
> > WiLink 8 WL1835MOD wireless chipset - although I realise that might be
> > extremely difficult.
> 
> That depends: What kind of interface is used for that? And is the chip
> already supported in FreeBSD?
> 
> 
> I have done a bit of research and can't find any FreeBSD support for it.
> There are obviously linux drivers but I realise these are not suitable
> for porting to RTEMS

I had a look at the Linux drivers. They are GPL only. So you are right:
They wouldn't be accepted in RTEMS. In theory you could use a private
repo for a port of the drivers but expect a lot of maintenance effort if
you want to keep them up to date.

You should think about asking on a FreeBSD mailing list whether someone
is working on a driver. Maybe someone is working on it and there already
exists a partial or complete driver in some private or separate repository.

>  
> 
> If it is an USB interface and it is supported in FreeBSD adding it
> shouldn't be much work. If it is an SDIO it will get a bit more
> difficult but still possible in a decent time frame. If FreeBSD doesn't
> know anything about it you will have a really hard time. WLAN drivers
> are _very_ complex and the need a lot of detail knowledge about the
> chipset and the regulations.
> 
> 
> I'm pretty sure it uses an SDIO interface, but as you say without the
> FreeBSD support it may be a bit of a long shot.
>  

Yes, seems to be SDIO. We had a GSoC project regarding SDIO two or three
years ago. The student managed to do most of the work for a SDIO support
in libbsd. But we could only partially merge it because at that point
the libbsd was too far behind FreeBSD. One extra difficulty has been
that SDIO was a compile time option in FreeBSD back then. You might want
to take a look at the project and whether you can re-use some parts of
it if you want to add the SDIO stuff.

> 
> > Are drivers for these features something that would be welcome in the
> > BBB BSP, and if so any tips for getting started?
> 
> Of course. Peripheral drivers are nearly always welcome.
> 
> For the PRU you might should contact the GSoC student working on the
> topic. For WLAN: Please check the interface and FreeBSD support. I don't
> know exactly what the eQEP does. But if there is a FreeBSD driver for it
> you might want to check that one too and maybe port it via libbsd
> (except the eQEP is a really simple module and it's a lot simpler to
> write the driver yourself in the BSP)
> 
> 
> I'll make a start on the eQEP module (quadrature decoder for reading
> encoders) and if that goes well I'll reach out to Nils Hölscher about
> the PRU work.

Sounds good. Feel free to ask questions on the mailing list anytime you
think necessary. And although I don't think that you have too much
overlap please keep an eye on this years GSoC projects and whether there
is any influence on your code or vice versa.

Best regards

Christian Mauderer

>  
> Thanks and regards, 
> James Fitzsimons
> 
> 
> 
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Interested in contributing to Beaglebone BSP

[James Fitzsimons]

Hi Christian,

Thanks for your reply.

On Wed, 22 Apr 2020 at 23:29, Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> Hello James,
>
> On 20/04/2020 13:13, James Fitzsimons wrote:
> > I am interested in adding support for the eQEP (Enhanced Quadrature
> > Encoder Pulse Module) which I am using to decode the quadrature encoders
> > on my motors.
>
> That one isn't implemented yet and I don't know of any current work on
> it. So feel free to go ahead.
>

Thanks for the encouragement - I will start with the eQEP drivers.

> I will eventually also need support for the ADC, PRU (I see some work
> > has already been done on that by a GSoC project),
>
> There has been some work on PRU. I'm not entirely sure about ADC.
>
> > and ideally the TI
> > WiLink 8 WL1835MOD wireless chipset - although I realise that might be
> > extremely difficult.
>
> That depends: What kind of interface is used for that? And is the chip
> already supported in FreeBSD?
>

I have done a bit of research and can't find any FreeBSD support for it.
There are obviously linux drivers but I realise these are not suitable for
porting to RTEMS


> If it is an USB interface and it is supported in FreeBSD adding it
> shouldn't be much work. If it is an SDIO it will get a bit more
> difficult but still possible in a decent time frame. If FreeBSD doesn't
> know anything about it you will have a really hard time. WLAN drivers
> are _very_ complex and the need a lot of detail knowledge about the
> chipset and the regulations.
>

I'm pretty sure it uses an SDIO interface, but as you say without the
FreeBSD support it may be a bit of a long shot.


> > Are drivers for these features something that would be welcome in the
> > BBB BSP, and if so any tips for getting started?
>
> Of course. Peripheral drivers are nearly always welcome.
>
> For the PRU you might should contact the GSoC student working on the
> topic. For WLAN: Please check the interface and FreeBSD support. I don't
> know exactly what the eQEP does. But if there is a FreeBSD driver for it
> you might want to check that one too and maybe port it via libbsd
> (except the eQEP is a really simple module and it's a lot simpler to
> write the driver yourself in the BSP)
>

I'll make a start on the eQEP module (quadrature decoder for reading
encoders) and if that goes well I'll reach out to Nils Hölscher about the
PRU work.

Thanks and regards,
James Fitzsimons

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

Re: Interested in contributing to Beaglebone BSP

[Christian Mauderer]

Hello James,

On 20/04/2020 13:13, James Fitzsimons wrote:
> Hi all,
> 
> I'm interested in contributing to the BeagleBone BSP by adding drivers
> for some of the missing features. I am working on a robotics project
> using the BeagleBoneBlack wireless and becoming frustrated by Linux. I
> would love to be able to use RTEMS, which I have dabbled with a bit in
> the past.
> 
> I am interested in adding support for the eQEP (Enhanced Quadrature
> Encoder Pulse Module) which I am using to decode the quadrature encoders
> on my motors.

That one isn't implemented yet and I don't know of any current work on
it. So feel free to go ahead.

> 
> I will eventually also need support for the ADC, PRU (I see some work
> has already been done on that by a GSoC project),

There has been some work on PRU. I'm not entirely sure about ADC.

> and ideally the TI
> WiLink 8 WL1835MOD wireless chipset - although I realise that might be
> extremely difficult.

That depends: What kind of interface is used for that? And is the chip
already supported in FreeBSD?

If it is an USB interface and it is supported in FreeBSD adding it
shouldn't be much work. If it is an SDIO it will get a bit more
difficult but still possible in a decent time frame. If FreeBSD doesn't
know anything about it you will have a really hard time. WLAN drivers
are _very_ complex and the need a lot of detail knowledge about the
chipset and the regulations.

> 
> Are drivers for these features something that would be welcome in the
> BBB BSP, and if so any tips for getting started?

Of course. Peripheral drivers are nearly always welcome.

For the PRU you might should contact the GSoC student working on the
topic. For WLAN: Please check the interface and FreeBSD support. I don't
know exactly what the eQEP does. But if there is a FreeBSD driver for it
you might want to check that one too and maybe port it via libbsd
(except the eQEP is a really simple module and it's a lot simpler to
write the driver yourself in the BSP).

Best regards

Christian

> 
> Cheers,
> James Fitzsimons
> 
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 

-- 

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.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users