rtems-libbsd build error
Christian Mauderer
list at c-mauderer.de
Thu Mar 21 16:51:13 UTC 2019
Am 21.03.19 um 15:36 schrieb Vijay Kumar Banerjee:
>
> On Wed, 20 Mar 2019 at 01:52, Christian Mauderer <list at c-mauderer.de
> <mailto: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>
> > <mailto: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>>
> > <mailto: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.
Part of it can be from not yet included headers. But I would more assume
that the iic system is missing. Like I said: That part will need an
translation layer so that the RTEMS drivers can be used.
>
> >
> > 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.
>
Sounds reasonable.
> 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.
If you use the fb and framebuffer headers from RTEMS, you will get an
RTEMS interface. The RTEMS based console code will work fine. But it
might would be the solution where more work is necessary to port other
applications or libraries. It seems that we have some libs already (like
nano-X: https://devel.rtems.org/wiki/GSoC/2009/Wrapup) so I would be OK
with that.
The other alternative would be to use the FreeBSD code that does the
same. I'm not sure whether they call it framebuffer or something else.
But I would expect that there is something similar. In that case it
might would be simpler to port graphics libraries that already work on
FreeBSD.
Both ways could be nice. I'm really not sure which one I would prefer.
The first one is better integrated into the existing RTEMS ecosystem.
The second one promises a wider world. So either take the one that
interests you more or just use the one that looks simpler ;-)
>
> 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?
>
The connection will be part of the work. But if you have the time, it
would be already a good idea to look at the interfaces.
> Also, we have graphics-toolkit in the rsb, what does it do? Is there
> something that can be
> used in the process?
>
No idea. Maybe it would be a good idea to try to contact Pavel Pisa if
you have some questions regarding the state of the libs in the RSB. It
seems he has been the last one who added libraries to
rtems/config/graphics in the RSB.
> 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?
Won't hurt to ask.
>
> >
> > 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>>
> > > <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 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>>>
> > > > <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 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>>>>
> > > > > <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 <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
> > >
> >
>
More information about the devel
mailing list