Interested in contributing to Beaglebone BSP
Vijay Kumar Banerjee
vijay at rtems.org
Sun May 3 14:50:24 UTC 2020
On Sun, May 3, 2020 at 8:12 PM Christian Mauderer <oss at c-mauderer.de> 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
> > <james.fitzsimons at gmail.com <mailto: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.
>
> 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] <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 .
>
> 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 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
> > <mailto: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>
> > > <mailto: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 <mailto:users at rtems.org>
> > > http://lists.rtems.org/mailman/listinfo/users
> > >
> >
> > _______________________________________________
> > users mailing list
> > users at rtems.org <mailto: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/1f15a965/attachment-0001.html>
More information about the users
mailing list