date:20200709

RE: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5

2020-07-09 Thread Jan.Sommer



> -Original Message-
> From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Gedare Bloom
> Sent: Wednesday, July 8, 2020 9:45 PM
> To: Mritunjay Sharma
> Cc: RTEMS Devel
> Subject: Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5
> 
> On Wed, Jul 8, 2020 at 12:33 PM Mritunjay Sharma
>  wrote:
> >
> > [UPDATE]: I tried to build the EPICS 7 with RTEMS 5 for pc386 with Heinz's
> https://github.com/hjunkes/epicsBaseOwnPlayground
> > while switching to Branch "7". The previous errors are gone but I am facing
> the following error:
> >
> > "../posix/rtems_init.c:38:10: fatal error: rtems/bsd/bsd.h: No such file or
> directory
> >  #include 
> >   ^
> 
> This error indicates it is looking for an installed rtems-libbsd. My
> guess is you need to build/install the rtems-libbsd to get this
> playground to work.
> 

I did not read everything in this thread, so maybe I misunderstand something.
If you want to build rtems-libbsd for a pc-based BSP, please be aware of the 
following:
- It should build fine if you use the 5-freebsd-12 branch.
- With master branch is should build if you set the option "dev_nic_e1000" to 
off in your buildset.ini. It should compile, but depending on your network 
adapter there might be problems to actually use the network devices.

Finishing a patchset for the master branch to fix that is on my todo list, but 
I haven't come around to do it yet.

> > compilation terminated.
> >
> /home/mritunjay/development/EPICS/epicsBaseOwnPlayground/configure/
> RULES_BUILD:234: recipe for target 'rtems_init.o' failed
> > make[4]: *** [rtems_init.o] Error 1
> > make[4]: Leaving directory
> '/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules/
> libcom/RTEMS/O.RTEMS-pc386'
> >
> /home/mritunjay/development/EPICS/epicsBaseOwnPlayground/configure/
> RULES_ARCHS:58: recipe for target 'install.RTEMS-pc386' failed
> > make[3]: *** [install.RTEMS-pc386] Error 2
> > make[3]: Leaving directory
> '/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules/
> libcom/RTEMS'
> >
> /home/mritunjay/development/EPICS/epicsBaseOwnPlayground/configure/
> RULES_DIRS:84: recipe for target 'RTEMS.install' failed
> > make[2]: *** [RTEMS.install] Error 2
> > make[2]: Leaving directory
> '/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules/
> libcom'
> > ../configure/RULES_DIRS:84: recipe for target 'libcom.install' failed
> > make[1]: *** [libcom.install] Error 2
> > make[1]: Leaving directory
> '/home/mritunjay/development/EPICS/epicsBaseOwnPlayground/modules'
> > configure/RULES_DIRS:84: recipe for target 'modules.install' failed
> > make: *** [modules.install] Error 2"
> >
> > Today's update is that I tried to fix the above error however I still have 
> > not
> been able to clear it.
> > If anyone has idea, please do tell what can be done.
> >
> > Thanks
> > Mritunjay
> >
> > On Wed, Jul 8, 2020 at 1:12 AM Mritunjay Sharma
>  wrote:
> >>
> >>
> >>
> >> 
> >> From: Heinz Junkes 
> >> Sent: Wednesday, July 8, 2020 1:05 AM
> >> To: Mritunjay Sharma
> >> Cc: Gedare Bloom; Joel Sherrill; Chris Johns; RTEMS Devel
> >> Subject: Re: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5
> >>
> >> I’m away from my keyboard. If you use the epics Adaption to rtems from
> my github “playground?” and bsp’s with —enable-networks should compile.
> >> Heinz
> >>
> >> FHI, Heinz Junkes
> >>
> >> Thank you Heinz, I was doing the same. I went to your GitHub and am
> experimenting with "playground" right now.
> >>
> >> Thanks,
> >> Mritunjay
> >>
> >> On 7. Jul 2020, at 18:14, Mritunjay Sharma
>  wrote:
> >>
> >> 
> >> [UPDATE]: I tried building EPICS with RTEMS5 for pc-386 and pc-386-qemu.
> >> Everything worked fine while building the pc-386 with  RTEMS5.
> >>
> >> After this when I entered epics-base and made the following change:
> >>
> >> epics-base/os/CONFIG_SITE.Common.RTEMS
> >> RTEMS_VERSION = 5
> >> RTEMS_BASE =
> /home/mritunjay/development/rtems_dev/$(RTEMS_VERSION)
> >>
> >> As an experiment, I ran the make and as expected got the following error
> >>
> >> Error:
> >>
> >> ```...de/compiler/gcc -I../../../../include/os/RTEMS -I../../../../include 
> >> -
> c ../rtems_init.c
> >> ../rtems_init.c:21:10: fatal error: sys/termios.h: No such file or 
> >> directory
> >>  #include 
> >>   ^~~
> >> compilation terminated.
> >> ../../../../configure/RULES_BUILD:240: recipe for target 'rtems_init.o'
> failed
> >> make[4]: *** [rtems_init.o] Error 1
> >> make[4]: Leaving directory '/home/mritunjay/development/EPICS/epics-
> base/modules/libcom/RTEMS/O.RTEMS-pc386'
> >> ../../../configure/RULES_ARCHS:58: recipe for target 'install.RTEMS-pc386'
> failed
> >> make[3]: *** [install.RTEMS-pc386] Error 2
> >> make[3]: Leaving directory '/home/mritunjay/development/EPICS/epics-
> base/modules/libcom/RTEMS'
> >> ../../configure/RULES_DIRS:85: recipe for target 'RTEMS.install' failed
> >> make[2]: *** [RTEMS.inst

RE: libbsd rtems 5 branches

2020-07-09 Thread Jan.Sommer



> -Original Message-
> From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian
> Huber
> Sent: Tuesday, July 7, 2020 3:22 PM
> To: j...@rtems.org; rtems-de...@rtems.org
> Subject: Re: libbsd rtems 5 branches
> 
> On 07/07/2020 15:19, Joel Sherrill wrote:
> > Hi
> >
> > What's the difference between these two branches?
> >
> >    remotes/origin/5
> 
> This branch synchronizes with the FreeBSD master.
> 
> >    remotes/origin/5-freebsd-12
> 
> 
> This branch synchronizes with the FreeBSD 12 branch.
> 
> Both are for RTEMS 5.
> 

Will both branches also be part of the RTEMS5 release?
My assumption was the 5-freebsd-12 branch will be the one officially published.

> --
> Sebastian Huber, embedded brains GmbH
> 
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ___
> 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: libbsd rtems 5 branches

2020-07-09 Thread Sebastian Huber

On 09/07/2020 09:17, jan.som...@dlr.de wrote:

-Original Message-
From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian
Huber
Sent: Tuesday, July 7, 2020 3:22 PM
To:j...@rtems.org;rtems-de...@rtems.org
Subject: Re: libbsd rtems 5 branches

On 07/07/2020 15:19, Joel Sherrill wrote:

Hi

What's the difference between these two branches?

    remotes/origin/5

This branch synchronizes with the FreeBSD master.

    remotes/origin/5-freebsd-12

This branch synchronizes with the FreeBSD 12 branch.

Both are for RTEMS 5.

Will both branches also be part of the RTEMS5 release?
My assumption was the 5-freebsd-12 branch will be the one officially published.

Chris performed some extra work in the release scripts to use the 
5-freebsd-12 for the release archive.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] media-server: Add ability for retry.

2020-07-09 Thread Christian Mauderer

This adds the possibility to request a retry in the media-listener if an
operation failed. Usefull for example if you want to automatically
reformat a disk if it wasn't possible to mount it.
---
 cpukit/include/rtems/media.h |  3 +++
 cpukit/libblock/src/media.c  | 29 -
 2 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/cpukit/include/rtems/media.h b/cpukit/include/rtems/media.h
index b2a3e2dc91..db13664975 100644
--- a/cpukit/include/rtems/media.h
+++ b/cpukit/include/rtems/media.h
@@ -281,6 +281,9 @@ typedef enum {
  *
  * @retval RTEMS_SUCCESSFUL Successful operation.
  * @retval RTEMS_IO_ERROR In the inquiry state this will abort the action.
+ * @retval RTEMS_INCORRECT_STATE In the failed state this will cause a retry.
+ * Make sure to have a retry counter or similar to avoid endless loops if you
+ * use this this value.
  */
 typedef rtems_status_code (*rtems_media_listener)(
   rtems_media_event event,
diff --git a/cpukit/libblock/src/media.c b/cpukit/libblock/src/media.c
index 5b2b06b5b2..c00825587c 100644
--- a/cpukit/libblock/src/media.c
+++ b/cpukit/libblock/src/media.c
@@ -420,26 +420,29 @@ static rtems_status_code process_event(
 )
 {
   rtems_status_code sc = RTEMS_SUCCESSFUL;
+  rtems_status_code sc_retry = RTEMS_SUCCESSFUL;
   rtems_media_state state = RTEMS_MEDIA_STATE_FAILED;
   char *dest = NULL;
 
-  sc = notify(event, RTEMS_MEDIA_STATE_INQUIRY, src, NULL);
-  if (sc == RTEMS_SUCCESSFUL) {
-state = RTEMS_MEDIA_STATE_READY;
-  } else {
-state = RTEMS_MEDIA_STATE_ABORTED;
-  }
-
-  sc = (*worker)(state, src, &dest, worker_arg);
-  if (state == RTEMS_MEDIA_STATE_READY) {
+  do {
+sc = notify(event, RTEMS_MEDIA_STATE_INQUIRY, src, NULL);
 if (sc == RTEMS_SUCCESSFUL) {
-  state = RTEMS_MEDIA_STATE_SUCCESS;
+  state = RTEMS_MEDIA_STATE_READY;
 } else {
-  state = RTEMS_MEDIA_STATE_FAILED;
+  state = RTEMS_MEDIA_STATE_ABORTED;
+}
+
+sc = (*worker)(state, src, &dest, worker_arg);
+if (state == RTEMS_MEDIA_STATE_READY) {
+  if (sc == RTEMS_SUCCESSFUL) {
+state = RTEMS_MEDIA_STATE_SUCCESS;
+  } else {
+state = RTEMS_MEDIA_STATE_FAILED;
+  }
 }
-  }
 
-  notify(event, state, src, dest);
+sc_retry = notify(event, state, src, dest);
+  } while (state == RTEMS_MEDIA_STATE_FAILED && sc_retry == 
RTEMS_INCORRECT_STATE);
   remember_event(event, state, src, dest);
 
   if (state == RTEMS_MEDIA_STATE_SUCCESS) {
-- 
2.26.2

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

[PATCH] lvgl: Update to v7.1.0

2020-07-09 Thread Christian Mauderer

---
 lv_conf.h  | 337 +++--
 lv_drivers |   2 +-
 lvgl   |   2 +-
 lvgl.py|   3 +-
 4 files changed, 281 insertions(+), 63 deletions(-)

diff --git a/lv_conf.h b/lv_conf.h
index 7453905..9299fdc 100644
--- a/lv_conf.h
+++ b/lv_conf.h
@@ -1,6 +1,6 @@
 /**
  * @file lv_conf.h
- *
+ * Configuration file for LVGL v7.1.0
  */
 
 /*
@@ -25,7 +25,7 @@
 
 /* Color depth:
  * - 1:  1 byte per pixel
- * - 8:  RGB233
+ * - 8:  RGB332
  * - 16: RGB565
  * - 32: ARGB
  */
@@ -53,7 +53,18 @@
 /* Dot Per Inch: used to initialize default sizes.
  * E.g. a button with width = LV_DPI / 2 -> half inch wide
  * (Not so important, you can adjust it to modify default sizes and spaces)*/
-#define LV_DPI  100 /*[px]*/
+#define LV_DPI  130 /*[px]*/
+
+/* The the real width of the display changes some default values:
+ * default object sizes, layout of examples, etc.
+ * According to the width of the display (hor. res. / dpi)
+ * the displays fall in 4 categories.
+ * The 4th is extra large which has no upper limit so not listed here
+ * The upper limit of the categories are set below in 0.1 inch unit.
+ */
+#define LV_DISP_SMALL_LIMIT  30
+#define LV_DISP_MEDIUM_LIMIT 50
+#define LV_DISP_LARGE_LIMIT  70
 
 /* Type of coordinates. Should be `int16_t` (or `int32_t` for extreme cases) */
 typedef int16_t lv_coord_t;
@@ -109,7 +120,7 @@ typedef int16_t lv_coord_t;
 #define LV_INDEV_DEF_DRAG_LIMIT   10
 
 /* Drag throw slow-down in [%]. Greater value -> faster slow-down */
-#define LV_INDEV_DEF_DRAG_THROW   20
+#define LV_INDEV_DEF_DRAG_THROW   10
 
 /* Long press time in milliseconds.
  * Time to send `LV_EVENT_LONG_PRESSSED`) */
@@ -119,6 +130,13 @@ typedef int16_t lv_coord_t;
  * Time between `LV_EVENT_LONG_PRESSED_REPEAT */
 #define LV_INDEV_DEF_LONG_PRESS_REP_TIME  100
 
