littleVGL now supports FreeBSD framebuffer

Vijay Kumar Banerjee vijaykumar9597 at gmail.com
Thu Aug 29 15:19:41 UTC 2019


Hello Chris,

I have written the scripts to build littlevgl using rtems_waf. The build
works fine
and installs the required header and the static library in the prefix
library path.

The repository is pushed here, please have a look:
https://github.com/thelunatic/littlevgl-rsb

Thanks,
Vijay


On Tue, Aug 27, 2019 at 1:19 AM Vijay Kumar Banerjee <
vijaykumar9597 at gmail.com> wrote:

>
>
> On Mon, Aug 19, 2019 at 4:26 AM Chris Johns <chrisj at rtems.org> wrote:
>
>> On 18/8/19 2:45 am, Christian Mauderer wrote:
>> > On 17/08/2019 18:05, Vijay Kumar Banerjee wrote:
>> >>
>> >>
>> >>
>> >> On Thu, Aug 15, 2019 at 3:46 AM Chris Johns <chrisj at rtems.org
>> >> <mailto:chrisj at rtems.org>> wrote:
>> >>
>> >>     On 15/8/19 2:07 am, Vijay Kumar Banerjee wrote:
>> >>     > I wrote a patch for lv_drivers repository to support FreeBSD
>> >>     framebuffer
>> >>     > in fbdev, which they merged to the master today.
>> >>
>> >>     Well done, that is great.
>> >>
>> >>     > I have tested
>> >>     > the driver to be working with an app that I wrote on FreeBSD and
>> >>     > tested it on Beaglebone black image 12-STABLE.
>> >>
>> >>     Awesome.
>> >>
>> >>     > I intend to write an RSB recipe to build littleVGL and seek some
>> >>     guidance
>> >>     > on how to proceed. :)
>> >>
>> >>     Please review
>> >>
>> https://docs.rtems.org/branches/master/user/rsb/third-party-packages.html
>> >>
>> >>     I suggest you see how the curl package is done. It is a nice clean
>> >>     example.
>> >>
>> >>     The packages are sort of based on the FreeBSD ports layout.
>> >>     Littlevgl is not a
>> >>     port so we can use `graphics/littlevgl`.
>> >>
>> >>     The file pattern used in the RSB for a 3rd party package is:
>> >>
>> >>     - A buildset or bset file, this is the top level wrapper for the
>> >>     config files
>> >>     and selects the version to be built...
>> >>
>> >>
>> https://git.rtems.org/rtems-source-builder/tree/rtems/config/ftp/curl.bset
>> >>
>> >>     - The version specific config file that sets the version and
>> >>     checksum for the
>> >>     package. It includes the build config or recipe...
>> >>
>> >>
>> https://git.rtems.org/rtems-source-builder/tree/rtems/config/ftp/curl-7.65.1-1.cfg
>> >>
>> >>     Note, this is a 3prd party package so includes `rtems-bsp.cfg`.
>> This
>> >>     create a
>> >>     suitable environment to build a package for a BSP.
>> >>
>> >>     - The build config file ...
>> >>
>> >>
>> https://git.rtems.org/rtems-source-builder/tree/source-builder/config/curl-1.cfg
>> >>
>> >> Hi,
>> >>
>> >> I have some doubts regarding the build.
>> >> The lvgl needs two directoried, lvgl (main) and lv_drivers (for the
>> >> driver). And on
>> >> top of both, there needs to be two header files to configure the
>> >> library, lvgl_conf.h
>> >> and lvgl_drv_conf.h . These conf headers are supposed to be edited by
>> >> the user
>> >> to set the options.
>>
>> Enable all the features. A user with tight memory needs will need to
>> customise
>> the config and so handle littlevgl themselves.
>>
>> > Do we want to build both the directories
>> >> separately?
>>
>> I think together. I have not tried to build the various hardware drivers
>> the
>> package provides. If a driver builds with RTEMS then I suggest we build
>> them. If
>> they need special config file settings it will be harder to do and I
>> suspect we
>> cannot build them.
>>
>> >> Or do we
>> >> want to create our own directoy and put both driver and other stuffs
>> in it?
>>
>> We may but that is something we look at later.
>>
>> >>
>> >> Also, lvgl doesn't have its own makefile, so we have to write our own.
>> in my
>> >> application, I included the .mk file in my app's makefile and added the
>> >> build recipe
>> >> for it. How do we want to handle this in RSB?
>>
>> I suggest we build the package using rtems_waf. It is the only clean way
>> we
>> currently have to get the needed BSP ABI build flags.
>>
>> Could a git repo be created where littlevgl and rtems_waf are submodules?
>>
>> Hi,
>
> Sorry for the late reply, I had to visit home and didn't get much time, so
> I decided
> to do it out of GSoC.
>
> I started the repo as you suggested and it's in the initial state. The
> repository is
> pushed in GitHub here:
> https://github.com/thelunatic/littlevgl-rsb .
>
> I'm starting to write the wscript for the repo by taking reference from
> your script below
> to get the file sources.
>
>> To get hold of the sources to build I am using a script that creates a
>> Makefile
>> that runs and outputs the list of source ...
>>
>> -----------
>> #! /bin/sh
>>
>> set -e
>> #set -x
>>
>> cd $(dirname $0)
>>
>> cleanup()
>> {
>>     rm -f Makefile.gen
>> }
>>
>> trap cleanup EXIT
>>
>> cat <<EOF > Makefile.gen
>> LVGL_DIR = \$(CURDIR)
>> include lvgl/lvgl.mk
>> include lv_drivers/lv_drivers.mk
>> CSRCS:
>>         @echo "\$(CSRCS)"
>> EOF
>>
>> excludes="R61581.c SSD1963.c ST7565.c UC1610.c FT5406EE8.c XPT2046.c"
>>
>> csrcs=$(make -f Makefile.gen CSRCS)
>> srcs=
>>
>> for c in ${csrcs}
>> do
>>     found=no
>>     for e in ${excludes}
>>     do
>>         if [ $c = $e ]; then
>>            found=yes
>>         fi
>>     done
>>     if [ $found != yes ]; then
>>         name=$(find . -name $c)
>>         srcs="${srcs} ${name}"
>>     fi
>> done
>>
>> #
>> # Add something to write littlevgl.py which can be imported in a
>> # wscript file
>> #
>> ------------
>>
>> >> If I create an lvgl tar with drivers and library in it, along with a
>> >> makefile, will it go
>> >> into our ftp server somewhere?  Can this be an approach to build the
>> >> whole stuff?
>> >
>> > Hm. Difficult case. We should also take into account that lvgl doesn't
>> > necessarily have to use the FreeBSD frame buffer but can use some other
>> > displays too. So what you do would be more a "lvgl-libbsd" packet.
>>
>> It can support any driver, the FB driver is just one. You can use the
>> same build
>> of the core, draw etc code with any other driver. The user needs to
>> register the
>> driver functions during initialisation so they can be the FreeBSD FB one
>> or
>> something else.
>>
>> In v6 the resolution is set at run time and the conf file are just
>> defaults.
>>
>> There is one issue, the path to the frame buffer is currently hard coded
>> in the
>> conf file and I would like to change that in littvlg so the path is
>> passed in. I
>> am not sure how this can be done without breaking the API. Maybe a new
>> call.
>>
>> Another change is to the memory allocator to not loop forever on an
>> error. It
>> would be nice to register a fault handler that is called.
>>
>> > If
>> > such a packet is created, it should most likely contain everything
>> > necessary: lvgl, lv_drivers and the config files (I hope they are not
>> > target specific but only display specific?)
>>
>> I suggest the configuration file enables all features present plus the
>> frame
>> buffer driver. I am not sure which input drivers to enable.
>>
>> > Regarding where to put files: RSB can use quite some sources. See
>> >
>> https://docs.rtems.org/branches/master/user/rsb/configuration.html#source-and-patches
>> >
>> > If the config and a Makefile can be put into a patch: It's also not
>> > uncommon to use patches from the mailing list like that:
>> >
>> > rtems/config/tools/rtems-gcc-7.2.0-newlib-2.5.0.20170922-1.cfg:31:%patch
>> > add gcc -p1
>> >
>> https://devel.rtems.org/raw-attachment/ticket/3242/gcc-sparc-ticket-3242-v2.patch
>> >
>> > I think Chris knows RSB a lot better than me. Maybe he has some better
>> > suggestions.
>>
>> A repo would be nice. We are discussing in another thread related to the
>> multiio
>> package if that stays as a separate repo and we grow the number we have
>> or do we
>> create a packages repo and collect it and this as separate pieces?
>>
>> Chris
>>
>> >
>> >>
>> >>     These configs do not include any other configs and could be used to
>> >>     build a
>> >>     native package for a host or a 3rd party package for RTEMS.
>> >>
>> >>     - The `%prep` section prepares the source to build. For github if
>> we are
>> >>     building from master we select a commit and fetch a compressed
>> >>     tarball. This
>> >>     means we can snapshot the source when making a release. The RSB
>> can work
>> >>     directly with the git repo however this has proven to be more
>> >>     fragile than a
>> >>     tarball.
>> >>
>> >>     - The `%build` section builds the package. The contents of this
>> file
>> >>     are used to
>> >>     create a shell script. Use --dry-run, --trace and --log to debug
>> what is
>> >>     happening. The shell script contents should be viewable in the log
>> >>     file if a dry
>> >>     run does not created it. There is a lot of trace but searching will
>> >>     help you
>> >>     locate the piece you are interested in. The `source_dir_*` shell
>> >>     variable is the
>> >>     directory created by extracting the tarfile. The macros
>> >>     `%{build_directory}` and
>> >>     `%{host_build_flags}` are defined in `defaults.mc
>> >>     <http://defaults.mc>` and should handle the
>> >>     compiler and flags. You may want to check libbsd is installed in
>> >>     your config,
>> >>     see ...
>> >>
>> >>
>> https://git.rtems.org/rtems-source-builder/tree/rtems/config/rtems-bsp.cfg#n198
>> >>
>> >>     .. for an example of how to check and add `%error This package
>> needs
>> >>     libbsd,
>> >>     please build and install` or something like that as an error. The
>> >>     paths to
>> >>     install to are set up for you, these match how a BSP and RTEMS are
>> >>     installed.
>> >>     The layout needs to be followed or applications will not be able to
>> >>     find the
>> >>     header or the library.
>> >>
>> >>     - The `%install` section installs the package. The install process
>> >>     is to a
>> >>     staging area `${SB_BUILD_ROOT}`. Nothing is installed unless all
>> >>     parts build so
>> >>     we do not have an inconsistent build in the install prefix.
>> >>
>> >>     Chris
>> >>
>> >>
>> >> _______________________________________________
>> >> devel mailing list
>> >> devel at rtems.org
>> >> http://lists.rtems.org/mailman/listinfo/devel
>> >>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190829/f0de6e3f/attachment-0002.html>


More information about the devel mailing list