<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 3, 2020 at 8:12 PM Christian Mauderer <<a href="mailto:oss@c-mauderer.de">oss@c-mauderer.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello James and Vijay,<br>
<br>
On 03/05/2020 14:33, Vijay Kumar Banerjee wrote:<br>
> Hi James<br>
> <br>
> On Sun, May 3, 2020 at 4:30 PM James Fitzsimons<br>
> <<a href="mailto:james.fitzsimons@gmail.com" target="_blank">james.fitzsimons@gmail.com</a> <mailto:<a href="mailto:james.fitzsimons@gmail.com" target="_blank">james.fitzsimons@gmail.com</a>>> wrote:<br>
> <br>
>     Hi Christian,<br>
> <br>
>     I tried to make a start this evening but I hate to say I ran into<br>
>     trouble getting my rtems environment setup, and after attempting to<br>
>     debug this for a couple of hours I thought I might see if you (or<br>
>     anyone else on the list) had some ideas.<br>
> <br>
>     I started by forking<br>
>     your <a href="https://gitlab.com/c-mauderer/rtems-bbb" rel="noreferrer" target="_blank">https://gitlab.com/c-mauderer/rtems-bbb</a> gitlab repo and running<br>
>     make setup.<br>
<br>
Note that the repo works only most of the time. It's more of a test repo<br>
for me that just collects the necessary commands and repositories so I<br>
don't have to type everything manually.<br>
<br>
The dtc that I build there currently doesn't work. I removed the step<br>
from the makefile so that the host dtc is used again.<br>
<br>
> <br>
>     Everything progresses fine up until the "dtb" step in the makefile.<br>
>     At that point I get the following error:<br>
> <br>
>     make -C /home/james/Documents/rtems/rtems-bbb//devicetree<br>
>     MACHINE=arm install<br>
>     make[1]: Entering directory<br>
>     '/home/james/Documents/rtems/rtems-bbb/devicetree'<br>
>     /home/james/Documents/rtems/rtems-bbb//install/rtems/5/bin/dtc -@ -o<br>
>     /home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo<br>
>     /home/james/Documents/rtems/rtems-bbb/devicetree//am335x-i2c-overlay.dtso<br>
>     /home/james/Documents/rtems/rtems-bbb//install/rtems/5/bin/dtc:<br>
>     invalid option -- '@'<br>
>     Usage: dtc [options] <input file><br>
> <br>
>     A bit of googling turned up some information that the -@ option is<br>
>     deprecated, and sure enough running ./install/rtems/5/bin/dtc --help<br>
>     shows that the version of dtc built (Version: DTC 1.4.1-gf2f0fdf1)<br>
>     does not have the @ option. I tried modifying the makefile in the<br>
>     devicetree directory so the last two lines look like this:<br>
> <br>
> The -@ option is required to generate the symbols without which there<br>
> will be errors in applying the overlay. The -@ option is not present in<br>
> version 1.4.1, you can build 1.4.6 from the source. I recently added the<br>
> rsb recipe for 1.4.6 but there's no bset present and the devel/dtc<br>
> builds the 1.4.1 . <br>
<br>
That's correct. The -@ or --symbols is only there in newer dtc versions.<br>
Out of interest: Where did you find that the option is deprecated? It is<br>
still there in 1.6.0.<br>
<br></blockquote><div>Firstly, sorry for the typo. I mistakenly wrote 1.4.6 instead of 1.6.</div><div>To make it clear: The option IS present in 1.6.0 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> Christian: Can we make a bset for dtc-1.4.6 which can be separately<br>
> build like build/dtc-1.4.6.bset ?<br>
<br>
I don't think that would be a good idea before the release. After the<br>
release we should work on a 1.6 build set. The 1.6 only needs libyaml<br>
(or libjson?) which is no default package on FreeBSD. So we need a<br>
solution for that on FreeBSD hosts.<br>
<br></blockquote><div>I didn't test it with FreeBSD. Yes, after the release we can make a best</div><div>for 1.6.0 and mention libjson/libyaml as a dependency. We'll just have</div><div>to figure out a way to check from RSB if the package is present, I hope</div><div>we'll find some example in the repo already. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
>     $(TARGETDIR)/%.dtbo: $(MAKEFILE_DIR)/%.dtso<br>
> <br>
>         $(PREFIX)/bin/dtc -o $@ $<<br>
> <br>
> <br>
>     Now running $make dtb gives the following output:<br>
> <br>
>     make[1]: Entering directory<br>
>     '/home/james/Documents/rtems/rtems-bbb/devicetree'<br>
>     /home/james/Documents/rtems/rtems-bbb//install/rtems/5/bin/dtc -o<br>
>     /home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo<br>
>     /home/james/Documents/rtems/rtems-bbb/devicetree//am335x-i2c-overlay.dtso<br>
>     Error:<br>
>     /home/james/Documents/rtems/rtems-bbb/devicetree//am335x-i2c-overlay.dtso:2.2-8<br>
>     syntax error<br>
>     FATAL ERROR: Unable to parse input tree<br>
>     Makefile:24: recipe for target<br>
>     '/home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo'<br>
>     failed<br>
>     make[1]: ***<br>
>     [/home/james/Documents/rtems/rtems-bbb//install/rtems/5/fdt/am335x-i2c-overlay.dtbo]<br>
>     Error 1<br>
>     make[1]: Leaving directory<br>
>     '/home/james/Documents/rtems/rtems-bbb/devicetree'<br>
>     Makefile:96: recipe for target 'dtb' failed<br>
>     make: *** [dtb] Error 2<br>
>     james@opportunity:~/Documents/rtems/rtems-bbb$<br>
> <br>
>     I'm not quite sure where to go from here though.<br>
> <br>
>     If I then run the following steps in the makefile manually,<br>
>     bootstrap and bsp complete, but libbsd fails with the following error:<br>
> <br>
>     [1497/2193] Compiling freebsd/sys/netpfil/pf/pf_lb.c<br>
>     ../../freebsd/sys/arm/freescale/imx/imx6_ccm.c:54:10: fatal error:<br>
>     arm/freescale/imx/imx_ccmvar.h: No such file or directory<br>
>      #include <arm/freescale/imx/imx_ccmvar.h><br>
>               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
>     compilation terminated.<br>
> <br>
> <br>
> This bug was recently fixed in the rtems-libbsd ( for both master and<br>
> 5-freebsd-12 branches), if you update to recent HEAD of the libbsd, then<br>
> this error will hopefully not be there.<br>
> <br>
> Best regards,<br>
> Vijay<br>
> <br>
> <br>
>     Thanks for any advice you can provide.<br>
> <br>
>     Regards,<br>
>     James Fitzsimons<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
>     On Mon, 27 Apr 2020 at 00:25, Christian Mauderer <<a href="mailto:oss@c-mauderer.de" target="_blank">oss@c-mauderer.de</a><br>
>     <mailto:<a href="mailto:oss@c-mauderer.de" target="_blank">oss@c-mauderer.de</a>>> wrote:<br>
> <br>
>         Hello James,<br>
> <br>
>         On 26/04/2020 12:05, James Fitzsimons wrote:<br>
>         > Hi Christian,<br>
>         ><br>
>         > Thanks for your reply.<br>
>         ><br>
>         > On Wed, 22 Apr 2020 at 23:29, Christian Mauderer<br>
>         > <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
>         <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>><br>
>         > <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
>         <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>>>> wrote:<br>
>         ><br>
>         >     Hello James,<br>
>         ><br>
>         >     On 20/04/2020 13:13, James Fitzsimons wrote:<br>
>         >     > I am interested in adding support for the eQEP (Enhanced<br>
>         Quadrature<br>
>         >     > Encoder Pulse Module) which I am using to decode the<br>
>         quadrature<br>
>         >     encoders<br>
>         >     > on my motors.<br>
>         ><br>
>         >     That one isn't implemented yet and I don't know of any<br>
>         current work on<br>
>         >     it. So feel free to go ahead.<br>
>         ><br>
>         ><br>
>         > Thanks for the encouragement - I will start with the eQEP<br>
>         drivers.<br>
>         ><br>
>         ><br>
>         >     > I will eventually also need support for the ADC, PRU (I<br>
>         see some work<br>
>         >     > has already been done on that by a GSoC project),<br>
>         ><br>
>         >     There has been some work on PRU. I'm not entirely sure<br>
>         about ADC.<br>
>         ><br>
>         >     > and ideally the TI<br>
>         >     > WiLink 8 WL1835MOD wireless chipset - although I realise<br>
>         that might be<br>
>         >     > extremely difficult.<br>
>         ><br>
>         >     That depends: What kind of interface is used for that? And<br>
>         is the chip<br>
>         >     already supported in FreeBSD?<br>
>         ><br>
>         ><br>
>         > I have done a bit of research and can't find any FreeBSD<br>
>         support for it.<br>
>         > There are obviously linux drivers but I realise these are not<br>
>         suitable<br>
>         > for porting to RTEMS<br>
> <br>
>         I had a look at the Linux drivers. They are GPL only. So you are<br>
>         right:<br>
>         They wouldn't be accepted in RTEMS. In theory you could use a<br>
>         private<br>
>         repo for a port of the drivers but expect a lot of maintenance<br>
>         effort if<br>
>         you want to keep them up to date.<br>
> <br>
>         You should think about asking on a FreeBSD mailing list whether<br>
>         someone<br>
>         is working on a driver. Maybe someone is working on it and there<br>
>         already<br>
>         exists a partial or complete driver in some private or separate<br>
>         repository.<br>
> <br>
>         >  <br>
>         ><br>
>         >     If it is an USB interface and it is supported in FreeBSD<br>
>         adding it<br>
>         >     shouldn't be much work. If it is an SDIO it will get a bit<br>
>         more<br>
>         >     difficult but still possible in a decent time frame. If<br>
>         FreeBSD doesn't<br>
>         >     know anything about it you will have a really hard time.<br>
>         WLAN drivers<br>
>         >     are _very_ complex and the need a lot of detail knowledge<br>
>         about the<br>
>         >     chipset and the regulations.<br>
>         ><br>
>         ><br>
>         > I'm pretty sure it uses an SDIO interface, but as you say<br>
>         without the<br>
>         > FreeBSD support it may be a bit of a long shot.<br>
>         >  <br>
> <br>
>         Yes, seems to be SDIO. We had a GSoC project regarding SDIO two<br>
>         or three<br>
>         years ago. The student managed to do most of the work for a SDIO<br>
>         support<br>
>         in libbsd. But we could only partially merge it because at that<br>
>         point<br>
>         the libbsd was too far behind FreeBSD. One extra difficulty has been<br>
>         that SDIO was a compile time option in FreeBSD back then. You<br>
>         might want<br>
>         to take a look at the project and whether you can re-use some<br>
>         parts of<br>
>         it if you want to add the SDIO stuff.<br>
> <br>
>         ><br>
>         >     > Are drivers for these features something that would be<br>
>         welcome in the<br>
>         >     > BBB BSP, and if so any tips for getting started?<br>
>         ><br>
>         >     Of course. Peripheral drivers are nearly always welcome.<br>
>         ><br>
>         >     For the PRU you might should contact the GSoC student<br>
>         working on the<br>
>         >     topic. For WLAN: Please check the interface and FreeBSD<br>
>         support. I don't<br>
>         >     know exactly what the eQEP does. But if there is a FreeBSD<br>
>         driver for it<br>
>         >     you might want to check that one too and maybe port it via<br>
>         libbsd<br>
>         >     (except the eQEP is a really simple module and it's a lot<br>
>         simpler to<br>
>         >     write the driver yourself in the BSP)<br>
>         ><br>
>         ><br>
>         > I'll make a start on the eQEP module (quadrature decoder for<br>
>         reading<br>
>         > encoders) and if that goes well I'll reach out to Nils<br>
>         Hölscher about<br>
>         > the PRU work.<br>
> <br>
>         Sounds good. Feel free to ask questions on the mailing list<br>
>         anytime you<br>
>         think necessary. And although I don't think that you have too much<br>
>         overlap please keep an eye on this years GSoC projects and<br>
>         whether there<br>
>         is any influence on your code or vice versa.<br>
> <br>
>         Best regards<br>
> <br>
>         Christian Mauderer<br>
> <br>
>         >  <br>
>         > Thanks and regards, <br>
>         > James Fitzsimons<br>
>         ><br>
>         ><br>
>         ><br>
>         > _______________________________________________<br>
>         > users mailing list<br>
>         > <a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a> <mailto:<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a>><br>
>         > <a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a><br>
>         ><br>
> <br>
>     _______________________________________________<br>
>     users mailing list<br>
>     <a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a> <mailto:<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a>><br>
>     <a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a><br>
> <br>
</blockquote></div></div>