+
+/* Gesture threshold in pixels */
+#define LV_INDEV_DEF_GESTURE_LIMIT50
+
+/* Gesture min velocity at release before swipe (pixels)*/
+#define LV_INDEV_DEF_GESTURE_MIN_VELOCITY 3
+
 /*==
  * Feature usage
  *==*/
@@ -134,6 +152,22 @@ typedef void * lv_anim_user_data_t;
 
 /* 1: Enable shadow drawing*/
 #define LV_USE_SHADOW   1
+#if LV_USE_SHADOW
+/* Allow buffering some shadow calculation
+ * LV_SHADOW_CACHE_SIZE is the max. shadow size to buffer,
+ * where shadow size is `shadow_width + radius`
+ * Caching has LV_SHADOW_CACHE_SIZE^2 RAM cost*/
+#define LV_SHADOW_CACHE_SIZE0
+#endif
+
+/* 1: Use other blend modes than normal (`LV_BLEND_MODE_...`)*/
+#define LV_USE_BLEND_MODES  1
+
+/* 1: Use the `opa_scale` style property to set the opacity of an object and 
its children at once*/
+#define LV_USE_OPA_SCALE1
+
+/* 1: Use image zoom and rotation*/
+#define LV_USE_IMG_TRANSFORM1
 
 /* 1: Enable object groups (for keyboard/encoder navigation) */
 #define LV_USE_GROUP1
@@ -142,7 +176,11 @@ typedef void * lv_group_user_data_t;
 #endif  /*LV_USE_GROUP*/
 
 /* 1: Enable GPU interface*/
-#define LV_USE_GPU  1
+#define LV_USE_GPU  1   /*Only enables `gpu_fill_cb` and 
`gpu_blend_cb` in the disp. drv- */
+#define LV_USE_GPU_STM32_DMA2D  0
+/*If enabling LV_USE_GPU_STM32_DMA2D, LV_GPU_DMA2D_CMSIS_INCLUDE must be 
defined to include path of CMSIS header of target processor
+e.g. "stm32f769xx.h" or "stm32f429xx.h" */
+#define LV_GPU_DMA2D_CMSIS_INCLUDE
 
 /* 1: Enable file system (might be required for images */
 #define LV_USE_FILESYSTEM   1
@@ -154,6 +192,12 @@ typedef void * lv_fs_drv_user_data_t;
 /*1: Add a `user_data` to drivers and objects*/
 #define LV_USE_USER_DATA1
 
+/*1: Show CPU usage and FPS count in the right bottom corner*/
+#define LV_USE_PERF_MONITOR 0
+
+/*1: Use the functions and types from the older API if possible */
+#define LV_USE_API_EXTENSION_V6  1
+
 /*
  * Image decoder and cache
  **/
@@ -178,12 +222,19 @@ typedef void * lv_img_decoder_user_data_t;
 /*=
  *  Compiler settings
  **/
+
+/* For big endian systems set to 1 */
+#define LV_BIG_ENDIAN_SYSTEM0
+
 /* Define a custom attribute to `lv_tick_inc` function */
 #define LV_ATTRIBUTE_TICK_INC
 
 /* Define a custom attribute to `lv_task_handler` function */
 #define LV_ATTRIBUTE_TASK_HANDLER
 
+/* Define a custom attribute to `lv_disp_flush_ready` function */
+#define LV_ATTRIBUTE_FLUSH_READY
+
 /* With size optimization (-Os) the compiler might not align data to
  * 4 or 8 byte boundary. This alignment will be explicitly applied where 
needed.
  * E.g. __attribute__((aligned(4))) */
@@ -193,6 +244,22 @@ typedef void * lv_img_decoder_user_data_t;
  * font's bitmaps */
 #define LV_ATTRIBUTE_LARGE_CONST
 
