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