Re: Build FreeBSD: FAILED 6/rtems-i386.bset on x86_64-freebsd12.0 (i386-rtems6-gcc-0f81292cb0a-newlib-d06517044-x86_64-freebsd12.0-1)

2019-08-26 Thread Joel Sherrill 
On Mon, Aug 26, 2019 at 1:30 AM Sebastian Huber
 wrote:
>
> Hello,
>
> this error was caused by and looks like a break introduced by the fenv.h
> changes:
>
> libtool: compile:
> /usr/home/user/rtems-source-builder/rtems/build/i386-rtems6-gcc-0f81292cb0a-newlib-d06517044-x86_64-freebsd12.0-1/build/./gcc/xgcc
> -
> B/usr/home/user/rtems-source-builder/rtems/build/i386-rtems6-gcc-0f81292cb0a-newlib-d06517044-x86_64-freebsd12.0-1/build/./gcc/
> -nostdinc -B/usr/home/u
> ser/rtems-source-builder/rtems/build/i386-rtems6-gcc-0f81292cb0a-newlib-d06517044-x86_64-freebsd12.0-1/build/i386-rtems6/newlib/
> -isystem /usr/home/use
> r/rtems-source-builder/rtems/build/i386-rtems6-gcc-0f81292cb0a-newlib-d06517044-x86_64-freebsd12.0-1/build/i386-rtems6/newlib/targ-include
> -isystem /us
> r/home/user/rtems-source-builder/rtems/build/i386-rtems6-gcc-0f81292cb0a-newlib-d06517044-x86_64-freebsd12.0-1/gnu-mirror-gcc-0f81292cb0a/newlib/libc/i
> nclude -B/usr/local/rtems/5/i386-rtems6/bin/
> -B/usr/local/rtems/5/i386-rtems6/lib/ -isystem
> /usr/local/rtems/5/i386-rtems6/include -isystem /usr/local/
> rtems/5/i386-rtems6/sys-include -DHAVE_CONFIG_H -I.
> -I../../../../gnu-mirror-gcc-0f81292cb0a/libquadmath -I
> ../../../../gnu-mirror-gcc-0f81292cb0a/libq
> uadmath/../include -g -O2 -mtune=i486 -MT math/acosq.lo -MD -MP -MF
> math/.deps/acosq.Tpo -c
> ../../../../gnu-mirror-gcc-0f81292cb0a/libquadmath/math/aco
> sq.c -o math/acosq.o
> In file included from
> ../../../../gnu-mirror-gcc-0f81292cb0a/libquadmath/math/x2y2m1q.c:19:
> ../../../../gnu-mirror-gcc-0f81292cb0a/libquadmath/math/x2y2m1q.c: In
> function '__quadmath_x2y2m1q':
> ../../../../gnu-mirror-gcc-0f81292cb0a/libquadmath/math/x2y2m1q.c:57:26:
> error: 'FE_TONEAREST' undeclared (first use in this function)
> 57 |   SET_RESTORE_ROUNDF128 (FE_TONEAREST);
>|  ^~~~
> ../../../../gnu-mirror-gcc-0f81292cb0a/libquadmath/quadmath-imp.h:318:35:
> note: in definition of macro 'SET_RESTORE_ROUNDF128'
>318 |   libc_feholdsetround_ctx (&ctx, (RM))
>|   ^~
> ../../../../gnu-mirror-gcc-0f81292cb0a/libquadmath/math/x2y2m1q.c:57:26:
> note: each undeclared identifier is reported only once for each function
> it ap
> pears in
> 57 |   SET_RESTORE_ROUNDF128 (FE_TONEAREST);
>|  ^~~~
> ../../../../gnu-mirror-gcc-0f81292cb0a/libquadmath/quadmath-imp.h:318:35:
> note: in definition of macro 'SET_RESTORE_ROUNDF128'
>318 |   libc_feholdsetround_ctx (&ctx, (RM))
>|   ^~

The code not compiling is incorrect per POSIX. The FE_TONEAREST constant should
not be defined if it is not supported by the implementation. This is
true for almost all
the constants provided by fenv.h

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/fenv.h.html

Alternatively, add an x86_64 implementation. Corinna suggested moving
the Cygwin implementations to newlib/libm so they could be used by all
targets. This one at least is just moving/porting software rather than
writing one from scratch.

--joel
> ___
> 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

Re: littleVGL now supports FreeBSD framebuffer

2019-08-26 Thread Vijay Kumar Banerjee 
On Mon, Aug 19, 2019 at 4:26 AM Chris Johns  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  >> > 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 < 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?
>

Re: LTTng sched_switch documentation patch.

2019-08-26 Thread Chris Johns 
On 26/8/19 8:16 pm, Ravindra Kumar Meena wrote:
> Hello Chris and Sebastian,
> 
> I have attached the updated LTTng sched_switch documentation patch(v4). This 
> one
> is a whole single patch.
> 
> *What changed v3 to v4:*
> Sebastian's patch for rtems-libbsd patch got merged today, So I have removed 
> my
> GitHub repo link from the documentation and updated it. There are some minor
> changes like whitespace fixes etc.
> 
> Please review the patch.

Steps [1-5] ... Why not use the REST list numbering rather than inventing
something? This is for 10.5.1 Trace Compass and 10.5.2.

10.5.1 Trace Compass

Step 1:

This is specific to QEMU and that leaves me wondering if this method of trace
works on all targets.

The language is not specific. For example "The host can be connected to target
via telnet." for what purpose and why? The documentation does not provide me
with any direction.

