rtems-libbsd build error
Christian Mauderer
list at c-mauderer.de
Tue Mar 19 20:22:35 UTC 2019
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.
>
> 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.
>
> 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
> >
>
More information about the devel
mailing list