Interested in contributing to Beaglebone BSP

Vijay Kumar Banerjee vijay at rtems.org
Sun May 3 12:33:31 UTC 2020 

Hi James

On Sun, May 3, 2020 at 4:30 PM James Fitzsimons <james.fitzsimons at 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.
>
> 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:
>
> 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 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.
>

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 <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
>> >
>>
> _______________________________________________
> 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/03d0f0c5/attachment.html>

More information about the users mailing list