Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu
This is an unusually long text for the mailing list. I tried to write a
kind
of tutorial using an example for a GSOC student. I'm looking forward to
the
comments from the pros and can write it down completely.
Hello, Mritunjay
if I understood it correctly, one idea of the rtems source builder is to
make existing
software packages usable for RTEMS. Most existing software packages do
not work without
changes in the RTEMS environment. You have already noticed this with
ptpd ;-)
The most common auto-tools and configure have trouble making the correct
assumptions for the rtems environment. Here you have to intervene. This
can
be done with the builder-cfg files.
This is a bit of hard work and you have to approach it with small steps.
You also have to use not so clean tricks in different places. When you
have
achieved the integration you can/must then try to optimize it so that it
becomes
generally valid.
That's my policy. Maybe the others here in the maillist have more ideas,
also for me.
I have now tried to implement what I mean using a similar example
(openntp).
Unfortunately, I haven't finished yet, but I hope to clear a few hurdles
for you.
I was doing some digging around and I came across this:
https://github.com/openntpd-portable/openntpd-portable
Here I was then confronted with the same problems as you with autoreconf
etc. Here it
didn't work, just run autoreconf twice and generate a tar-file for
installation like
I did with the ptpd from github.
Then I found this:
https://artfiles.org/openbsd/OpenNTPD/openntpd-6.2p3.tar.gz
Now I have made a "standard" config file for rsb:
#
# OpenNTPd 6.2p3 Version 1.
#
# This configuration file configure's, make's and install's OpenNTPd.
#
%if %{release} == %{nil}
%define release 1
%endif
Name: openntpd-%{openntpd_version}-%{_host}-%{release}
Summary: NTP is the Network Time Protocol.
Version: %{openntpd_version}
Release: %{release}
URL: https://github.com/openntpd-portable
#
# NTP Source
#
%source set openntpd
https://artfiles.org/openbsd/OpenNTPD/openntpd-%{openntpd_version}.tar.gz
%hash sha512 openntpd-%{openntpd_version}.tar.gz
56a04bfd8b161b365607673ac80086ff53ae943938fa49bf52edbc541432eca30730a46a4af581fe26ce3bbceb144cb25982a38959b7a3f9304c727fe60f9
f50
#
# Prepare the source code.
#
%prep
build_top=$(pwd)
source_dir_openntpd="openntpd-%{openntpd_version}"
%source setup openntpd -q -n openntpd-%{openntpd_version}
%patch setup openntpd -p1
cd ${build_top}
%build
build_top=$(pwd)
%{build_directory}
mkdir -p ${build_dir}
cd ${build_dir}
%{host_build_flags}
../${source_dir_openntpd}/configure \
--host=%{_host} \
--prefix=%{_prefix} \
--bindir=%{_bindir} \
--exec_prefix=%{_exec_prefix} \
--includedir=%{_includedir} \
--libdir=%{_libdir} \
--libexecdir=%{_libexecdir} \
--mandir=%{_mandir} \
--infodir=%{_infodir} \
--datadir=%{_datadir} \
--disable-shared \
--enable-static \
--with-gnu-ld \
--disable-https-constraint
%{__make} all
cd ${build_top}
%install
build_top=$(pwd)
%{__rmdir} $SB_BUILD_ROOT
cd ${build_dir}
%{__make} DESTDIR=$SB_BUILD_ROOT install
cd ${build_top}
Then I "executed" that.
[h1@earth rtems (master *)]$ ../source-builder/sb-set-builder --log
log.ntpd.txt --with-rtems-bsp=xilinx_zynq_a9_qemu --host=arm-rtems5
--prefix /home/h1/GSOC/RTEMS/5.0.0-m20
03 net/ntpd
RTEMS Source Builder - Set Builder, 5 (26e335ca159e modified)
Build Set: net/ntpd
config: net/openntpd-6.2p3-1.cfg
package: openntpd-6.2p3-arm-rtems5-1
building: openntpd-6.2p3-arm-rtems5-1
error: building openntpd-6.2p3-arm-rtems5-1
Build FAILED
See error report: rsb-report-openntpd-6.2p3-arm-rtems5-1.txt
error: building openntpd-6.2p3-arm-rtems5-1
Build Set: Time 0:00:16.036623
Build FAILED
Error! I looked at that one:
[h1@earth rtems (master *)]$ tail -20
rsb-report-openntpd-6.2p3-arm-rtems5-1.txt
CC setproctitle.lo
CC bsd-setresgid.lo
CC bsd-setresuid.lo
CCLD libcompat.la
arm-rtems5-ar: `u' modifier ignored since `D' is the default (see `U')
CCLD libcompatnoopt.la
arm-rtems5-ar: `u' modifier ignored since `D' is the default (see `U')
make[1]: Leaving directory
'/home/h1/GSOC/RTEMS_DEV/rtems-source-builder/rtems/build/openntpd-6.2p3-arm-rtems5-1/build-cxc/compat'
Making all in src
make[1]: Entering directory
'/home/h1/GSOC/RTEMS_DEV/rtems-source-builder/rtems/build/openntpd-6.2p3-arm-rtems5-1/build-cxc/src'
CC ntpd-client.o
arm-rtems5-gcc: fatal error:
/home/h1/GSOC/RTEMS/5.0.0-m2003/arm-rtems5/xilinx_zynq_a9_qemu/lib/bsp_specs:
attempt to rename spec 'endfile' to already defined spec 'old_endfi
le'
compilation terminated.
Makefile:526: recipe for target 'ntpd-client.o' failed
make[1]: *** [ntpd-client.o] Error 1
make[1]: Leaving directory
'/home/h1/GSOC/RTEMS_DEV/rtems-source-builder/rtems/build/openntpd-6.2p3-arm-rtems5-1/build-cxc/src'
Makefile:401: recipe for target
Re: [PATCH v3] updates #3889, Added test for timer_create() using CLOCK_MONOTONIC
Thanks for the patch. Sorry this slipped through for so long without such simple feedback. First, there is a ticket for this: https://devel.rtems.org/ticket/3889 which should be referenced. Second, although the ticket just mentions timer_create, the capabilities (e.g. user use case) not exercised is that the created timer works correctly and is actually based on CLOCK_MONOTONIC. There are existing tests for CLOCK_REALTIME which should be a good basis for what positive functionality is expected of a timer based on CLOCK_MONOTONIC. --joel On Sun, Apr 19, 2020 at 1:30 PM Eshan dhawan wrote: > >I will create a timer using timer_create() function, > and passing CLOCK_MONOTONIC in clock_id argument. > > >The test will fail as there is no support for > CLOCK_MONOTONIC in cpukit/posix/src/psxtimercreate.c. > > >The added code compiles successfully without any errors. > > Signed-off-by: Eshan dhawan > --- > testsuites/psxtests/psxtimer02/psxtimer.c | 8 ++-- > testsuites/psxtests/psxtimer02/psxtimer02.scn | 3 ++- > 2 files changed, 8 insertions(+), 3 deletions(-) > > diff --git a/testsuites/psxtests/psxtimer02/psxtimer.c > b/testsuites/psxtests/psxtimer02/psxtimer.c > index 9f79d33c42..e071f98857 100644 > --- a/testsuites/psxtests/psxtimer02/psxtimer.c > +++ b/testsuites/psxtests/psxtimer02/psxtimer.c > @@ -62,9 +62,9 @@ void *POSIX_Init ( >status = timer_create( CLOCK_REALTIME, , NULL ); >fatal_posix_service_status_errno( status, EINVAL, "bad timer id" ); > > - puts( "timer_create - OK" ); > + puts( "timer_create (CLOCK_REALTIME) - OK" ); >status = timer_create( CLOCK_REALTIME, NULL, ); > - posix_service_failed( status, "timer_create OK" ); > + posix_service_failed( status, "timer_create (CLOCK_REALTIME)" ); > >puts( "timer_create - too many - EAGAIN" ); >status = timer_create( CLOCK_REALTIME, NULL, ); > @@ -127,6 +127,10 @@ void *POSIX_Init ( >status = timer_delete( timer ); >fatal_posix_service_status_errno( status, EINVAL, "bad id" ); > > + puts( "timer_create (CLOCK_MONOTONIC) - OK" ); > + status = timer_create( CLOCK_MONOTONIC, NULL, ); > + posix_service_failed( status, "timer_create (CLOCK_MONOTONIC)" ); > + >TEST_END(); >rtems_test_exit (0); > } > diff --git a/testsuites/psxtests/psxtimer02/psxtimer02.scn > b/testsuites/psxtests/psxtimer02/psxtimer02.scn > index e78425a32e..7429bcf291 100644 > --- a/testsuites/psxtests/psxtimer02/psxtimer02.scn > +++ b/testsuites/psxtests/psxtimer02/psxtimer02.scn > @@ -1,7 +1,7 @@ > *** POSIX Timers Test 02 *** > timer_create - bad clock id - EINVAL > timer_create - bad timer id pointer - EINVAL > -timer_create - OK > +timer_create (CLOCK_REALTIME) - OK > timer_create - too many - EAGAIN > timer_delete - bad id - EINVAL > timer_getoverrun - bad id - EINVAL > @@ -13,4 +13,5 @@ timer_settime - bad itimer value - negative nanosecond - > EINVAL > timer_settime - bad clock value - EINVAL > timer_delete - OK > timer_delete - bad id - EINVAL > +timer_create (CLOCK_MONOTONIC) - OK > *** END OF POSIX Timers Test 02 *** > -- > 2.17.1 > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v12] tests for fenv.h functions
Tested on leon3. Pushed.
Thanks.
--joel
On Mon, Apr 20, 2020 at 1:22 PM Eshan dhawan
wrote:
> added tests for fesetexeptflag(), fegetexeptflag(),
> fegetround(), fesetround().
>
> In the test fegetround() does not return any flag
> other then FE_TONEAREST in tests.
> This is probably due to soft float.
>
> The test complies successfully and returns assert
> at fegetround()
>
> Other tests run without any errors
> tested on RISCV/rv32imac
>
> The test prints nothing if runs successfully.
>
> updates #2971
>
> Signed-off-by: Eshan dhawan
> ---
> testsuites/psxtests/psxfenv01/init.c| 92 -
> testsuites/psxtests/psxfenv01/psxfenv01.doc | 9 +-
> testsuites/psxtests/psxfenv01/psxfenv01.scn | 4 -
> 3 files changed, 78 insertions(+), 27 deletions(-)
>
> diff --git a/testsuites/psxtests/psxfenv01/init.c
> b/testsuites/psxtests/psxfenv01/init.c
> index cdb0fa596e..766b9de581 100644
> --- a/testsuites/psxtests/psxfenv01/init.c
> +++ b/testsuites/psxtests/psxfenv01/init.c
> @@ -6,6 +6,7 @@
> /*
> * SPDX-License-Identifier: BSD-2-Clause
> *
> + * Copyright (C) 2020 Eshan Dhawan
> * Copyright (C) 2019 Vaibhav Gupta
> *
> * Redistribution and use in source and binary forms, with or without
> @@ -46,11 +47,12 @@
> #include
> #include
> #include
> +#include
>
> const char rtems_test_name[] = "PSXFENV 01";
>
> /* forward declarations to avoid warnings */
> -rtems_task Init(rtems_task_argument ignored);
> +rtems_task Init( rtems_task_argument ignored );
>
> /* Test Function Begins */
> rtems_task Init(rtems_task_argument ignored)
> @@ -62,42 +64,92 @@ rtems_task Init(rtems_task_argument ignored)
>
>/*
> * 'FE_ALL_EXCEPT' will be defined only when 'feclearexcept()',
> - * 'fegetexceptflag()', 'feraiseexcept()', 'fesetexceptflag()' and
> - * 'fetestexcept()' functions are supported by the architecture.
> + * fegetexceptflag() , feraiseexcept(), fesetexceptflag() and
> + * fetestexcept() functions are supported by the architecture.
> * Hence their testcases can be wrapped under #ifdef and #endif.
> */
>#ifdef FE_ALL_EXCEPT /* floating-point exceptions */
> -puts( "fesetenv(FE_DFL_ENV)." );
> -r = fesetenv(FE_DFL_ENV);
> -if (r)
> - printf("fesetenv ==> %d\n", r);
> +r = fesetenv( FE_DFL_ENV );
> +if ( r ) {
> + printf( "fesetenv ==> %d\n", r);
> +}
> rtems_test_assert( r == 0 );
>
> -/* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
> -puts( "feclearexcept(FE_ALL_EXCEPT)." );
> -r = feclearexcept(FE_ALL_EXCEPT);
> -if (r)
> - printf("feclearexcept ==> 0x%x\n", r);
> +/* Test feclearexcept() and fetestexcept() in one go. */
> +r = feclearexcept( FE_ALL_EXCEPT );
> +if ( r ) {
> + printf( "feclearexcept ==> 0x%x\n", r );
> +}
> rtems_test_assert( r == 0 );
>
> r = fetestexcept( FE_ALL_EXCEPT );
> -if (r)
> - printf("fetestexcept ==> 0x%x\n", r);
> +if ( r ) {
> + printf( "fetestexcept ==> 0x%x\n", r );
> +}
> rtems_test_assert( r == 0 );
>
> -/* Test 'FE_DIVBYZERO' */
> -puts( "Divide by zero and confirm fetestexcept()" );
> +/* Test 'FE_DIVBYZERO'
> + * Divide by zero and confirm fetestexcept() */
> a = 0.0;
> b = 1.0;
> c = b/a;
> (void) c;
> +/* Test fegetexceptflag() and fesetexceptflag() */
> +r = fegetexceptflag( , FE_ALL_EXCEPT );
> +if ( r ) {
> + printf( "fegetexceptflag ==> 0x%x\n", r );
> +}
> +rtems_test_assert( r == 0 );
>
> -fegetexceptflag(,FE_ALL_EXCEPT);
> +r = fesetexceptflag( , FE_ALL_EXCEPT );
> +if ( r ) {
> + printf( "fesetexceptflag ==> 0x%x\n", r );
> +}
> +rtems_test_assert( r == 0 );
>
> -#ifdef FE_DIVBYZERO
> -r = feraiseexcept(FE_DIVBYZERO);
> +/* Test for fegetround() and fesetround()
> + * They have four main macros to be tested separated by ifdef
> + * Since not all architectures support them
> + * The test case gets and sets the rounding directions */
> + #ifdef FE_TONEAREST /* Rounding direction TONEAREST */
> +rtems_test_assert( fegetround() == FE_TONEAREST );
> + #endif /*rounding direction TONEAREST */
> + #ifdef FE_TOWARDZERO /* rounding direction TOWARDZERO */
> +r = fesetround( FE_TOWARDZERO );
> +if ( r ) {
> + printf( "fesetround ==> 0x%x\n", r );
> +}
> +rtems_test_assert( r == 0 );
> +rtems_test_assert( fegetround() == FE_TOWARDZERO );
> + #endif/*rounding direction TOWARDZERO */
> + #ifdef FE_DOWNWARD /* rounding direction DOWNWARD */
> +r = fesetround( FE_DOWNWARD );
> +if ( r ) {
> + printf( "fesetround ==> 0x%x\n", r );
> +}
> +rtems_test_assert( r == 0 );
> +rtems_test_assert( fegetround() == FE_DOWNWARD );
> + #endif /* rounding direction DOWNWARD */
> + #ifdef FE_UPWARD /* rounding direction UPWARD */
> +r = fesetround( FE_UPWARD );
> +if ( r ) {
> + printf( "fesetround ==> 0x%x\n", r );
>
Re: Need help in figuring out how a scheduler is assigned to a task
On Sat, Jun 6, 2020 at 7:22 AM Richi Dubey wrote:
>
> Hii everyone,
>
> I was going through the code testsuites/sptests/spsimplesched01/init.c
> and there is only one mention of simple scheduler :
>
> #define CONFIGURE_SCHEDULER_SIMPLE
>
> and on checking the meaning of this preprocessor directive from
> scheduler.h , The relevant code is:
>
> #ifdef CONFIGURE_SCHEDULER_SIMPLE
> #include
>
> #define SCHEDULER_SIMPLE_CONTEXT_NAME( name ) \
> SCHEDULER_CONTEXT_NAME( simple_ ## name )
>
> #define RTEMS_SCHEDULER_SIMPLE( name ) \
> static Scheduler_simple_Context \
> SCHEDULER_SIMPLE_CONTEXT_NAME( name )
>
> #define RTEMS_SCHEDULER_TABLE_SIMPLE( name, obj_name ) \
> { \
> _SIMPLE_CONTEXT_NAME( name ).Base, \
> SCHEDULER_SIMPLE_ENTRY_POINTS, \
> SCHEDULER_SIMPLE_MAXIMUM_PRIORITY, \
> ( obj_name ) \
> SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( true ) \
> }
>
> /* Provided for backward compatibility */
>
> #define RTEMS_SCHEDULER_CONTEXT_SIMPLE( name ) \
> RTEMS_SCHEDULER_SIMPLE( name )
>
> #define RTEMS_SCHEDULER_CONTROL_SIMPLE( name, obj_name ) \
> RTEMS_SCHEDULER_TABLE_SIMPLE( name, obj_name )
> #endif
>
> And that's it! How does the task get assigned to this scheduler when we write
>
> status = rtems_task_create(
> Task_name[ 1 ], 1, RTEMS_MINIMUM_STACK_SIZE * 2, RTEMS_DEFAULT_MODES,
> RTEMS_DEFAULT_ATTRIBUTES, _id[ 1 ]
> );
>
> in init.c? How can we not use the _Scheduler_simple_Initialize anywhere?
>
What you are trying to do is unsupported in uniprocessor mode. It is
not allowed to share the same core by more than scheduler. Cores are
mutually exclusive resources owned by schedulers. A user separately
binds tasks to schedulers by using cpu affinity.
Maybe this needs to be mentioned in
https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#
somewhere. You should be able to get to understand it by reading the
configuration documentation in the Classic API Manual Chapter 24.18
and 24.19, starting at
https://docs.rtems.org/branches/master/c-user/config/scheduler-general.html
>
>
> Another small doubt that I had was about the linking of different .c
> files corresponding to simplescheduler.
> For Ex:
> One of the files is src/rtems/cpukit/score/src/schedulersimpleyield.c
> and other is
> src/rtems/cpukit/score/src/schedulersimpleblock.c
>
> and both of them are defining the functions listed in
> include/rtems/score/schedulersimpleimpl.h but I could not find any
> code anywhere linking these two files with this. Can someone please
> help me find the code that links all the files related to
> schedulersimple.c together?
>
You mean like compiler linking? Maybe this helps:
https://docs.rtems.org/branches/master/user/exe/executables.html#rtems-executable
The build system makes them both part of the same intermediate object
code file. Have a look at cpukit/Makefile.am currently as we still use
the autotools to make this happen.
If you mean something else, please clarify.
Gedare
> Thanks,
> Richi.
> ___
> 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
Need help in figuring out how a scheduler is assigned to a task
Hii everyone,
I was going through the code testsuites/sptests/spsimplesched01/init.c
and there is only one mention of simple scheduler :
#define CONFIGURE_SCHEDULER_SIMPLE
and on checking the meaning of this preprocessor directive from
scheduler.h , The relevant code is:
#ifdef CONFIGURE_SCHEDULER_SIMPLE
#include
#define SCHEDULER_SIMPLE_CONTEXT_NAME( name ) \
SCHEDULER_CONTEXT_NAME( simple_ ## name )
#define RTEMS_SCHEDULER_SIMPLE( name ) \
static Scheduler_simple_Context \
SCHEDULER_SIMPLE_CONTEXT_NAME( name )
#define RTEMS_SCHEDULER_TABLE_SIMPLE( name, obj_name ) \
{ \
_SIMPLE_CONTEXT_NAME( name ).Base, \
SCHEDULER_SIMPLE_ENTRY_POINTS, \
SCHEDULER_SIMPLE_MAXIMUM_PRIORITY, \
( obj_name ) \
SCHEDULER_CONTROL_IS_NON_PREEMPT_MODE_SUPPORTED( true ) \
}
/* Provided for backward compatibility */
#define RTEMS_SCHEDULER_CONTEXT_SIMPLE( name ) \
RTEMS_SCHEDULER_SIMPLE( name )
#define RTEMS_SCHEDULER_CONTROL_SIMPLE( name, obj_name ) \
RTEMS_SCHEDULER_TABLE_SIMPLE( name, obj_name )
#endif
And that's it! How does the task get assigned to this scheduler when we write
status = rtems_task_create(
Task_name[ 1 ], 1, RTEMS_MINIMUM_STACK_SIZE * 2, RTEMS_DEFAULT_MODES,
RTEMS_DEFAULT_ATTRIBUTES, _id[ 1 ]
);
in init.c? How can we not use the _Scheduler_simple_Initialize anywhere?
Another small doubt that I had was about the linking of different .c
files corresponding to simplescheduler.
For Ex:
One of the files is src/rtems/cpukit/score/src/schedulersimpleyield.c
and other is
src/rtems/cpukit/score/src/schedulersimpleblock.c
and both of them are defining the functions listed in
include/rtems/score/schedulersimpleimpl.h but I could not find any
code anywhere linking these two files with this. Can someone please
help me find the code that links all the files related to
schedulersimple.c together?
Thanks,
Richi.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/2] Adding strong and weak definitions
Hii, Thanks for your review. > The glossary is generated from specification items: > > https://git.rtems.org/sebh/rtems-qual.git/tree/spec/glos/term > > I will work on a documentation how this works in the next days. Have you already submitted one? If yes, could you please send me the link to it. If no, Do I need to wait and learn that before sending in the new patch? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 4/5] libfreebsd: Port OFW to RTEMS
On 04/06/2020 19:43, G S Niteesh Babu wrote:
> The following files have been ported to RTEMS
> 1) openfirm.h
> 2) openfirm.c
> 3) ofw_fdt.c
> ---
> cpukit/libfreebsd/dev/ofw/ofw_fdt.c | 117 ++-
> cpukit/libfreebsd/dev/ofw/openfirm.c | 59 +-
> cpukit/libfreebsd/dev/ofw/openfirm.h | 18 +
> 3 files changed, 191 insertions(+), 3 deletions(-)
>
> diff --git a/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> b/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> index e4f72e8142..5341440789 100644
> --- a/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> +++ b/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> @@ -29,10 +29,13 @@
> * SUCH DAMAGE.
> */
>
> +#ifndef __rtems__
> #include
> __FBSDID("$FreeBSD$");
> +#endif /* __rtems__ */
>
> #include
> +#ifndef __rtems__
> #include
> #include
> #include
> @@ -45,9 +48,18 @@ __FBSDID("$FreeBSD$");
> #include
> #include
> #include
> +#endif /* __rtems__ */
>
> #include "ofw_if.h"
> -
I'm not really happy about lines starting with "-" in the porting
commits. I think we should apply the same rules like in libbsd: Only add
stuff. Exception: The one at the end of the file is OK (where git tells
you "\ No newline at end of file"). You can't really avoid that.
> +#ifdef __rtems__
> +#include
> +#include
> +#include
> +#include
> +#include "openfirm.h"
> +#endif /* __rtems__ */
> +
> +#ifndef __rtems__
> #ifdef DEBUG
> #define debugf(fmt, args...) do { printf("%s(): ", __func__);\
> printf(fmt,##args); } while (0)
> @@ -63,6 +75,7 @@ __FBSDID("$FreeBSD$");
> #define FDT_MARVELL
> #endif
> #endif
> +#endif /* __rtems__ */
>
> static int ofw_fdt_init(ofw_t, void *);
> static phandle_t ofw_fdt_peer(ofw_t, phandle_t);
> @@ -78,6 +91,7 @@ static ssize_t ofw_fdt_canon(ofw_t, const char *, char *,
> size_t);
> static phandle_t ofw_fdt_finddevice(ofw_t, const char *);
> static ssize_t ofw_fdt_instance_to_path(ofw_t, ihandle_t, char *, size_t);
> static ssize_t ofw_fdt_package_to_path(ofw_t, phandle_t, char *, size_t);
> +#ifndef __rtems__
> static int ofw_fdt_interpret(ofw_t, const char *, int, cell_t *);
>
> static ofw_method_t ofw_fdt_methods[] = {
> @@ -104,9 +118,11 @@ static ofw_def_t ofw_fdt = {
> 0
> };
> OFW_DEF(ofw_fdt);
> +#endif /* __rtems__ */
>
> static void *fdtp = NULL;
>
> +#ifndef __rtems__
> static int
> sysctl_handle_dtb(SYSCTL_HANDLER_ARGS)
> {
> @@ -127,6 +143,24 @@ sysctl_register_fdt_oid(void *arg)
> sysctl_handle_dtb, "", "Device Tree Blob");
> }
> SYSINIT(dtb_oid, SI_SUB_KMEM, SI_ORDER_ANY, sysctl_register_fdt_oid, NULL);
> +#else /* __rtems__ */
> +const void* bsp_fdt_get(void);
> +static void
> +ofw_init(void)
> +{
> + int rv;
> + const void *fdt;
> +
> + fdt = bsp_fdt_get();
> + rv = ofw_fdt_init(NULL, fdt);
> + assert(rv == 0);
Is assert really the only error handling possible here? Asserts are
allways a bit difficult because they stop the entire system. In which
cases would it hit?
> +}
> +RTEMS_SYSINIT_ITEM(
> + ofw_init,
> + RTEMS_SYSINIT_BSP_START,
> + RTEMS_SYSINIT_ORDER_FIRST
> +);
> +#endif /* __rtems__ */
>
> static int
> ofw_fdt_init(ofw_t ofw, void *data)
> @@ -297,7 +331,11 @@ ofw_fdt_getprop(ofw_t ofw, phandle_t package, const char
> *propname, void *buf,
> if (prop == NULL)
> return (-1);
>
> +#ifndef __rtems__
> bcopy(prop, buf, min(len, buflen));
> +#else /* __rtems__ */
> + memcpy(buf, prop, MIN(len, buflen));
> +#endif /* __rtems__ */
>
> return (len);
> }
> @@ -407,6 +445,7 @@ ofw_fdt_package_to_path(ofw_t ofw, phandle_t package,
> char *buf, size_t len)
> return (-1);
> }
>
> +#ifndef __rtems__
> #if defined(FDT_MARVELL)
> static int
> ofw_fdt_fixup(ofw_t ofw)
> @@ -476,4 +515,78 @@ ofw_fdt_interpret(ofw_t ofw, const char *cmd, int nret,
> cell_t *retvals)
> #else
> return (0);
> #endif
> -}
> \ No newline at end of file
> +}
> +#endif /* __rtems__ */
> +
> +#ifdef __rtems__
> +int OFW_INIT(ofw_t ofw_obj, void *cookie)
Again: Please use FreeBSD style. The return value should be on it's onw
line during the definition (not during declaration).
> +{
There should be one empty line if you have no local variables (I'm not
really consequent here too).
> + return ofw_fdt_init(ofw_obj, cookie);
And brackets around everything that is returned.
> +}
> +
> +phandle_t OFW_PEER(ofw_t ofw_obj, phandle_t node)
> +{
> + return ofw_fdt_peer(ofw_obj, node);
> +}
> +
> +phandle_t OFW_CHILD(ofw_t ofw_obj, phandle_t node)
> +{
> + return ofw_fdt_child(ofw_obj, node);
> +}
> +
> +phandle_t OFW_PARENT(ofw_t ofw_obj, phandle_t node)
> +{
> + return ofw_fdt_parent(ofw_obj, node);
> +}
> +
> +phandle_t OFW_INSTANCE_TO_PACKAGE(ofw_t ofw_obj, ihandle_t instance)
> +{
> + return ofw_fdt_instance_to_package(ofw_obj, instance);
> +}
> +
> +ssize_t OFW_GETPROPLEN(ofw_t ofw_obj, phandle_t package, const char
> *propname)
> +{
> + return
Re: [PATCH 3/5] libfreebsd: FreeBSD porting helper header
On 04/06/2020 19:43, G S Niteesh Babu wrote: > This file serve the purpose as rtems-bsd-kernel-space.h in the > rtems-libbsd. > This file is intended to be included in every source file that > is to imported from FreeBSD. This is to reduce the number of > redefinitions for commonly used functions like malloc, free > and KASSERT. > --- > cpukit/libfreebsd/rtems-freebsd-helper.h | 45 > 1 file changed, 45 insertions(+) > create mode 100644 cpukit/libfreebsd/rtems-freebsd-helper.h > > diff --git a/cpukit/libfreebsd/rtems-freebsd-helper.h > b/cpukit/libfreebsd/rtems-freebsd-helper.h How do you plan to include it? Currently you would need a #include "../../../rtems-freebsd-helper.h" right? Can become a bit hard to count the .. with a deep directory tree. > new file mode 100644 > index 00..1b9b7609f9 > --- /dev/null > +++ b/cpukit/libfreebsd/rtems-freebsd-helper.h > @@ -0,0 +1,45 @@ > + > +/* SPDX-License-Identifier: BSD-2-Clause > + > + * > + * @file > + * > + * @ingroup LIBFREEBSD You have a group LIBFREEBSD here. Earlier you had a LIBFREEBSDOFW. Do you really want multiple groups? I would suggest to start with one for the new libfreebsd subsystem. > + * > + * @brief > + */ > + > +/* > + * Copyright (C) <2020> Niteesh Babu > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + *notice, this list of conditions and the following disclaimer. > + * 2. Redistributions in binary form must reproduce the above copyright > + *notice, this list of conditions and the following disclaimer in the > + *documentation and/or other materials provided with the distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS > IS" > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE > + * POSSIBILITY OF SUCH DAMAGE. > + */ > + > +#ifndef _LIBFREEBSD_RTEMS_FREEBSD_HELPER_H > +#define _LIBFREEBSD_RTEMS_FREEBSD_HELPER_H > + > +#define _KERNEL 1 > +#define KASSERT(cnd, msg)assert(cnd) > +#define malloc(size, type, flags)malloc(size) > +#define free(addr, type) free(addr) The tabs between the define name and the value seem a bit random here. Please try to use FreeBSD style (I really hope I don't start a discussion now whether we should use RTEMS style instead for new files). https://www.freebsd.org/cgi/man.cgi?query=style=0=9 If it's not clear there: Take a look at some FreeBSD files. > + > +#endif /* _LIBFREEBSD_RTEMS_FREEBSD_HELPER_H */ > \ No newline at end of file > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/5] libfreebsd: Added ofw_if.h
Some style comments: On 04/06/2020 19:43, G S Niteesh Babu wrote: > This file is the RTEMS implementation of ofw_if.h in FreeBSD. The > ofw_if.h in FreeBSD is an autogenerated header file that maps the > OF_function calls to their respective implementation. But in RTEMS > this file maps the OF_functions directly to their FDT implementation. > --- > cpukit/libfreebsd/dev/ofw/ofw_if.h | 63 ++ > 1 file changed, 63 insertions(+) > create mode 100644 cpukit/libfreebsd/dev/ofw/ofw_if.h > > diff --git a/cpukit/libfreebsd/dev/ofw/ofw_if.h > b/cpukit/libfreebsd/dev/ofw/ofw_if.h > new file mode 100644 > index 00..7b9bcaa24a > --- /dev/null > +++ b/cpukit/libfreebsd/dev/ofw/ofw_if.h > @@ -0,0 +1,63 @@ > +/* SPDX-License-Identifier: BSD-2-Clause > + > + * > + * @file > + * > + * @ingroup LIBFREEBSDOFW > + * > + * @brief Declaration of OFW functions. > + */ > + > +/* > + * Copyright (C) <2020> Niteesh Babu > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + *notice, this list of conditions and the following disclaimer. > + * 2. Redistributions in binary form must reproduce the above copyright > + *notice, this list of conditions and the following disclaimer in the > + *documentation and/or other materials provided with the distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS > IS" > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE > + * POSSIBILITY OF SUCH DAMAGE. > + */ > + > +#ifndef _LIBFREEBSD_OFW_IF_H > +#define _LIBFREEBSD_OFW_IF_H > + > +#include > +#include "openfirm.h" > + > +typedef void*ofw_t; > + > +int OFW_INIT(ofw_t ofw_obj, void *cookie); > +phandle_t OFW_PEER(ofw_t ofw_obj, phandle_t node); > +phandle_t OFW_CHILD(ofw_t ofw_obj, phandle_t node); > +phandle_t OFW_PARENT(ofw_t ofw_obj, phandle_t node); > +phandle_t OFW_INSTANCE_TO_PACKAGE(ofw_t ofw_obj, ihandle_t instance); > +ssize_t OFW_GETPROPLEN(ofw_t ofw_obj, phandle_t package, const char > *propname); > +ssize_t OFW_GETPROP(ofw_t ofw_obj, phandle_t package, const char *propname, > +void *buf, size_t buflen); If we use FreeBSD Kernel style (which I would suggest for code that has to do with FreeBSD) you should indent the second line one tab more. Means ssize_t OFW_GETPROP(ofw_t ofw_obj, ..., void *buf, size_t buflen); That is: ssize_t OFW_GETPROP(ofw_t ofw_obj, ..., <1*tab><4*space>void *buf, size_t buflen); Take a look at some FreeBSD headers for that. For example rtems-libbsd/freebsd/sys/sys/rwlock.h. > +int OFW_NEXTPROP(ofw_t ofw_obj, phandle_t package, const char *prev, char > *buf, > +size_t size); > +int OFW_SETPROP(ofw_t ofw_obj, phandle_t package, const char *propname, > +const void *buf, size_t len); > +ssize_t OFW_CANON(ofw_t ofw_obj, const char *device, char *buf, size_t len); > +phandle_t OFW_FINDDEVICE(ofw_t ofw_obj, const char *device); > +ssize_t OFW_INSTANCE_TO_PATH(ofw_t ofw_obj, ihandle_t instance, char *buf, > +size_t len); > +ssize_t OFW_PACKAGE_TO_PATH(ofw_t ofw_obj, phandle_t package, char *buf, > +size_t len); > + > +#endif /* _LIBFREEBSD_OFW_IF_H */ > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: LVGL applications with mouse
On 06/06/2020 13:09, Vijay Kumar Banerjee wrote: > On Fri, Jun 5, 2020 at 8:30 PM Christian Mauderer wrote: >> >> Hello Vijay, >> >> On 04/06/2020 21:36, Vijay Kumar Banerjee wrote: >>> Hi! >>> >>> I had been looking for an opportunity to do this for a long time and I'm >>> excited to post that LVGL apps on RTEMS can now use input devices >>> through the evdev interface! >> >> Sounds like a nice feature. >> >>> >>> I prepared some BSD evdev patches for lvgl repository and managed to get >>> them merged upstream. The patchset that I recently send to devel for >>> libbsd[1] and rtems-littlevgl[2], updates the rtems-libbsd and >>> rtems-littlevgl repository to adapt to the latest lvgl changes upstream >>> and adds the evdev support to rtems-littlevgl. >>> >>> I wrote an example lvgl application that uses the mouse, connected >>> through USB port of Beaglebone black. The example application uses the >>> RTEMS logo, which makes it a bit heavier patch for the devel. I have >>> posted the commit on my github fork [3] and would really appreciate it >>> if someone can review and approve it to merge upstream. >> >> Although most likely touch screens are more common in embedded systems, >> it's a good example. A lot of touchscreens should work via evdev too. >> > I couldn't work on the touchscreen due to the lack of hardware. The > intention is indeed to enable the use of a touchscreen or mouse > through evdev interface. > Can you please test if the touchscreen works on BBB with evdev01.exe > test in libbsd? If this works, I'll try to get the touchscreen model > that you have (most probably after the lockdown is over :) ) and will > integrate it into the same demo app. I would have to try first whether the touch is supported in FreeBSD. I'm not sure about that. But if you have tested one evdev device, another one should work too. You did test that the interface between libbsd and littelvgl works with the mouse. > >> Regarding the logo size: Also an RTEMS logo is a nice idea, maybe >> something smaller would be better to avoid that big file in the repo? >> Depending on how you generated the image: Maybe some run length encoding >> could reduce the size too (for example GIMP offers an option for that >> when exporting images to C sources). >> > Thanks for pointing this out. This indeed lowered the size by half. > I'm trying to get it working with lvgl and will post a patch to the > list once I get it done. Great. > >>> >>> Finally, please have a look at this very short video that shows the >>> example application running. It uses many features of lvgl, including >>> image, button, and input: >>> https://blog.thelunatic.dev/assets/video/lvgl_rtems_logo.mp4 >> >> Looks great. >> > Thanks. > > Best regards, > Vijay >> Best regards >> >> Christian >> >>> >>> We can now make full-fledged GUI applications with LVGL on RTEMS. :) >>> >>> [1]: https://lists.rtems.org/pipermail/devel/2020-June/060049.html >>> [2]: https://lists.rtems.org/pipermail/devel/2020-June/060050.html >>> [3]: >>> https://github.com/thelunatic/rtems-examples/commit/c526d3c06a69591dc36e62af32728c51012ea6c1 >>> >>> Thanks! >>> Vijay >>> >>> ___ >>> 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: LVGL applications with mouse
On Fri, Jun 5, 2020 at 8:30 PM Christian Mauderer wrote: > > Hello Vijay, > > On 04/06/2020 21:36, Vijay Kumar Banerjee wrote: > > Hi! > > > > I had been looking for an opportunity to do this for a long time and I'm > > excited to post that LVGL apps on RTEMS can now use input devices > > through the evdev interface! > > Sounds like a nice feature. > > > > > I prepared some BSD evdev patches for lvgl repository and managed to get > > them merged upstream. The patchset that I recently send to devel for > > libbsd[1] and rtems-littlevgl[2], updates the rtems-libbsd and > > rtems-littlevgl repository to adapt to the latest lvgl changes upstream > > and adds the evdev support to rtems-littlevgl. > > > > I wrote an example lvgl application that uses the mouse, connected > > through USB port of Beaglebone black. The example application uses the > > RTEMS logo, which makes it a bit heavier patch for the devel. I have > > posted the commit on my github fork [3] and would really appreciate it > > if someone can review and approve it to merge upstream. > > Although most likely touch screens are more common in embedded systems, > it's a good example. A lot of touchscreens should work via evdev too. > I couldn't work on the touchscreen due to the lack of hardware. The intention is indeed to enable the use of a touchscreen or mouse through evdev interface. Can you please test if the touchscreen works on BBB with evdev01.exe test in libbsd? If this works, I'll try to get the touchscreen model that you have (most probably after the lockdown is over :) ) and will integrate it into the same demo app. > Regarding the logo size: Also an RTEMS logo is a nice idea, maybe > something smaller would be better to avoid that big file in the repo? > Depending on how you generated the image: Maybe some run length encoding > could reduce the size too (for example GIMP offers an option for that > when exporting images to C sources). > Thanks for pointing this out. This indeed lowered the size by half. I'm trying to get it working with lvgl and will post a patch to the list once I get it done. > > > > Finally, please have a look at this very short video that shows the > > example application running. It uses many features of lvgl, including > > image, button, and input: > > https://blog.thelunatic.dev/assets/video/lvgl_rtems_logo.mp4 > > Looks great. > Thanks. Best regards, Vijay > Best regards > > Christian > > > > > We can now make full-fledged GUI applications with LVGL on RTEMS. :) > > > > [1]: https://lists.rtems.org/pipermail/devel/2020-June/060049.html > > [2]: https://lists.rtems.org/pipermail/devel/2020-June/060050.html > > [3]: > > https://github.com/thelunatic/rtems-examples/commit/c526d3c06a69591dc36e62af32728c51012ea6c1 > > > > Thanks! > > Vijay > > > > ___ > > 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
