Hi James On Sun, May 3, 2020 at 4:30 PM James Fitzsimons <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. > > 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@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 <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
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
