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