Interested in contributing to Beaglebone BSP

Sun May 3 11:00:35 UTC 2020

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] <input file>

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 at 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 <arm/freescale/imx/imx_ccmvar.h>
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

Thanks for any advice you can provide.

Regards,
James Fitzsimons

On Mon, 27 Apr 2020 at 00:25, Christian Mauderer <oss at c-mauderer.de> 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
> > <christian.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at 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
>
> 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 at rtems.org
> > http://lists.rtems.org/mailman/listinfo/users
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20200503/5557cdc5/attachment.html>