On Mon, Aug 19, 2019 at 4:26 AM Chris Johns <chr...@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 <chr...@rtems.org > >> <mailto:chr...@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@rtems.org > >> http://lists.rtems.org/mailman/listinfo/devel > >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