+/* Prefix performance critical functions to place them into a faster memory 
(e.g RAM)
+ * Uses 15-20 kB extra memory */
+#define LV_ATTRIBUTE_FAST_MEM
+
+/* Export integer

GSoC 2020: Location for FreeBSD files in RTEMS

2020-07-09 Thread Niteesh G. S.

Hello,

The current directory structure I have been using in my GSoC project
for the FreeBSD drivers is giving me troubles while installing/including
the headers.

The current structure of the drivers is as follows
cpukit/libfreebsd/freebsd --> After this we follow the FreeBSD file
structure

Eg: ti_pinmux.h is placed under sys/arm/ti/ti_pinmux.h in FreeBSD
 In RTEMS this is placed under
 cpukit/libfreebsd/freebsd/sys/arm/ti/ti_pinmux.h

And the files implemented to make porting easier are placed under
cpukit/libfreebsd/rtems
You can find these files here
https://github.com/gs-niteesh/rtems/tree/rtemsbsd/cpukit/libfreebsd/rtems
I have already started a discussion and written a blog about these files
please check out
https://lists.rtems.org/pipermail/devel/2020-July/060541.html
With the current structure, we aren't able to include the header files in
BSP and test suite directory.

The spec file for libfreebsd can be found here
https://github.com/gs-niteesh/rtems/blob/pinmux-rtems-6/spec/build/cpukit/objfreebsd.yml

After a discussion regarding this with Christian, he suggested to break out
of the FreeBSD structure and place the header files under cpukit/include
and install them with FreeBSD like structure.
I tried this and was able to include the headers in the BSP and testsuite
directory.
On using this approach we have the following structure.
FreeBSD header files are under
cpukit/include
FreeBSD source files under
cpukit/libfreebsd/freebsd

We will also be using the same approach for the files that have implemented
to make porting easier.
All the headers will be placed under
cpukit/include
The source files under
cpukit/libfreebsd/rtems ( Currently we are having only one source file).

I kindly request everyone to quickly provide their feedback on this
structure
since this is hampering my progress. If you don't like this structure please
suggest something better.

Thank you,
Niteesh.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] lvgl: Update to v7.1.0

2020-07-09 Thread Vijay Kumar Banerjee

Hi Christian,

I tested the patch and it's running fine with the example applications
on BBB. Thanks for the patch.

Best regards,
Vijay

On Thu, Jul 9, 2020 at 5:34 PM Christian Mauderer
 wrote:
>
> ---
>  lv_conf.h  | 337 +++--
>  lv_drivers |   2 +-
>  lvgl   |   2 +-
>  lvgl.py|   3 +-
>  4 files changed, 281 insertions(+), 63 deletions(-)
>
> diff --git a/lv_conf.h b/lv_conf.h
> index 7453905..9299fdc 100644
> --- a/lv_conf.h
> +++ b/lv_conf.h
> @@ -1,6 +1,6 @@
>  /**
>   * @file lv_conf.h
> - *
> + * Configuration file for LVGL v7.1.0
>   */
>
>  /*
> @@ -25,7 +25,7 @@
>
>  /* Color depth:
>   * - 1:  1 byte per pixel
> - * - 8:  RGB233
> + * - 8:  RGB332
>   * - 16: RGB565
>   * - 32: ARGB
>   */
> @@ -53,7 +53,18 @@
>  /* Dot Per Inch: used to initialize default sizes.
>   * E.g. a button with width = LV_DPI / 2 -> half inch wide
>   * (Not so important, you can adjust it to modify default sizes and spaces)*/
> -#define LV_DPI  100 /*[px]*/
> +#define LV_DPI  130 /*[px]*/
> +
> +/* The the real width of the display changes some default values:
> + * default object sizes, layout of examples, etc.
> + * According to the width of the display (hor. res. / dpi)
> + * the displays fall in 4 categories.
> + * The 4th is extra large which has no upper limit so not listed here
> + * The upper limit of the categories are set below in 0.1 inch unit.
> + */
> +#define LV_DISP_SMALL_LIMIT  30
> +#define LV_DISP_MEDIUM_LIMIT 50
> +#define LV_DISP_LARGE_LIMIT  70
>
>  /* Type of coordinates. Should be `int16_t` (or `int32_t` for extreme cases) 
> */
>  typedef int16_t lv_coord_t;
> @@ -109,7 +120,7 @@ typedef int16_t lv_coord_t;
>  #define LV_INDEV_DEF_DRAG_LIMIT   10
>
>  /* Drag throw slow-down in [%]. Greater value -> faster slow-down */
> -#define LV_INDEV_DEF_DRAG_THROW   20
> +#define LV_INDEV_DEF_DRAG_THROW   10
>
>  /* Long press time in milliseconds.
>   * Time to send `LV_EVENT_LONG_PRESSSED`) */
> @@ -119,6 +130,13 @@ typedef int16_t lv_coord_t;
>   * Time between `LV_EVENT_LONG_PRESSED_REPEAT */
>  #define LV_INDEV_DEF_LONG_PRESS_REP_TIME  100
>
> +
> +/* Gesture threshold in pixels */
> +#define LV_INDEV_DEF_GESTURE_LIMIT50
> +
> +/* Gesture min velocity at release before swipe (pixels)*/
> +#define LV_INDEV_DEF_GESTURE_MIN_VELOCITY 3
> +
>  /*==
>   * Feature usage
>   *==*/
> @@ -134,6 +152,22 @@ typedef void * lv_anim_user_data_t;
>
>  /* 1: Enable shadow drawing*/
>  #define LV_USE_SHADOW   1
> +#if LV_USE_SHADOW
> +/* Allow buffering some shadow calculation
> + * LV_SHADOW_CACHE_SIZE is the max. shadow size to buffer,
> + * where shadow size is `shadow_width + radius`
> + * Caching has LV_SHADOW_CACHE_SIZE^2 RAM cost*/
> +#define LV_SHADOW_CACHE_SIZE0
> +#endif
> +
> +/* 1: Use other blend modes than normal (`LV_BLEND_MODE_...`)*/
> +#define LV_USE_BLEND_MODES  1
> +
> +/* 1: Use the `opa_scale` style property to set the opacity of an object and 
> its children at once*/
> +#define LV_USE_OPA_SCALE1
> +
> +/* 1: Use image zoom and rotation*/
> +#define LV_USE_IMG_TRANSFORM1
>
>  /* 1: Enable object groups (for keyboard/encoder navigation) */
>  #define LV_USE_GROUP1
> @@ -142,7 +176,11 @@ typedef void * lv_group_user_data_t;
>  #endif  /*LV_USE_GROUP*/
>
>  /* 1: Enable GPU interface*/
> -#define LV_USE_GPU  1
> +#define LV_USE_GPU  1   /*Only enables `gpu_fill_cb` and 
> `gpu_blend_cb` in the disp. drv- */
> +#define LV_USE_GPU_STM32_DMA2D  0
> +/*If enabling LV_USE_GPU_STM32_DMA2D, LV_GPU_DMA2D_CMSIS_INCLUDE must be 
> defined to include path of CMSIS header of target processor
> +e.g. "stm32f769xx.h" or "stm32f429xx.h" */
> +#define LV_GPU_DMA2D_CMSIS_INCLUDE
>
>  /* 1: Enable file system (might be required for images */
>  #define LV_USE_FILESYSTEM   1
> @@ -154,6 +192,12 @@ typedef void * lv_fs_drv_user_data_t;
>  /*1: Add a `user_data` to drivers and objects*/
>  #define LV_USE_USER_DATA1
>
> +/*1: Show CPU usage and FPS count in the right bottom corner*/
> +#define LV_USE_PERF_MONITOR 0
> +
> +/*1: Use the functions and types from the older API if possible */
> +#define LV_USE_API_EXTENSION_V6  1
> +
>  /*
>   * Image decoder and cache
>   **/
> @@ -178,12 +222,19 @@ typedef void * lv_img_decoder_user_data_t;
>  /*=
>   *  Compiler settings
>   **/
> +
> +/* For big endian systems set to 1 */
> +#define LV_BIG_ENDIAN_SYSTEM0
> +
>  /* Define a custom attribute to `lv_tick_inc` function */
>  #define LV_ATTRIBUTE_TICK_INC
>
>  /* Define a custom attribute to `lv_task_handler` function */
>  #define LV_ATTRIBUTE_TASK_HANDLER
>
> +/* Define a custom attribute to `lv_disp_flush_ready` function */
> +#define LV_ATTRIBUTE_FLUSH_READY
> +
>  /* With size optimization (-Os)

Re: Converting stack address to shared-memory object name

2020-07-09 Thread Gedare Bloom

On Wed, Jul 8, 2020 at 10:08 PM Utkarsh Rai  wrote:
>
>
>
>
> On Wed, Jul 8, 2020 at 6:56 PM Gedare Bloom  wrote:
>>
>> On Wed, Jul 8, 2020 at 6:53 AM Sebastian Huber
>>  wrote:
>> >
>> > On 08/07/2020 14:43, Utkarsh Rai wrote:
>> >
>> > > Hello,
>> > > For my GSoC project, I have to provide high-level APIs for sharing
>> > > isolated stacks.
>> > > The POSIX compliant high-level way of sharing stacks can be to create
>> > > a shared memory object of the stack to be shared through shm_open and
>> > > then mmap that to the address space of the current stack. My doubt is,
>> > > shm_open() takes the path-name of the shared memory object. Since this
>> > > is a high-level API, how does the user 'convert' the stack address to
>> > > a shared memory object name?
>> > Do we need any POSIX compatibility for this? What would you do in a
>> > POSIX environment? You first get some memory, then hand it over to
>> > shm_open() to get a file descriptor, then use the file descriptor in
>> > mmap(), then use this for pthread_attr_setstack() and whatever?
>>
>> Yes, but the way to name objects is not set by posix.
>>
>> We need to provide our own way of translating an address into a name.
>>
>> > >
>> > > Dr.Gedare mentioned that one way to deal with naming would be
>> > > something like Mr.Sebastian has been doing with specifications. From
>> > > what I could gather, it is a hierarchical way of representing
>> > > objects(Though, I am not very sure if  I understand this accurately).
>> > > How can something like this be implemented for naming stack-addresses?
>> > I am not sure if the specification of RTEMS is helpful in this context.
>>
>> I should have provided a little bit more guidance. I was thinking out
>> loud in yesterday's IRC meeting. My thought was more along the lines
>> of looking at how UIDs/naming should be done, and that specs had to
>> solve a naming problem. However the static nature of specs is not a
>> great fit to this problem.
>>
>> Actually, what is a good model would be something like /proc or
>> Linux's sysfs. An IMFS filesystem that exports task information could
>> be used to name memory regions. (It could eventually supplant
>> task-based statistics reporting too.)
>>
>> Another idea I had though, which seems to have been lost in the
>> shuffle, is to look at how the object names work in RTEMS and see if
>> we can add some fixed relationships, e.g., task_name # stack.
>>
>> I think we should start by just treating the entire task stack as a
>> single named object; either it is all shared, or none of it is shared.
>> This will be easier to implement and also more widely supported by
>> simpler MPU/MMU hardware. Later on, we can consider extending the
>> namespace with 'offsets' /taskfs/IDLE/stack/0A28
>> could be a location at byte A28 offset from the start of the stack of
>> the IDLE task.
>>
>
> I have a few questions -
>
> > Users would get the stack address of the stack they want to share through 
> > pthread_attr_getstack(). Now, when they get the address they want to share, 
> > they would pass the appropriate name of this memory-region. What we have to 
> > provide is a mechanism to 'convert' this address to an appropriate name. Is 
> > this the accepted way or the other way round, i.e. the user passes a name 
> > as per a specified convention, and that name is 'converted' to a specific 
> > address?
>
We may want both to work. You definitely want to have the
address->name working though, at the very least with the base address
returned by pthread_attr_getstack, but you might also want to be able
to map any address in a task's stack to the stack's "name". I'm not
sure if that is needed yet, but keep it in mind as a possible
extension later to use an address interval instead of a fixed base
address.

> > When you say "treating the entire task stack as a single named object" does 
> > it mean that we assign a single name, say "task_stack" to the complete 
> > stack address space? In that case, how do we deal we the presence of 
> > multiple tasks that are allocated from the same pool of task stack? I 
> > understand that on a simpler MPU/MMU hardware it would make sense to 
> > specify names for each memory section (.txt- "text", .bss - "bss" etc.) but 
> > in this case,  where we are sharing only selected thread-stacks, I suppose 
> > we will have to have a way to handle 'offsets' right from the start?
>

No, I'm thinking one name for each task's stack. If you have 10 tasks,
you'd have 10 names.

Each allocated task stack is logically a separate region within the
pool. For simple MPU hardware, it may not be possible to share
arbitrary task stacks, but in that case the implementation can just
ignore the name and share the entire pool if that is preferred, or
return an error. (The behavior could be configurable, maybe.)

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

Re: Converting stack address to shared-memory object name

2020-07-09 Thread Gedare Bloom

On Thu, Jul 9, 2020 at 9:24 AM Gedare Bloom  wrote:
>
> On Wed, Jul 8, 2020 at 10:08 PM Utkarsh Rai  wrote:
> >
> >
> >
> >
> > On Wed, Jul 8, 2020 at 6:56 PM Gedare Bloom  wrote:
> >>
> >> On Wed, Jul 8, 2020 at 6:53 AM Sebastian Huber
> >>  wrote:
> >> >
> >> > On 08/07/2020 14:43, Utkarsh Rai wrote:
> >> >
> >> > > Hello,
> >> > > For my GSoC project, I have to provide high-level APIs for sharing
> >> > > isolated stacks.
> >> > > The POSIX compliant high-level way of sharing stacks can be to create
> >> > > a shared memory object of the stack to be shared through shm_open and
> >> > > then mmap that to the address space of the current stack. My doubt is,
> >> > > shm_open() takes the path-name of the shared memory object. Since this
> >> > > is a high-level API, how does the user 'convert' the stack address to
> >> > > a shared memory object name?
> >> > Do we need any POSIX compatibility for this? What would you do in a
> >> > POSIX environment? You first get some memory, then hand it over to
> >> > shm_open() to get a file descriptor, then use the file descriptor in
> >> > mmap(), then use this for pthread_attr_setstack() and whatever?
> >>
> >> Yes, but the way to name objects is not set by posix.
> >>
> >> We need to provide our own way of translating an address into a name.
> >>
> >> > >
> >> > > Dr.Gedare mentioned that one way to deal with naming would be
> >> > > something like Mr.Sebastian has been doing with specifications. From
> >> > > what I could gather, it is a hierarchical way of representing
> >> > > objects(Though, I am not very sure if  I understand this accurately).
> >> > > How can something like this be implemented for naming stack-addresses?
> >> > I am not sure if the specification of RTEMS is helpful in this context.
> >>
> >> I should have provided a little bit more guidance. I was thinking out
> >> loud in yesterday's IRC meeting. My thought was more along the lines
> >> of looking at how UIDs/naming should be done, and that specs had to
> >> solve a naming problem. However the static nature of specs is not a
> >> great fit to this problem.
> >>
> >> Actually, what is a good model would be something like /proc or
> >> Linux's sysfs. An IMFS filesystem that exports task information could
> >> be used to name memory regions. (It could eventually supplant
> >> task-based statistics reporting too.)
> >>
> >> Another idea I had though, which seems to have been lost in the
> >> shuffle, is to look at how the object names work in RTEMS and see if
> >> we can add some fixed relationships, e.g., task_name # stack.
> >>
> >> I think we should start by just treating the entire task stack as a
> >> single named object; either it is all shared, or none of it is shared.
> >> This will be easier to implement and also more widely supported by
> >> simpler MPU/MMU hardware. Later on, we can consider extending the
> >> namespace with 'offsets' /taskfs/IDLE/stack/0A28
> >> could be a location at byte A28 offset from the start of the stack of
> >> the IDLE task.
> >>
> >
> > I have a few questions -
> >
> > > Users would get the stack address of the stack they want to share through 
> > > pthread_attr_getstack(). Now, when they get the address they want to 
> > > share, they would pass the appropriate name of this memory-region. What 
> > > we have to provide is a mechanism to 'convert' this address to an 
> > > appropriate name. Is this the accepted way or the other way round, i.e. 
> > > the user passes a name as per a specified convention, and that name is 
> > > 'converted' to a specific address?
> >
> We may want both to work. You definitely want to have the
> address->name working though, at the very least with the base address
> returned by pthread_attr_getstack, but you might also want to be able
> to map any address in a task's stack to the stack's "name". I'm not
> sure if that is needed yet, but keep it in mind as a possible
> extension later to use an address interval instead of a fixed base
> address.
>

One more clarification, the "name to address" conversion should be
done within the shm+mmap implementation. shm takes a name and returns
a fd, mmap takes an fd and returns an address.

> > > When you say "treating the entire task stack as a single named object" 
> > > does it mean that we assign a single name, say "task_stack" to the 
> > > complete stack address space? In that case, how do we deal we the 
> > > presence of multiple tasks that are allocated from the same pool of task 
> > > stack? I understand that on a simpler MPU/MMU hardware it would make 
> > > sense to specify names for each memory section (.txt- "text", .bss - 
> > > "bss" etc.) but in this case,  where we are sharing only selected 
> > > thread-stacks, I suppose we will have to have a way to handle 'offsets' 
> > > right from the start?
> >
>
> No, I'm thinking one name for each task's stack. If you have 10 tasks,
> you'd have 10 names.
>
> Each allocated task stack is logically a separate region within t

[PATCH rtems-littlevgl] Allow to pass custom lv_conf.h and lv_drv_conf.h.

2020-07-09 Thread Christian Mauderer

---
 lv_conf.h => default_lv_conf.h |  0
 lv_drv_conf.h => default_lv_drv_conf.h |  0
 lvgl.py| 19 ---
 wscript| 13 +
 4 files changed, 29 insertions(+), 3 deletions(-)
 rename lv_conf.h => default_lv_conf.h (100%)
 rename lv_drv_conf.h => default_lv_drv_conf.h (100%)

diff --git a/lv_conf.h b/default_lv_conf.h
similarity index 100%
rename from lv_conf.h
rename to default_lv_conf.h
diff --git a/lv_drv_conf.h b/default_lv_drv_conf.h
similarity index 100%
rename from lv_drv_conf.h
rename to default_lv_drv_conf.h
diff --git a/lvgl.py b/lvgl.py
index c154a5e..6d55db7 100644
--- a/lvgl.py
+++ b/lvgl.py
@@ -73,6 +73,17 @@ def build(bld):
 includes.append('.')
 include_paths = []
 
+def write_stuff(stuff):
+def stuff_writer(task):
+task.outputs[0].write(stuff)
+return stuff_writer
+
+lv_conf_h='lv_conf.h'
+lv_drv_conf_h='lv_drv_conf.h'
+
+bld(rule=write_stuff(bld.env.LV_CONF), target=lv_conf_h)
+bld(rule=write_stuff(bld.env.LV_DRV_CONF), target=lv_drv_conf_h)
+
 for source in sources:
 source_dir = os.path.dirname(source)
 if source_dir not in include_paths:
@@ -80,7 +91,7 @@ def build(bld):
 
 bld.stlib(target = 'lvgl',
   features = 'c',
-  cflags = ['-O2', '-g'],
+  cflags = ['-O2', '-g', '-DLV_CONF_INCLUDE_SIMPLE'],
   includes = includes,
   source = sources)
 
@@ -96,6 +107,8 @@ def build(bld):
 for include_path in include_paths:
 files = os.listdir(include_path)
 include_headers = [os.path.join(include_path, x) for x in files if 
(x[-2:] == '.h')]
-bld.install_files(os.path.join("${PREFIX}/" , arch_inc_path, 
include_path),
+bld.install_files(os.path.join("${PREFIX}", arch_inc_path, 
include_path),
   include_headers)
-bld.install_files('${PREFIX}/' + arch_lib_path, ["liblvgl.a"])
+bld.install_files(os.path.join('${PREFIX}', arch_lib_path), ["liblvgl.a"])
+bld.install_files(os.path.join('${PREFIX}', arch_inc_path, include_path),
+[lv_conf_h])
diff --git a/wscript b/wscript
index ae91daa..0e1a51d 100644
--- a/wscript
+++ b/wscript
@@ -49,9 +49,22 @@ def options(opt):
dest = "drivers",
help = "Build without lv_drivers." +
   "Useful for building without libbsd.")
+opt.add_option("--lv-conf",
+   default = "default_lv_conf.h",
+   dest = "lv_conf",
+   help = "Use a custom lv_conf.h instead of the default one.")
+opt.add_option("--lv-drv-conf",
+   default = "default_lv_drv_conf.h",
+   dest = "lv_drv_conf",
+   help = "Use a custom lv_drv_conf.h instead of the default 
one.")
 
 def configure(conf):
 conf.env.DRIVERS = conf.options.drivers
+with open(conf.options.lv_conf, "rb") as lv_conf:
+conf.env.LV_CONF = lv_conf.read()
+with open(conf.options.lv_drv_conf, "rb") as lv_drv_conf:
+conf.env.LV_DRV_CONF = lv_drv_conf.read()
+conf.env.BUILDINCLUDE = 'build-include'
 rtems.configure(conf)
 
 def build(bld):
-- 
2.26.2

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

Re: Converting stack address to shared-memory object name

2020-07-09 Thread Utkarsh Rai

On Thu, Jul 9, 2020 at 8:57 PM Gedare Bloom  wrote:

> On Thu, Jul 9, 2020 at 9:24 AM Gedare Bloom  wrote:
> >
> > On Wed, Jul 8, 2020 at 10:08 PM Utkarsh Rai 
> wrote:
> > >
> > >
> > >
> > >
> > > On Wed, Jul 8, 2020 at 6:56 PM Gedare Bloom  wrote:
> > >>
> > >> On Wed, Jul 8, 2020 at 6:53 AM Sebastian Huber
> > >>  wrote:
> > >> >
> > >> > On 08/07/2020 14:43, Utkarsh Rai wrote:
> > >> >
> > >> > > Hello,
> > >> > > For my GSoC project, I have to provide high-level APIs for sharing
> > >> > > isolated stacks.
> > >> > > The POSIX compliant high-level way of sharing stacks can be to
> create
> > >> > > a shared memory object of the stack to be shared through shm_open
> and
> > >> > > then mmap that to the address space of the current stack. My
> doubt is,
> > >> > > shm_open() takes the path-name of the shared memory object. Since
> this
> > >> > > is a high-level API, how does the user 'convert' the stack
> address to
> > >> > > a shared memory object name?
> > >> > Do we need any POSIX compatibility for this? What would you do in a
> > >> > POSIX environment? You first get some memory, then hand it over to
> > >> > shm_open() to get a file descriptor, then use the file descriptor in
> > >> > mmap(), then use this for pthread_attr_setstack() and whatever?
> > >>
> > >> Yes, but the way to name objects is not set by posix.
> > >>
> > >> We need to provide our own way of translating an address into a name.
> > >>
> > >> > >
> > >> > > Dr.Gedare mentioned that one way to deal with naming would be
> > >> > > something like Mr.Sebastian has been doing with specifications.
> From
> > >> > > what I could gather, it is a hierarchical way of representing
> > >> > > objects(Though, I am not very sure if  I understand this
> accurately).
> > >> > > How can something like this be implemented for naming
> stack-addresses?
> > >> > I am not sure if the specification of RTEMS is helpful in this
> context.
> > >>
> > >> I should have provided a little bit more guidance. I was thinking out
> > >> loud in yesterday's IRC meeting. My thought was more along the lines
> > >> of looking at how UIDs/naming should be done, and that specs had to
> > >> solve a naming problem. However the static nature of specs is not a
> > >> great fit to this problem.
> > >>
> > >> Actually, what is a good model would be something like /proc or
> > >> Linux's sysfs. An IMFS filesystem that exports task information could
> > >> be used to name memory regions. (It could eventually supplant
> > >> task-based statistics reporting too.)
> > >>
> > >> Another idea I had though, which seems to have been lost in the
> > >> shuffle, is to look at how the object names work in RTEMS and see if
> > >> we can add some fixed relationships, e.g., task_name # stack.
> > >>
> > >> I think we should start by just treating the entire task stack as a
> > >> single named object; either it is all shared, or none of it is shared.
> > >> This will be easier to implement and also more widely supported by
> > >> simpler MPU/MMU hardware. Later on, we can consider extending the
> > >> namespace with 'offsets' /taskfs/IDLE/stack/0A28
> > >> could be a location at byte A28 offset from the start of the stack of
> > >> the IDLE task.
> > >>
> > >
> > > I have a few questions -
> > >
> > > > Users would get the stack address of the stack they want to share
> through pthread_attr_getstack(). Now, when they get the address they want
> to share, they would pass the appropriate name of this memory-region. What
> we have to provide is a mechanism to 'convert' this address to an
> appropriate name. Is this the accepted way or the other way round, i.e. the
> user passes a name as per a specified convention, and that name is
> 'converted' to a specific address?
> > >
> > We may want both to work. You definitely want to have the
> > address->name working though, at the very least with the base address
> > returned by pthread_attr_getstack, but you might also want to be able
> > to map any address in a task's stack to the stack's "name". I'm not
> > sure if that is needed yet, but keep it in mind as a possible
> > extension later to use an address interval instead of a fixed base
> > address.
> >
>
> One more clarification, the "name to address" conversion should be
> done within the shm+mmap implementation. shm takes a name and returns
> a fd, mmap takes an fd and returns an address.
>

Got it.


> > > > When you say "treating the entire task stack as a single named
> object" does it mean that we assign a single name, say "task_stack" to the
> complete stack address space? In that case, how do we deal we the presence
> of multiple tasks that are allocated from the same pool of task stack? I
> understand that on a simpler MPU/MMU hardware it would make sense to
> specify names for each memory section (.txt- "text", .bss - "bss" etc.) but
> in this case,  where we are sharing only selected thread-stacks, I suppose
> we will have to have a way to handle 'offsets' right from the star

make error on 5 branch?

2020-07-09 Thread Gedare Bloom

I built/installed clean tools from rsb/5 and bootstrapped rtems/5 then:
../../rtems/configure --prefix=/home/gedare/development/rtems/5
--target=sparc-rtems5 --enable-rtemsbsp=erc32 --enable-posix
--enable-tests
[...] looks ok
make
[...]
checking for RTEMS_BSP... erc32
configure: error: Invalid BSP
configure: error:
../../../../../../../../rtems/c/src/lib/libbsp/sparc/configure failed
for lib/libbsp/sparc
Makefile:731: recipe for target 'erc32' failed

Can anyone reproduce?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Converting stack address to shared-memory object name

2020-07-09 Thread Gedare Bloom

On Thu, Jul 9, 2020 at 9:46 AM Utkarsh Rai  wrote:
>
>
>
> On Thu, Jul 9, 2020 at 8:57 PM Gedare Bloom  wrote:
>>
>> On Thu, Jul 9, 2020 at 9:24 AM Gedare Bloom  wrote:
>> >
>> > On Wed, Jul 8, 2020 at 10:08 PM Utkarsh Rai  
>> > wrote:
>> > >
>> > >
>> > >
>> > >
>> > > On Wed, Jul 8, 2020 at 6:56 PM Gedare Bloom  wrote:
>> > >>
>> > >> On Wed, Jul 8, 2020 at 6:53 AM Sebastian Huber
>> > >>  wrote:
>> > >> >
>> > >> > On 08/07/2020 14:43, Utkarsh Rai wrote:
>> > >> >
>> > >> > > Hello,
>> > >> > > For my GSoC project, I have to provide high-level APIs for sharing
>> > >> > > isolated stacks.
>> > >> > > The POSIX compliant high-level way of sharing stacks can be to 
>> > >> > > create
>> > >> > > a shared memory object of the stack to be shared through shm_open 
>> > >> > > and
>> > >> > > then mmap that to the address space of the current stack. My doubt 
>> > >> > > is,
>> > >> > > shm_open() takes the path-name of the shared memory object. Since 
>> > >> > > this
>> > >> > > is a high-level API, how does the user 'convert' the stack address 
>> > >> > > to
>> > >> > > a shared memory object name?
>> > >> > Do we need any POSIX compatibility for this? What would you do in a
>> > >> > POSIX environment? You first get some memory, then hand it over to
>> > >> > shm_open() to get a file descriptor, then use the file descriptor in
>> > >> > mmap(), then use this for pthread_attr_setstack() and whatever?
>> > >>
>> > >> Yes, but the way to name objects is not set by posix.
>> > >>
>> > >> We need to provide our own way of translating an address into a name.
>> > >>
>> > >> > >
>> > >> > > Dr.Gedare mentioned that one way to deal with naming would be
>> > >> > > something like Mr.Sebastian has been doing with specifications. From
>> > >> > > what I could gather, it is a hierarchical way of representing
>> > >> > > objects(Though, I am not very sure if  I understand this 
>> > >> > > accurately).
>> > >> > > How can something like this be implemented for naming 
>> > >> > > stack-addresses?
>> > >> > I am not sure if the specification of RTEMS is helpful in this 
>> > >> > context.
>> > >>
>> > >> I should have provided a little bit more guidance. I was thinking out
>> > >> loud in yesterday's IRC meeting. My thought was more along the lines
>> > >> of looking at how UIDs/naming should be done, and that specs had to
>> > >> solve a naming problem. However the static nature of specs is not a
>> > >> great fit to this problem.
>> > >>
>> > >> Actually, what is a good model would be something like /proc or
>> > >> Linux's sysfs. An IMFS filesystem that exports task information could
>> > >> be used to name memory regions. (It could eventually supplant
>> > >> task-based statistics reporting too.)
>> > >>
>> > >> Another idea I had though, which seems to have been lost in the
>> > >> shuffle, is to look at how the object names work in RTEMS and see if
>> > >> we can add some fixed relationships, e.g., task_name # stack.
>> > >>
>> > >> I think we should start by just treating the entire task stack as a
>> > >> single named object; either it is all shared, or none of it is shared.
>> > >> This will be easier to implement and also more widely supported by
>> > >> simpler MPU/MMU hardware. Later on, we can consider extending the
>> > >> namespace with 'offsets' /taskfs/IDLE/stack/0A28
>> > >> could be a location at byte A28 offset from the start of the stack of
>> > >> the IDLE task.
>> > >>
>> > >
>> > > I have a few questions -
>> > >
>> > > > Users would get the stack address of the stack they want to share 
>> > > > through pthread_attr_getstack(). Now, when they get the address they 
>> > > > want to share, they would pass the appropriate name of this 
>> > > > memory-region. What we have to provide is a mechanism to 'convert' 
>> > > > this address to an appropriate name. Is this the accepted way or the 
>> > > > other way round, i.e. the user passes a name as per a specified 
>> > > > convention, and that name is 'converted' to a specific address?
>> > >
>> > We may want both to work. You definitely want to have the
>> > address->name working though, at the very least with the base address
>> > returned by pthread_attr_getstack, but you might also want to be able
>> > to map any address in a task's stack to the stack's "name". I'm not
>> > sure if that is needed yet, but keep it in mind as a possible
>> > extension later to use an address interval instead of a fixed base
>> > address.
>> >
>>
>> One more clarification, the "name to address" conversion should be
>> done within the shm+mmap implementation. shm takes a name and returns
>> a fd, mmap takes an fd and returns an address.
>
>
> Got it.
>
>>
>> > > > When you say "treating the entire task stack as a single named object" 
>> > > > does it mean that we assign a single name, say "task_stack" to the 
>> > > > complete stack address space? In that case, how do we deal we the 
>> > > > presence of multiple tasks that are allocated from the same pool of

Re: [PATCH rtems-littlevgl] Allow to pass custom lv_conf.h and lv_drv_conf.h.

2020-07-09 Thread Vijay Kumar Banerjee

Hi,

Thanks for the patch, I tested the patch and it's building fine. I
just had two questions which I have inlined below.

On Thu, Jul 9, 2020 at 9:13 PM Christian Mauderer
 wrote:
>
> ---
>  lv_conf.h => default_lv_conf.h |  0
>  lv_drv_conf.h => default_lv_drv_conf.h |  0
>  lvgl.py| 19 ---
>  wscript| 13 +
>  4 files changed, 29 insertions(+), 3 deletions(-)
>  rename lv_conf.h => default_lv_conf.h (100%)
>  rename lv_drv_conf.h => default_lv_drv_conf.h (100%)
>
> diff --git a/lv_conf.h b/default_lv_conf.h
> similarity index 100%
> rename from lv_conf.h
> rename to default_lv_conf.h
> diff --git a/lv_drv_conf.h b/default_lv_drv_conf.h
> similarity index 100%
> rename from lv_drv_conf.h
> rename to default_lv_drv_conf.h
> diff --git a/lvgl.py b/lvgl.py
> index c154a5e..6d55db7 100644
> --- a/lvgl.py
> +++ b/lvgl.py
> @@ -73,6 +73,17 @@ def build(bld):
>  includes.append('.')
>  include_paths = []
>
> +def write_stuff(stuff):
> +def stuff_writer(task):
> +task.outputs[0].write(stuff)
> +return stuff_writer
> +
> +lv_conf_h='lv_conf.h'
> +lv_drv_conf_h='lv_drv_conf.h'
> +
> +bld(rule=write_stuff(bld.env.LV_CONF), target=lv_conf_h)
> +bld(rule=write_stuff(bld.env.LV_DRV_CONF), target=lv_drv_conf_h)
> +
>  for source in sources:
>  source_dir = os.path.dirname(source)
>  if source_dir not in include_paths:
> @@ -80,7 +91,7 @@ def build(bld):
>
>  bld.stlib(target = 'lvgl',
>features = 'c',
> -  cflags = ['-O2', '-g'],
> +  cflags = ['-O2', '-g', '-DLV_CONF_INCLUDE_SIMPLE'],
>includes = includes,
>source = sources)
>
> @@ -96,6 +107,8 @@ def build(bld):
>  for include_path in include_paths:
>  files = os.listdir(include_path)
>  include_headers = [os.path.join(include_path, x) for x in files if 
> (x[-2:] == '.h')]
> -bld.install_files(os.path.join("${PREFIX}/" , arch_inc_path, 
> include_path),
> +bld.install_files(os.path.join("${PREFIX}", arch_inc_path, 
> include_path),
>include_headers)
> -bld.install_files('${PREFIX}/' + arch_lib_path, ["liblvgl.a"])
> +bld.install_files(os.path.join('${PREFIX}', arch_lib_path), 
> ["liblvgl.a"])
> +bld.install_files(os.path.join('${PREFIX}', arch_inc_path, include_path),
> +[lv_conf_h])

Should lv_drv_conf_h be installed as well?

> diff --git a/wscript b/wscript
> index ae91daa..0e1a51d 100644
> --- a/wscript
> +++ b/wscript
> @@ -49,9 +49,22 @@ def options(opt):
> dest = "drivers",
> help = "Build without lv_drivers." +
>"Useful for building without libbsd.")
> +opt.add_option("--lv-conf",
> +   default = "default_lv_conf.h",
> +   dest = "lv_conf",
> +   help = "Use a custom lv_conf.h instead of the default 
> one.")
> +opt.add_option("--lv-drv-conf",
> +   default = "default_lv_drv_conf.h",
> +   dest = "lv_drv_conf",
> +   help = "Use a custom lv_drv_conf.h instead of the default 
> one.")
>
>  def configure(conf):
>  conf.env.DRIVERS = conf.options.drivers
> +with open(conf.options.lv_conf, "rb") as lv_conf:
> +conf.env.LV_CONF = lv_conf.read()
> +with open(conf.options.lv_drv_conf, "rb") as lv_drv_conf:
> +conf.env.LV_DRV_CONF = lv_drv_conf.read()
> +conf.env.BUILDINCLUDE = 'build-include'

It's not clear to me where is build-include being used. It builds fine
without this line, should it be removed from the patch?


Thanks for working on this feature, it was much needed.

Best regards,
Vijay

>  rtems.configure(conf)
>
>  def build(bld):
> --
> 2.26.2
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] lvgl: Update to v7.1.0

2020-07-09 Thread Christian Mauderer

Thanks for testing it.

On 09/07/2020 17:06, Vijay Kumar Banerjee wrote:
> Hi Christian,
> 
> I tested the patch and it's running fine with the example applications
> on BBB. Thanks for the patch.
> 
> Best regards,
> Vijay
> 
> On Thu, Jul 9, 2020 at 5:34 PM Christian Mauderer
>  wrote:
>>
>> ---
>>  lv_conf.h  | 337 +++--
>>  lv_drivers |   2 +-
>>  lvgl   |   2 +-
>>  lvgl.py|   3 +-
>>  4 files changed, 281 insertions(+), 63 deletions(-)
>>
>> diff --git a/lv_conf.h b/lv_conf.h
>> index 7453905..9299fdc 100644
>> --- a/lv_conf.h
>> +++ b/lv_conf.h
>> @@ -1,6 +1,6 @@
>>  /**
>>   * @file lv_conf.h
>> - *
>> + * Configuration file for LVGL v7.1.0
>>   */
>>
>>  /*
>> @@ -25,7 +25,7 @@
>>
>>  /* Color depth:
>>   * - 1:  1 byte per pixel
>> - * - 8:  RGB233
>> + * - 8:  RGB332
>>   * - 16: RGB565
>>   * - 32: ARGB
>>   */
>> @@ -53,7 +53,18 @@
>>  /* Dot Per Inch: used to initialize default sizes.
>>   * E.g. a button with width = LV_DPI / 2 -> half inch wide
>>   * (Not so important, you can adjust it to modify default sizes and 
>> spaces)*/
>> -#define LV_DPI  100 /*[px]*/
>> +#define LV_DPI  130 /*[px]*/
>> +
>> +/* The the real width of the display changes some default values:
>> + * default object sizes, layout of examples, etc.
>> + * According to the width of the display (hor. res. / dpi)
>> + * the displays fall in 4 categories.
>> + * The 4th is extra large which has no upper limit so not listed here
>> + * The upper limit of the categories are set below in 0.1 inch unit.
>> + */
>> +#define LV_DISP_SMALL_LIMIT  30
>> +#define LV_DISP_MEDIUM_LIMIT 50
>> +#define LV_DISP_LARGE_LIMIT  70
>>
>>  /* Type of coordinates. Should be `int16_t` (or `int32_t` for extreme 
>> cases) */
>>  typedef int16_t lv_coord_t;
>> @@ -109,7 +120,7 @@ typedef int16_t lv_coord_t;
>>  #define LV_INDEV_DEF_DRAG_LIMIT   10
>>
>>  /* Drag throw slow-down in [%]. Greater value -> faster slow-down */
>> -#define LV_INDEV_DEF_DRAG_THROW   20
>> +#define LV_INDEV_DEF_DRAG_THROW   10
>>
>>  /* Long press time in milliseconds.
>>   * Time to send `LV_EVENT_LONG_PRESSSED`) */
>> @@ -119,6 +130,13 @@ typedef int16_t lv_coord_t;
>>   * Time between `LV_EVENT_LONG_PRESSED_REPEAT */
>>  #define LV_INDEV_DEF_LONG_PRESS_REP_TIME  100
>>
>> +
>> +/* Gesture threshold in pixels */
>> +#define LV_INDEV_DEF_GESTURE_LIMIT50
>> +
>> +/* Gesture min velocity at release before swipe (pixels)*/
>> +#define LV_INDEV_DEF_GESTURE_MIN_VELOCITY 3
>> +
>>  /*==
>>   * Feature usage
>>   *==*/
>> @@ -134,6 +152,22 @@ typedef void * lv_anim_user_data_t;
>>
>>  /* 1: Enable shadow drawing*/
>>  #define LV_USE_SHADOW   1
>> +#if LV_USE_SHADOW
>> +/* Allow buffering some shadow calculation
>> + * LV_SHADOW_CACHE_SIZE is the max. shadow size to buffer,
>> + * where shadow size is `shadow_width + radius`
>> + * Caching has LV_SHADOW_CACHE_SIZE^2 RAM cost*/
>> +#define LV_SHADOW_CACHE_SIZE0
>> +#endif
>> +
>> +/* 1: Use other blend modes than normal (`LV_BLEND_MODE_...`)*/
>> +#define LV_USE_BLEND_MODES  1
>> +
>> +/* 1: Use the `opa_scale` style property to set the opacity of an object 
>> and its children at once*/
>> +#define LV_USE_OPA_SCALE1
>> +
>> +/* 1: Use image zoom and rotation*/
>> +#define LV_USE_IMG_TRANSFORM1
>>
>>  /* 1: Enable object groups (for keyboard/encoder navigation) */
>>  #define LV_USE_GROUP1
>> @@ -142,7 +176,11 @@ typedef void * lv_group_user_data_t;
>>  #endif  /*LV_USE_GROUP*/
>>
>>  /* 1: Enable GPU interface*/
>> -#define LV_USE_GPU  1
>> +#define LV_USE_GPU  1   /*Only enables `gpu_fill_cb` and 
>> `gpu_blend_cb` in the disp. drv- */
>> +#define LV_USE_GPU_STM32_DMA2D  0
>> +/*If enabling LV_USE_GPU_STM32_DMA2D, LV_GPU_DMA2D_CMSIS_INCLUDE must be 
>> defined to include path of CMSIS header of target processor
>> +e.g. "stm32f769xx.h" or "stm32f429xx.h" */
>> +#define LV_GPU_DMA2D_CMSIS_INCLUDE
>>
>>  /* 1: Enable file system (might be required for images */
>>  #define LV_USE_FILESYSTEM   1
>> @@ -154,6 +192,12 @@ typedef void * lv_fs_drv_user_data_t;
>>  /*1: Add a `user_data` to drivers and objects*/
>>  #define LV_USE_USER_DATA1
>>
>> +/*1: Show CPU usage and FPS count in the right bottom corner*/
>> +#define LV_USE_PERF_MONITOR 0
>> +
>> +/*1: Use the functions and types from the older API if possible */
>> +#define LV_USE_API_EXTENSION_V6  1
>> +
>>  /*
>>   * Image decoder and cache
>>   **/
>> @@ -178,12 +222,19 @@ typedef void * lv_img_decoder_user_data_t;
>>  /*=
>>   *  Compiler settings
>>   **/
>> +
>> +/* For big endian systems set to 1 */
>> +#define LV_BIG_ENDIAN_SYSTEM0
>> +
>>  /* Define a custom attribute to `lv_tick_inc` function */
>>  #define LV_ATTRIBUTE_TICK_INC
>>
>>  /* Define a

Re: [PATCH rtems-littlevgl] Allow to pass custom lv_conf.h and lv_drv_conf.h.

2020-07-09 Thread Christian Mauderer

Hello Vijay,

thanks for the review and the test.

On 09/07/2020 19:58, Vijay Kumar Banerjee wrote:
> Hi,
> 
> Thanks for the patch, I tested the patch and it's building fine. I
> just had two questions which I have inlined below.
> 
> On Thu, Jul 9, 2020 at 9:13 PM Christian Mauderer
>  wrote:
>>
>> ---
>>  lv_conf.h => default_lv_conf.h |  0
>>  lv_drv_conf.h => default_lv_drv_conf.h |  0
>>  lvgl.py| 19 ---
>>  wscript| 13 +
>>  4 files changed, 29 insertions(+), 3 deletions(-)
>>  rename lv_conf.h => default_lv_conf.h (100%)
>>  rename lv_drv_conf.h => default_lv_drv_conf.h (100%)
>>
>> diff --git a/lv_conf.h b/default_lv_conf.h
>> similarity index 100%
>> rename from lv_conf.h
>> rename to default_lv_conf.h
>> diff --git a/lv_drv_conf.h b/default_lv_drv_conf.h
>> similarity index 100%
>> rename from lv_drv_conf.h
>> rename to default_lv_drv_conf.h
>> diff --git a/lvgl.py b/lvgl.py
>> index c154a5e..6d55db7 100644
>> --- a/lvgl.py
>> +++ b/lvgl.py
>> @@ -73,6 +73,17 @@ def build(bld):
>>  includes.append('.')
>>  include_paths = []
>>
>> +def write_stuff(stuff):
>> +def stuff_writer(task):
>> +task.outputs[0].write(stuff)
>> +return stuff_writer
>> +
>> +lv_conf_h='lv_conf.h'
>> +lv_drv_conf_h='lv_drv_conf.h'
>> +
>> +bld(rule=write_stuff(bld.env.LV_CONF), target=lv_conf_h)
>> +bld(rule=write_stuff(bld.env.LV_DRV_CONF), target=lv_drv_conf_h)
>> +
>>  for source in sources:
>>  source_dir = os.path.dirname(source)
>>  if source_dir not in include_paths:
>> @@ -80,7 +91,7 @@ def build(bld):
>>
>>  bld.stlib(target = 'lvgl',
>>features = 'c',
>> -  cflags = ['-O2', '-g'],
>> +  cflags = ['-O2', '-g', '-DLV_CONF_INCLUDE_SIMPLE'],
>>includes = includes,
>>source = sources)
>>
>> @@ -96,6 +107,8 @@ def build(bld):
>>  for include_path in include_paths:
>>  files = os.listdir(include_path)
>>  include_headers = [os.path.join(include_path, x) for x in files if 
>> (x[-2:] == '.h')]
>> -bld.install_files(os.path.join("${PREFIX}/" , arch_inc_path, 
>> include_path),
>> +bld.install_files(os.path.join("${PREFIX}", arch_inc_path, 
>> include_path),
>>include_headers)
>> -bld.install_files('${PREFIX}/' + arch_lib_path, ["liblvgl.a"])
>> +bld.install_files(os.path.join('${PREFIX}', arch_lib_path), 
>> ["liblvgl.a"])
>> +bld.install_files(os.path.join('${PREFIX}', arch_inc_path, 
>> include_path),
>> +[lv_conf_h])
> 
> Should lv_drv_conf_h be installed as well?

I haven't seen that it is used but I can install it too. I didn't test
all drivers.

> 
>> diff --git a/wscript b/wscript
>> index ae91daa..0e1a51d 100644
>> --- a/wscript
>> +++ b/wscript
>> @@ -49,9 +49,22 @@ def options(opt):
>> dest = "drivers",
>> help = "Build without lv_drivers." +
>>"Useful for building without libbsd.")
>> +opt.add_option("--lv-conf",
>> +   default = "default_lv_conf.h",
>> +   dest = "lv_conf",
>> +   help = "Use a custom lv_conf.h instead of the default 
>> one.")
>> +opt.add_option("--lv-drv-conf",
>> +   default = "default_lv_drv_conf.h",
>> +   dest = "lv_drv_conf",
>> +   help = "Use a custom lv_drv_conf.h instead of the 
>> default one.")
>>
>>  def configure(conf):
>>  conf.env.DRIVERS = conf.options.drivers
>> +with open(conf.options.lv_conf, "rb") as lv_conf:
>> +conf.env.LV_CONF = lv_conf.read()
>> +with open(conf.options.lv_drv_conf, "rb") as lv_drv_conf:
>> +conf.env.LV_DRV_CONF = lv_drv_conf.read()
>> +conf.env.BUILDINCLUDE = 'build-include'
> 
> It's not clear to me where is build-include being used. It builds fine
> without this line, should it be removed from the patch?
> 

That is a part of a dead end during writing the patch. I missed to
remove it. Thanks for finding it.

Best regards

Christian

> 
> Thanks for working on this feature, it was much needed.
> 
> Best regards,
> Vijay
> 
>>  rtems.configure(conf)
>>
>>  def build(bld):
>> --
>> 2.26.2
>>
> ___
> 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: [PATCH rtems-littlevgl] Allow to pass custom lv_conf.h and lv_drv_conf.h.

2020-07-09 Thread Vijay Kumar Banerjee

On Fri, Jul 10, 2020, 12:11 AM Christian Mauderer  wrote:

> Hello Vijay,
>
> thanks for the review and the test.
>
> On 09/07/2020 19:58, Vijay Kumar Banerjee wrote:
> > Hi,
> >
> > Thanks for the patch, I tested the patch and it's building fine. I
> > just had two questions which I have inlined below.
> >
> > On Thu, Jul 9, 2020 at 9:13 PM Christian Mauderer
> >  wrote:
> >>
> >> ---
> >>  lv_conf.h => default_lv_conf.h |  0
> >>  lv_drv_conf.h => default_lv_drv_conf.h |  0
> >>  lvgl.py| 19 ---
> >>  wscript| 13 +
> >>  4 files changed, 29 insertions(+), 3 deletions(-)
> >>  rename lv_conf.h => default_lv_conf.h (100%)
> >>  rename lv_drv_conf.h => default_lv_drv_conf.h (100%)
> >>
> >> diff --git a/lv_conf.h b/default_lv_conf.h
> >> similarity index 100%
> >> rename from lv_conf.h
> >> rename to default_lv_conf.h
> >> diff --git a/lv_drv_conf.h b/default_lv_drv_conf.h
> >> similarity index 100%
> >> rename from lv_drv_conf.h
> >> rename to default_lv_drv_conf.h
> >> diff --git a/lvgl.py b/lvgl.py
> >> index c154a5e..6d55db7 100644
> >> --- a/lvgl.py
> >> +++ b/lvgl.py
> >> @@ -73,6 +73,17 @@ def build(bld):
> >>  includes.append('.')
> >>  include_paths = []
> >>
> >> +def write_stuff(stuff):
> >> +def stuff_writer(task):
> >> +task.outputs[0].write(stuff)
> >> +return stuff_writer
> >> +
> >> +lv_conf_h='lv_conf.h'
> >> +lv_drv_conf_h='lv_drv_conf.h'
> >> +
> >> +bld(rule=write_stuff(bld.env.LV_CONF), target=lv_conf_h)
> >> +bld(rule=write_stuff(bld.env.LV_DRV_CONF), target=lv_drv_conf_h)
> >> +
> >>  for source in sources:
> >>  source_dir = os.path.dirname(source)
> >>  if source_dir not in include_paths:
> >> @@ -80,7 +91,7 @@ def build(bld):
> >>
> >>  bld.stlib(target = 'lvgl',
> >>features = 'c',
> >> -  cflags = ['-O2', '-g'],
> >> +  cflags = ['-O2', '-g', '-DLV_CONF_INCLUDE_SIMPLE'],
> >>includes = includes,
> >>source = sources)
> >>
> >> @@ -96,6 +107,8 @@ def build(bld):
> >>  for include_path in include_paths:
> >>  files = os.listdir(include_path)
> >>  include_headers = [os.path.join(include_path, x) for x in
> files if (x[-2:] == '.h')]
> >> -bld.install_files(os.path.join("${PREFIX}/" , arch_inc_path,
> include_path),
> >> +bld.install_files(os.path.join("${PREFIX}", arch_inc_path,
> include_path),
> >>include_headers)
> >> -bld.install_files('${PREFIX}/' + arch_lib_path, ["liblvgl.a"])
> >> +bld.install_files(os.path.join('${PREFIX}', arch_lib_path),
> ["liblvgl.a"])
> >> +bld.install_files(os.path.join('${PREFIX}', arch_inc_path,
> include_path),
> >> +[lv_conf_h])
> >
> > Should lv_drv_conf_h be installed as well?
>
> I haven't seen that it is used but I can install it too. I didn't test
> all drivers.
>
One use case would be to check if USE_BSD_FBDEV (Or some other driver) is
defined. The example apps assumed that both evdev and fbdev is defined
since the conf was fixed. I think they would need some check to ensure it
is defined.

> >
> >> diff --git a/wscript b/wscript
> >> index ae91daa..0e1a51d 100644
> >> --- a/wscript
> >> +++ b/wscript
> >> @@ -49,9 +49,22 @@ def options(opt):
> >> dest = "drivers",
> >> help = "Build without lv_drivers." +
> >>"Useful for building without libbsd.")
> >> +opt.add_option("--lv-conf",
> >> +   default = "default_lv_conf.h",
> >> +   dest = "lv_conf",
> >> +   help = "Use a custom lv_conf.h instead of the
> default one.")
> >> +opt.add_option("--lv-drv-conf",
> >> +   default = "default_lv_drv_conf.h",
> >> +   dest = "lv_drv_conf",
> >> +   help = "Use a custom lv_drv_conf.h instead of the
> default one.")
> >>
> >>  def configure(conf):
> >>  conf.env.DRIVERS = conf.options.drivers
> >> +with open(conf.options.lv_conf, "rb") as lv_conf:
> >> +conf.env.LV_CONF = lv_conf.read()
> >> +with open(conf.options.lv_drv_conf, "rb") as lv_drv_conf:
> >> +conf.env.LV_DRV_CONF = lv_drv_conf.read()
> >> +conf.env.BUILDINCLUDE = 'build-include'
> >
> > It's not clear to me where is build-include being used. It builds fine
> > without this line, should it be removed from the patch?
> >
>
> That is a part of a dead end during writing the patch. I missed to
> remove it. Thanks for finding it.
>
> Best regards
>
> Christian
>
> >
> > Thanks for working on this feature, it was much needed.
> >
> > Best regards,
> > Vijay
> >
> >>  rtems.configure(conf)
> >>
> >>  def build(bld):
> >> --
> >> 2.26.2
> >>
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mail

Re: [PATCH rtems-littlevgl] Allow to pass custom lv_conf.h and lv_drv_conf.h.

2020-07-09 Thread Christian Mauderer

On 09/07/2020 20:52, Vijay Kumar Banerjee wrote:
> 
> 
> On Fri, Jul 10, 2020, 12:11 AM Christian Mauderer  > wrote:
> 
> Hello Vijay,
> 
> thanks for the review and the test.
> 
> On 09/07/2020 19:58, Vijay Kumar Banerjee wrote:
> > Hi,
> >
> > Thanks for the patch, I tested the patch and it's building fine. I
> > just had two questions which I have inlined below.
> >
> > On Thu, Jul 9, 2020 at 9:13 PM Christian Mauderer
> >  > wrote:
> >>
> >> ---
> >>  lv_conf.h => default_lv_conf.h         |  0
> >>  lv_drv_conf.h => default_lv_drv_conf.h |  0
> >>  lvgl.py                                | 19 ---
> >>  wscript                                | 13 +
> >>  4 files changed, 29 insertions(+), 3 deletions(-)
> >>  rename lv_conf.h => default_lv_conf.h (100%)
> >>  rename lv_drv_conf.h => default_lv_drv_conf.h (100%)
> >>
> >> diff --git a/lv_conf.h b/default_lv_conf.h
> >> similarity index 100%
> >> rename from lv_conf.h
> >> rename to default_lv_conf.h
> >> diff --git a/lv_drv_conf.h b/default_lv_drv_conf.h
> >> similarity index 100%
> >> rename from lv_drv_conf.h
> >> rename to default_lv_drv_conf.h
> >> diff --git a/lvgl.py b/lvgl.py
> >> index c154a5e..6d55db7 100644
> >> --- a/lvgl.py
> >> +++ b/lvgl.py
> >> @@ -73,6 +73,17 @@ def build(bld):
> >>      includes.append('.')
> >>      include_paths = []
> >>
> >> +    def write_stuff(stuff):
> >> +        def stuff_writer(task):
> >> +            task.outputs[0].write(stuff)
> >> +        return stuff_writer
> >> +
> >> +    lv_conf_h='lv_conf.h'
> >> +    lv_drv_conf_h='lv_drv_conf.h'
> >> +
> >> +    bld(rule=write_stuff(bld.env.LV_CONF), target=lv_conf_h)
> >> +    bld(rule=write_stuff(bld.env.LV_DRV_CONF), target=lv_drv_conf_h)
> >> +
> >>      for source in sources:
> >>          source_dir = os.path.dirname(source)
> >>          if source_dir not in include_paths:
> >> @@ -80,7 +91,7 @@ def build(bld):
> >>
> >>      bld.stlib(target = 'lvgl',
> >>                features = 'c',
> >> -              cflags = ['-O2', '-g'],
> >> +              cflags = ['-O2', '-g', '-DLV_CONF_INCLUDE_SIMPLE'],
> >>                includes = includes,
> >>                source = sources)
> >>
> >> @@ -96,6 +107,8 @@ def build(bld):
> >>      for include_path in include_paths:
> >>          files = os.listdir(include_path)
> >>          include_headers = [os.path.join(include_path, x) for x
> in files if (x[-2:] == '.h')]
> >> -        bld.install_files(os.path.join("${PREFIX}/" ,
> arch_inc_path, include_path),
> >> +        bld.install_files(os.path.join("${PREFIX}",
> arch_inc_path, include_path),
> >>                            include_headers)
> >> -    bld.install_files('${PREFIX}/' + arch_lib_path, ["liblvgl.a"])
> >> +    bld.install_files(os.path.join('${PREFIX}', arch_lib_path),
> ["liblvgl.a"])
> >> +    bld.install_files(os.path.join('${PREFIX}', arch_inc_path,
> include_path),
> >> +        [lv_conf_h])
> >
> > Should lv_drv_conf_h be installed as well?
> 
> I haven't seen that it is used but I can install it too. I didn't test
> all drivers.
> 
> One use case would be to check if USE_BSD_FBDEV (Or some other driver)
> is defined. The example apps assumed that both evdev and fbdev is
> defined since the conf was fixed. I think they would need some check to
> ensure it is defined.

I think it is OK for the example apps to use the default configuration
used in RTEMS. But it's a good point. I'll add the lv_drv_conf.h to the
installed headers too before I push the commit.

> 
> >
> >> diff --git a/wscript b/wscript
> >> index ae91daa..0e1a51d 100644
> >> --- a/wscript
> >> +++ b/wscript
> >> @@ -49,9 +49,22 @@ def options(opt):
> >>                     dest = "drivers",
> >>                     help = "Build without lv_drivers." +
> >>                            "Useful for building without libbsd.")
> >> +    opt.add_option("--lv-conf",
> >> +                   default = "default_lv_conf.h",
> >> +                   dest = "lv_conf",
> >> +                   help = "Use a custom lv_conf.h instead of the
> default one.")
> >> +    opt.add_option("--lv-drv-conf",
> >> +                   default = "default_lv_drv_conf.h",
> >> +                   dest = "lv_drv_conf",
> >> +                   help = "Use a custom lv_drv_conf.h instead of
> the default one.")
> >>
> >>  def configure(conf):
> >>      conf.env.DRIVERS = conf.options.drivers
> >> +    with open(conf.options.lv_conf, "rb") as lv_conf:
> >> +        conf.env.LV_CONF = lv_conf.read()
> >>

Re: make error on 5 branch?

2020-07-09 Thread Gedare Bloom

It turns out there are some changes in my rtems.git/5 HEAD. I don't
know how they got there. Maybe just some leftover changes while
switching branches. curious, but I cleaned up the branch and things
are working.

I don't know if there's a way to make a warning appear for a dirty
tree. just something to keep an eye on I guess.

For those curious:

$ git status
modified:   c/src/lib/libbsp/arm/acinclude.m4
modified:   c/src/lib/libbsp/bfin/acinclude.m4
modified:   c/src/lib/libbsp/epiphany/acinclude.m4
modified:   c/src/lib/libbsp/i386/acinclude.m4
modified:   c/src/lib/libbsp/lm32/acinclude.m4
modified:   c/src/lib/libbsp/m68k/acinclude.m4
modified:   c/src/lib/libbsp/mips/acinclude.m4
modified:   c/src/lib/libbsp/moxie/acinclude.m4
modified:   c/src/lib/libbsp/nios2/acinclude.m4
modified:   c/src/lib/libbsp/no_cpu/acinclude.m4
modified:   c/src/lib/libbsp/or1k/acinclude.m4
modified:   c/src/lib/libbsp/powerpc/acinclude.m4
modified:   c/src/lib/libbsp/riscv/acinclude.m4
modified:   c/src/lib/libbsp/sh/acinclude.m4
modified:   c/src/lib/libbsp/sparc/acinclude.m4
modified:   c/src/lib/libbsp/sparc64/acinclude.m4
modified:   c/src/lib/libbsp/v850/acinclude.m4
modified:   c/src/lib/libbsp/x86_64/acinclude.m4

[...]

$ git diff c/src/lib/libbsp/sparc/acinclude.m4
diff --git a/c/src/lib/libbsp/sparc/acinclude.m4
b/c/src/lib/libbsp/sparc/acinclude.m4
index 4d40305601..296a6f7882 100644
--- a/c/src/lib/libbsp/sparc/acinclude.m4
+++ b/c/src/lib/libbsp/sparc/acinclude.m4
@@ -2,12 +2,6 @@
 AC_DEFUN([RTEMS_CHECK_BSPDIR],
 [
   case "$1" in
-  erc32 )
-AC_CONFIG_SUBDIRS([erc32]);;
-  leon2 )
-AC_CONFIG_SUBDIRS([leon2]);;
-  leon3 )
-AC_CONFIG_SUBDIRS([leon3]);;
   *)
 AC_MSG_ERROR([Invalid BSP]);;
   esac


On Thu, Jul 9, 2020 at 9:58 AM Gedare Bloom  wrote:
>
> I built/installed clean tools from rsb/5 and bootstrapped rtems/5 then:
> ../../rtems/configure --prefix=/home/gedare/development/rtems/5
> --target=sparc-rtems5 --enable-rtemsbsp=erc32 --enable-posix
> --enable-tests
> [...] looks ok
> make
> [...]
> checking for RTEMS_BSP... erc32
> configure: error: Invalid BSP
> configure: error:
> ../../../../../../../../rtems/c/src/lib/libbsp/sparc/configure failed
> for lib/libbsp/sparc
> Makefile:731: recipe for target 'erc32' failed
>
> Can anyone reproduce?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Test suite for FTW.H methods

2020-07-09 Thread Eshan dhawan

It mainly uses nftw to test
as ftw also calls nftw with flag as 0

Signed-off-by: Eshan dhawan 
---
 testsuites/psxtests/Makefile.am   |  26 +++
 testsuites/psxtests/configure.ac  |   1 +
 testsuites/psxtests/psxftw01/init.c   | 204 ++
 testsuites/psxtests/psxftw01/psxftw01.doc |  18 ++
 testsuites/psxtests/psxftw01/psxftw01.scn |  10 ++
 testsuites/psxtests/psxftw01/psxftw01.tar | Bin 0 -> 10240 bytes
 6 files changed, 259 insertions(+)
 create mode 100644 testsuites/psxtests/psxftw01/init.c
 create mode 100644 testsuites/psxtests/psxftw01/psxftw01.doc
 create mode 100644 testsuites/psxtests/psxftw01/psxftw01.scn
 create mode 100644 testsuites/psxtests/psxftw01/psxftw01.tar

diff --git a/testsuites/psxtests/Makefile.am b/testsuites/psxtests/Makefile.am
index 1f9e4233ec..39a6995827 100755
--- a/testsuites/psxtests/Makefile.am
+++ b/testsuites/psxtests/Makefile.am
@@ -453,6 +453,32 @@ psxfilelock01_CPPFLAGS = $(AM_CPPFLAGS) 
$(TEST_FLAGS_psxfilelock01) \
$(support_includes)
 endif
 
+if TEST_psxftw01
+psx_tests += psxftw01
+psx_screens += psxftw01/psxftw01.scn
+psx_docs += psxftw01/psxftw01.doc
+psxftw01_SOURCES = psxftw01/init.c psxfile01/test_cat.c \
+   psxftw01-tar.c psxftw01-tar.h psxftw01-tar-gz.c psxftw01-tar-gz.h
+
+psxftw01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxftw01) \
+   $(support_includes) $(test_includes) -I$(top_srcdir)/include
+psxftw01_LDADD = $(RTEMS_ROOT)cpukit/librtemscpu.a $(RTEMS_ROOT)cpukit/libz.a 
$(LDADD)
+psxftw01-tar.c: psxftw01/psxftw01.tar
+   $(AM_V_GEN)$(BIN2C) -C $< $@
+psxftw01-tar.h: psxftw01/psxftw01.tar
+   $(AM_V_GEN)$(BIN2C) -H $< $@
+psxftw01-tar.o: psxftw01-tar.c psxftw01-tar.h
+psxftw01.tar.gz: psxftw01/psxftw01.tar
+   $(AM_V_GEN)$(GZIP) < $< > $@
+psxftw01-tar-gz.c: psxftw01.tar.gz
+   $(AM_V_GEN)$(BIN2C) -C $< $@
+psxftw01-tar-gz.h: psxftw01.tar.gz
+   $(AM_V_GEN)$(BIN2C) -H $< $@
+CLEANFILES += psxftw01.tar psxftw01-tar.c psxftw01-tar.h \
+   psxftw01.tar.gz psxftw01-tar-gz.c psxftw01-tar-gz.h
+psxftw01/init.c: psxftw01-tar.h psxftw01-tar-gz.h $(TAR01_XZ_H)
+endif
+
 if TEST_psxgetattrnp01
 psx_tests += psxgetattrnp01
 psx_screens += psxgetattrnp01/psxgetattrnp01.scn
diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/configure.ac
index 139787cccb..3f95010cd3 100644
--- a/testsuites/psxtests/configure.ac
+++ b/testsuites/psxtests/configure.ac
@@ -90,6 +90,7 @@ RTEMS_TEST_CHECK([psxfenv01])
 RTEMS_TEST_CHECK([psxfile01])
 RTEMS_TEST_CHECK([psxfile02])
 RTEMS_TEST_CHECK([psxfilelock01])
+RTEMS_TEST_CHECK([psxftw01])
 RTEMS_TEST_CHECK([psxgetattrnp01])
 RTEMS_TEST_CHECK([psxgetrusage01])
 RTEMS_TEST_CHECK([psxglobalcon01])
diff --git a/testsuites/psxtests/psxftw01/init.c 
b/testsuites/psxtests/psxftw01/init.c
new file mode 100644
index 00..8e7e996d10
--- /dev/null
+++ b/testsuites/psxtests/psxftw01/init.c
@@ -0,0 +1,204 @@
+/*
+ *  @file
+ *  @brief Test suite for ftw.h methods
+ */
+
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2020 Eshan Dhawan, embedded brains GmbH, Joel Sherrill
+ *
+ * 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.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+/* Header files */
+#include  /* for device driver prototypes */
+#include "tmacros.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "psxftw01-tar.h"
+#include "psxftw01-tar-gz.h"
+
+#define TARFILE_STARTpsxftw01_tar
+#define TARFILE_SIZE psxftw01_tar_size
+#define TARFILE_GZ_START psxftw01_tar_gz
+#define TARFILE_GZ_SIZE  psxftw01_tar_gz_size
+
+const char rtems_test_name[] = "psxftw0

