<div dir="ltr"><div dir="ltr"><br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 20 Mar 2019 at 01:52, Christian Mauderer <<a href="mailto:list@c-mauderer.de">list@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">Am 19.03.19 um 20:37 schrieb Vijay Kumar Banerjee:<br>> <br>> <br>> <br>> On Tue, 19 Mar 2019 at 02:44, Christian Mauderer <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>> wrote:<br>> <br>> Am 18.03.19 um 20:31 schrieb Vijay Kumar Banerjee:<br>> ><br>> ><br>> ><br>> > On Tue, 19 Mar 2019 at 00:56, Vijay Kumar Banerjee<br>> > <<a href="mailto:vijaykumar9597@gmail.com" target="_blank">vijaykumar9597@gmail.com</a> <mailto:<a href="mailto:vijaykumar9597@gmail.com" target="_blank">vijaykumar9597@gmail.com</a>><br>> <mailto:<a href="mailto:vijaykumar9597@gmail.com" target="_blank">vijaykumar9597@gmail.com</a> <mailto:<a href="mailto:vijaykumar9597@gmail.com" target="_blank">vijaykumar9597@gmail.com</a>>>><br>> wrote:<br>> ><br>> ><br>> > Hi Christian,<br>> ><br>> > (it got sent by mistake :) )<br>> ><br>> > Thanks for telling about the script, now I have the code imported and<br>> > it's building successfully.<br>> > I have forked the repo and created a branch with my commits.<br>> Please have<br>> > a look and see if <br>> > It's going in the right direction. <br>> > <a href="https://github.com/thelunatic/rtems-libbsd/tree/hdmi_framer" rel="noreferrer" target="_blank">https://github.com/thelunatic/rtems-libbsd/tree/hdmi_framer</a> <br>> ><br>> > I have also wrote a first draft of the proposal. Are we supposed<br>> to send<br>> > the draft proposals only after the the application period stars?<br>> or can<br>> > we just share it offlist with the mentors now?<br>> ><br>> > Thanks <br>> <br>> Hello Vijay,<br>> <br>> first regarding the proposal:<br>> <br>> @Joel: Please correct me if I'm wrong!<br>> <br>> I think it should be OK to discuss the proposal as soon as you have<br>> something. I assume you already have completed the Hello world and sent<br>> it to at least one of our Org Admins?<br>> <br>> I have sent pictures in the offlist thread with Joel and you, where we<br>> were dicussing the<br>> hardwares. I can send again in an offlist thread, along with the<br>> proposal. :) <br>> <br>
<br>If Joel has them, it's OK.<br>
<br>> <br>> Regarding the code:<br>> <br>> Although the commits need some polishing (see * at the end) it looks<br>> like a good start that you were already able to import and compile some<br>> of the necessary files.<br>> <br>> From what I've seen, you currently pulled in three parts:<br>> <br>> 1. Some part of videomode. There are some awk scripts in that directory<br>> too so some generated files might need some processing.<br>> <br>> the ediddevs and modelines.c needed the scripts. I added them and<br>> imported, but <br>> there's a strange error with modelines.c <br>> (If I comment it out, it builds fine)<br>> =======<br>> ../../freebsd/sys/dev/videomode/modelines.c:13:19: error: expected<br>> declaration specifiers or '...' before string constant<br>> __KERNEL_RCSID(0, "$NetBSD$");<br>> =======<br>> <br>
<br>Most likely it's necessary to import them sooner or later. It will be<br>necessary to take a look at the original make process in FreeBSD and<br>duplicate the steps. For other awk scripts that's done in the Makefile.todo.<br>
<br>> <br>> 2. The iic headers. That looks good. An RTEMS implementation for the<br>> functions most likely is necessary.<br>> <br>> I have added this in the proposal. <br>
<br>Great.<br>
<br>> <br>> 3. The driver for the chip that converts from the LCD interface to an<br>> HDMI interface. That's good and necessary too.<br>> <br>> What is missing (which is entirely OK at the current phase) are the<br>> following parts:<br>> <br>> A. The LCD controller driver itself (am335x_lcd.c, ...).<br>> <br>> Added. Along with it, I had to import other fb codes that it depends on.<br>> I can push it in my<br>> forked branch for you to see. <br>> Since it has already seen some trial and errors. I think it would be<br>> better to create a new <br>> branch after we're happy with what's imported, then we can squash it all<br>> into a commit <br>> and then start the porting work to get two clean commits. <br>
<br>If you haven't forgotten the files everything is OK. It's totally OK to<br>do some trial and error to find out what's necessary. You can do a clean<br>version during the work phases.<br>
<br>> <br>> B. The driver isn't referenced anywhere (normally would be done in<br>> nexus-devices.h for devices that should be always there). So it isn't<br>> linked into the applications yet. That's the reason that you currently<br>> didn't get any `function not found` errors during the linking yet ;-)<br>> <br>> Is there any reference that I can follow to understand how the<br>> nexusmodule is working,<br>> and how to add the driver to it? I had a look into the libbsd.txt<br>
<br>I don't think that there is a real reference. libbsd is quite heavily<br>lacking documentation. The nexus-devices.h is more or less the file that<br>defines which drivers are linked to which BSP in the default<br>configuration for each application. If you have a look at the file you<br>will see (especially for BBB) a lot of lines like<br>
<br> SYSINIT_DRIVER_REFERENCE(usbss, simplebus);<br>
<br>or<br>
<br> SYSINIT_MODULE_REFERENCE(wlan_ccmp);<br>
<br>If you have a look at the corresponding sources of the drivers or<br>modules, you will see matching lines like<br>
<br> DRIVER_MODULE(usbss, simplebus, usbss_driver, usbss_devclass, 0, 0);<br>
<br>and<br>
<br> DECLARE_MODULE(...);<br> /* hidden behind IEEE80211_CRYPTO_MODULE(ccmp, 1)) */<br>
<br>Basically for your drivers you just have to add the<br>SYSINIT_DRIVER_REFERENCE lines. After that the drivers should be linked<br>in and the probe and attach is called during startup if a matching<br>device is in the flattend device tree.<br>
<br></blockquote><div>Hi,</div><div>I have pushed all the imported code in the forked branch. </div><div>I am seeing a lot of 'undefined reference' from iicbus after adding the driver, </div><div> I guess that's expected (?) as I have not yet added the the rtems-bsd* includes </div><div>to the files as suggested in the Contributing guide.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> <br>> C. The framebuffer interface of FreeBSD. I haven't had a detailed look<br>> at that yet. But someone has to do something with the fb_getinfo<br>> DEVMETHOD that is defined in am335x_lcd.c. I'm also not sure whether we<br>> have some generic framebuffer code in RTEMS or whether we should use it<br>> completely from libbsd.<br>> <br>> We have the fb.h and framebuffer.h headers. The RPi seems to have<br>> implemented those<br>> functions using own implementation using the mailbox module. <br>
<br>Yes, I have seen that they implement them. But I haven't found yet where<br>they are used. Sorry that I'm of little help here but I haven't had a<br>target with framebuffer yet. I expect that there must be some<br>applications using it ;-)<br>
<br>I think you should evaluate two possibilities here:<br>
<br>- Either add an adaption layer so that the RTEMS framebuffer interface<br>can be used (by whatever application).<br>
<br>- Or take a look at the FreeBSD framebuffer interface and think what<br>demo applications of FreeBSD could be used.<br>
<br>If you are awfully lucky, they are more or less compatible. In both<br>cases, I would say that some framebuffer console should be the target in<br>mind for this project.<br>
<br>If you are not that lucky applications have to be adapted to use the<br>RTEMS API (first solution). For the second way I think it is quite<br>possible that some FreeBSD applications or libraries can be compiled<br>without much changes. So the second one would be the one that I would<br>prefer.<br>
<br>But please have a look at the other boards with framebuffer and whether<br>you find some example applications. Maybe one of them has been a GSoC<br>project. In that case you might find a blog with some screenshots on one<br>of the old GSoC pages.<br>
<br></blockquote><div>The objective of this project is to have a framebuffer graphic console as the end product.</div><div>I had a look at the pc386 and RPi fb codes. The RPi has taken some code from the pc386</div><div>for the console_select.c, the font file and the outch.c that is used to display characters on </div><div>console. </div><div>I'm importing the hdmi framer driver and the am3355 along with a lot for framebuffer headers</div><div>including fbio and the the terminal header. This is confusing as there really seems to be two</div><div>possible ways to implement it. According to my understanding ...</div><div><br></div><div>what we need from freebsd :</div><div>* tda19988 driver for reading the cec nd edid blocks</div><div>* the edid headers and the c files to process the headers </div><div>* the videomode headers and source , which will be used by the tda dirver to </div><div>set videomode on basis of the edid info.</div><div>* The am335x_lcd dirver for configuring and setting the lcd display.</div><div><br></div><div>What we have in rtems (pc386/console/):</div><div>* The font_data header</div><div>* The console_select code</div><div>* The algorithm to print character on screen.</div><div>* The fb and framebuffer headers, with the declarations that will be used to write the</div><div>fb.c for the BSP. </div><div><br></div><div>I haven't had a detailed look at all of them and don't yet have a proper understanding of </div><div>how they'll connect together, this is just a rough outline. Does it make sense to you?</div><div><br></div><div>Also, we have graphics-toolkit in the rsb, what does it do? Is there something that can be</div><div>used in the process? </div><div><br></div><div>I found that the RPi framebuffer was a 2015 GSoC project by Yang Qiao. Couldn't find much</div><div>details in the blog. Do you think I should try reaching out to Yang and see if he wants to</div><div>help?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> <br>> So most likely you will find some more problems when the real work<br>> starts. But it would be no fun if everything would run smoothly ;-)<br>> <br>> Best regards<br>> <br>> Christian<br>> <br>> <br>> (*) See hints in CONTRIBUTING.md in chapter "How to Import Code from<br>> FreeBSD". The final commits should be (for each sensible module) one<br>> import commit where unchanged files are imported and one port commit<br>> where the files are added to libbsd.py and necessary changes are made.<br>> <br>> <br>> ><br>> ><br>> > On Sun, 17 Mar 2019 at 14:30, Christian Mauderer<br>> <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>> > <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>>> wrote:<br>> ><br>> > Am 16.03.19 um 23:52 schrieb Vijay Kumar Banerjee:<br>> > ><br>> > ><br>> > > On Sat, 16 Mar 2019 at 01:00, Christian Mauderer<br>> > <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>><br>> > > <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>>>> wrote:<br>> > ><br>> > > Am 15.03.19 um 19:20 schrieb Vijay Kumar Banerjee:<br>> > > ><br>> > > ><br>> > > > On Fri, 15 Mar 2019 at 21:47, Christian Mauderer<br>> > > <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>><br>> > <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>>><br>> > > > <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>><br>> > <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>>>>> wrote:<br>> > > ><br>> > > > Am 15.03.19 um 15:48 schrieb Vijay Kumar Banerjee:<br>> > > > > Hello, <br>> > > > ><br>> > > > > I am trying to `./waf install` the libbsd but<br>> > getting some<br>> > > error,<br>> > > > need help<br>> > > > > with that. The commands used and the errors are<br>> > given below ...<br>> > > > ><br>> > > > > configured using: `./waf configure<br>> > > --buildset=buildset/default.ini<br>> > > > > --prefix=$HOME/development/rtems/5<br>> --rtems-arch=arm`<br>> > > > ><br>> > > > > configure was successful.<br>> > > > ><br>> > > > > then : `./waf install`<br>> > > > ><br>> > > > > Error ...<br>> > > > > ================<br>> > > > > Build failed<br>> > > > > -> task in 'lex__nsyy' failed with exit<br>> status 1<br>> > (run with<br>> > > -v to<br>> > > > > display more information)<br>> > > > > -> task in 'yacc__nsyy' failed with exit<br>> status 1<br>> > (run with<br>> > > -v to<br>> > > > > display more information)<br>> > > > > -> task in 'lex_pcap' failed with exit status 1<br>> > (run with -v to<br>> > > > display<br>> > > > > more information)<br>> > > > > -> task in 'yacc_pcap' failed with exit<br>> status 1<br>> > (run with<br>> > > -v to<br>> > > > > display more information)<br>> > > > > -> task in 'objs01' failed with exit status 1<br>> > (run with -v<br>> > > to display<br>> > > > > more information)<br>> > > > > -> task in 'objs01' failed with exit status 1<br>> > (run with -v<br>> > > to display<br>> > > > > more information)<br>> > > > > -> task in 'yacc_pfctly' failed with exit<br>> status<br>> > 1 (run<br>> > > with -v to<br>> > > > > display more information)<br>> > > > ><br>> > > > > ================<br>> > > > ><br>> > > > > Thanks<br>> > > > > --vijay<br>> > > > ><br>> > > ><br>> > > > Hello Vijay,<br>> > > ><br>> > > > did you try to build before the install? I<br>> don't see<br>> > the call.<br>> > > > Normally it's<br>> > > ><br>> > > > waf configure ...<br>> > > > waf<br>> > > > waf install<br>> > > ><br>> > > > If you did that: It seems that some of the lex /<br>> > yacc files<br>> > > should be<br>> > > > regenerated. Did you enable --enable-auto-regen<br>> > somewhen during an<br>> > > > earlier configuration run (not necessary except if<br>> > you import<br>> > > yacc or<br>> > > > lex files)? Did you import some yacc or lex files?<br>> > > ><br>> > > > I had to install `byacc` package using yum in fedora,<br>> > then I used the<br>> > > > --enable-auto-regen<br>> > > > option, that worked. <br>> > > > However, it's still not building and I'm seeing a<br>> lot of<br>> > warnings, I<br>> > > > think this is because of the<br>> > > > files I imported from the freebsd source, maybe they<br>> > depend on some<br>> > > > other headers that <br>> > > > I didn't include. Any suggestion on how to debug, if<br>> > this is the<br>> > > case? <br>> > > ><br>> > > > Best regards<br>> > > ><br>> > > > Christian<br>> > > ><br>> > ><br>> > ><br>> > > Hello Vijay,<br>> > ><br>> > > normally you shouldn't need the --enable-auto-regen<br>> > option. It only<br>> > > changes a lot of files that you don't want to change.<br>> > Especially: If you<br>> > > use Fedora (or some other Linux) you get GPL licensed<br>> > output. We<br>> > > normally use FreeBSD for that step and check in the<br>> > generated files so<br>> > > that no user has to use --enable-auto-regen.<br>> > ><br>> > > Regarding how to start such a port: Normally it's a good<br>> > idea to get<br>> > > some overview over what's missing. For that you<br>> import the<br>> > files that<br>> > > you think are relevant (like you already did). Then you<br>> > can build with<br>> > > `waf -k -j1` which continues even if some files are not<br>> > compilable (-k<br>> > > is for continue, -j1 so that you receive the messages in<br>> > order). You<br>> > > should get a lot of compiler errors during that run.<br>> > ><br>> > > Now comes the hard part: You have to analyse the errors<br>> > and try to find<br>> > > out what's the reason for them. If some big part is<br>> > missing you most<br>> > > likely get a lot of similar errors (like "header<br>> xy.h not<br>> > found"). Most<br>> > > likely you can identify some groups. With that you can<br>> > estimate what has<br>> > > to be ported besides the files you already imported.<br>> > ><br>> > > Identifying these groups is a quite relevant step for<br>> > planning the<br>> > > amount of work for your GSoC proposal. If you are<br>> unsure,<br>> > try to ask on<br>> > > the mailing list. You can also post the build output and<br>> > an assumption<br>> > > what groups you estimate to get some feedback.<br>> > ><br>> > > Best regards<br>> > ><br>> > > Christian<br>> > ><br>> > ><br>> > > Hi<br>> > ><br>> > > I figured out that there were some unnecessary imports I was<br>> > doing and<br>> > > also some necessary<br>> > > header files that I'm missing, after adding those most<br>> of the<br>> > warnings<br>> > > vanished. The error I'm<br>> > > seeing now is due to a missing '.m' header file. The error<br>> > looks like<br>> > > this ...<br>> > > =========<br>> > > ../../freebsd/sys/arm/ti/am335x/tda19988.c:56:10:<br>> fatal error:<br>> > > rtems/bsd/local/iicbus_if.h: No such file or directory<br>> > > #include <rtems/bsd/local/iicbus_if.h><br>> > > =========<br>> > > There's an iicbus_if.m file in the freebsd source which is<br>> > being included as<br>> > > ``#include "iicbus_if.h"``<br>> > > How to work with the .m files ?<br>> > ><br>> > > Thanks <br>> ><br>> > Hello Vijay,<br>> ><br>> > that sounds like somewhere during the FreeBSD build process at<br>> > least the<br>> > .h file is generated out of the .m file. As far as I can tell,<br>> > most .m<br>> > files are processed with the makeobjops.awk script.<br>> ><br>> > That's something that isn't yet cleanly integrated into<br>> the waf<br>> > build<br>> > system yet. Instead there is a "Makefile.todo" in libbsd<br>> that is<br>> > used<br>> > for this cases. Most likely you can just add that .m file<br>> and call a<br>> > make on that target.<br>> ><br>> > Some background for the "Makefile.todo": Originally the libbsd<br>> > has been<br>> > build using one big Makefile. Due to the decision that RTEMS<br>> > should go<br>> > toward waf, most parts of that Makefile has been replaced. The<br>> > "Makefile.todo" is the part that is left and should be<br>> > integrated into<br>> > waf as soon as someone feels like doing it or finds<br>> someone who<br>> > funds<br>> > the the time.<br>> ><br>> > Regarding iicbus: Most likely that is an interfaces that<br>> needs a<br>> > translation layer so that the RTEMS i2c framework is used. So<br>> > importing<br>> > the header with the declarations is good and correct. But you<br>> > will need<br>> > to plan some time to implement the functions based on the<br>> RTEMS i2c<br>> > interface.<br>> ><br>> > Best regards<br>> ><br>> > Christian<br>> ><br>> <br>
<br>
</blockquote></div></div>