10.5.2 RTEMS LTTng Trace Generation Example

Step 1:

I think the language is too casual, for example ...

"Step 1: Clone the repositories rtems-libbsd and rtems-tools and set up the
environment, if haven’t done already."

This should reference the specific sections in the User manual that detail how
to do this.

Step 3:

Can the `Host` box be expanded to show how each of the other parts are 
connected?

Step 2:

I feel we should reference the rtems-run command to run these qemu sessions. If
there needs to be extra detail that handles the net connection then this should
be investigated and added to `rtems-run`.

Step 3:

This does not specify the host these command are to be used on. If this is Linux
are these command available on all distros? It is complicated to make a
cross-platform way to handle this but this is what needs to be solved for RTEMS.
I am not sure what is needed but I suspect we may need a tool in rtems-tools to
wrap the cross-platform ways of doing this.

Telnet is not available on MacOS any more. This has been discussed on this list
before. The issue is the User Manual is for all hosts and we need to consider
and cater for a new user who uses MacOS. There is no indication of why this is
needed to use this method of trace.

The reason I raise these things is a core developer would need to clean this up.

Step 4:

I raised using commands in the build before now. Please do not do this. A user
will not built the rtems-tool repo by hand and will not have a `build`
directory. The RSB will build and install the tools.

What is `raw-data`? There is no explanation of the types of data, where they
come from and what uses them.

Step 5:

Maybe it would be good to present more detail on what is needed to install Trace
Compass. This could be in the Trace Compass section. Has anyone promoting this
method of trace actually tried FreeBSD and solved how this is done? I hope this
is not being left to a FreeBSD user to sort out.

I followed the link and see MacOS, Linux, and Windows. Also I think the Add-On
link is too specific and maybe fragile. An RTEMS release will capture this link
and it needs to be around for a number of years.

Step 6:

I see no value in the screen capture. It is impossible to see any detail and
there is no context explaining any parts of interest. I can see what the tool
does on the Trace Compass website.

"Move the trace and metadata generated in common folder ..." ? What is this?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

LibBSD is not linking for the BBB BSP

2019-08-26 Thread Chris Johns 
Hi,

Libcurl is not building for the BBB using HEAD on master. The config.log
fragment with the failure is below. It looks like something to do with the frame
buffer changes ... `_bsd_fb_fb_modmodule_sys_init` ?

Thanks
Chris

configure:19546: checking for gethostbyname
configure:19546: arm-rtems5-gcc -o conftest -qrtems
-B/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-chris-staging/arm-rtems5/lib/
-B/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-chris-staging/arm-rtems5/beagleboneblack/lib/
--specs bsp_specs -mcpu=cortex-a8 -O2 -ffunction-sections -fdata-sections
-Werror-implicit-function-declaration -Wno-system-headers -isy
stem
/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-chris-staging/arm-rtems5/beagleboneblack/lib/include
-L/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-chris-staging/arm-rtems5/beagleboneblack/lib
-L/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-chris/ftp/curl/opt/work/cs/water/bbb/lib
conftest.c -lbsd -lm -lz -lrtemsdefaultconfig >&5
/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-chris-staging/bin/../lib/gcc/arm-rtems5/7.4.1/../../../../arm-rtems5/bin/ld:
/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-chris-staging/arm-rtems5/beagleboneblack/lib/libbsd.a(rtems-bsd-init-dhcp.c.18.o):/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/rtems-libbsd-vabbce3f757340930a737f1e8da529443
ce88e9c6-x86_64-freebsd12.0-1/rtems-libbsd-abbce3f757340930a737f1e8da529443ce88e9c6/build/arm-rtems5-beagleboneblack-default/../../rtemsbsd/include/bsp/nexus-devices.h:73:
undefined reference to `_bsd_fb_fb_modmodule_sys_init'
/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-chris-staging/bin/../lib/gcc/arm-rtems5/7.4.1/../../../../arm-rtems5/bin/ld:
/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/tmp/sb-chris-staging/arm-rtems5/beagleboneblack/lib/libbsd.a(rtems-bsd-init-dhcp.c.18.o):/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/rtems-libbsd-vabbce3f757340930a737f1e8da529443
ce88e9c6-x86_64-freebsd12.0-1/rtems-libbsd-abbce3f757340930a737f1e8da529443ce88e9c6/build/arm-rtems5-beagleboneblack-default/../../rtemsbsd/include/bsp/nexus-devices.h:74:
undefined reference to `_bsd_fb_modmodule_sys_init'
collect2: error: ld returned 1 exit status
configure:19546: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "curl"
| #define PACKAGE_TARNAME "curl"
| #define PACKAGE_VERSION "-"
| #define PACKAGE_STRING "curl -"
| #define PACKAGE_BUGREPORT "a suitable curl mailing list:
https://curl.haxx.se/mail/";
| #define PACKAGE_URL ""
| #define PACKAGE "curl"
| #define VERSION "-"
| #define OS "arm-unknown-rtems5"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define LT_OBJDIR ".libs/"
| #define HAVE_LDAP_SSL 1
| /* end confdefs.h.  */
|
| #define gethostbyname innocuous_gethostbyname
| #ifdef __STDC__
| # include 
| #else
| # include 
| #endif
| #undef gethostbyname
| #ifdef __cplusplus
| extern "C"
| #endif
| char gethostbyname ();
| #if defined __stub_gethostbyname || defined __stub___gethostbyname
| choke me
| #endif
|
| int main (void)
| {
| return gethostbyname ();
|  ;
|  return 0;
| }
configure:19546: result: no
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel