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@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 <o...@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.maude...@embedded-brains.de > > <mailto: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 > > 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