[PATCH] ftw.h port for newlib

2020-07-09 Thread Eshan dhawan

added _FTW_ENABLE_

Signed-off-by: Eshan dhawan 
---
 newlib/configure.host |   2 +-
 newlib/libc/include/ftw.h |  64 ++
 newlib/libc/posix/Makefile.am |   2 +-
 newlib/libc/posix/ftw.c   |  36 
 newlib/libc/posix/nftw.c  | 154 ++
 5 files changed, 256 insertions(+), 2 deletions(-)
 create mode 100644 newlib/libc/include/ftw.h
 create mode 100644 newlib/libc/posix/ftw.c
 create mode 100644 newlib/libc/posix/nftw.c

diff --git a/newlib/configure.host b/newlib/configure.host
index a84c0c80a..33a3175c7 100644
--- a/newlib/configure.host
+++ b/newlib/configure.host
@@ -661,7 +661,7 @@ case "${host}" in
default_newlib_io_c99_formats="yes"
newlib_cflags="${newlib_cflags} -ffunction-sections -fdata-sections "
newlib_cflags="${newlib_cflags} -D_COMPILING_NEWLIB"
-newlib_cflags="${newlib_cflags} -DCLOCK_PROVIDED -DMALLOC_PROVIDED 
-DEXIT_PROVIDED -DSIGNAL_PROVIDED -DGETREENT_PROVIDED 
-DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE -DHAVE_FCNTL 
-DHAVE_ASSERT_FUNC"
+newlib_cflags="${newlib_cflags} -DCLOCK_PROVIDED -DMALLOC_PROVIDED 
-DEXIT_PROVIDED -DSIGNAL_PROVIDED -DGETREENT_PROVIDED 
-DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE -DHAVE_FCNTL 
-DHAVE_ASSERT_FUNC -D_FTW_ENABLE_"
 # turn off unsupported items in posix directory 
