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