Re: LVGL applications with mouse
On Sat, Jun 6, 2020 at 4:58 PM Christian Mauderer wrote: > > 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. > Hi Christian, I tried a few times to work out the run-length encoding with lvgl but it's not working quite as expected. I can have a deeper look at it later. The C file I generated with the logo is 282 KB currently, is it too big for the repo? If not, I'd like to make a fresh patch by changing it into a header file and would like to push after a review from the list. If it's big, then I would like to post a patch without any image so that we at least have some example code that uses evdev. We can improve it later when we have time. What do you suggest? Best regards, Vijay > 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: [PATCH RTEMS v2 5/6] libfreebsd: Port OFW to RTEMS
On Sat, Jun 13, 2020 at 11:44 PM Niteesh G. S. wrote:
>
>
>
> On Sat, Jun 13, 2020 at 6:30 PM Vijay Kumar Banerjee wrote:
>>
>> On Thu, Jun 11, 2020 at 5:53 PM 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 | 146 ++-
>> > cpukit/libfreebsd/dev/ofw/openfirm.c | 58 ++-
>> > cpukit/libfreebsd/dev/ofw/openfirm.h | 17
>> > 3 files changed, 219 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
>> > b/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
>> > index e4f72e8142..aba170d67a 100644
>> > --- a/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
>> > +++ b/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
>> > @@ -30,9 +30,12 @@
>> > */
>> >
>> > #include
>> > +#ifndef __rtems__
>> > __FBSDID("$FreeBSD$");
>> > +#endif /* __rtems__ */
>> >
>> > #include
>> > +#ifndef __rtems__
>> > #include
>> > #include
>> > #include
>> > @@ -45,9 +48,20 @@ __FBSDID("$FreeBSD$");
>> > #include
>> > #include
>> > #include
>> > +#endif /* __rtems__ */
>> >
>> > #include "ofw_if.h"
>> >
>> > +#ifdef __rtems__
>> > +#include
>> > +#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 +77,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 +93,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 +120,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 +145,27 @@ 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);
>>
>> Why is it declared here? The function declaration is in fdt.h which is
>> included in the libfdt.h
>
>
> We cannot include a BSP headers from cpukit.
>
The definition of the function is in bsps/shared/start so we're
already using code from the bsps/ here. I wonder if this raises the
question of whether cpukit is the right location for this driver or if
we should use the bsps codes in this driver as a special case?
>>
>> > +static void
>> > +ofw_init(void)
>> > +{
>> > + int rv;
>> > + const void *fdt;
>> > +
>> > + fdt = bsp_fdt_get();
>> > + rv = ofw_fdt_init(NULL, fdt);
>> > +
>> > + /* Fatal if invalid FDT is provided */
>> > + if (rv != 0)
>> > + bsp_fatal(LIBFREEBSD_FATAL_INVALID_FDT);
>> > +}
>> > +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 +336,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 +450,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 +520,104 @@ 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)
>> > +{
>> > +
>> > + return (ofw_fdt_init(ofw_obj, cookie));
>> > +}
>> > +
>> > +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,
Re: LVGL applications with mouse
On 14/06/2020 13:26, Vijay Kumar Banerjee wrote: > On Sat, Jun 6, 2020 at 4:58 PM Christian Mauderer wrote: >> >> 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. >> > Hi Christian, > > I tried a few times to work out the run-length encoding with lvgl but > it's not working quite as expected. I can have a deeper look at it > later. The C file I generated with the logo is 282 KB currently, is it > too big for the repo? If not, I'd like to make a fresh patch by > changing it into a header file and would like to push after a review > from the list. If it's big, then I would like to post a patch without > any image so that we at least have some example code that uses evdev. > We can improve it later when we have time. What do you suggest? Hi Vijay, go on with your patch set. We have other big files too. If soeone else is unhappy too after you send the whole patch set: Shrink the logo to reduce the size. Best regards Christian > > > Best regards, > Vijay >> 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: [PATCH RTEMS v2 5/6] libfreebsd: Port OFW to RTEMS
On 14/06/2020 13:37, Vijay Kumar Banerjee wrote:
> On Sat, Jun 13, 2020 at 11:44 PM Niteesh G. S. wrote:
>>
>>
>>
>> On Sat, Jun 13, 2020 at 6:30 PM Vijay Kumar Banerjee wrote:
>>>
>>> On Thu, Jun 11, 2020 at 5:53 PM 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 | 146 ++-
cpukit/libfreebsd/dev/ofw/openfirm.c | 58 ++-
cpukit/libfreebsd/dev/ofw/openfirm.h | 17
3 files changed, 219 insertions(+), 2 deletions(-)
diff --git a/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
b/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
index e4f72e8142..aba170d67a 100644
--- a/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
+++ b/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
@@ -30,9 +30,12 @@
*/
#include
+#ifndef __rtems__
__FBSDID("$FreeBSD$");
+#endif /* __rtems__ */
#include
+#ifndef __rtems__
#include
#include
#include
@@ -45,9 +48,20 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#endif /* __rtems__ */
#include "ofw_if.h"
+#ifdef __rtems__
+#include
+#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 +77,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 +93,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 +120,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 +145,27 @@ 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);
>>>
>>> Why is it declared here? The function declaration is in fdt.h which is
>>> included in the libfdt.h
>>
>>
>> We cannot include a BSP headers from cpukit.
>>
> The definition of the function is in bsps/shared/start so we're
> already using code from the bsps/ here. I wonder if this raises the
> question of whether cpukit is the right location for this driver or if
> we should use the bsps codes in this driver as a special case?
I wondered about that too. That's why Niteesh moved it in an earlier
patch set. I think Sebastian said that it would be better in cpukit.
But I'm not that happy with the current solution either. That code
wouldn't even link without the bsp_fdt_get function. Is there an
alternative that we could use that would link?
>>>
+static void
+ofw_init(void)
+{
+ int rv;
+ const void *fdt;
+
+ fdt = bsp_fdt_get();
+ rv = ofw_fdt_init(NULL, fdt);
+
+ /* Fatal if invalid FDT is provided */
+ if (rv != 0)
+ bsp_fatal(LIBFREEBSD_FATAL_INVALID_FDT);
+}
+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 +336,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 +450,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 +520,104 @@ ofw_fdt_interpret(ofw_t ofw, const char *cmd, int
nret, cell_t *retvals)
#else
return (0);
#endif
-}
\ No newline at end of f
Re: LVGL applications with mouse
On Sun, Jun 14, 2020 at 5:45 PM Christian Mauderer wrote: > > On 14/06/2020 13:26, Vijay Kumar Banerjee wrote: > > On Sat, Jun 6, 2020 at 4:58 PM Christian Mauderer > > wrote: > >> > >> 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. > >> > > Hi Christian, > > > > I tried a few times to work out the run-length encoding with lvgl but > > it's not working quite as expected. I can have a deeper look at it > > later. The C file I generated with the logo is 282 KB currently, is it > > too big for the repo? If not, I'd like to make a fresh patch by > > changing it into a header file and would like to push after a review > > from the list. If it's big, then I would like to post a patch without > > any image so that we at least have some example code that uses evdev. > > We can improve it later when we have time. What do you suggest? > > Hi Vijay, > > go on with your patch set. We have other big files too. If soeone else > is unhappy too after you send the whole patch set: Shrink the logo to > reduce the size. > Thanks! Sent the patch. :) > Best regards > > Christian > > > > > > > Best regards, > > Vijay > >> 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: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu
I can't find configure in the zip-file (master.zip) which you are loading..
ptpd-master still needs to be reconfigured (autoreconf -vi)
This reconfigure is missing in the cfg file.
It only works the second time and therefore cannot really be used at the
moment.
Unfortunately I don't know why it only works every second time.
So you have to do the reconfigure by hand once (2 times) and then save the
result as tgz
and load it every time you run the build.
You should also compare the %source with the right so that you do not get
confused.
Heinz
E.g.
in rtems-source-builder/rtems
cd sources/
unzip master.zip
cd ptpd-master/
autoreconf -vi -> fails
autoreconf -vi -> ok
cd ..
tar cvzf master.tgz ptpd-master
mv master.tgz $HOME
echo $HOME -> /home/h1
cd ..
vi ../source-builder/config/ptpd-2-1.cfg -> add the new source
sha512sum /home/h1/master.tgz
vi ../source-builder/config/ptpd-2-1.cfg -> add the hash line
../source-builder/sb-set-builder --log log.ptpd.txt
--with-rtems-bsp=xilinx_zynq_a9_qemu --host=arm-rtems5 --prefix
/home/h1/GSOC/RTEMS/5.0.0-m2003 net/ptpd
tail -200 rsb-report-ptpd-master-arm-rtems5-1.txt -> now on a real error ;-)
the ptpd-2-1.cfg
#
# PTPD 2.x.x Version 1.
#
# This configuration file configure's, make's and install's PTPD.
#
%if %{release} == %{nil}
%define release 1
%endif
Name: ptpd-%{ptpd_version}-%{_host}-%{release}
Summary: PTPD is Precision Time Protocol Daemon.
Version: %{ptpd_version}
Release: %{release}
URL: http://ptpd.sourceforge.net/
#
# PTPD Source
#
#%source set ptpd https://github.com/mritunjaysharma394/ptpd/archive/master.zip
%source set ptpd file:///home/h1/master.tgz
%hash sha512 master.tgz
9809119ddac8e98ba871f52a74230d3fc29f87ae7ffd7ece1550f196a13e83a71aaffb3ae94e6c7f334e06d612a6913d2fb070c4db05813b9aaccaa04ca91249
#
# Prepare the source code.
#
%prep
build_top=$(pwd)
source_dir_ptpd="ptpd-%{ptpd_version}"
…
> On 13. Jun 2020, at 23:37, Mritunjay Sharma
> wrote:
>
> First of all Heinz, I would like to thank you for such a wonderful guide
> which really helped me fix a lot of errors.
> After following your advice, I made certain changes to make PTPd work,
> few errors came again but I managed to remove them with the use of Google.
>
> However, the recent most error has caught me in a fix and I am still trying
> to figure it out where I went wrong.
>
> https://github.com/mritunjaysharma394/rtems-source-builder/tree/master/source-builder
> https://github.com/ptpd/ptpd/compare/master...mritunjaysharma394:master
>
> The above two links will tell what changes I have made and the error that I
> am receiving now is:
> "configure: WARNING: unrecognized options: --disable-shared
> configure: error: cannot find install-sh, install.sh, or shtool in build-aux
> "../ptpd-master"/build-aux
> shell cmd failed: /bin/sh -ex
> /home/mritunjay/development/rtems/rsb/rtems/build/ptpd-master-arm-rtems5-1/do-build
> error: building ptpd-master-arm-rtems5-1"
>
>
> I have attached the trace log file and error report.
> I tried to google and made few more changes in ptpd Makefile.am but it didn't
> help.
>
> It will be very kind of you all to help me figure out on how to tackle this
> bug.
>
> Thanks
> Mritunjay
>
> On Sun, Jun 7, 2020 at 10:19 AM junkes wrote:
> 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
Re: [PATCH RTEMS v2 5/6] libfreebsd: Port OFW to RTEMS
On Sun, Jun 14, 2020 at 5:48 PM Christian Mauderer
wrote:
>
>
> On 14/06/2020 13:37, Vijay Kumar Banerjee wrote:
> > On Sat, Jun 13, 2020 at 11:44 PM Niteesh G. S.
> wrote:
> >>
> >>
> >>
> >> On Sat, Jun 13, 2020 at 6:30 PM Vijay Kumar Banerjee
> wrote:
> >>>
> >>> On Thu, Jun 11, 2020 at 5:53 PM 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 | 146
> ++-
> cpukit/libfreebsd/dev/ofw/openfirm.c | 58 ++-
> cpukit/libfreebsd/dev/ofw/openfirm.h | 17
> 3 files changed, 219 insertions(+), 2 deletions(-)
>
> diff --git a/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> b/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> index e4f72e8142..aba170d67a 100644
> --- a/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> +++ b/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> @@ -30,9 +30,12 @@
> */
>
> #include
> +#ifndef __rtems__
> __FBSDID("$FreeBSD$");
> +#endif /* __rtems__ */
>
> #include
> +#ifndef __rtems__
> #include
> #include
> #include
> @@ -45,9 +48,20 @@ __FBSDID("$FreeBSD$");
> #include
> #include
> #include
> +#endif /* __rtems__ */
>
> #include "ofw_if.h"
>
> +#ifdef __rtems__
> +#include
> +#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 +77,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 +93,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 +120,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 +145,27 @@ 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);
> >>>
> >>> Why is it declared here? The function declaration is in fdt.h which is
> >>> included in the libfdt.h
> >>
> >>
> >> We cannot include a BSP headers from cpukit.
> >>
> > The definition of the function is in bsps/shared/start so we're
> > already using code from the bsps/ here. I wonder if this raises the
> > question of whether cpukit is the right location for this driver or if
> > we should use the bsps codes in this driver as a special case?
>
> I wondered about that too. That's why Niteesh moved it in an earlier
> patch set. I think Sebastian said that it would be better in cpukit.
>
> But I'm not that happy with the current solution either. That code
> wouldn't even link without the bsp_fdt_get function. Is there an
> alternative that we could use that would link?
>
Hello Christian,
Sebastian already suggested creating an API to register a device
tree. The main goal of this was to allow unit testing. But then he
mentioned about using wrapper functions to test.
https://lists.rtems.org/pipermail/devel/2020-June/060025.html
I would like to get this patch to a state where this can be pushed
without any changes. The upcoming patches are also libfreebsd
related. If we could finalize this patch we can avoid some
repetitive discussions and will also make it easier for me to create
the next patches.
These are the following points that need to be finalized
1) Where to place the header files? Should they be placed under
cpukit/include/libfreebsd or can we add libfreebsd to the include path?
The latter one will allow us to have same header structure as FreeBSD.
2) How to handle BSP dependencies?
Thanks,
Niteesh.
> >>>
> +static void
> +ofw_init(void)
> +{
> + int rv;
> + const void *fdt;
> +
> + fdt = bsp_fdt_get();
> + rv = ofw_fdt_init(NULL, fdt);
> +
> + /* Fatal if invalid FDT is provided */
> +
GSoC and the RTEMS release
Hello, with GSoC started now and the release still needing some time (*) we start to get a situation: Our GSoC students will add new features and add some files too. I don't assume that we want the new, experimental stuff in the release? Additional to that I think that we will have a switch to the new build system quite quick after the release. Should we start to guide our students to a branch with the new build system already? (*) Please don't get me wrong. I fully understand that the release needs it's time and that nearly all of that time is unfunded and therefore at least twice as valuable. Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC and the RTEMS release
On Sun, Jun 14, 2020, 2:20 PM Christian Mauderer wrote: > Hello, > > with GSoC started now and the release still needing some time (*) we > start to get a situation: > > Our GSoC students will add new features and add some files too. I don't > assume that we want the new, experimental stuff in the release? > I think that's a safe assumption for most of the GSoC projects. Some of Eshan's work should be considered for 5.2. Just bumping newlib in the rsb will pick up his addition of fenv support for a number of architectures. > Additional to that I think that we will have a switch to the new build > system quite quick after the release. Should we start to guide our > students to a branch with the new build system already? > I would tend to lean that way for most of the work. It would be ideal if we could branch 5 soon though. There is an issue where the BSP bsets do not build now. I suspect it is because the configure time probes for methods in libbsd and maybe some threading methods need the default configuration library included to successfully link. I was starting to set up a set of test cases Friday but ran out of time. > (*) Please don't get me wrong. I fully understand that the release needs > it's time and that nearly all of that time is unfunded and therefore at > least twice as valuable. > > Best regards > > Christian > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] build: Do not convert cflags to defines
This makes it possible to use module-specific C flags, for example to
instrument functions (-finstrument-functions).
---
waf_libbsd.py | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/waf_libbsd.py b/waf_libbsd.py
index 14f2ae78..310a6924 100644
--- a/waf_libbsd.py
+++ b/waf_libbsd.py
@@ -452,19 +452,11 @@ class Builder(builder.ModuleManager):
for arch in archs:
if bld.get_env()['RTEMS_ARCH'] == arch:
bld_sources += Builder._sourceList(bld, build[arch])
-if 'cflags' in build:
-bld_defines = [d[2:] for d in build['cflags']]
-else:
-bld_defines = []
-if 'includes' in build:
-bld_includes = build['includes']
-else:
-bld_includes = []
bld.objects(target = target,
features = 'c',
-cflags = cflags,
-includes = sorted(bld_includes) + includes,
-defines = defines + sorted(bld_defines),
+cflags = cflags + sorted(build.get('cflags', [])),
+includes = sorted(build.get('includes', [])) +
includes,
+defines = defines,
source = bld_sources)
libbsd_use += [target]
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