newlib_cflags="${newlib_cflags} -D_NO_GETLOGIN -D_NO_GETPWENT 
-D_NO_GETUT -D_NO_GETPASS -D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN 
-D_NO_POSIX_SPAWN"
;;
diff --git a/newlib/libc/include/ftw.h b/newlib/libc/include/ftw.h
new file mode 100644
index 0..f88ce87b2
--- /dev/null
+++ b/newlib/libc/include/ftw.h
@@ -0,0 +1,64 @@
+/*
+* Copyright © 2005-2020 Rich Felker, et al.
+*
+* Permission is hereby granted, free of charge, to any person obtaining
+* a copy of this software and associated documentation files (the
+* "Software"), to deal in the Software without restriction, including
+* without limitation the rights to use, copy, modify, merge, publish,
+* distribute, sublicense, and/or sell copies of the Software, and to
+* permit persons to whom the Software is furnished to do so, subject to
+* the following conditions:
+*
+* The above copyright notice and this permission notice shall be
+* included in all copies or substantial portions of the Software.
+*
+* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+* IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
+* CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+* TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+* SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+*/
+
+#ifndef _FTW_H
+#define_FTW_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include 
+#include 
+
+#define FTW_F   1
+#define FTW_D   2
+#define FTW_DNR 3
+#define FTW_NS  4
+#define FTW_SL  5
+#define FTW_DP  6
+#define FTW_SLN 7
+
+#define FTW_PHYS  1
+#define FTW_MOUNT 2
+#define FTW_CHDIR 4
+#define FTW_DEPTH 8
+
+struct FTW {
+   int base;
+   int level;
+};
+
+int ftw(const char *, int (*)(const char *, const struct stat *, int), int);
+int nftw(const char *, int (*)(const char *, const struct stat *, int, struct 
FTW *), int, int);
+
+#if defined(_LARGEFILE64_SOURCE) || defined(_GNU_SOURCE)
+#define ftw64 ftw
+#define nftw64 nftw
+#endif
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif
diff --git a/newlib/libc/posix/Makefile.am b/newlib/libc/posix/Makefile.am
index 6cdee1df0..5a358f782 100644
--- a/newlib/libc/posix/Makefile.am
+++ b/newlib/libc/posix/Makefile.am
@@ -10,7 +10,7 @@ GENERAL_SOURCES = \
opendir.c readdir.c readdir_r.c \
regcomp.c regerror.c regexec.c regfree.c \
rewinddir.c sleep.c usleep.c \
-   telldir.c
+   telldir.c ftw.c nftw.c
 
 ELIX_2_SOURCES = \
 scandir.c seekdir.c
