littleVGL now supports FreeBSD framebuffer
Christian Mauderer
list at c-mauderer.de
Sat Aug 17 16:45:02 UTC 2019
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. Do we want to build both the directories
> separately? Or do we
> want to create our own directoy and put both driver and other stuffs in it?
>
> 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?
> 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. 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?)
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.
>
> 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
>
More information about the devel
mailing list