diff --git a/newlib/libc/posix/ftw.c b/newlib/libc/posix/ftw.c
new file mode 100644
index 0..c295fa984
--- /dev/null
+++ b/newlib/libc/posix/ftw.c
@@ -0,0 +1,36 @@
+/*
+* Copyright © 2005-2020 Rich Felker, et al.
+*
+* Permission is hereby granted, free of charge, to any person obtaining
+* a copy of this software and associated documentation files (the
+* "Software"), to deal in the Software without restriction, including
+* without limitation the rights to use, copy, modify, merge, publish,
+* distribute, sublicense, and/or sell copies of the Software, and to
+* permit persons to whom the Software is furnished to do so, subject to
+* the following conditions:
+*
+* The above copyright notice and this permission notice shall be
+* included in all copies or substantial portions of the Software.
+*
+* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+* MERCHANTABILITY, FITNESS

RTEMS Specification and Qualification Toolchain Status

2020-07-09 Thread Sebastian Huber


Hello,

in the ongoing ESA activity to produce a pre-qualified subset of RTEMS 
with SMP support (so called "space profile") we had the first part of 
the Detailed Design Review (DDR) this week. This presentation


https://ftp.rtems.org/pub/rtems/people/sebh/rtems-smp-qual-eb-ddr-1-v2.pdf

gives an overview of the current status from the embedded brains point 
of view.


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

RE: [GSoC 2020: Daily Update]: Building EPICS with RTEMS5

RE: libbsd rtems 5 branches

Re: libbsd rtems 5 branches

[PATCH] media-server: Add ability for retry.

[PATCH] lvgl: Update to v7.1.0

GSoC 2020: Location for FreeBSD files in RTEMS

Re: [PATCH] lvgl: Update to v7.1.0

Re: Converting stack address to shared-memory object name

Re: Converting stack address to shared-memory object name

[PATCH rtems-littlevgl] Allow to pass custom lv_conf.h and lv_drv_conf.h.

Re: Converting stack address to shared-memory object name

make error on 5 branch?

Re: Converting stack address to shared-memory object name

Re: [PATCH rtems-littlevgl] Allow to pass custom lv_conf.h and lv_drv_conf.h.

Re: [PATCH] lvgl: Update to v7.1.0

Re: [PATCH rtems-littlevgl] Allow to pass custom lv_conf.h and lv_drv_conf.h.

Re: [PATCH rtems-littlevgl] Allow to pass custom lv_conf.h and lv_drv_conf.h.

Re: [PATCH rtems-littlevgl] Allow to pass custom lv_conf.h and lv_drv_conf.h.

Re: make error on 5 branch?

[PATCH] Test suite for FTW.H methods

[PATCH] ftw.h port for newlib

RTEMS Specification and Qualification Toolchain Status

22 matches

Site Navigation

Mail list logo

Footer information